Problems defining the MVP pattern for Android Apps

Question

I've been developing on Android during the last couple of months, I've learned a few things but I think it's time to start doing it right, so I'm trying to implement the MVP/MVC pattern, which are in this case the most suitable patterns to handle UI.

I've read many threads and examples but I still have some doubts, very probably for my lack of experience with android.

Some authors, defines Activities as presenters/controllers and some others as views, what I think is that activities should work as presenters instead of views, for its natural capabilities of keeping state and present a layout to the user, maybe I'm wrong and I hope someone can clarify this.

If I am correct, then Views should be different classes that uses the layout and bind events to communicate with the presenter (activity), this is where I get lost...

I couldn't find a way to properly create a class that extends from view and uses a layout to bind the events and be able to communicate with the presenter. The only way I did this was by using a Builder object, the builder creates the view through an inflater, and bind the events. This works, but the view doesn't implement any Interface, which destroy my MVP pattern.

The other way I think of, is by using View as Proxies to the android view object, but I'm not sure if this is the best way to handle it...

I would really appreciate if someone can point me to the right direction.

Thanks and sorry for the long post!

Answer 1

If you don't mind spaghetti code and perhaps potential memory leak. You can do something like having one base layout/view tied to the activity. Then load your preferred view into a Layout. This custom class of the View will then take Activity into itself so it can refer back to the activity calling it and communicate with it. When you want to switch view, you will then just replace the current view with another one.

The principle is the same with Fragment, but my way is just heap messier.

So after that one, I stick with the API & Fragment. It is close enough for MVC kinda structure while keeping things neat.

You can try my way, it's a good experience still as it may teach you a lot of what not to do. Also stuff like Map won't work on the view as well, just in case you haven't figured out yet :)

Answer 2

I have some experience with MVC in other contexts, and after having developed quite a lot on Android, I'd say it's not straightforward at all.

You are likely to end up mixing Controller and View code in the Activity. It should be a Controller yes, but it does deal with user interaction a lot, for menus, dialogs, etc... And it's not easy to get out of that.

I think that Android development follows a different paradigm, which reminds me of Django and what they call MVT, Model-View-Template.

So I'd advise not to try and adhere to strictly to MVC on Android. View and Controller code may mix, but your code can remain maintainable with a modular approach. Custom views or other dedicated classes can help a lot in this regard.

And you'll save a lot of time by following the natural logic of the framework instead of looking for academic MVC, in my opinion.