MVP for Android – Is Model-View-Presenter (MVP) Scheme Useful for Android?

androidmvp

How to separate View and Presenter in Android, while the reactions on the user actions (Presenter part of MVP) are set into the same activities that shows GUI elements (View part of MVP).

"In model view presenter just as Martin Fowler or Michael Feathers [2] say, the logic of the UI is separated into a class called presenter, that handles all the input from the user and that tells the "dumb" view what and when to display" (cited from here).

Till now I thought that one of the main features of Android is the smart Activity that takes actions, reacts to them and shows the results. Is MVP scheme in contradiction with Android philosophy? Has it sense to try to realize it on Android? If yes, how could it be done?

Best Answer

Android applications are fundamentally built around Model-View-Controller (MVC) - MVP sounds like the same thing, although I've not heard the term before. Activities fill the role of Controller, XML Views are just that (although you can build them programmatically in the Activity - it's just easier and simpler to do it in XML), and the Model you write yourself. So yes, that model is quite practical.

A possible reason you may not have heard much about this design model is that the Android framework forces you to separate the view out. Because the application on mobile devices tend to be small, people don't tend to use full-on MVC; they tend toward view and action layers where the action layer does much of the model's (small) job.

If you are writing a cross platform app, you may want to look at a four-layer approach: View, Action, Business Logic, and Model. The View and Action layers would be platform specific, while the Business Logic and Model would not change. Basically, you split out the presenter and user interaction out to the Action layer, which calls the Business Logic layer to perform the action the user wants.

Related Solutions

Android MVP – How to Use One Presenter for Multiple Views

Yes, it is fine.

Applying MVP design pattern means having MVP triplets (model-presenter-view) per every (even a bit complex) item to display. The logic goes to the model, and the presenter is there just to glue things.

Best practices for MVP pattern on Android

Here is an example of what the interface between the View and Presenter could be, from this article

interface MessageView {
  // View methods should be directives, as the View is just executing orders from the 
  // Presenter.

  // Methods for updating the view
  void setMessageBody(String body);
  void setAuthorName(String name);
  void showTranslationButton(boolean shouldShow);

  // Navigation methods
  void goToUserProfile(User user);
}

interface MessagePresenter {
  // Presenter methods should mostly be callbacks, as the View is reporting events for the
  // Presenter to evaluate

  // Lifecycle events methods
  void onStart();

  // Input events methods
  void onAuthorClicked();
  void onThreeFingersSwipe();
}

Here are a couple of interesting points to notice about this interface:

The methods to update the view should be simple and targeted on a single element. This is better than having a single setMessage(Message message) method that will update everything, because formatting what should be displayed should be the responsibility of the Presenter. For example, you might want to start displaying “You” instead of the user name if the current user is the author of the message, and this is part of your business logic.
Lifecycle events methods on the Presenter are simple and don’t have to map the (overly complicated) Android lifecycle ones. You don’t have to implement any of them, but you can implement as many as you want if the Presenter needs to take specific actions.
Input events methods on the Presenter are kept at a high level. If for example you’re trying to detect a complex gesture, like the 3 fingers swipe example, all the gesture detection should be done in the View. You can see that there are MessagePresenter.onAuthorClicked() and MessageView.goToAuthorProfile() methods. The implementation of the View will probably have a click listener that calls this Presenter method that will call goToAuthorProfile(). Should you skip all this and just directly go to the author profile from the click listener? No! The decision of going to that profile when the author name is clicked is part of your business logic, and belongs in the Presenter.

Best Answer

Related Solutions

Android MVP – How to Use One Presenter for Multiple Views

Best practices for MVP pattern on Android

Related Topic