Нетворкінг у Flutter додатках — про просте і складне на прикладі Tide. Частина 0: вступ

Усі статті, обговорення, новини про Mobile — в одному місці. Підписуйтеся на телеграм-канал!

Привіт! Я Анна — експертка з мобільної розробки, GDE з Dart та Flutter, досвідчена розробниця мобільних додатків на Flutter.

Більшість додатків, чи то мобільні, чи то веб, чи десктоп, залежать від того чи іншого бекенда. Отже, імплементація комунікації з API є невід’ємною частиною реалізації додатку. У цій серії з шести частин представлені інструменти та підходи, які полегшують розробку комунікації з API у Flutter додатках, які ми використовуємо в Tide.

Обіцяю, буде корисно і цікаво розробникам будь-якого рівня!

Read in English

У цій серії поговоримо про:

Задля розваги використаємо Marvel Comic API і створимо додаток на Flutter, який відображає список Marvel коміксів.

В процесі розробки розберемо різні типові і нетипові задачі, які постають при необхідності комунікації додатку з бекендом, у проектах різного розміру.

Знання з кожної частини можна застосовувати окремо, але разом вони доповнюють одна одну і утворюють повноцінну реалізацію рівня API у Flutter додатках.

Для нетерплячих, GitHub репозиторій Flutter Advanced Networking містить повний приклад коду.

Якщо більше довподоби відео-контент, обов’язково подивіться мою доповідь «Basic and advanced networking in Dart and Flutter — the Tide way» на Flutter Global Summit’22.

Генерування коду з build_runner

Ми в Tide в значній мірі покладаємося на механізм генерування коду за допомогою build_runner для вирішення багатьох задач: інверсія залежностей, навігація, локалізація, реалізація моделей і API запитів, і навіть тести. Наступні частини серії активно використовують цей механізм, отже розберемо основні повʼязані з цим моменти.

Знову ж таки, якщо більше довподоби відео-контент, раджу подивись мій виступ «Code less, deliver more» на The Flutteristas Conference.

build_runner — це особливий пакет, який забезпечує механізм функціонування кодогенеруючих пакетів. Він мусить бути частиною dev залежностей проекту у pubspec.yaml:

Після цього, будь-який інший пакет з залежностей може інформувати build_runner, що він є кодогенеруючим. В цьому прикладі такими пакетами є freezed та json_serializable. Ми ближче познайомимось з тим, як їх конфігурувати, та який код генерують ці пакети, в першій частині серії. Коли розробники запускають цю команду у терміналі:

build_runner запускає процес генерування, звертаючись до кодогенеруючих залежностей, і у вашому пакеті можуть зʼявитися нові файли на основі конфігурації, зазначеної у коді. Якщо вас цікавлять деталі того, що відбувається «під капотом», або вабить тема написання власних кодогенеруючих пакетів, рекомендую виступ «Create your own Code-Generating Package» з конференції Flutter Vikings Online Feb’22.

До речі, параметр build означає, що код буде згенеровано один раз, і команда завершить виконання. Замість нього, є можливість використовувати параметр watch, що означатиме постійний трекінг змін у файловій системі і регенерацію коду за потреби з кожною зміною. При активній розробці, ми зазвичай використовуємо саме параметр watch.

В налаштуваннях свого терміналу я створила аліаси flbrb (від flutter ... build_runner build ...) і flbrw (від flutter ... build_runner watch ...) для швидкого перезапуску команд генерування коду після оновлення списку залежностей у pubspec.yaml.

Існують протилежні погляди на те, чи варто додавати згенеровані файли у git. Адже важливою є тільки інформація у файлах з конфігурацією, а згенеровані файли завжди можна відтворити, запустивши команду генерування коду у кожному пакеті проекту. Спираючись на власний досвід, я твердо переконана, що це варто робити. З багатьох причин:

  • Помилки в коді. Файли з конфігурацією для майбутнього згенерованого коду тим чи іншим чином використовують цей майбутній код. А отже, якщо нові згенеровані файли не додати в git, проект у репозиторії матиме помилки компіляції.
  • Час на білд. Для того, щоб запустити додаток на новій машині, окрім завантаження самого проекту, через помилки в коді, існуватиме потреба в додаткових маніпуляціях для геренування коду, що бракує. Звісно, якщо в проекті один-два пакети — додаткові 30-60 секунд не є проблемою. Однак, на масштабах ентерпрайз проекту з 150+ пакетами, накшталт тих, що розробляє наша команда, це займає додаткові 40-60 хвилин. Це додатковий час на обробку кожного PR і білда на CI.
  • Робота в команді. При відсутності згенерованих файлів у git, проблема необхідності додаткових маніпуляцій з кодом проявляється не лише на CI. Під час розробки або перед відкриттям нового PR команда забирає свіжий код з main у свої бранчі. Оскільки щойно завантажений код може містити оновлені конфігурації для згенерованого коду, а локально згенерований код відповідає старим конфігураціям, це може призводити або до помилок компіляції, або до непередбачуваної поведінки додатку. Отже існує потреба перегенеровувати код локально, що означає ті ж самі витрати часу, що й на CI, але помножені на кількість розробників у команді, і ще на кількість оновлень з main на день або тиждень.

Отже, тепер ми готові зануритись у деталі реалізації рівня API у Flutter додатках, які ми використовуємо в Tide.

Продовження у Частині 1: моделі даних з freezed та json_serializable. Про просте.

Пссс... Ми наймаємо!

Tide є провідним провайдером банківських рахунків для малого та середнього бізнесу та однією з найбільш швидкозростаючих фін-тех компаній у Великобританії. Ми трансформуємо ринок бізнес-банкінгу, надаючи смарт-рахунок, і повертаємо власникам бізнесу їх час назад.

У Tide ми розробляємо мобільні додатки для Android та iOS за допомогою Flutter. В нашій команді понад 30 мобільних розробників, проте ми маємо на меті розширення. На нашому сайті можна знайти вакансії для Flutter розробників у різних країнах, в тому числі й віддаленно в Україні.

👍ПодобаєтьсяСподобалось3
До обраногоВ обраному3
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Підписатись на коментарі