Sign in Go Pro

Android MVI Pattern

Hooking up Retrofit

This lesson is for PRO members.

Upgrade today to get access to all the PRO lessons.

Unlock this lesson



So far, we've done everything in memory only. This lesson will show you how you can hook up with external asynchronous APIs, using Retrofit.


This course was pure gold. It was filled with awesome tips and tricks. I learned a lot. Thank you very much. I really liked your teaching style and the video production. Could you highlight some negatives with MVI? Thanks

Thank you, I'm really happy you found the material helpful. :)

When thinking about architectures in general, I tend to think of it less in terms of pros-and-cons, and more in terms of "gotchas".

MVI uses still fairly novel programming patterns. Reactive programming, unidirectional data flow, and functional principles. Those patterns bring to the table a lot of desirable things. But, by being relatively "new", they bring some risks to the table.

How much experience does a team have with those new concepts? How motived are folks to learn new things? How much legacy code are you dealing with? Is this a greenfield app? Architecture choices by nature will involve teams of individuals.

The number one gotcha on my list is adoption. But to be fair, that gotcha applies to MVVM as well as MVI. MVI is more niche, so in my opinion, a team adopting it needs to be clear on the benefits.

My number two gotcha would have to be regarding state management. I believe a big key to a successful MVI implementation lies with modelling state in a very clear, deliberate manner. That means taking the time to model your state transitions, and when appropriate taking the time to modeling a full-fledged state machine.

Not doing this could lead to inconsistent state creeping into your model, which again, is a problem not exclusive to MVI.

Thanks for sharing!

Could you answer: how would you handle situations like initial item load? Say, I want the app to load items from the server right after the fragment is shown? Would you issue an intent and, if so, what is responsible for that?

There are a few options there. It depends on what you're exactly aiming for.

The key is to have "one-time" signals for your state transitions. What I mean by that is, you'll want to avoid starting to emit viewEvents every time onCreate() or onResume() is called. Anything that's linked to configuration changes is basically going to cause problems.

If you look in the sample code, those kinds of "transitions" are always managed at the "source". When we start editing a Task, for example, we do it from the moment the user triggers "edit-task", when they click on an item in the list. We trigger a "clearing" of the edit state when the user presses cancel or back on the toolbar.

If we'd be trying to load the list of Tasks right off the bat, we'd usually do that as part of the app-initialization sequence. Meaning, a trigger to load the current TODOs (from network or from disk, or disk then network) could be triggered from our App class itself, in the background.

You need to go PRO to post comments.

Lessons in Android MVI Pattern