Stateful Android Apps With MVI (MODEL — VIEW — INTENT)
There are a lot of architecture pattern (like MVC, MVP, MVVM) for android but today we will talk about MVI.
I will walk you through,
- What is MVI architecture?
- How does the MVI work?
- Advantages and Disadvantages of MVI
- Creating a Project with MVI architecture
What is MVI architecture?
MVI is a Reactive Architecture Pattern which is short for Model -View-Intent. It introduces two new concepts: the intent and the state. UI might have different states — Loading State, Fetch Data State, Error State, User button submit state etc.
Consequently, we can say that the following three functions create the main components of MVI architecture:
- Model represents the state (data display after fetch, user interaction with any button, loading states during fetch the data) of the UI . Creating new states for each situation. Our View renders everything that the model/state contains. Every time a new immutable model is created which is then observed by the view. Our model object, which tells View what to display on the screen.
- View is represented by an interface which defines a set of user actions (intents) as Observables and a
render(ViewState)method.view()is a function that takes a new state and defines the display logic inside of it.
- Intent is not
android.content.Intent :).The intent simply describes an intention. We will be sending models as action to the Intents which can load or show it through Views. This function takes the input or action, or command generated by the user (i.e. UI events, like click events) and translate it to “something” that will be passed as parameter to model() function.
How does it work?
In Model-View-Intent architecture, view exposes view-events (user input/action) and observes model for view-state changes. We process view-events and convert them into respective intent and pass it to the model. The model layer creates a new immutable view-state using intent and previous view-state. So, this way it follows the Unidirectional Data Flow principle i.e. data flows only in one direction: View > Intent > Model > View.
The user interacts with the UI like User hits any button on the screen which can also be called User’s Intention to interaction the screen. This Intent brings about change in State of the screen. This change can occur via any kind of background logic, but the most important thing is that any change in this state has to happen only by firing an Intent. This new State is rendered on View and this newly updated View is shown to the User.
Advantages and Disadvantages of MVI
Generally, MVI gives more guarantees about what happens in the app because changing state happens in a single transaction at a time (usually through copy method of state data class).
This architecture really forces you to think about how you model the users interactions and the possible states of the View, and this can be highly beneficial.
There’s a lot of separation at every step, and this makes every part extremely easy to test. Mappings from Intent to Action, the Reducer logic, the Processor… all of these components have very few, tightly defined responsibilities and that makes it super easy to write unit tests at every stage. If you’re a TDD sort of person, this architecture lends itself well to that. This also makes MVI extremely predictable.
Conclusion
You can find detail of MVI architecture sample on my github project. I will update it asap.
References:
We will continue with the detail of MVI architecture. Stay with me :)
