So I’ll give my 2 cents about the need of it and what are we trying to solve with the thingy. Because once that is clear, the coding part is dead simple and effortless. Architecture (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, 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. Android Architecture Why do we need an architecture? In general, all the architectures are there to solve few we have when we don’t use any architectural design and write (all the code inside activities/fragments). common problems activities GOD 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? (tell me if I am lying) Everybody in the universe knows it is Model , View , Presenter It allows to separate the presentation layer from the logic, so that everything about the part of the app works is separated from how we it on screen. how represent 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 . The only thing that the view will do is to call a method from the every time there is an interface action. Presenter Presenter 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 and . It retrieves data from the and returns it formatted to the . View Model Model 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 and the , this gives the developer the ability to simulate different results in order to test different behaviours of the Presenter. View Model 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 that 💚 — — — — — — — — — — — —If you know someone who might extract value please — — — hit Share
