Android Architectures: MVI vs. Viper

Posted: 12 Jul 2021. Last modified on 27-May-22.

This article will take about 4 minutes to read.

The State Problem

Stateful code can cause subtle problems, especially on large teams.

It’s hard to reason about things which can change while we are reasoning about them. 1

If the data is immutable you need to know:

what it means,
where it was first assigned,
and how it is used here.

If the data is mutable you need to know

what it means,
where it was first assigned,
where it can be changed,
when it can be changed,
if those changes can happen concurrently and require locks,
what sequence those locks need to be acquired in,
if changing the data needs coordination with other teams,
if it has been changed before,
and how it is used here.

There is much more to keep track of! Concurrency is another reason why immutable data structures are great.

MVI

While MVI stands for Model, View, Intent, I prefer to call it Model, View, Intention to decrese confusion when talking about it in an Android context (Intent is a common Android class).

Before talking about that MVI is, it is worth it to discuss the alternatives.

MVC, MVP, MVVM

All of these architectures serve a common purpose:

Separation of concerns, to reduce code duplication
Increasingly testable code, which keeps the bugs at bay
Standardized structure, which allows teams to collaborate more effectively

It takes a lot of effort to bring an entire team on board with an architecture. If we are happy with our codebase and its test coverage, why do we need to try a new architecture?

MVI can be applied on top of existing patterns.

We don’t have to change the style that we’ve already adopted

we can modify our existing style to take advantage of the reactive flow
we can work towards achieving better state management.

Some things that you can do to work towards a more MVI architecture:

Enforced immutablity, using val in datamodels
Observing the view as a stream of user events

Pros of MVI

It’s functional!

Reactive programming is functional programming in disguises
It comes with all of the benefits of functional programming

It can be easy to add new user actions and components

with kotlin’s sealed classes and when statements, the compiler makes sure that we’ve covered all of our bases.
Adding in a new view event is as easy as adding another event stream to the view stream.

Reactive programming allows for cleaner, less verbose code

reduced verbosity mitigates human erros = incremental changes to features can be done in less time, for devs with reactive experience

Reduced coupling allows for tons of code reuse

anything that can accept a specific event can react to it

Cons of MVI

It’s heavily dependent on Rx

RxJava/ RxKotlin have a steep learning curve
A non-beginner level knowledge of Rx is required to get started.

There are lots of small objects being generated and thrown around

It can be hard to keep track of what each type of object is
discipline is required when naming files, or it can be difficult to tell them apart.

Changes and modifications may take more time than when done impreatively

Developers need to code mroe deliberately - but this may also decrease the number of bugs.

Pure MVI

How does this measure up against an architecture like VIPER?

VIPER is attempting to do the same thing in a very similar way.

One common deviation that MVI takes is the concept of a reducer.

Reducers take in

a stream of Results which are generated in the Interactor (Intention)
based on the (view) Events which are streaming into that Interactor, and
generate an Immutable State object (Model), which represents the whole of the view in question.

Reducers can keep a reference to the previous State, so that unchanged values can be passed along to the new State.

Keeping all of the State of a screen in one place is a good idea for simple screens, but it’s harder to maintain in an invironment where each view can have its own DataModel.