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.
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.
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
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
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.