Навіть досвідчені розробники стикаються з неочевидними речами: як обрати архітектуру додатку на Flutter

Фреймворк Flutter, напевно, стає найпопулярнішим трендом кросплатформної мобільної розробки, витісняючи з цієї позиції React Native. Кількість проєктів на Flutter постійно зростає, як і кількість розробників, що його вивчають.

Давайте розберемо одне з недооцінених питань опанування цього фреймворку — питання тонкощів вибору архітектури (state management).

Адже досвідчені розробники йдуть до Flutter з досвідом нативної розробки, або з того ж React Native, де стикаються з неочевидними нюансами state management.

А кодери-початківці зазвичай не замислюються про архітектуру зовсім.

«Ти пробував Flutter? — Так. — І чого це тобі коштувало? — Два вечори та два пива»

Що таке архітектура і чому вона важлива

Як загалом влаштований мобільний додаток? Є UI-частина, що бачить користувач на екрані свого смартфона. Є те, що приховано «під капотом» — частина з даними та бізнес-логікою, які необхідні для функціональності програми.

Щоб ви могли замовити в додатку піцу, UI повинен взаємодіяти з даними та логікою через певний контролер, або провайдер. Вибудувати таку взаємодію можна зовсім по-різному.

Отже, архітектура програми, або state management, описує ієрархію цієї взаємодії, характер відносин між рівнями та елементами програми — від фронтенду до бекенду.

Часто архітектуру описують через чотири шари:

• UI;
• provider;
• domain;
Онлайн-курс "React Native Developer" від robot_dreams.
Опануйте кросплатформну розробку на React Native та навчіться створювати повноцінні застосунки для iOS та Android.
Програма курсу і реєстрація
• data.

Архітектура — це умовне поняття. Її можна назвати «кресленням» для проектування софту, а можна і ключовим патерном розробки.

Від state management залежить багато чого:

• швидкість розробки та тестування;
• розширюваність продукту;
• простота підтримки;
• продуктивність застосунку.

Але найголовніше — без архітектури налагодити командну роботу над продуктом дуже складно.

«Якщо ти працюєш не один, а в команді, то ти маєш працювати так, як усі, щоби вся команда розуміла, що відбувається. Плюс, якщо ти не будеш дотримуватись проєктування, то твій проєкт розростеться, стане просто некерованим, ти не зможеш на ньому працювати. Грубо кажучи, ти через місяць відкриєш його і не розумітимеш, що відбувалося, тому що в тебе немає чіткої архітектури», — каже Head of mobile у WEZOM Михайло.

Базовою архітектурою «для всього» можна вважати MVC (Model-View-Controller). Ця логіка написання софту виникла задовго до появи мобільної розробки, але отримала новий імпульс розвитку з приходом фреймворків, націлених на швидке розгортання. Фактично всі відомі архітектури так чи інакше успадковують MVC. Домінуючі стандарти у нативній мобільній розробці — MVM, MVVM, зупинятися на них докладно ми тут не будемо.

Ключова ідея практично всіх архітектур — поділ бізнес-логіки (model), UI-частини (View), і за необхідності — впровадження ланки управління (controller). Це дозволяє модифікувати окремі елементи продукту незалежно.

Чому важливо стежити за архітектурою

Звичайно, ви можете почати писати код без думки про якісь там архітектури, і цей код працюватиме. Якщо йдеться про найпростіший додаток — «Калькулятор калорій», або про MVP, то більшого і не треба.

Але якщо проєкт потрібно буде підтримувати та розширювати (а найчастіше так і є), то така розробка в майбутньому забере у вас чимало часу та нервів.

Продукт без архітектури вкрай незручно розвивати — аж до того, що легше написати новий додаток з нуля.

«Таких кейсів дуже багато. У нас є такий клієнт — спочатку хотів зробити MVP якнайшвидше. Ми все зробили, потім він накидував нам нові фічі та інше. Майже рік із гаком ми робили цей проєкт — доповнювали, розвивали, і так далі. Коли ми зібрали нові вимоги, то зрозуміли, що дописувати ці фічі на старому проєкті занадто дорого, легше написати новий — це просто дешевше. Ми це і зробили», — коментує Head of mobile at WEZOM Михайло.

Часто буває і так, що в одному проєкті можна зустріти ознаки кількох архітектур. Команди розробників згодом змінюються, вимоги до проєкту теж. У таких випадках для перевикористання елементів або реалізації нових фіч для проєкту починають писатися «милиці», що вочевидь не йде йому на користь. Далеко не кожний розробник виявить бажання працювати над підтримкою такого монстра.

Які архітектури є у Flutter

