When I think about MVI, the process boils down to three key concepts:
- A unidirectional cycle of data — i.e. data flows in one direction
- Processing of intents is non-blocking
- The state is immutable — outside of the Model (typically a ViewModel on Android)
Conceptually MVI is not complicated, so why use a framework when you can write your own? Watch How to write your own MVI system and why you shouldn’t, which demonstrates how to write a framework in less than 30 lines of code.
Writing an MVI style framework is not as simple as it seems:
- there are lifecycle concerns from saving state for device rotation and process death to handling side effect caching
- potential for multithreading issues
- necessary to write tests for your framework along with its multi-threaded code
- support for advanced features such as idling resource support for Espresso tests, logging, time-travel debugging and screenshot and interaction testing support
- multi-platform support
Until recently, I’d never taken the time to fully reflect on the market of MVI libraries for Android to see if what Orbit does still makes sense and what we can do to improve it.
This article attempts to address that by adding scores to the following table for the most popular MVI libraries.
Evaluating MVI libraries
When evaluating MVI libraries, there are a few things I consider important, and I’ve used this list to help me judge the main set…