How to implement MVP Passive View in an android application?

Question

I recently started building an android application and I would like to use an design pattern right from the scratch. I was told that MVP (Model-View-Presenter) is a good pattern for android applications.

I was wondering if it's possible to implement the "Passive View" variant of the MVP pattern? If I could, I would show any code.. but right now I have no idea how a passive view should look like in an android application. Also.. which role would play the MainActivity in a passive view scenario?

I would appreciate any explanations, tutorials or examples on how to implement a passive view.

Answer 1

MVP pattern in Android suggests that your View classes (Fragments, Activities) don't contain any presentation or business logic, but all logic is delegated to a Presenter class. The Presenter in turn calls usually void methods provided by the View when the View is initialised, an event occurs, or the View is destroyed.

So imagine a View and a Presenter implementing the following interfaces:

public interface Contract {

    interface View {

        void initView();

        void setTextColor();

    }

    interface Presenter {

        void init();

        void onButtonClicked();

    }
} 

In our simplistic example the View would initialise the Presenter (dependency injection is out of scope of this post) and then call Presenter's initView method. The Presenter would be responsible for all initialisation logic like fetching data from network / storage and, if need be, update the View. When in turn the user clicks a button the View would delegate action to the Presenter by calling Presenter's onButtonClicked() method. The Presenter can do some processing and depending on the outcome maybe call View's setTextColor() method.

The most important reason for using MVP is to be able to test your logic with Junit and a mocking framework like Mockito. Your Presenter should be written in pure Java or Kotlin without any dependencies on the Android framework library. Then you can just test your Presenter by using the JVM and not having to hook up a device. This is all part of uncle Bob's clean architecture guidelines.

The two best resources for MVP are the Antonio Leiva's blog post and Google's architecture samples in github

Answer 2

Working with MVP is not that hard

First, in the package Model, you will store all sort of POJO classes that have setters, getters and all the data structure of your app

Then comes the presenter, where you bind this objects and do some logic on it.

After you do all the logic into the presenter, it passes all that information to the View, so after that your MainActivity (the view in this case) will have just a few lines of code and your code will look really organized.

As for passive view, it means that you have the View with the less code possible to run tests in the future and have a mantenible code.

you can use MVC, MVP, MVVM, but if you want to start I would suggest you starting with MVP

Take a look at this image of MVP

You can also check THIS tutorial about MVP

Answer 3

I have a feeling that there is a fatal misunderstanding of presenters here. Even though MVP is the common standard, most people think of Presenters as Controllers or even worse a mix of Controllers, Repositories, Gateways.

A Presenter should do one thing: to present. That should be it's sole purpose. Many people unknowingly implement a MVC Architecture, calling it MVP, with limiting the data flow as following: View <-> Controller / Presenter <-> Model.. Now there is nothing wrong about this pattern, as it separates the layers of your system, if done correctly. You should be able to swap your Domain and Data layers (Android Devs usually call the layers the Presenter and Model layer) to another system and the code should still work without any dependency issues. To achieve this you have to avoid any dependency that would cause a binding to a so called detail (UI, Database, Frameworks, Hardware, Browsers, OS). Now speaking of layers, we’d usually have this data-flow hierarchy: UI -> Domain -> Data where within Android Applications we would put all our UI Code into the UI component. Now there are 2 options to position the presenter: You could abstract the View by introducing an interface for the presenters specific view. Avoid any android / hardware specific dependencies (like Contexts) within the presenter. If you achieve this, then you could say, your Presenter belongs to your Domain layer. If your Presenter knows any Android detail (or even worse a database), then you’re automatically putting it into the View layer (or even breaking your architecture, if you try to access the database from it). Now let’s assume you abstracted your View and have your Presenter being a Domain object. Your Presenter does not care about the actual implementation of its representing View anymore, it has its abstraction and it knows where to pass the value to. Whether it’s a mobile, web or embedded App doesn’t matter anymore. Now how does the Presenter receive data from the Data-layer and fill the UI with data? We do the same technique that we did with the View: abstractions. We’d create an interface / abstract class of a Repository, Gateway, DataService or however you would like to call the interface of your data/model layer. You’d have POJO, your data access logic, caching, etc. Note that until now, we’re working with POJOs! We have no dependencies to any platform-binding detail (as described above). But since we need to do some caching now, we’d have to use the SQLite Manager from Android (or Room). How to do this? abstractions. Abstract any detail that causes your code to be bound to any platform.

Below you can see a picture of Uncle Bob’s proposed design of a solid software architecture. The inner layers should not have any knowledge of the outer layers. This picture reflects the development technique I just described here, which is the same technique described in Uncle Bob’s book. We’re avoiding any dependencies to details by using their abstractions. The real implementations (Activities, Fragments, SQLiteDatabase) are being „wired“ to the inner layers from outside through dependency injection. This technique is also called dependency inversion.

I’d recommend you to read the book „Clean Architecture“ by Robert C. Martin to develop a deeper understanding to it.