MVI pattern

[hardikm9850]

MVI - view(model(intent()))

Architecture Layers View — The view layer observes user actions and system events. As a result, it sets the intention for the triggered event. Also, it listens and reacts to the change in state of the model.

Model — A model is a representation of the view state. It contains all the information necessary to render the view correctly.

Intent — A representation of a future action that changes the state of the model.

User* — He or she observes and reacts to view state changes by playing with the application

https://hannesdorfmann.com/android/mosby3-mvi-2/

https://betterprogramming.pub/all-you-need-for-mvi-is-kotlin-how-to-reduce-without-reducer-5e986856610f

https://medium.com/amsterdam-standard/modern-android-architecture-with-mvi-design-pattern-417c4ee79045

[hardikm9850]

graph LR
    A[View] -->|User Actions| B[Intent]
    B -->|Processed| C[Model]
    C -->|New State| D[View Model / Presenter]
    D -->|Update| A

1. Data Flow Direction: The unidirectional flow in MVI is about how data and state changes propagate through the system, not about where actions originate. The flow goes: Intent → Model → View, without backward data flow.

2. View as Input/Output: The view serves dual roles - it's both the source of user actions and the destination of state updates. However, these are separate processes in the MVI cycle.

3. Separation of Concerns: User actions from the view are immediately converted into Intents. The view doesn't directly modify the state or model.

4. No Direct View-to-Model Updates: Unlike in some implementations of MVVM where the view might directly update the ViewModel, in MVI the view never directly updates the model or state.

5. State as Single Source of Truth: All view updates come from the model's state changes, not from direct manipulation by user actions.

6. Cycle Nature: While the user actions do originate from the view, they're the start of a new cycle, not a "backwards" flow in the existing cycle.

The key point is that while actions originate in the view, they don't directly cause state changes. Instead, they're translated into Intents, which are then processed to produce new states. This maintains the unidirectional flow of data and state changes.

So, a more accurate representation of the flow might be:

(View: User Actions) → Intents → Model (State) → View (Render) → (View: User Actions) ...

Each cycle is unidirectional, even though the overall process is cyclical. This approach helps maintain predictability and easier debugging, as each state change is a result of a well-defined Intent, regardless of where that Intent originated.