Build a task app across ArkTelos packages

This tutorial follows one working feature: load tasks, add a task, and open its detail screen. It shows how the packages meet at the application boundary without making each package depend on every other package. The complete source and host project are published with ark_mvp_flutter 1.2.0.

1. Run the app

Clone the ark_mvp_flutter repository at tag v1.2.0, then run these commands from its example/app directory:

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

If Chrome is unavailable, use flutter run -d web-server -t ../ecosystem_integration.dart and open the URL printed by Flutter. Do not open web/index.html with file://: Flutter must compile and serve the entrypoint. The host resolves published 1.2.0 packages; no local path overrides are required.

You should see one initial task, an Add task button, and a diagnostic line. Add a task, then select a row to open /tasks/:id. Run flutter test test/ecosystem_integration_test.dart from the repository root to check the same flow in a widget test.

2. Keep storage behind Repository

MemoryTaskDataSource stores records for this example. TaskRepository obtains it through DataSourceContainer, reads or inserts records, and commits immutable TaskData. The DataSource owns storage operations; the Repository owns the current business data and its observable stream. Replacing the memory source with an HTTP or database adapter does not require changing the screen.

3. Compose once at the application root

Ark DI registers the DataSource, Repository, and TaskUseCase. The root resolves the UseCase and creates a stable ModelBinding<TaskModel>. The binding reads the current UseCaseSnapshot and exposes one named addTask operation; it does not pass the UseCase object to Presenter. Widgets receive the binding directly, not a global service locator.

TaskUseCase handles LoadTasks and AddTask. Its handlers call Repository methods and publish TaskState. This is where command execution and cancellation policy would live if the feature needed more than the simple example.

4. Adapt business state for each View

TaskPresenter turns a TaskModel snapshot into task rows and a busy flag. TaskDetailPresenter prepares the selected task title. MvpView owns each Presenter and invokes its builder with ready-to-render ViewState; View does not interpret Repository data or subscribe to the UseCase itself.

Ark Navigation maps typed TaskListDestination and TaskDetailDestination to / and /tasks/:id. Selecting a row calls an explicit push with a typed destination. A direct detail link reconstructs the list underneath through the route's stack plan.

5. Observe and close without leaking business values

The diagnostic line counts DI registrations, Repository commits, UseCase execution events, Presenter events, and navigation steps. These opt-in 1.2.0 signals carry metadata, not task titles. Ark Error Manager lives at the root for uncaught errors and reported presentation failures; feature classes do not depend on it.

When the host is removed, it disposes navigation, closes DI-owned UseCase and Repository, then separately owned DataSource and Error Manager. Read the example guide for the four composition shapes and exact ownership rules.