. . .

Android framework does not advocate any specific way to design your application. That in a way, make us more powerful and vulnerable at the same time.

Why am I even thinking about this, when I am provided with Activity and I can, in essence, write my entire implementation using few Activities?

Over the years writing code for Android, I have realized that solving a problem or implementing a feature at that point of time is not enough. Your app goes through a lot of change cycles and features addition/removal. Incorporating these over a period of time creates havoc in your application if not designed properly with separation of concern. That is why I have come up with a guide that I follow religiously for all my architectural designs from the very single code I write for that application.

The principles presented in the MVP philosophy is by far the best I have come across.

What is an MVP and why should we explore it?

Let’s take a ride into the past. Most of us started creating an Android app with Activity at the center and capable of deciding what to do and how to fetch data. Activity code over a period of time started to grow and became a collection of non-reusable components. We then started packaging those components and the Activity could use them through the exposed apis of these components. We started to take pride and began breaking codes into pieces as much as possible. Then we found ourselves in an ocean of components with hard to trace dependencies and usage. Also, we later got introduced to the concept of testability and found that regression is much safer if it’s written with tests. We felt that the jumbled code that we have developed in the above process is very tightly coupled with the Android apis, preventing us to do JVM tests and also hindering an easy design of test cases. This is the classic MVC with Activity or Fragment acting as a Controller.

So, we formulated few principles that solved most of the above-mentioned problems if implemented carefully. Those principles, we call as MVP (Model-View-Presenter) design pattern.

What is an MVP design pattern?

MVP design pattern is a set of guidelines that if followed, decouples the code for reusability and testability. It divides the application components based on its role, called separation of concern.MVP divides the application into three basic components:

  1. Model: It is responsible for handling the data part of the application.
  2. View: It is responsible for laying out the views with specific data on the screen.
  3. Presenter: It is a bridge that connects a Model and a View. It also acts as an instructor to the View.

MVP lays few ground rules for the above mentioned components, as listed below:

  1. A View’s sole responsibility is to draw UI as instructed by the Presenter. It is a dumb part of the application.
  2. View delegates all the user interactions to its Presenter.
  3. The View never communicates with Model directly.
  4. The Presenter is responsible for delegating View’s requirements to Model and instructing View with actions for specific events.
  5. Model is responsible for fetching the data from server, database and file system.

The above-mentioned principles can be implemented in a number of ways. Each developer will have its own vision of it. But in the nutshell, basic nuts and bolts are common with minor modification.

With great power, comes great responsibility.

Now, I lay down the preamble, I follow for MVP.

  1. Activity, Fragment, and a CustomView act as the View part of the application.
  2. Each View has a Presenter in a one-to-one relationship.
  3. View communicates with its Presenter through an interface and vice versa.
  4. The Model is broken into few parts: ApiHelper, PreferenceHelper, DatabaseHelper, and FileHelper. These are all helpers to a DataManager, which in essence binds all Model parts.
  5. Presenter communicates with the DataManager through an interface.
  6. DataManager only serves when asked.
  7. Presenter does not have access to any of the Android’s apis.

Now, all these information can evidently be found on any blog or Android guide for MVP. Then what’s the point of this article?

The reason that this article is written is to solve a very important challenge with MVP. How to actually implement it as an entire application?

MVP appears to be very simple when explained with a simple Activity example but makes us feel lost when we try binding all the components of an application together.

If you want to dive deep into a world of beautiful coding and be mesmerized then follow along with this article. It’s not a news article, so get involved with it, put on your shoes with your back straight and away from all distractions.

Leave a Reply

Your email address will not be published. Required fields are marked *