Architectural Guidelines to follow for MVP pattern in Android
By default, Android doesn’t enforce any architectural pattern. Although, this makes the framework more powerful when it comes to developing applications but the same tends to make your code more vulnerable in more complex app scenarios.
This is because over the time an app development involves more complex life cycles and feature management which might create havoc in your application when not handled in a proper way.
That’s why developers rely on different architectural patterns such as MVC, MVP and MVVM for app development in Android.
As far as my experience of developing apps is concerned, I recommend using MVP architectural pattern for Android app development. With this article, I intend to help my fellow developers with some guidelines which i usually follow while developing android apps with MVP architecture.
Before discussing guidelines, let’s understand what exactly is an MVP architectural pattern for Android and how should everyone use it in their project.
MVP Architectural pattern — A Recap
MVP architectural design pattern is quite renowned design pattern for Android developers. It let you decouple business logic (Model) from view logic (Activity/ Fragment) by introducing an intermediator called as Presenter.
As the name implies, Model-View-Presenter is divided into three different layers with their separate layers defined as follows:
Model — As mentioned above, Model is where your business logic and application data is stored. In Android, the role of a model is usually played by a data access layer such as database API or REST API.
Not only Model is responsible for storing your application data, it also consists of components that holds responsibilities for generating, exposing and fetching the data.
In general, all these functionalities run in background as they can block the UI thread.
View — View is basically a passive interface cum UI which is responsible for routing user’s action to the presenter. In Android, View can be your Activity, fragment or RecyclerView Adapters.
In general, View is not visible to your Model except for the POJOS and entities of your application. To put in more simpler terms, Views do not communicate directly to Models. However, they talk to presenters.
Presenter — Presenter is the middleman or mediator between View and Model which hold responsibilities of everything which has to deal with presentation logic in your application.
In general terms, Presenter does the job of querying your Model, updating the View while responding to the user’s interactions.
It monitors Model and talks to View so that they can handle when a particular View needs to be updated and when to not.
Why use MVP architectural pattern in Android?
MVP is one of the few architectural patterns that follows uncle bob’s clean architecture guidelines.
Following are some reasons which makes MVP a good architectural pattern for Android:
- Makes debugging easier in Applications — MVP enforces three different layers of abstractions which makes it easier to debug your applications. Moreover, since business logic is completely decoupled from View, it is more easier to perform unit testing while developing your application.
- Enforces better separation of Concerns — MVP does the great job of separating out your business logic and persistence logic out of your Activity and Fragment classes which in turn better enforce good separation of concerns.
- Code Re-usability — In MVP, the code can be better reused since you can have multiple presenters controlling your Views. This is more important as you definitely don’t want to rely on a single presenter to control your different Views.
Guidelines to follow to effectively implement MVP architectural pattern in Android
1) Make your View as dumb as possible
Ask any novice Android developers and they will tell you why testing Android is more of a pain for testers. 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 using Passive View pattern.
By implementing this pattern, you will reduce the behavior of the View to the almost minimal level by introducing a presenter which respond to the user actions by talking to View.
For instance, let’s consider you need to implement a login screen in your app. Users will fill their registered email and username to login. While implementing the same, you don’t need to write the authentication logic in your view. Instead, you will write it in presenter which will update your View when the user successfully logged in (Say profile screen).
In this case, the role of your View is to only receive inputs in the form of email and password and pass it to presenter which will update the View.
2) Manage Remote and local data sources in the Model
You can increase the speed your app by managing Remote and local data sources in the Model.
For instance, let’s say you need to develop an offline-first app which will run even when the data connection is turned off. One solution to implement the same will be by fetching the data and storing the cache so that it can be queried when the user become online.
You can implement this by creating three different Model classes particularly in the form of Remote Data Source, Local Data Source and Data Repository.
Your Data Repository class will contain the logic which will talk to presenter. Local Data storage class may deal with cached data and local storage of the same while Remote Data Source class will deal with all the remote API calls and responses.
3) Use libraries like Dagger2 and RxJava for minimizing code Redundancy
I recommend using a dependency injection library such as Dagger2 which will make your Model and Presenter independent of the lifecycle of your View. Using Dagger will simplify the behavior of components by injecting dependency between them.
Moreover, you should use libraries like RxJava which will simplify your codebase while dealing with heavy grunt work such as multiple user interactions (such as click, swipe, etc.) and background data for networking.
4) Use proper Naming conventions to separate responsibilities
Use proper naming conventions for the methods you use in your codebase.
In general, you have two different categories of methods such as Actions and User events in your Presenter.
Actions are the methods which will contains the logic with which a view will be update. For example: load( ) or loadmore( ) will tell presenter to load another page when user scrolls down the application. That said, View will know when to update itself (say by talking with presenter) when the user scrolls to the end of page
On the other hand, User events denotes the actions which are triggered by a user. For example: querychanged () method can be called only when user types in the correct number of characters that shows the relevant searches.
To put succinctly, a proper naming convention should be used which is suitable for the action that needs to be triggered which implies what logic should run and when exactly it should run.
5) Make your presenter independent of a framework to improve testability
The main idea to use MVP in Android is to enforce proper testability within your project. In order to implement the same (improved testability), you should make your presenter independent of any Android class.
The main idea is to make presenter deprived of any platform dependencies so that you can test your presenter using Junit. You should refrain from using context object from your shared resources to make it more platform independent.
Ivan Skoric has written an excellent article explaining how to make your presenter independent from android states.
Conclusion
MVP architectural pattern in Android maintains code simplicity and reusability which in turn promotes higher testability. By adhering to above points on MVP architecture, you can effectively implement it and take its advantage to develop better mobile apps for Android.
References:
