View interface in MVI extending MvpView?

[jshvarts]

Hey @sockeqwe, Is there a reason why the View interface in MVI in Mosby should implement MvpView? Just because there is a Presenter in MVI too, I think mixing Mvi and Mvp prefixes is confusing. I would prefer to see MviView marker interface added instead.

I am talking about public interface MviPresenter<V extends MvpView, VS> extends MvpPresenter<V> {

Thanks

[sockeqwe]

We had a similar discussion here: https://github.com/sockeqwe/mosby/issues/296

[jshvarts]

Thanks! I see your point about giving users flexibility with the API. I am not advocating adding a MviView#render(state), just advocating a separate marker interface MviView.

If you had started Mosby with MVI and then added MVP, would you end up with MvpView interface for both? Unlikely. It seems like the interface was just re-used but the name just irks me. Sure I can create my own MviBasePresenter just to get around it—it just seems like more code I’d like to write to get around this small but visible (to me) issue.

Anyway, not a huge deal. Feel free to close this.

[sockeqwe]

Yes, starting from scratch today maybe we would have something like MVI inteface and MviPresenter. The historical reason why in Mosby-MVI we have this relationship to MvpView and MvpPresenter is that there is a PresenterManager which is basically a Map<KEY, MvpPresenter<MvpView> that keeps Presenter during screenorientation changes and so on. As you see, unless we use raw types instead of generics, there must be some common super type for both, mvp and mvi ...

So what would you recommend to do?

[jshvarts]

I see! How about a parent interface Presenter or BasePresenter to be extended by MvpPresenter and MviPresenter and parent marker interface View or BaseView to be extended by MvpView and MviView? Perhaps the new interfaces could live in the presentermanager module or a new module common or presentermanager could be renamed to common.