MVP in Android — Part I

SHISHIR
PROGRAMMING LITE
Published in
5 min readJun 9, 2018

Its true that Android doesn’t enforce any architectural pattern. But in android, one of the biggest problems is that views aren’t easy to test because of the complexity of framework. To reduce this complexity you must use a architectural pattern. Also you should always separate your business logic from the view. The more you can do that, the better. Because It will make your code portable and obviously it will be very much easier to test. And there is a best way to do that. Yes, The way is MVP (Model View Presenter).

The Model View Presenter (MVP) separates your data Model from the view through a presenter and dramatically it increases the testability of code.

For example, Suppose you have a username/password form and a “LOGIN” button, Then you don’t need to write the validation logic inside the view but inside the presenter. Your view should just collect the username and password and send them to the presenter. That’s it.

Why MVP?

  • Best reason to switch to MVP is testability. In MVP, It is much easier to unit testing.
  • Makes debugging easier in Applications.
  • It makes things easier for developers and makes the views independent of the data source.
  • Its maintenance cost is low than MVC.
  • MVP (Model View Presenter) can fulfill the complete requirements of Android developers.
  • In Android, the common pattern of developing an app is to write thousands lines of code in a single Activity/ Fragment class. However, the same kind of implementation tends to become buggy when your app evolves and become more complex. In order to solve this problem, you should keep your View as dumb as possible. The more dumber your View, more better it will be to test your Android UI. In MVP, you can implement the same pattern.

Details of Model View Presenter

Model View Presenter divides our application into three layers namely the Model, View and Presenter.

If i briefly describe then it would be like below…

  1. Model:
  • It is an interface responsible for handling the data part of out application.
  • It manages data.
  • It contains the code to fetch and update data.
  • If you are using the Repository pattern the model could be a Repository. If you are using the clean architecture, instead, the Model could be an Interactor.
  • It can start a service, Bind to a service, Send a broadcast, Register a broadcast receiver, Load resource values.
  • It can not show a dialog, Start an activity, Inflate a layout

2. View:

  • This is an interface responsible for handling the visual part of the application.
  • Its function is only to detect the input (e.g. touch or swipe) and visualisation.
  • It contains only the UI and it does not contain any logic or knowledge of the data displayed.
  • The view is responsible for All functionality related to android context like showing a ProgressBar, updating a TextView, populating a RecyclerView also Menus, Permissions, Event listeners, Showing dialogs, Toasts, Snackbars or any other User Interface related changes.
  • The view, usually implemented by an Activities,Fragments, any Android widget or anything and will contains a reference to the presenter. Presenter will be ideally provided by a dependency injector such as Dagger, but in case you don’t use something like this, it will be responsible for creating the presenter object

Note: The View never communicates with Model directly.

3. Presenter:

  • It is also an interface which acts as a ‘bridge’ or the ‘middle man’ between view and model.
  • It connects a Model and a View.
  • It retrieves data from the model and returns to the view.
  • The presenter doesn’t make sense without a view. It comes with the view and goes when the view is destroyed.
  • It manages one view at a time.

MVP VS MVC

  • MVC is one of the old patters Whereas MVP is the advanced form of MVC.
  • In MVC the view has some intelligence. It can query with model directly. On the other hand View in completely passive in MVP.
  • MVP offers highly support unit testing where MVC offers limited supports to unit testing.
  • In the Model View Presenter pattern, the presenter communicates between model and view and the views is separated from the model. Whereas in Model View Controller pattern View can communicate directly with the model.
  • In MVP, the presenter can work with only one views at a time. Whereas in MVC, the controller can share multiple views.
  • Maintenance cost is comparatively low in MVP than MVC.

MVP is gaining more importance in the development of Android applications now a days

Basic Structure of MVP

Model Interface

package com.shishirstudio.mvparchitecture.MainActivityMvp;

public interface MainViewInterector {
interface OnFinishedListener {
void onUsernameError();
void onPasswordError();
void onSuccess();
}
void validate(String username, String password,
OnFinishedListener listener);
}

View Interface

package com.shishirstudio.mvparchitecture.MainActivityMvp;

public interface MainView {
void initiateViews();
void showProgress();
void hideProgress();
void setUsernameError();
void setPasswordError();
void showValidateFinished();
}

Presenter interface

package com.shishirstudio.mvparchitecture.MainActivityMvp;public interface Presenter {    
void validateCredentials(String username, String password);
void onDestroy();
}

Now Google recommends to keep a single contract interface file for the Model View and Presenter. So lets club the interfaces defined above into one.

package com.shishirstudio.mvparchitecture.MainActivityMvp;
public interface MainActivityContract { interface MainView {
void initiateViews();
void showProgress();
void hideProgress();
void setUsernameError();
void setPasswordError();
void showValidateFinished();
}
interface Presenter {
void validateCredentials(String username, String password);
void onDestroy();
}
interface MainViewInterector {
interface OnFinishedListener {
void onUsernameError();
void onPasswordError();
void onSuccess();
}
void validate(String username, String password,
OnFinishedListener listener);
}
}

You can also use the solution proposed by Google in the Android Architecture Repository: it consists of an contract interface with two inner interfaces, one for the view and one for the presenter.

Conclusion

Yeah its not so easy to separate interface from logic in Android but the MVP pattern has made a little easier it to us. Specially for large application where it is essential to organize our code well, (If not, it would be impossible to maintain and extend) MVP can be a great helper.

As a conclusion, it is possible to say that MVP architectural pattern in Android maintains code simplicity and reusability which in turn promotes higher testability.

I hope you liked this article. Feel free to give your feedback in comment below: I would be very happy to get new suggestions.

Happy Coding…!!!

--

--

SHISHIR
PROGRAMMING LITE

{ 'designation' : 'Lead Software Engineer' , 'hobby' : [ 'Music', 'Photography', 'Travelling' ] ,’email’: ‘shishirthedev@gmail.com’ }