How Many Presenters to Use in Proper MVP Design

androidArchitecturedesign-patternsmvp

I have an Android app which I am refactoring to use MVP. I have an Activity that has two Fragments.

Scenario 1 (one presenter):
The presenter "knows" each view. So, if one view receives input a presenter method is called and it could call a method of any of the views.

  • Advantage: flexible
  • Disadvantage: the presenter might get really big

enter image description here

Scenario 2 (three presenters):
Each presenter only knows its own view and any other presenter. It calls methods only on the other presenters it knows or its own view.

  • Advantage: strict modularity, flow may be more obvious
  • Disadvantage: a lot of overhead (two more interfaces and presenter classes).

enter image description here

This is meant for one Activity only and not for the communication between Activities.

Which is the way to go with MVP or does it depend on the use case?

Edit: I tend to use the structure described in the first scenario. It makes the most sense to me. My only problem is, that I don't know whether this is proper MVP or I am making up something new on my own (which I don't want).

Best Answer

Making the Presenters be dependent one one another does not sound right. The dependencies are such that you will need all the Views and all the Presenters to make one pair of View and Presenter work.

I think it will be better to make the Presenters independent of one another. You can put all the common functionality in another layer that can be used by all the Presenters.

From my cursory understanding of the MVP model in Android Apps, a simple App consists of the following components.

enter image description here

If you have an App that consists multiple Views, with each View having a corresponding Presenter, I am suggesting the following architecture.

enter image description here

PresenterCommon is meant to be independent of the individual Presenters. It can communicate with the Presenters using an abstract interface that is known to it but it should not know any thing specific about any particular Presenter N. Presenter N, on the other hand, is meant to be aware of the PresenterCommon and may make direct calls to it. Presenter N needs be registered with the PresenterCommon at some point.

Any changes to the Model by any of the Views is communicated to the other Viewers by PresenterCommon using an abstract Presenter interface.

Related Topic