Android MVP - should an Activity be a View or Presenter?

Question

I want to implement my next application with MVP pattern, so I started of reading some articles about how it should be implemented. The main problem for me is that there are different approaches to this pattern. Some people say that we should treat activity as a view but some others that activity should be a presenter.

Activity as a view is described here: MVP Android and it makes sense. But on the other hand I found this answer with a few upvotes https://stackoverflow.com/a/7609943 and someone says that activity should be a presenter.

Does anyone has an experience with this pattern?

Bruno

Answer 1

After a moment's thought I think Activity should be considered as a View. If we separate business logic from activity then it will be easy to replace activity with a fragment or a view. We even will be able to take our models and presenters and use them in desktop application, just adding new views to them. It is also better for testing purpose to create presenter as an normal object, not activity.

Bruno

Answer 2

Activity is very close to your layout so it should be a view. And your business logic should be in the Presenter created by your Activity. To understand more about MVP take a look at - MVP for android

Astragal

Answer 3

I think it is safe to consider Activity to be a Presenter. The View can be considered as the layout XML file. The presenter is something which has direct connection to Model(s) as well as View(s) as said in the answer you posted above. In an Activity, you connect to the View(s), and stays as in intermediary between the View(s) and the Model(s), which is effectively the functionality of the Presenter. It takes input events from the View(s) and set the value(s) received from the Model(s) to display in the View(s).

Langtry

View doesn't suggest underlying implementation details. A view is just an abstraction that can be implemented in many ways (a GWT view, a mock view, an Android-based view). I really think that an activity in Android is closer to the View, because the activity tends to know the implementation details (underlying layout XML, etc). In unit testing, having the Presenter to be an activity, binds you tight to Android environment whereas a separated view-layer-agnostic presenter gives much more flexibility (you can easily test your presenters using mvn test in this way). – Mneme

So what do you propose as the presenter? – Langtry

As I told above, the presenter should be a view-layer-agnostic middle man. For example, it can be a simple class that references a model and a view via interfaces in its simplest case, and can dictate the interaction and workflow between the model and the view. Just suppose you have such a presenter that can be easily reused for different environments: Android, GWT, etc. – Mneme

Answer 4

Take a look at G+ community Android MVP and especcially for the sample https://github.com/spengilley/ActivityFragmentMVP

It's a Passive View pattern implementation, best for use in tests.

Ictinus

Answer 5

Activities should be views, since it's where graphics are rendered. Presenters and models can be written in pure java and easily tested.

See this AndroidMvc/Mvp framework

https://github.com/kejunxia/AndroidMvc

Also check out the MVP sample here https://github.com/kejunxia/AndroidMvc/tree/master/samples/simple-mvp

Caudill

Answer 6

The term View is overloaded here, android view is different than the view supposed to be used in the MVP pattern. View is an interface supposed to be implemented either by the Activity / Fragment. You can have a look on Official Android MVP Examples.

I will suggest to start it from the basic one. Here is a flow from the page.

Soraya

due to the docs you refer "In this version of the app, the Activity is the overall controller which creates and connects views and presenters." – Hebraism

Answer 7

We must follow Single Responsibility Principle , when deciding wether activity should be view or presenter component.

It is nearly impossible to separate business logic from activity. One Big Reason for this is

Activity extends Context.

Functionally, Context objects provide access to most platform’s features that third party applications can use.

Since Activity is Context’s subclass, our applications use its API in order to take control over a subset of features and resources of the platform. And the logic that uses these features and resources is our business logic. Therefore, no matter how hard we try, we will not be able to completely separate business logic from Activities.

Since we can’t separate business logic from Activities, we shall separate all UI logic from it. This is not a trivial task, but it is very well worth the effort in a long run.

Cassette

You should at least mention the article from where you copied this. This is the link – Pubis