[WIP] MVI-rxjava

[oldergod]

• Statistics
• Tasks
• TaskDetail by @malmstein
• AddEditTask

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

[oldergod]

@malmstein if you have thoughts.

[malmstein]

I'll look at this as soon as possible @oldergod

[oldergod]

Naming

The current MviViewModel are named as so because they extends the architecture component's ViewModel class. To me, they are more close to a presenter or something else because of the logic they contain.
Not really a problem in this sample but with DataBinding, I would usually have a class called ViewModel with the ObservableField in it and only it. In this architecture, the View would probably update the ViewModel with the latest State and the UI would update automatically.

I would end up with a ViewModel that really is a value object representing the View's state and some kind of presenter extends android.arch.lifecycle.ViewModel... That could easily get confusing. :/