Якщо говорити про Flutter, то в ньому базовою одиницею архітектури можна вважати віджети. Це цеглини, з яких складається користувацький інтерфейс, але вони також формують ієрархію. Кожен віджет вкладений в інший батьківський віджет і може отримувати контекст від нього аж до кореневого контейнера.

У Flutter сьогодні домінують кілька архітектур. Одні виступають як звичайні патерни розробки, тоді як інші вимагають сторонніх бібліотек.

• • Vanilla/Native state. Де-факто відсутність архітектури. Пишемо код начисто, слідуючи офіційному мануалу Google. Поділ моделі та UI тут відсутній, тому перевикористовувати код або масштабувати проєкт буде складно.
  • Scoped Model (Provider). У цій архітектурі бізнес-логіка вже відокремлена від уявлення: є блок model, є віджети інтерфейсу, що взаємодіють з ним. Це дає базові зручності розробки.
  • BLoC (Business Logic Component). У цій архітектурі бізнес-логіка розподіляється на окремі модулі, що спрощує розвиток продукту, особливо на пізніх стадіях.
  • Redux. Ця бібліотека спочатку була створена для JavaScript, різновид Flux. Хоча Redux трохи складніший за інші архітектури, він забезпечує дивовижну простоту тестування функцій. Ще один важливий плюс — опція Time Travel, можливість поетапно відстежити розвиток стану застосунку.
  • GetX. Дуже зручне рішення для управління станом Flutter, по суті є «фреймворком над фреймворком». Але часом йому поки що не вистачає функціональності.

Кожна модель State management має свої плюси та мінуси, які потрібно враховувати та співвідносити з умовами кожного окремо взятого проєкту.

Як ми підбираємо архітектуру для застосунку

Обирати патерн керування станом потрібно виходячи, перш за все, із масштабів проєкту. Чим більший проєкт — тим більш докладна архітектура йому буде потрібна. Призначення програми також накладає свій відбиток на верхньорівневий менеджмент. Скажімо, мобільний месенджер потребує зберігання досить великих обсягів даних, у той час як додатку для рітейлу набагато важливіша швидкість провантаження екранів.

Ми на практиці випробували практично всі популярні архітектурні рішення, зупинившись на BLoC.

Чому він:

1. BLoC рекомендують використовувати з Flutter самі його творці Google.
2. Він дуже зручний для розуміння. Фактично BLoC є інтерпретацію базової MVC-архітектури під особливості Flutter.
3. З BLoC дуже просто виділяти в бізнес-логіці окремі модулі та перевикористовувати їх на власний розсуд.

Основна проблема в роботі з BLoC — високий поріг входу та необхідність писати чимало коду.

У відносно невеликих проєктах така марнотратність часу буває надмірною, тому наші розробники поглядають і на інше популярне рішення GetX. Цей мікрофреймворк не тільки забезпечує state management: у нього є приємні фічі на кшталт зручної навігації та різного синтаксичного цукоруПозначає доповнення синтаксису мови програмування, які не додають нових можливостей, а роблять використання мови програмування зручнішим для людини., який дозволяє вирішувати завдання швидше.

Поради новачкам

Якщо ви лише починаєте вивчати мобільну розробку, то відкладіть питання управління станом на майбутнє. Вам поки що достатньо буде лише загального уявлення про архітектури.

Михайло радить зробити якийсь простий додаток без жодного архітектурного менеджменту повністю з нуля (можна навіть під відео). Потім спробувати зробити на MVC і звичайному Provider. А вже потім спробувати зробити на дефолтному MVM, зрозуміти, що це таке і лише потім перейти до BLoC.

Розуміння state management приходить з практикою та навичками — чим більше ви кодите, тим швидше освоїте цю логіку. Джунам на своїх перших проєктах також не варто переживати — архітектуру вже продумали за них, команда домовляється працювати за патернами того ж BLoC і cтає до роботи.

Фахівці, які взялися за освоєння Flutter після нативної або веброзробки, зазвичай не мають особливих труднощів з тим же BLoC, адже він успадковує базові принципи MVC.

Фахівці з досвідом розробки в React Native часто переходять на Flutter з бекграундом у Flux або Redux, які у спільноті Flutter поступається популярністю тому ж блок BLoC, або Provider. Складність може скласти і мова Dart, яка поки що рідко використовується за межами Flutter. Крім того, у React Native, як і раніше, більш солідний вибір бібліотек.

Пам’ятайте, state management — це не жорсткий набір догматів, у кожному проєкті є місце для творчого пошуку найкращого рішення. Вірте у свою наполегливість і прислухайтеся до команди, це допоможе подолати будь-які складнощі.

Читайте також: Хайп чи революція? Чому ми обираємо писати програми на Flutter