Tests
Mostly untouched basically. Just removed obsolete view/presenter two way connections and rewrote other tests so they would pass.
View
It might be a good idea to rewrite part of them to match in a more idiomatic way the architecture works; i.e. testing 1) intents() based on UI interaction and 2) render() based on a state.
ViewModel
To which extent can we consider it a black box?
A: Would it be better to test every step of the data flow? intents → actions, actions → results, results → state
B: Or just test the input/ouput of the model? Basically intents → state.
At the moment, this is moving toward B and I don't dislike it. Although with A, we can find restrain greatly the scope of a bug. Not sure here.
SchedulerHook
Right now, we handle EspressoIdlingResource
based on emitted state
: it's ugly and does not support multiple intent
s returning only one state
(Use of switch map).
How about doing some stuff with a custom scheduler that would handle this for us? Sounds great.
[UPDATE] I removed everything that dealed with IdlingResource
and tests still pass... ? Otherwise I thought it would be nice to try RxIdler
initialIntentFilter
Could this be done differently? I don't see it as a hack but I am not proud of it either. I've heard stories about making the state
observable a BehaviorSubject
but then, that means the ViewModel
is itself initializing the first load?
All those classes and all those casts
That would be the "downside" of the architecture as it might look like a lot of boilerplate. But, Kotlin
could help a lot with this and since the android-architecture
would propably accept a sample in Kotlin
now, we should give it a try too. Also compare the java version + the kotlin version.
Navigation
I see different patterns for navigation and I'd use one of each, based on the context.
A/ A menu link has been clicked and it's a dumb, no repo side-effect navigation; e.g. statistics link in the drawer. In this case, just startActivity
without entering the data flow.
B/ Navigation is the result of a side effect; e.g. AddEditTask#saveTask
. In this case, I would just startActivity
inside the View#render
. The problem is that only works when the activity finishes as well. If this was not the case, that would be a problem for the navigating state would be repeated when coming back on the activity.
These do not seem to cover what @malmstein called a Navigator
. I'd like to see how it fits the architecture and what are its responsibilities.
Interfaces
I created MviIntent, MviAction, MviViewModel, etc as a guide but I'm not sure they really need to stay on real projects. Did they help? Would it be better without them?
UI Notification
How to deal with UI notification such as SnackBar? I kind of cheated so far.
For instance, see how I handle a task marked as completed. I show a message only when the boolean says so here and I set it to true only on an IN_FLIGHT result.
I don't think it's a good use of the status here but I actually like the idea: 1/ emit an event that renders as a UI notification and 2/ cancel it so it won't be displayed an other time on config change.
But it is a way which badly ends up coupling the UI and the Processor? Don't know.