2

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?

2

I don't believe the examples are different implementations of MVP, they are different understandings of MVP.

The Activity or Fragment is the view layer in Android. There is no way around that fact and they can't be the presenters themselves. A View in MVP by definition displays the data and routes the data to the presenter. In Android you are stuck with activities, fragments, adapters and the XML for the layer that the user actually sees.

The other issue is the idea of "inside." You need to think of MVP in terms of dependencies instead. Dependencies are not difficult to understand, the quick trick is simply to look at your import statements. If you have an import then you also have a dependency with the class. A presenter can be inside the project and not have a dependency to the Android framework and that's really the difference. It is independent of android and yet resides inside the project directory.

In MVP the Presentation layer is the only layer that really should never have a dependency for the platform framework (in this case Android). This layer is the strictly for presenting the logic to the other layer which means that you should be able to use this portion of the project in other platforms easily. A dependency is some class that you need for stability. So if you where to actually build a "presenter" dependent on the activity or fragment then you need to have that activity or fragment in order to use the presenter at all. So a presenter that's dependent on a fragment or activity is not a presenter because it is not independent of the platform.

The model is different entirely. It defiantly can depend on the android framework but it doesn't have to. The most common scenario for this is the architectural components where you can use room, and live data to handle the life-cycle in an easier, less-prone-to-memory-leaks way. With the model you generally just handle the gathering and storing of the data.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.