Should MviPresenter offer getViewStateObservable() or not? #186

Open
sockeqwe opened this Issue Jan 8, 2017 · 0 comments

Projects

None yet

1 participant

@sockeqwe
Owner
sockeqwe commented Jan 8, 2017

The idea of MviPresenter.getViewStateObservable() is that another MVI UI component could use this observable as "intent" for rendering it's own view state.

i.e: AView has APresenter. BView has BPresenter that takes APresenter.getViewStateObservable() as input (i.e. as intent) to coordinate BView. In other words: Changing AView has impact to what BView displays.

However, I think that usually both UI components should rather "observe" both the same "model" from business logic. Offering getViewStateObservable() may lead to the wrong impression that getViewStateObservable() should be used everywhere. Actually, I think that there are only very few edge cases where using MviPresenter.getViewStateObservable() makes sense and should be preferred over "observing the same model".

Furthermore, parent - child relations are not a good idea and MviPresenter.getViewStateObserable() allows you to build such parent-child relations (attention: cycles in your dependency graph).

As compromise we could move getViewStateObservable() to MviBasePresenter (rather than MviPresenter and make getViewStateObservable() protected.

By doing so a developer explicitly has to override getViewStateObservable() with public visibility in his own presenter to make getViewStateObservable() visible for other presenters (to establish a child-parent relationship).

Note: child-parent relation may not be the correct word because there is no Presenter.getParentPresenter() method etc. so that is not really a parent - child relation from a hierarchical point of view, but I hope you get what I'm trying to say with "parent-child" relation.

@sockeqwe sockeqwe added this to the 3.0 milestone Jan 8, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment