A robust MVI implementation with Jetpack Compose

Photo by Rivage on Unsplash

Why am I doing this?

I’ve been working to develop a robust architecture, with a small learning curve and recognizable to all developers.

The aim was to have something project-agnostic. Simply put, we wanted all developers to be comfortable with the architecture, so that they could more easily contribute to other projects (that they may or may not know in detail), if and when needed.

Building an architecture takes time. I’ve spent most of that time learning about the Android ecosystem and its best practices, as well as transition from previous recommendations to new ones such as:

• Recommendation of ViewBinding over DataBinding
• Transition from XML to Jetpack Compose
• Appearance of MVI
• Stable release of KMP

How am I going to do it?

Before writing a single line of code, we need to do a certain number of things to make sure we don’t head in too many different directions:

• Grab a good cup of <insert preferred beverage>
• Research what MVI actually is
• Define the target behaviour
• Code the actual implementation
• Test the result in a real example

For the sake of simplicity, I’ll avoid explaining how to “Grab a good cup of” anything and assume you all know how to do so

Research phase

Although I assume you all know what MVI stands for (or you’ve somehow managed to avoid it so far), I’ll briefly catch everyone up to speed.

MVI stands for Model-View-Intent. This architecture is part of the MV* family along with MVVM and others. The core principle behind it is a state machine that takes input Intents, and produces a View State representing the underlying UI. With all this, MVI respects the SSoT (Single Source of Truth) principle unlike its older brother MVVM.

MVI as a function. Credit to Hannes Dorfmann

Target behaviour

First things first, we need a screen that will serve as the foundation for our implementation. We’re going to be using the Now In Android application for this (that you can find here) which looks like the following:

Now In Android screenshots

For the sake of simplicity, we’ll focus solely on the first screenshot (the ForYouScreen) which has various different pieces of data to display and interact with.

We now need to explain a core concept of MVI, the Reducer! A Reducer is, in some sense, a contract between the UI and the ViewModel. It is split into two parts:

• The object interfaces : State, Event and Effect
• The reduce function (not to be mistaken with the mathematical reduce operator)

ViewState

This is a representation of the UI. In theory, this should contain everything the Compose screen needs to display. This has the added benefit of making it super easy to create multiple previews which each represent a different state of the screen.

ViewEvent

This is the core of the MVI as it holds all the user interactions (and a bit more). This is what will be used by the ViewModel to trigger state changes.

ViewEffect

This is a special kind of ViewEvent. Its role is to be fired into the UI by the ViewModel. Actions such as Navigation or displaying a Snackbar/Toast.

It can also be triggered as a response to a ViewEvent (Updating something then navigating to a Success or Error screen based on the result).

reduce function

The reduce function takes a ViewState and a ViewEvent and produces a new ViewState and optionally a ViewEffect linked to the provided event.

Now we have the Reducer, we need to define our BaseViewModel that will be implemented by all our ViewModels:

For more information on the TimeCapsule, check out this article.

Implementation

Now we have the base structure set up and available, it’s now time to actually implement these for our screen!

Reducer

We’ll start by defining our ViewState, allowing us to identify some of our events easily.

For more information on the Immutable annotation, check out this article.

Now we have the ViewState, we can define the ViewEvent to handle the user interactions and update the state accordingly.

I consider the above to be self-explanatory alongside the ViewState. The last 3 events, however, may not be.

They are linked to the clickable elements on the screen in the following manner:

• UpdateTopicIsFollowed is associated to the elements in the Green outline
• UpdateNewsIsSaved is associated to the element in the Orange outline
• UpdateNewsIsViewed is associated to the element in the Purple outline

Now we need to define the final part of the MVI architecture, the ViewEffect! Luckily for us, on this screen, it’s relatively simple as we only have two possible effects.

Finally, we have the reduce function to implement. In most cases, the reduce function will be very simple and map the input ViewEvent data to a modified ViewState.

One important thing to note here (specifically for the last 3 ViewEvent cases) is that in a real production application, you would very rarely modify the actual data being displayed directly in the Reducer.

The follow-up article which builds upon this one and talks about the architecture in terms of APIs (the Data and Domain layers in Clean Architecture) can be found further down.

ViewModel

Now we have our Reducer, we also need to use it in a ViewModel which looks like the following:

You will notice that our ViewModel contains very little code and this is thanks to the use of our BaseViewModel which contains the main functions we will use.

Screen

Finally, we can plug all of this into our screen and see how simple it is to handle the different cases we can have in our UI.

Going that extra step

For those that want to go the extra step, you can find my article that builds upon this one in terms of network and business logic at the link below:

Correctly combining APIs with Business logic

That’s all folks!

With everything we have done, we now have a fully defined MVI Architecture that takes advantage of respecting the SSoT principle and also a ViewState that directly represents the UI!

Some of you may still be wondering why I went through all this R&D when existing architectures have been tried and tested and have been proven to work. Well, simply put, because I needed to. I work on multiple projects, under various project managers, with a number of other developers.

Being the Lead Developer on these projects means I am often required to spend time reviewing PRs (Or MRs for you GitLab users). I often have to direct comments to small architectural mistakes that could be avoided with a greater knowledge of said architecture.

Hence, imagining an architecture that is compatible with all the projects I work on and also known and recognised by my colleagues, makes the overall review process faster and easier for all parties involved and speeds up the overall development!

You can find the full project on GitHub at the following link:

GitHub - worldline/Compose-MVI at MVI

There are many other great articles that cover MVI, here are a few if you’re interested:

Migrate from MVVM to MVI

Android: Simple MVI implementation with Jetpack Compose

The above article explains the use of the TimeCapsule in this implementation and is where this was discovered

MVI Architecture With Android