Даже опытные разработчики сталкиваются с неочевидными вещами: как выбрать архитектуру приложения на Flutter

Фреймворк Flutter становится самым популярным трендом кроссплатформенной мобильной разработки, вытесняя с этой позиции React Native. Количество проектов на Flutter постоянно растет, как и количество изучаемых его разработчиков.

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

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

А начинающие кодеры обычно не задумываются об архитектуре совсем.

«Ты пробовал Flutter? – Да. – И чего это тебе стоило? — Два вечера и два пива»

Что такое архитектура и почему она важна

Как в общем устроено мобильное приложение? Есть UI-часть, которую видит пользователь на экране своего смартфона. Есть то, что скрыто под капотом — часть с данными и бизнес-логикой, которые необходимы для функциональности программы.

Чтобы вы могли заказать в приложении пиццу, UI должен взаимодействовать с данными и логикой через определенный контроллер или провайдер. Выстроить такое взаимодействие можно совершенно по-разному.

Итак, архитектура программы или state management описывает иерархию этого взаимодействия, характер отношений между уровнями и элементами программы — от фронтенда до бэкенда.

Часто архитектуру описывают через четыре слоя:

• интерфейс;
• провайдер;
• домен;
• данные.

Архитектура — ​​это условное понятие. Ее можно назвать «чертежом» для проектирования софта, а можно и ключевым паттерном разработки.

От state management зависит многое:

• скорость разработки и тестирования;
Професійний курс від skvot: PR basis.
Засвоєте основи PR та комунікації.
Дізнатись про курс
• расширяемость продукта;
• простота поддержки;
• производительность приложения.

Но самое главное — без архитектуры наладить командную работу над продуктом очень сложно.

«Если ты работаешь не один, а в команде, то ты должен работать так, как все, чтобы вся команда понимала, что происходит. Плюс, если ты не будешь придерживаться проектирования, то твой проект, разрастаясь, станет просто неуправляемым, ты не сможешь на нем работать. Грубо говоря, ты через месяц откроешь его и не будешь понимать, что происходило, потому что у тебя нет четкой архитектуры», — говорит 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 и работает.

Специалисты, взявшиеся за освоение Flutter после нативной или веб-разработки, обычно не испытывают особого труда с тем же BLoC, ведь он наследует базовые принципы MVC.

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

Помните, state management — ​​это не жесткий набор догматов, в каждом проекте есть место для поиска наилучшего решения. Верьте в свое упорство и прислушивайтесь к команде, это поможет преодолеть любые сложности.

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