5 min read

The Android framework does not encourage any specific way to design an application. In a way, that makes the framework more powerful and vulnerable at the same time.

You may be asking yourself things like, “Why should I know about this? I’m provided with Activity and I can write my entire implementation using a few Activities and Fragments, right?”

Based on my experience, I have realized that solving a problem or implementing a feature at that point of time is not enough. Over time, our apps will go through a lot of change cycles and feature management. Maintaining these over a period of time will create havoc in our application if not designed properly with separation of concerns. That’s why developers have come up with architectural design patterns for better code crafting.

How has it evolved?

Most developers 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.Then developers started packaging those components and the Activity could use them through the exposed APIs of these components. Then they started to take pride and began breaking codes into bits and pieces as much as possible. After that, they found themselves in an ocean of components with hard-to-trace dependencies and usage. Also, later we were introduced to the concept of testability and found that regression is much safer if it’s written with tests. Developers realized that the jumbled code that they developed in the above process is very tightly coupled with the Android APIs, preventing JVM tests and also hindering an easy design of test cases. This is the classic MVC with Activity or Fragment acting as a Controller.

SOLID principles

SOLID principles are object-oriented design principles, thanks to dear Robert C. Martin.

According to the SOLID article on Wikipedia, it stands for:

  • S (SRP): Single responsibility principle
  • This principle means that a class must have only one responsibility and do only the task for which it has been designed. Otherwise, if our class assumes more than one responsibility we will have a high coupling causing our code to be fragile with any changes.
  • O (OCP): Open/closed principle
  • According to this principle, a software entity must be easily extensible with new features without having to modify its existing code in use.
  • Open for extension: new behavior can be added to satisfy the new requirements.
  • Close for modification: extending the new behavior is not required to modify the existing code.
  • If we apply this principle, we will get extensible systems that will be less prone to errors whenever the requirements are changed. We can use abstraction and polymorphism to help us apply this principle.
  • L (LSP): Liskov substitution principle
  • This principle was defined by Barbara Liskov and says that objects must be replaceable by instances of their subtypes without altering the correct functioning of our system.
  • Applying this principle, we can validate that our abstractions are correct.
  • I (ISP): Interface segregation principle
  • This principle defines that a class should never implement an interface that does not go to use. Failure to comply with this principle means that in our implementations we will have dependencies on methods that we do not need but that we are obliged to define.
  • Therefore, implementing a specific interface is better than implementing a general-purpose interface. An interface is defined by the client that will use it; so it should not have methods that the client will not implement.
  • D (DIP): Dependency inversion principle
  • The dependency inversion principle means that a particular class should not depend directly on another class, but on an abstraction (interface) of this class. When we apply this principle we will reduce dependency on specific implementations and thus make our code more reusable.

MVP somehow tries to follow (not 100% completely) all of these five principles. You can try looking up clean architecture for pure SOLID implementation.

What is an MVP design pattern?

An 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 concerns.

MVP divides the application into three basic components:

  • Model: The Model represents a set of classes that describes the business logic and data. It also defines business rules for data, which means how the data can be changed and manipulated. In other words, it is responsible for handling the data part of the application.
  • View: The View represents the UI components. It is only responsible for displaying the data that is received from the presenter as the result. This also transforms the model(s) into UI. In other words, it is responsible for laying out the views with specific data on the screen.
  • Presenter: The Presenter is responsible for handling all UI events on behalf of the view. This receives input from users via the View, then processes the user’s data with the help of Model, and passes the results back to the View. Unlike view and controller, view and presenter are completely decoupled from each other and communicates to each other by an interface. Also, Presenter does not manage the incoming request traffic as Controller.
  • In other words, it is a bridge that connects a Model and a View. It also acts as an instructor to the View.

MVP lays down a few ground rules for the abovementioned components, as listed below:

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

MVP projects for getting started

Every developer will have his/her own way of implementing MVP. I’m listing a few projects down the line. Migrating to MVP will not be quick and it will take some time. Please take your time and get your hands dirty with MVP:

About the author

HariVigneshJayapalan is a Google-certified Android app developer, IDF-certified UI &UX Professional, street magician, fitness freak, technology enthusiast, and wannabe entrepreneur.

HariVigneshJayapalan

LEAVE A REPLY

Please enter your comment!
Please enter your name here