Model View Presenter - same view, different presenters

Question

I'm building one Android app using MVP, and I have one question about this pattern.

Say I have one screen for creating a new person. This screen will show one EditText for inserting the name, another for the surname, one ImageView to show the picked photo picture, etc. This will lead to one View interface, implemented by the Fragment. It will cooperate with one Presenter interface, implemented by another class.

Fine.

Now I have another feature: a screen for editing an existing person. As it happens, the View for this feature is identical to the one for creating a new person. However, the Presenter is different. It will start by loading the existing person from db to pre-populate the view with the current data, and the action over the database when clicking "save" will be an update instead of a insertion.

So, I think this is an example of MVP where one View works with different implementations of the presenter to achieve different use cases.

1. Do you think this is a correct assumption, or do you think different features should have different View and Presenter interfaces?

2. Also, if you'd with a common View and different Presenters, will the implementation of the View be common, or would it lead to the same interface implemented by two classes? In practice, I see two options.

   • Having just one Fragment implementing the View. Depending on whether the user is about to create a new person or update an existing one, the Fragment should receive and use a different Presenter.

   • Having two Fragments. Each one would instantiate a different Presenter. Use composition or inheritance to avoid replication of code between the two fragments.

What do you think is better to do in these cases?

Thanks.

Answer 1

You'll run into this when you create a CRUD-like application using the MVP pattern on Android.

You can very easily just have the single view, as long as you document well in your class that it impl the 'view' for two different presenters, then it 'is okay'

---

I would personally suggest creating 2 views, one for 'create' and one for 'edit' (They might be the same(for now), but separating them makes it clear that they -are- different things.)

You could easily see a situation in the future (or another impl of this pattern) where your 'create' and 'edit' views actually have different APIs. Or slightly different visual cues, such as a button labelled 'create/add' in one and 'update' in another.

I'd personally make a view-library/helper class that both Views pull logic from. This should help you reduce overall LoC, even if you make 2 'view' classes. The benefit of this is that you change either the Create/Edit views easily without worrying about impacting the other. (I tend to think the 2 view files, would be easier to maintain down the road when there is even a 'slight' variance between Create/Edit)