Приложение задач с пакетами ArkTelos

Здесь мы проследим одну работающую функцию: загрузить задачи, добавить задачу и открыть экран подробностей. Пример показывает, как пакеты соединяются на границе приложения, не заставляя каждый пакет зависеть от остальных. Полный исходный код и проект для запуска опубликованы вместе с ark_mvp_flutter 1.2.0.

1. Запустите приложение

Склонируйте репозиторий ark_mvp_flutter на теге v1.2.0 и выполните команды из директории example/app:

flutter pub get
flutter run -d chrome -t ../ecosystem_integration.dart

Если Chrome недоступен, используйте flutter run -d web-server -t ../ecosystem_integration.dart и откройте адрес, напечатанный Flutter. Не открывайте web/index.html через file://: Flutter должен собрать и обслуживать приложение. Проект получает опубликованные пакеты 1.2.0; локальные подмены путей не нужны.

На экране появятся начальная задача, кнопка Add task и строка диагностики. Добавьте задачу, затем выберите строку, чтобы перейти на /tasks/:id. Команда flutter test test/ecosystem_integration_test.dart из корня репозитория проверяет тот же сценарий в виджетном тесте.

2. Спрячьте хранение за Repository

MemoryTaskDataSource хранит записи для примера. TaskRepository получает источник через DataSourceContainer, читает или добавляет записи и сохраняет неизменяемый TaskData. DataSource отвечает за операции хранения; Repository — за текущие бизнес-данные и поток их изменений. Замена памяти на HTTP- или DB-адаптер не требует менять экран.

3. Соберите зависимости в корне приложения

Ark DI регистрирует DataSource, Repository и TaskUseCase. Корень получает UseCase и создаёт стабильный ModelBinding<TaskModel>. Он читает текущий UseCaseSnapshot и открывает одно именованное действие addTask, но не передаёт объект UseCase в Presenter. Виджеты получают binding напрямую, без глобального сервис-локатора.

TaskUseCase обрабатывает LoadTasks и AddTask. Обработчики вызывают Repository и публикуют TaskState. Здесь же находились бы правила конкурентного выполнения и отмены, если бы функции понадобилось больше, чем в этом простом примере.

4. Подготовьте данные для каждого View

TaskPresenter превращает снимок TaskModel в строки задач и признак занятости. TaskDetailPresenter готовит заголовок выбранной задачи. MvpView владеет каждым Presenter и вызывает builder с готовым к показу ViewState; View не разбирает данные Repository и не подписывается на UseCase самостоятельно.

Ark Navigation связывает типизированные TaskListDestination и TaskDetailDestination с / и /tasks/:id. Выбор строки вызывает явный push с типизированным Destination. При прямом открытии страницы подробностей план стека восстанавливает под ней список.

5. Наблюдайте и завершайте без утечки бизнес-данных

Строка диагностики считает регистрации DI, изменения Repository, события выполнения UseCase, события Presenter и шаги навигации. Эти необязательные сигналы 1.2.0 несут технические сведения, но не названия задач. Ark Error Manager находится в корне приложения для необработанных ошибок и ошибок границы представления; классы функции от него не зависят.

При удалении хоста приложение закрывает навигацию, затем принадлежащие DI UseCase и Repository, после них — отдельно принадлежащие DataSource и Error Manager. В руководстве к примеру разобраны четыре способа композиции и правила владения.