What is the role of the Activity class in MVC?

Question

I know that there were quite a few questions about this, however, I'm still trying to understand what role the Activity class should play in implementing the traditional Model-View-Controller design pattern on Android?

I feel it should be a Controller, however it means a one-to-one relationship between the user interface screens (since you have to have one Activity per screen) and the controllers that defeat the MVC decoupling point between the various components.

Answer 1

You're right. Xml interfaces can be defined as a View and your other data class as a Model .

The activity accepts all events and user inputs from the view, so we can easily say that this is the Controller .

But let it be clear that this is not ideal (does it really exist?) MVC

Look at this question , or rather, at the first comment of the accepted answer, it may be useful

Answer 2

Competent controllers can create actions, and with the help of fragments you can also implement hierarchical MVC. Most of the work of MVC depends on the programmer, because even in the most stringent framework you can still find ways to do crazy things .

Answer 3

I think confusion can arise with the definition of a view as XML, and therefore activity is mistakenly perceived as a point of view. Not this. You pass the view (your XML layout) to the Activity, which then inflates the views contained in the XML layout. Your activity also transfers data (models) to your views (EditText, TextView, extended version of base views, etc.).

If you really want MVC, you can achieve this by simply customizing your view in the XML layout, create a view object that extends from your root view (if this RelativeLayout extends from this). From there, you add your accessors and other logic needed for this view, and then you can add unit testing around this.

In action, you will no longer pass the layout id and instead do something like this:

 CustomView customView = new CustomView(...); setContentView(customView); ... 

Of course, almost all applications will not do this, and you really don't need to do this. A call to findViewById is enough to bind this object and call the methods that it has. This, in my opinion, is MVC.

Answer 4

Android does not have a good architecture and does not match the MVC design pattern.

The best way to conceptualize Activity in MVC is to browse (with some controller logic), because it is destroyed every time a configuration change occurs, such as changing a screen or changing a locale, losing all its state.

The controller in this case will be an Application object, because this is your bridge for accessing the view (Activity and its GUI components) from code outside the Activity context. You must use singleton so that at the moment there is only one application object, otherwise there will be one application object for each process. An application object is not a good place to store the Model because its life cycle is separate from what happens in the actions. It can be destroyed and recreated at any time in the Activity lifecycle (while the application is in the background), without forcing it to reboot, and then all its variables and references not assigned inside its onCreate () method will become null.

Thus, the model should be stored in a graphic graphic fragment without a header with setRetainInstance (true), which is associated with the activity and must be attached to it every time the activity is recreated. You must use the fragment manager to make sure that you are restoring the saved fragment and not re-creating it. It is also the best place to run background tasks, although you can also run them in the Application object. Never run tasks in Activity, as they will be destroyed when configuration changes.