Згідно з LinkedIn, розробка мобільних застосунків на Flutter є найшвидше зростаючою навичкою серед розробників, а також за даними опитування StackOverflow про найулюбленіші інші фреймворки, бібліотеки та інструменти — вона входить до трійки найулюбленіших фреймворків у 2019 році. Ми також не залишилися осторонь і не лише вирішили спробувати опанувати новий продукт, але навіть змогли реалізувати проект і відправити його в продакшн!
По-перше, слід зазначити, що наша компанія займалася лише нативною розробкою. Інтерес до крос-розробки був лише навчальним, і ми не наважувалися використовувати його в комерційних проектах.
(Примітка редактора: через відсутність розширеної експертизи, думка, викладена нижче, не може вважатися абсолютною істиною.)
Проте, наша Android-команда була зацікавлена в тому, що компанія, яка розробляє нашу улюблену мобільну ОС, запропонувала власне рішення. Це означало, що ми не могли не спробувати його. Крім того, опановувати його з досвідом нативної розробки було досить безболісно, тоді як нашим конкурентам було інакше.
Отже, що цікавого пропонує Flutter разом з іншими фреймворками? Перше, чим він дійсно може похвалитися, це побудова UI. Завдяки власному движку рендерингу, який рендерить всі елементи без використання інструментів, вбудованих в SDK ОС, продуктивність помітно зростає.
Іншими словами, замість того, щоб інтерпретувати код умовної кнопки у нативний код для кожної платформи (як це роблять інші фреймворки), фреймворк Flutter бере на себе амбіційну задачу рендерити все, точно імітуючи поведінку нативних елементів інтерфейсу (з урахуванням анімацій, стану тощо). Це значно збільшує швидкість рендерингу в порівнянні з іншими підходами, а також дозволяє створювати дійсно складні екрани без зниження FPS. Крім того, коробкове рішення надає багато готових до використання UI-елементів з рекомендацій як Material Design, так і iOS, які можна майже повністю налаштувати під ваші потреби.
Також слід зазначити, що використовується підхід до дизайну реактивного UI, в результаті чого весь застосунок будується у вигляді дерева так званих «віджетів», що спрощує управління станом не лише одного екрана, але й застосунку в цілому.
Ще одним безумовним плюсом є робота з анімаціями Flutter. Просте перетворення можна здійснити всього за кілька рядків коду завдяки спеціальним віджетам для анімації змін розміщення, а згаданий вище реактивний підхід робить їх використання ще зручнішим:
Таким чином, Flutter стає ідеальним інструментом для створення графічного інтерфейсу одночасно на обох популярних платформах. Але жоден застосунок не може обійтися лише хорошим дизайном, він також повинен містити бізнес-логіку.
Архітектурні патерни «реактивного» типу використовуються на повну потужність у Flutter Redux, Scoped Model, BLoC та інших. Загалом, тут немає проблем. Однак, ми обрали BLoC, який є більш традиційним для спільноти. Це дозволило нам без проблем застосувати підхід Clean Architecture. Таким чином, ми відокремили код дизайну додатку від його бізнес-логіки (що дуже корисно для крос-платформного проєкту). У плані роботи з мережею все досить добре — пропонується кілька бібліотек для роботи з Http, і наш вибір впав на Dio серед них. До речі, вона дуже нагадує Retrofit2, який є загальноприйнятим у спільноті Android. Також є бібліотеки для зберігання системних даних додатку (Shared Preferences в Android, NSUserDefaults в iOS).
Для бізнес-даних є порт SQLite (звісно, це не Realm чи Room, але принаймні щось). Є мости для використання камери, GPS та багато іншого.
Однак, наразі ми не наважимося назвати цю роботу стабільною та готовою до використання в продуктивному середовищі. Наприклад, ми стикнулися з проблемою, коли OOM трапляється під час запису відео на iOS, іноді перші кілька кадрів просто чорні. Також, через те, що фреймворк досить молодий, поки що немає широкого вибору бібліотек.
Слід також звернути увагу на кількість проблем в репозиторії на Github:
Звісно, це не єдині недоліки Flutter. Вони характерні для всіх крос-платформних рішень:
- Необхідність писати нативний код не зникла (так звані мости), оскільки необхідної бібліотеки часто не вистачає або їй бракує функціональності. Сценарій може бути навіть більш песимістичним: все працює належним чином, але потрібно додати доповнення, яке не передбачене рішенням. В результаті, вам доводиться створювати власне рішення за рахунок часу.
- Затримки в адаптації додатків до нових версій ОС. Свіжий приклад — колір панелі в iOS 13. Минув місяць після випуску операційної системи, однак жодної офіційної версії ще не надано.
- Більше проблем з непопулярними виробниками пристроїв (пов'язано з Android).
- Дуже уважний користувач все ще може помітити відмінності від нативної поведінки (анімція Ripple, яка відображається, коли користувач натискає на клікабельні елементи списку, картки або фон у Flutter, помітно відрізняється).
- Розробник абсолютно безсилий, якщо помилка закралася в саму систему.
На завершення:
Якщо вам потрібен прототип для тестування бізнес-ідеї, і логіка не передбачає «вичавлювання всіх соків» з можливостей пристрою, додаток має досить просту логіку (типова взаємодія клієнт-сервер), але має нестандартний дизайн — тоді Flutter є відмінним вибором. Ви отримаєте єдину базу коду, простоту змін та відмінну швидкість відгуку. Однак варто зазначити, що ускладнення таких продуктів призведе до більших витрат і часу в порівнянні з розробкою додатків для кожної ОС окремо.
Для складних рішень, які потребують взаємодії з різними модулями пристроїв, все ж слід обирати нативну розробку.
