Why you should use MVP clean architecture in your next android project
This is a brief look into MVP clean architecture discussing why it is the best architecture for android development
Filter by Category
Filter by Author
Tech industry is moving at a staggering pace. Gone the good old days when a release cycle takes year or more. And we enter a new era. The era of Apps and “rapid release cycle”. Big companies like Tumblr, Github, Facebook are all embracing a short release cycle with some even removed the need for QA. All of that because the need for fast innovation is critical. Customer nowadays could easily switch to another product because of a single feature they like.
Meanwhile, that has put a great emphasis on developing a software that would be a future prove a software that is reusable, flexible and maintainable. So developers have looked into architecture pattern to address their need as a vanilla android SDK doesn’t address these concerns and often result in spaghetti code when used in a large project.
Android programming mostly based on activity, and putting most of the responsibility On the activity clearly isn’t a good idea as it violates single responsibility principle, making the code harder to test, convoluted and harder to understand as a consequence of violating SOLID principle which is stands for :
– S for Single responsibility principle.
– O for Open closed principle.
– L for Lisko substitution principle.
– I Interface segregation principle.
– D Dependency inversion principle.
As the name implies SOLID principle is indeed solid principle if it’s been applied correctly. It will result in software that is reusable, flexible and maintainable but above all will lead your code to be more readable. As uncle Bob once said
“so if you want to go fast, if you want to get done quickly, if you want your code to be easy to write make it easy to read” – Robert C. Martin from clean code.
Moreover, following an architecture pattern when developing an Android App will help immensely in the long run (a pattern is nothing but “ a tried and tested solution to a general occurring problem).
However, when you decide to choose an architecture pattern you might encounter names like MVVM, MVC but here is one that gains a lot’s of popularities among android developer which is MVP and it is a short-form for Model View Presenter.
So Why Using MVP?
MVP addresses most of the problems that come bundled with android development problem that mostly related to testability and maintainability. With the use of MVP, we could separate background tasks from Activities or Fragments and make them independent from lifecycle events of the activity. Achieving high decoupling and make it a lot easier to reason about our code.
In Addition, MVP core concept is built upon dividing the architecture into layers.
let’s start with Model which is defining the data to be displayed. Then comes the Presenter which is acting upon both the Model and the View and it behaves like a hub coordinating the actions and the data flowing from both Model and View. then we come to the Presenter and the responsibility of which is to retrieve data from the model and formats it to be displayed in the view. The View, on the other hand, is a passive interface that displays data and routes user commands to the presenter to act upon it.
How MVP Make Test faster and easier?
MVP passive view stands out by removing all the interaction code from the view and place it into the presenter whose role it is handling the presentation and update the UI. Hence, the name passive view.
In return UI test becomes a whole lot easier and faster. And that’s due to the removal of the role of the Android framework in testing since we remove all the interactive code from the view and place it into the presenter we are able to rely only on JVM test without worrying on how to test android UI components, firing up the emulator and what have you …
MVP Under the hood?
So let’s look at the MVP under the hood and discuss the role of Presenter, Model, and View in the light of the clean architecture.
Each layer in the MVP has its own model, a model which contains data related to that layer only and when the data moves from one layer to another the models are transformed accordingly. So potentially will going to have a view model that holds data relevant to view, database model which represents a data entities in the database and the network model for the data entities fetch online.
Acts as middlemen between the Model and the View contains the presentation logic like retrieving the data from the model in addition, formatting the data before passing it to the view as well as updating the view data.
The view is passive and cannot access the model directly so it relies on the presenter. Furthermore, by having a reference to a presenter, the view is able to propagate events forward to the presenter which in return supply the needed data back to the view.
As we can see In the MVP clean architecture a layer must only rely on the layer below it, this is known as dependency rule. Inner circle like Model has no idea about the outer circle like the view. And the outer circle like view has no mean of accessing the model. Therefore, it relies on the presenter. However, to reduce direct dependency when implementing MVP we should program against interfaces rather than concrete classes.
Overall, when using MVP we divide our code into layers and follow the dependency rule. And that results in clean code that is reusable and very easy to test.
featured image by Meriç Dağlı
Uber is a nice and features rich App, here in this tutorial we’ll implement a feature on it that is very useful. In particular, moving the map under the marker which is UBER...