PART 5. ADVANCED ANDROID DEVELOPMENT - MVP ARCHITECTURE

Maintaining a clean architectural pattern is imperative for project maintenance and ensuring that it is clean, testable, and expandable. In Android domain, the classic Model View Controller pattern is no longer the default choice for developers. More and more developers are shifting their loyalty to Model View Presenter pattern (including me 😝).

Watch the two videos about the MVC and MVP patterns before proceeding.

Why MVP is being preferred over MVC?

While using Android SDK and Google documentation, you will get the impression that the Android ecosystem is tailor-made for MVC. But as your project grows more in complexity and size, it quickly becomes clear that this pattern is not ideal for writing tests. It does not offer the same level of separation of concerns as MVP. Some of the benefits that MVP pattern offers us over MVC can be summarized as follows:

1. The user interface can be unit tested. Inside the unit test, we replace the view with a test driver that makes calls to the presenter.
2. The user interface is developed completely isolated from the application logic. They can be developed independently of each other. 

It can't be all good. There must be some catch here 😈. Yes of course. There are certain drawbacks to the MVP approach too. 

1. It requires more effort 😕.
2. For every screen or window, we require separate presenters and contracts, which may ultimately complicate our project. 

In spite of these potential problems, I am a strong advocate of MVP, because if you adhere to it strictly, even for very complex projects, you can successfully avoid spaghetti code situation.

Differences Between MVP and MVC?

The important differences between the two patterns are: 

1. In MVP, there is one to one mapping between View and Presenter (for example, one presenter for every fragment). For a complex View, we can even have more than one presenter! In MVC, the Controller can share multiple views. 
2. In MVP, the View is totally stupid 😂. It only knows how to render a screen on the device. It does not know anything about the model (not even it's existence!). In MVC, the View can directly communicate with the model. Hence, the big problem! How to test them separately?

Now that I have again convinced (coerced 😈) you to believe that MVP is better, in the next article of this series I will discuss MVP in more detail. I have used MVP pattern in the sample application and I will use its code to demonstrate implementation of MVP pattern for Android projects.