So I’ll give my 2 cents about the need of it and what are we trying to solve with the Architecture thingy. Because once that is clear, the coding part is dead simple and effortless.
(I will mostly be talking about MVP (Model | View | Presenter) — a common yet amazing pattern.)
I know, I am late to the party as there are a lot of technologies and tons of articles in the sea of Android blogs BUT actually I am not!
Why?Where the Jake Wharton’s of the world are using/building/talking/juggling MVP, MVVM, Android Architecture components, ROOM, Kotlin and all the toppings of a Pizza, there still exist an audience(a really big audience like myself some time back) who are still unaware of the benefits of a good architecture in building an app.
Why do we need an architecture?
In general, all the architectures are there to solve few common problems we have when we don’t use any architectural design and write GOD activities(all the code inside activities/fragments).
We all know a friend of a friend that has an application in which there is a Thousand-liner-Activity a.k.a. The Unmaintainable where all business logic is inside the Activity because he made copy-paste-coding from Stack Overflow.
The problems without an architecture -
- Android activities are closely coupled to both — User interface and Data access mechanisms.
- A small change and have to redo our entire views(activities/fragments).
- The views — Activities, Fragments,… aren’t easy to test because of their massive size and framework complexity and
- Programmers are involved into fight with View complexities instead of solving business tasks.
- The code cannot be reused, tested, easily debugged and refactored.
How a good architecture make life easier?
- Complex tasks are split into simpler tasks and are easier to solve.
- Smaller objects, less bugs, easier to debug.
- View classes stay neat and classy.
- Testable code — Writing tests is a breeze(Aaha).
- Coupling remains in the sweet spot of functionality vs complexity.
- If the requirements change, usually is quite simple to pinpoint exactly what you need to change in your code with minimal implications.
Why MVP?
Well, this is highly debatable. MVP and MVVM are 2 most popular choices these days. And priority of developers is also fragmented. Personally I am using MVP because its fairly simple and still serve the purpose. MVVM is amazing, I am personally not a big fan because, though it makes Java files small and powerful with Data Binding, it also makes XMLs over complicated.(Just a personal opinion, don’t kill me Yeah!)
What is MVP?
Everybody in the universe knows it is Model, View, Presenter(tell me if I am lying)
It allows to separate the presentation layer from the logic, so that everything about how the part of the app works is separated from how we represent it on screen.
View — The Stupid, The Better
- Usually an Activity, Fragment or a custom Android view. Only takes care of displaying things.
- The View, usually implemented by an Activity/Fragment, will contain a reference to the P_resenter_.
- Directs user interaction to the Presenter. The only thing that the view will do is to call a method from the Presenter every time there is an interface action.
Model — The Data Access Layer
- It is your data source, doesn’t matter if fetch results from a database, network calls or a hard-coded list of objects.
- It controls how data can be created, stored, and modified.
Presenter —The Middle Chap
- The middle layer between View and Model. It retrieves data from the Model and returns it formatted to the View.
- It also decides what happens when you interact with the View.
How testing the app became a smooth child’s play after MVP?
MVP allows you to easily write separated tests for the Model and the Presenter. Since the Model does not have any reference to the View or the Presenter, it can be tested separately, allowing the developer to abstract the Model from any other component such as databases.
The Presenter can be unit-tested by mocking the View and the Model, this gives the developer the ability to simulate different results in order to test different behaviours of the Presenter.
Conclusion
Separating interface from logic in Android is not easy, but the Model-View-Presenter pattern makes it easier to prevent our activities end up degrading into very coupled classes consisting on hundreds or even thousands of lines. In large applications it is essential to organise our code well. If not, it becomes impossible to maintain and extend. With MVP, we can achieve all of above.
Whats next?
On the next article of this series, we’ll implement the Model View Presenter pattern in Android. We’ll follow a more conservative path, using only canonical code, without any libraries from outside the Android SDK. This approach will help to understand the different relations between the MVP’s layers.
— — — — — — — — If you liked this article hit that 💚 — — — — — — — — — — — —If you know someone who might extract value please Share — — —