Learn Ark MVP

Ark MVP is a presentation boundary, not an application framework and not a state manager. It begins after the application has created its business objects and ends before a concrete View renders pixels.

Start with the problem

A screen often consumes several pieces of business information but should not know how they are loaded, coordinated, or stored. It needs ready-to-render labels, enabled states, progress flags, public actions, and one-time UI requests. Passing a UseCase, Repository, or application manager directly into the widget makes the View translate business state and couples rendering to the source framework.

Ark MVP inserts one explicit adaptation boundary:

• application composition reads a complete immutable Model from existing business objects;
• Presenter converts that Model and the current presentation environment into ViewState;
• View renders ViewState and invokes named Presenter actions;
• ViewEffect carries one-time work such as a dialog or navigation request.

Model is not another owner of business state. It is a snapshot of exactly what this feature may read and call. Presenter is not a general controller: it owns presentation adaptation and small presentation-local choices only.

The complete flow

application-owned business objects
        ↓ read a complete snapshot
ModelBinding<Model>
        ↓ Model changed
Presenter<Model, ViewState, ViewEffect, Environment>
        ↓ presentation-ready state and actions
View

The direction matters. View never receives Model, a UseCase, Repository, or service. Presenter adapts business information for presentation; it does not become a second business-state container.

Recommended path

1. Architecture assigns responsibility to composition, Model, Presenter, and View.
2. Model and ModelBinding explains complete snapshots and change signals.
3. Presenter covers adaptation, actions, and small presentation-local state.
4. ViewState, View, and ViewEffect separates durable output from one-time UI work.
5. Lifecycle and ownership defines session identity, updates, and teardown.

Continue with Tutorials to see the same contracts applied to one UseCase, several UseCases, and an independent application state manager.

Where a new reader should begin

• Read Architecture if the difference between business state and presentation state is unclear.
• Read Model and ModelBinding before connecting any state manager.
• Build the one UseCase tutorial for the smallest complete Flutter path.
• Use the several UseCases tutorial only when one screen genuinely reads independent business sources.
• Use the application state manager tutorial when UseCase Forge is not part of the feature.