Problems defining the MVP pattern for Android applications

Question

I’ve been developing on Android for the past two months, I have 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 in this case is the most suitable patterns for processing the user interface.

I read a lot of threads and examples, but I still have some doubts, very likely due to my lack of experience with Android.

Some authors define actions as presenters / controllers, and some others as perceptions that I believe that actions should work as presenters, not views, for its natural ability to save state and present layout to the user, maybe I'm wrong, and I hope someone can clarify this.

If I'm right, then the views should be different classes that use the layout and bind events to communicate with the host (activity), this is where I get lost ...

I could not find a way to correctly create a class that extends from the view, and uses the layout to bind events and the ability to communicate with the host. The only way I did this is to use the Builder object, the creator creates the view through the inflatable element and binds the events. This works, but the view does not implement an interface that destroys my MVP pattern.

Another way I'm thinking of is using View as Proxies for the android view object, but I'm not sure if this is the best way to handle this ...

I would really appreciate it if someone could point me in the right direction.

Thank you and sorry for the long post!

Answer 1

I have experience with MVC in other contexts, and after I have developed quite a lot on Android, I would say that it is not so simple.

You will probably finish mixing Controller and View code in Activity. It should be a controller, yes, but it works a lot with user interaction, for menus, dialogs, etc. And it’s not easy to get rid of it.

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

Therefore, I would advise against trying to strictly adhere to MVC on Android. View and Controller code may mix, but your code may remain supported with a modular approach. Custom views or other highlighted classes can help with this.

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

Answer 2

If you don't mind spaghetti code and possibly a potential memory leak. You can do something like snap to a base layout / view. Then load your preferred view into the layout. This custom view class then takes the Activity into itself, so it can refer to the activity that calls it and exchanges with it. When you want to switch the view, you simply replace the current view with another.

The principle is the same as in Fragment, but my path is just a bunch of messier.

So after that I stick with the API and the snippet. It is close enough to the MVC structure, while keeping things neat.

You can try your way, it is a good experience, as it can teach you a lot not to do. Also, things like Map will also not appear in the view, in case you haven't figured out :)