7

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

Improve this question
5
  • 2
    Well, you have yourself identified both relevant advantages and disadvantages. If you have those, it's obviously a matter of context and requirements.
    – Alex
    May 29, 2017 at 22:28
  • @Alex: yes, that's true. But are both scenarios proper MVP, or did I make up something new?
    – Willi Mentzel
    May 30, 2017 at 7:47
  • Proper this and propert that... Design patterns are great, but I think our whole community is a little bit too focused on what we call things and nitpicking on how things should look to be classified as some fancy acronym :)
    – Alex
    May 30, 2017 at 8:00
  • @Alex: I see, but since I am starting with MVP and don't have proper experience with it, I would like to know what is good in the long run. Maybe I should just start writing tests, to see what works best. Because that is what it is mainly about: Testability, right?
    – Willi Mentzel
    May 30, 2017 at 8:11
  • Tests are great for verifying functionality, not very good for evaluating non-functional qualities. Testability is one non-functional quality of a system, others can be stuff like performance, readability, scalability (in a bunch of different ways), extendability (in a bunch of different ways) etc.
    – Alex
    May 30, 2017 at 8:16

1 Answer 1

Reset to default
7

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.

Improve this answer
16
  • So, the (Main)Presenter knows all the other Presenters (1,2,3)? If, yes why are the arrows only in one direction? Can't the Presenter call methods on the (Sub)Presenters? If View1 receives a button click for instance, methods would be called on the following entities in order: View1 -> Presenter1 -> Presenter -> Presenter3 -> View3? Isn't that a little too much complexity?
    – Willi Mentzel
    May 30, 2017 at 7:44
  • @WilliMentzel Presenter 1,2,&3 don't know about the master controller. That's why the arrows only go in one direction. The overseer is responsible for coordinating between presenters, not individual actions on models or views. Is it too much complexity? I don't think so. I think it's less complex than having a God presenter that knows everything about every model/view.
    – RubberDuck
    May 30, 2017 at 11:46
  • @RubberDuck If P1, P2, P3 don't know about the main presenter who is going to call its methods?
    – Willi Mentzel
    May 30, 2017 at 11:52
  • @WilliMentzel, I updated the answer a bit to clarify a few things. Hopefully the answer makes more sense now.
    – R Sahu
    May 30, 2017 at 15:23
  • @RSahu So, with API/Framework you would mean my Activity (to speak in Android terms)? The way I thought of it until now was: View1 (Activity), View2 (Fragment 1), View3 (Fragment 2). I know the concept is not bound to any Framework, but it would be nice if you would use Android terms next to the abstract ones. Thank you!
    – Willi Mentzel
    May 30, 2017 at 15:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.