This article covers goals #1 and #2. In a future post, I’ll dig into why #4 is true.
I definitely recommend checking out Hannes Dorfmann’s amazing blog series on MVI and Android. I won’t get in to what Model View Intent is, but rather my specific implementation of it.
In a nutshell, we will merge input from our data layer with user input to output a continuously updated
ViewState
over time, rendering each new instance of aViewState
onto ourUi
/View
.
Here’s the simplified implementation ofStateRenderer<DealCardsUi.State>
.
Using Rx’s Schedulers and observing the latest ViewState
, we achieve Goal #2 — stay off the UI thread as much as possible.
All of our Ui
classes have the following function — a single point of entry for displaying information to the user.
fun render(state: ViewState)
Testing is reduced to a simple input/output function.
ViewState
. Grab a reference to your Ui
, and call the ui.render(viewState)
function.Ui
. Use Espresso to verify the Ui
looks as expected.Want to test configuration changes? Call activity.recreate()
and verify the output is unchanged again.
Meet the following requirements to simplify testing.
Presenter
from activating during testing, and/or disable your disk/network layer.Activity
, Fragment
, ViewGroup
, Controller
, etc - but you must be able to call your view.render(state: ViewState)
function.I truly believe this style of view architecture is the natural evolution over MVP, MVVM, etc. A single ViewState
allows for predictable state and maximum testability.
In future articles, I will dig deeper into other components, such as the business logic that is responsible for the ViewState
.
Catch the conversation on Reddit
All source is available on GitHub.
Shoutout to the many pioneers of reactive programming that have made this architecture possible!
Additional resource — watch Jake Wharton’s awesome talk on managing state with Rx.