MVC pattern on Android

Question

Is it possible to implement the model–view–controller pattern in Java for Android?

Or is it already implemented through Activities? Or is there a better way to implement the MVC pattern for Android?

Solution 1

In Android you don't have MVC, but you have the following:

• You define your user interface in various XML files by resolution, hardware, etc.
• You define your resources in various XML files by locale, etc.
• You extend clases like ListActivity, TabActivity and make use of the XML file by inflaters.
• You can create as many classes as you wish for your business logic.
• A lot of Utils have been already written for you - DatabaseUtils, Html.

Solution 2

There is no universally unique MVC pattern. MVC is a concept rather than a solid programming framework. You can implement your own MVC on any platform. As long as you stick to the following basic idea, you are implementing MVC:

• Model: What to render
• View: How to render
• Controller: Events, user input

Also think about it this way: When you program your model, the model should not need to worry about the rendering (or platform specific code). The model would say to the view, I don't care if your rendering is Android or iOS or Windows Phone, this is what I need you to render. The view would only handle the platform-specific rendering code.

This is particularly useful when you use Mono to share the model in order to develop cross-platform applications.

Solution 3

The actions, views and activities on Android are the baked-in way of working with the Android UI and are an implementation of the model–view–viewmodel (MVVM) pattern, which is structurally similar (in the same family as) model–view–controller.

To the best of my knowledge, there is no way to break out of this model. It can probably be done, but you would likely lose all the benefit that the existing model has and have to rewrite your own UI layer to make it work.

Solution 4

After some searching, the most reasonable answer is the following:

MVC is already implemented in Android as:

1. View = layout, resources and built-in classes like Button derived from android.view.View.
2. Controller = Activity
3. Model = the classes that implement the application logic

(This by the way implies no application domain logic in the activity.)

The most reasonable thing for a small developer is to follow this pattern and not to try to do what Google decided not to do.

PS Note that Activity is sometimes restarted, so it's no place for model data (the easiest way to cause a restart is to omit android:configChanges="keyboardHidden|orientation" from the XML and turn your device).

EDIT

We may be talking about MVC, but it will be so to say FMVC, Framework--Model--View--Controller. The Framework (the Android OS) imposes its idea of component life cycle and related events, and in practice the Controller (Activity/Service/BroadcastReceiver) is first of all responsible for coping with these Framework-imposed events (such as onCreate()). Should user input be processed separately? Even if it should, you cannot separate it, user input events also come from Android.

Anyway, the less code that is not Android-specific you put into your Activity/Service/BroadcastReceiver, the better.

Solution 5

There is no single MVC pattern you could obey to. MVC just states more or less that you should not mingle data and view, so that e.g. views are responsible for holding data or classes which are processing data are directly affecting the view.

But nevertheless, the way Android deals with classes and resources, you're sometimes even forced to follow the MVC pattern. More complicated in my opinion are the activities which are responsible sometimes for the view, but nevertheless act as an controller in the same time.

If you define your views and layouts in the XML files, load your resources from the res folder, and if you avoid more or less to mingle these things in your code, then you're anyway following an MVC pattern.

View more solutions

Comments

[pqsk]

would be great to get a summary in case the article is deleted one day.

[Admin]

@JDPekham, why do you say "You cannot instantiate an activity without talking to your layout/view"? Instantiating an activity does not require talking to views, in fact talking to views is by no means a part of the Activity instantiation. You CAN (but do not have to) call various Activity methods that interact with your views when and if you see fit. Second question: Assuming Activity is intended to take the "controller" role (I believe many Android devs see it that way) why not talk to your views from the Activity?

[TWiStErRob]

While that's true, and well put, this is theory and people are practical!

[Rat-a-tat-a-tat Ratatouille]

the link is broken sir

[Mark Peterson]

For anyone who says that "Android is MVC" please try Backbone.js (yes, client side js) for a week, and then come back and say that "Android is MVC". You'll finally understand the question and why we keep asking :)

[Konrad Morawski]

Activity has direct access to UI, whereas in MVC controller shouldn't know about the view (only vice versa).

[18446744073709551615]

@KonradMorawski Hmmm.... A View knowing about displaying things and about the Controller? A child of, say, Button knowing about the Controller? It seems more logical that Views know only about displaying things. And taking into account that Model knows only about the nature of the data, this is why Controller is needed: something must know both about the Model and the View.

[Konrad Morawski]

Obviously the View needs to know about the controller in order to delegate events to the controller. The controller follows it up to the model and informs the View what the results were (so that it can display it). The controller does not inflate the view (whereas Activity does), nor should it know a thing about buttons, textboxes, lists etc. (whereas Activity knows).

[mmBs]

The link you provided is broken.

[CL22]

I think Services come under the umbrella of controller too

[SMBiggs]

Agreed. Android has enough flexibility to hang yourself. That Activity of your can quickly grow gigantic and complicated as it handles all three aspects of MVC.

[Lorenzo Barbagli]

"In Android you don't have MVC" ???? In Android, as in other languages, you have MVC if you want MVC.

[Srneczek]

Ever heard of observers? The best separation Iv found so far is when 1. controller has only model instance, 2. model has no knowladge of controller or view but view can register as model observer (so model kinda know about view but he doesnt know who it is and he doesnt care) - when model is done with loading data, he notifies all observers (usually 1) and 3. view has only model instance to pull data out of it. This way there are only 2 dependecies for all MVC framework. I think 2 is minimum so it should be the best layout.

[Srneczek]

btw - Activity/Fragment is kinda Controller + View and I think you should use it only as view and extract the controller outside of it. Similary as some PHP and maybe other frameworks (laravel, symphony...) where you have view which then loads "template" (smarty, twig, blade...) - Activity is the view here and XML is template

[Piovezan]

@LorenzoBarbagli He means, Android doesn't enforce MVC in apps by design (as iOS does). You have to implement a flavor of MVC, MVP or something else yourself if you want to achieve what MVC provides -- namely separation of concerns and an isolated, easily testable Model.

[Jacksonkr]

I've only ever used the controller as a conduit for how view / model relay information. I'm curious as to how you have model and view in direct contact with one another. Do you have a source or example of this implementation?

[james]

Seems this COSC346-lab2.2up.pdf file does not include full detail.

[Lukas Juhrich]

@TWiStErRob But design patterns are theoretical, abstract ideas which don't have just one way of realizing them. Proclaiming “I don't want to understand MVC in theory, I just want to have it implemented” sounds to me like it could result in “I'm going to put a washing machine in my kitchen because washing machines implement the Cleaner™ pattern and kitchens need that”.

[TWiStErRob]

I think examples are invaluable because they show what other people have come up with. One can improve upon them and learn from their effort. No need for everyone to reinvent the wheel. In context of Android and it's complex lifecycle there are problems not addressed in a design pattern, but everyone will face them. This is what I meant by practical.

[6rchid]

No. There definitely is MVC in Android, but more implicitly. It's just implemented in a different way as per how Android structures everything.

[brandonx]

I have taken an architecture course where the instructor states that activities and fragments should not be used as views and in fact should be controllers and views should be separate files. Do you have any opinion on or reasoning why this shouldn't be?

[Ali Nem]

I don't think the instructor is accurate on that. Choosing activity or fragment as controller means passing context to the controller. On the other hand view also needs context for drawing to the screen. This way, i.e. passing context to controller, renders the app prone to memory leak and I believe controller should not carry state.

[Thomas S.]

The linked page shows nothing for me.