Should MVP adapt the software framework, or just reside inside it?

Question

In android there are many different implementations for MVP. Most of them favor to use the Activity or Fragment as the view, a few would make them presenters, and even less, would separate the Activity or Fragment from the MVP, and have the classes related to Model, View, and Presenter reside inside the Activity or Fragment class.

The first 2 options seem to adapt the Android framework into becoming MVP, but the third option if applied correctly is creating the 3 layers inside the Android framework.

In Andorid-MVP the view is almost always recommended to be a passive view, and the Presenter as a middle-man between the model and the view. So having either be an Activity or Fragment, seems to give them more responsibility. On the other hand if MVP is inside an Activity or a Fragment, all three layers would need to communicate with the Activity or Fragment to get access to the system (get context, get resources, navigate, or trigger events based on life-cycle events).

Both have pros and cons, but which would adhere more to the rules of MVP?

Answer 1

Activities are responsible for handling a window, the life-cycle and other things. They must have some controller in them but they don't have to have view layer objects. They can have a view layer interact with its own XML and any class can subscribe to their messages with Interfaces/Listeners. You get to decide which ones. That's the major point that keeps getting stuff 'added onto.'

It is most beneficial to make a controller/presenter and a view for each Activity or fragment using composition if you want the most decoupling (that is you want strict MVC because an Activity/Fragment can be everything in one). If you want to treat the activity as a controller/presenter that's fine but note its not the strictest MVC. I think you refer to this as a 3 layer architecture.

The important thing is MVX is just an example of decoupling a common problem or pattern it's not really an architecture and it's not really a set standard either. Unfortunately, everyone has a different opinion on what it is. What is important is you understand the principle behind it. That is; a controller doesn't know about the view. A view doesn't know about interpretation of anything. When you do it your view is so dumb that it shouldn't be tested.

Also, chances are if your view is the Activity you might not understand the problem MVC is trying to address or you do but don't realize the ways to decouple them in Android. You might think it is a bad idea because like most frameworks they are built on telling you to couple your application and logic to it. They design things specific to keeping that coupling. Now your app has to change with the framework.

I don't see much of people 'adapting the framework,' where are these adapted frameworks? My best guess is you are confused. The difference I think you are thinking of is letting the framework make all your design choices. If you put your application and business logic in activity and mix the dependencies then you have coupling to a specific framework to code that has not anything to do with that framework.

You should start looking at dependencies not what relies inside of what. People who do not understand clean architecture could easily become confused when looking at the code. It does't look like the code the framework writes. In short the framework wants you to couple to it. However, a good framework is not so restrictive that you must do it.

Please see a link below for some context:

https://github.com/techyourchance/android-architecture-course/tree/master/app/src/main/java/com/techyourchance/mvc