Application Coordinator

Давайте по порядку — почему именно AppCoordinator?

Для одной задачки мне нужно реализовать несколько экранов с общим состоянием. Я начала перебирать варианты решения: создавать архитектуру на основе BLoC я уже пробовала, получалось громоздко. Пробовала и GetX — это мини-фреймворк, который не даст мне глубокого понимания Flutter. Да и критики в его сторону больно много.

Определённо стоило копать глубже — в сторону архитектурных паттернов, а не в сторону библиотек.

В чём идея?

Идея подхода Application Coordinator в создании отдельной сущности — Coordinator, которая отвечает за флоу приложения. Coordinator инкапсулирует часть приложения и ничего не знает о своем родителе, но может запускать свои дочерние Coordinator-элементы.

Почему я не выбрала MVC или MVVM?

Скажу сразу, я не ставлю себя в позицию эксперта. Это лишь мой субъективный опыт.

Обычно эти архитектурные паттерны описывают поведение одного экрана, но не нескольких. Более того, они не описывают взаимодействие нескольких экранов и, возможно, их общего состояния.

AppCoordinator стоит на один абстрактный уровень выше — он решает проблему переходов между модулями экранов и передачи данных между ними. Отвязываясь через определение программного интерфейса экрана от конкретных реализаций экранов, он позволяет заменять их.

Получается, что возможно использовать оба паттерна: и AppCoordinator, и другой архитектурный паттерн, который описывает поведение одного экрана.

Всё это звучит хорошо. А реализовать как?

Вот один из вариантов: создаём класс состояния, пихаем его в ValueNotifier, прокидываем его в экран и через координатор меняем состояние. В этом случае экран перерисуется, если изменить состояние в координаторе.

А как ещё можно?

Я сделала небольшой публичный репозиторий с примером использования — в нём показаны последовательные экраны. Здесь в экраны передаётся объект состояния, но в случае более сложной логики можно передать ValueNotifier с объектом состояния внутри.