Introducing the Android Model-View-Presenter (MVP) Design Pattern
Introduction

Architecture Pattern is a fundamental part of computer science. it expresses a fundamental structural organization or schema for software systems to maintain a project clean and testable. Several patterns are popular within the Android community to improve the Android Development.
The most popular architecture choices are:
- MVC : Model View Controller
- MVP : Model View Presenter
The Model View Controller architecture for Android

When we analyze the Android SDK, especially the relations between layout, activity and data, we have the impression that the most comfortable pattern for the Android Development is the Model View Controller (MVC) where each layer is responsible for an aspect of the application : Model responds to business logic, View is the user interface, and Controller mediates View access to Model.
What Is the Problem with MVC?
Some could say that there aren’t any issues with the MVC architecture for the Android Development. Certainly,it gets the job done. But we can have issues if system will be more and more complex.
After the application is developed, unit testing is an important phase in the software development life cycle. How can we use unit testing, in an application in which data is so strictly coupled with the View (Activity or Fragment) ? Unit testing offer the opportunity to test the smallest possible piece of code. So, the lack of a proper architectural pattern could make unit testing a real agony.
What Is the Solution?
Android allows us to choose between several alternative architectural patterns, then we can solve this by implementing a different architectural pattern. Let’s take a look to MVP.
Model View Presenter architecture for Android

Model View Presenter (MVP) is one of the best design patterns available for Android. MVP separates the application into three layers:
- The Model holds the business logic of the application. which will allow us to perform and manage any business layer logic and data access, such as retrieving data from our Web service, Access to the database, etc.
- The View is a passive interface that displays data and routes user actions to the Presenter only.
- The Presenter acts as a bridge between the view and the model,. It will be responsible for events created by the user during interaction with the interface and to perform any action.
Differences between MVC and MVP:
- In MVP, the View cannot access the Model.
- In MVC,Views tend to have more logic in them because they are responsible for handling of notifications and data processing
- The Presenter is tied to a single View.
- The View is completely passive in the MVP pattern.
- Views can communicate directly with Model
Why we should use MVP?
We chose MVP for its various advantages:
- Separation of concerns: This separation allows for an understanding and easier code maintenance. Components have no conceptual relationship.
- Facilitates unit testing: Since there are well defined separation between components, it is much easier to test each component in isolation.
Implementation
At the end of this, I created an MVP example on GitHub consisting of an application is created using the MVP pattern that allow users to loading the current weather data of any city from OpenWeatherMap API using Retrofit Library from.

