Comparing Java swing MVC with Android design pattern

Question

I'm doing a small research on design patterns in various platforms and I have prior experience in programming with Java.

While reading these posts: MVC pattern on Android and MVC architecture in Android,
I had an interesting question in mind: Why Java swing MVC can not be compared with Android development pattern? or Why we can't say that Android follows MVC? (in the context of overall "look and feel").

In one answer, someone clarified MVC as:

• Model: What to render

• View: How to render

• Controller: Events, user input

OK. well, now what I understand is:

Java Swing MVC:

• In Java swing MVC, component class is an abstract class for all attributes in visual environment. There is a distinct keyword called controls is used for some components such as buttons, lists etc. So, all controls and components are part of Model in MVC.

• Container inherits component. and there are several LayoutManagers that defines layouts and place of components in container. Also there are Listenershave to be registered with according EventSources. So, they all are the View in MVC.

• Class that implements Listener interface methods in which we put our main logic and there are some EventClasses for each event. They all are part of Controller in MVC.

putting all these examples together in an image; in swing MVC we have:

Android design pattern (visualizing as MVC):

• I think widgets are same as controls here. Also, there are some other EventSources.They all act as a Model.

• View package has viewgroups (that also contains several kinds of layouts.) and Listener interfaces. they all are the part of View in MVC.

• Same as swing MVC, we can say Listener interface methods and activities are the part of controller.

putting all together in an image; in Android we have:

As per above comparison, I consider following similarities:

• Container - same as View

• Layout managers - same as ViewGroup

• Listeners - overall same in both architecture

• controls - overall same as widgets

• Event delegation (registering appropriate listener with Event source and then implementing Listener's methods) - overall same in both architecture

So, can anyone explain which are the things that makes the Android design pattern different than Java swing MVC pattern?
or If you believe that both are different things (in the context of design patterns used for development), then explain why?

Answer 1

Each Swing JComponent has ComponentUI that is responsible for displaying a component. While JComponent has a paint method, only user derived classes use it directly - "standard" implementations very often just call the paint method of the attached UI instead. This allows to plug-in various look and feel implementations very easily - a different look and feel just provides different ComponentUI's. Very clearly component is the "model" and the UI is the "view". And Android does not inherit this decoupling in very obvious way. For instance, its TextView seems just painting drawables when a similar JLabel has UI.

This is however not the only place where MVC approach is used, and for some other specific cases Android and Swing MVC are very similar. For instance, Android ListView has a model (ListAdapter) very much like Swing JList has ListModel. In both cases the model provides data while the component itself provides possibilities to display. The possible difference is that Swing has more components with such decoupled data and presentation. JTable and JTree have similar models when Android does not provide such components out of box. There is no tree at all, and TableLayout is a that is called GridLayout in Swing, not similar to JTable.

The general approach for invalidating and repainting is not much different and in both frameworks only dedicated master thread can touch components. Also, event listeners (probably other group of "controllers") are very similar in Java and Android, all differences between them could probably be called "subtle" only.

Containers and layout manages are also quite similar between Swing and Android, the main differences being that Swing has much more possible implementations of its LayoutManager to choose from than Androids ViewGroup (classes like DatePicker, while derived from ViewGroup, are not general purpose layout managers). Also, part of Android layout is encoded in XML while Swing is typically plain Java only. If layout managers are also kind of "controllers" responding to events like resizing or reorientation, this part is very similarly done. However I am not sure if layout managers are really "controllers" as they update more the view than the model.

In general, Swing seems more optimized for the large, complex GUI that shows up on a large screen when Android is better suited for small screens with just a few visible components, large enough to be operated with fingers without stylus.