The user interacts with the UI like User hits pull to refresh on the screen which can also be called User’s Intention to refresh 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.

As you can see there is a unidirectional flow of data and none of these components can break this chain and start interacting with each other. This kind of approach restricts any change to the State of the system only via a defined set of actions (intentions). An undefined action by a user cannot cause any undesired change to our System.

That’s all about “What is MVI” which brings us to the end of this first introductory article.

Now, let’s try to learn about “Why MVI” in the next series of blog posts: This series will be divided into two parts:

1. Why MVI?

The first and upcoming part of this series will focus on questions like, What is State (yes I really like (hate) this term), The State Problem and How we can run into these issues by misusing our current patterns like MVP or MVVM.

2. Moving from MVP / MVVM to MVI.

In the second half of the series, We will look into how we can evolve and restrict our current patterns by taking certain goodies and guidelines from the MVI world.

If you are interested, I also gave a talk at Droidcon Boston 2018 regarding this and you can watch it here: