Jede Swing JComponent hat ComponentUI , die dafür zuständig ist Anzeige einer Komponente Während JComponent über eine Paint-Methode verfügt, verwenden nur von Benutzern abgeleitete Klassen diese direkt - "Standard" -Implementierungen sehr oft nur rufen Sie stattdessen die Paint-Methode der angefügten Benutzeroberfläche auf. Dies ermöglicht die einfache Integration verschiedener Look-and-Feel-Implementierungen - ein anderes Aussehen und Verhalten bietet nur verschiedene ComponentUIs. Ganz klar ist Komponente das "Modell" und die UI ist die "Ansicht". Und Android erbt diese Entkopplung nicht sehr offensichtlich. Zum Beispiel erscheint sein TextView nur Zeichnen von Zeichnungen , wenn ein ähnliches JLabel Benutzeroberfläche .

Dies ist jedoch nicht der einzige Ort, an dem der MVC-Ansatz verwendet wird, und für einige andere spezifische Fälle sind Android und Swing MVC sehr ähnlich. Zum Beispiel, Android ListView hat ein Modell ( ListAdapter ) sehr ähnlich wie Swing JList hat ListModel . In beiden Fällen stellt das Modell Daten zur Verfügung, während die Komponente selbst Möglichkeiten zur Anzeige bietet. Der mögliche Unterschied ist, dass Swing mehr Komponenten mit solchen entkoppelten Daten und Präsentationen hat. JTable und JTree haben ähnliche Modelle, wenn Android solche Komponenten nicht direkt zur Verfügung stellt. Es gibt überhaupt keinen Baum und TableLayout ist ein GridLayout in Swing, nicht ähnlich zu JTable .

Der allgemeine Ansatz zum Ungültigmachen und Neuanstreichen unterscheidet sich nicht sehr und in beiden Frameworks kann nur dedizierter Master-Thread Komponenten berühren. Event-Listener (wahrscheinlich auch andere Gruppen von "Controllern") sind in Java und Android sehr ähnlich, alle Unterschiede zwischen ihnen könnten wahrscheinlich nur "subtil" genannt werden.

Container und Layout-Verwaltung sind auch zwischen Swing und Android ziemlich ähnlich, wobei der Hauptunterschied darin besteht, dass Swing viel mehr mögliche Implementierungen von LayoutManager zur Auswahl als Androids ViewGroup (Klassen wie DatePicker , die von ViewGroup abgeleitet sind, sind keine allgemeinen Layout-Manager ). Außerdem ist ein Teil des Android-Layouts in XML kodiert, während Swing normalerweise nur Java ist. Wenn Layout-Manager auch als "Controller" auf Ereignisse wie Größenanpassung oder Neuausrichtung reagieren, ist dieser Teil sehr ähnlich. Ich bin mir jedoch nicht sicher, ob Layout-Manager wirklich "Controller" sind, da sie die Ansicht mehr aktualisieren als das Modell.

Im Allgemeinen scheint Swing mehr für die große, komplexe GUI optimiert zu sein, die auf einem großen Bildschirm angezeigt wird, wenn Android besser für kleine Bildschirme mit wenigen sichtbaren Komponenten geeignet ist, die groß genug sind, um mit Fingern ohne Stift bedient zu werden. p>     

Das Hauptmerkmal von MVC ist die Trennung von Bedenken zwischen den drei Komponenten:

• Das Modell ist verantwortlich für die Aufrechterhaltung einer internen Darstellung der Daten.
• Die Ansicht ist verantwortlich für die Anzeige dieser Daten für den Benutzer und ermöglicht ihnen die Interaktion mit ihm.
• Der Controller ist verantwortlich für die Aktualisierung des Modells als Reaktion auf Benutzerinteraktionen mit der Ansicht und um sicherzustellen, dass die Ansicht den aktuellen Status des Modells widerspiegelt.

Je nachdem, wie strikt eine MVC-Definition ist, die Sie anwenden, können Sie auch Einschränkungen für die Entkopplung der Komponenten angeben. Sie könnten beispielsweise behaupten, dass das Modell keine Kenntnisse über die Ansicht oder den Controller haben sollte. In den meisten Fällen dürfte es jedoch als ausreichend erachtet werden, zu zeigen, dass die drei Komponenten in der Software separat wiedergegeben werden und den oben genannten allgemeinen Verantwortlichkeiten entsprechen.

In Bezug auf Ihre MVC-Zuordnungen zu Swing und Android denke ich, dass das Hauptproblem, mit dem Sie zu kämpfen haben, die Identifizierung des Modells ist. Das Modell muss im UI-Framework kein eigenständiger Komponententyp sein, es kann sich lediglich um eine einfache Klasse oder einen Satz von Klassen handeln, die die fraglichen Daten kapseln. Wo das Model-Mapping zu Widgets und Controls ist, würde ich das als falsch einstufen: Das Model ist einfach, was auch immer Daten für den Benutzer darstellen. Also, für Swing würde ich die MVC-Komponenten wie folgt zuordnen:

• Modell: Beliebige Domänenklassen, die Ihre Daten darstellen, z. B. com.example.Order .
• Ansicht: Die Steuerelemente, Container und Layout-Manager.
• Controller: Die Event-Listener-Implementierungen, die das Model manipulieren und die Ansicht aktualisieren.

Sie könnten in Swing eine strengere MVC-Implementierung finden, aber das obige ist wahrscheinlich eine vernünftige Zuordnung.

Das Android-UI-Framework ist restriktiver als Swing, weil Anwendungen auf Mobilgeräten eingeschränkter sind und Google es vorziehen würde, dass sie sich ziemlich konsistent verhalten. Daher müssen Klassen wie Activity eine bestimmte Sache für den Benutzer darstellen muss tun, und die relativ enge Kopplung mit einem Activity und gegebenem View / ViewGroup .

Trotzdem könnten Sie die Android-Komponenten wie folgt zuordnen:

• Modell: Beliebige Domänenklassen, die Ihre Daten darstellen, z. B. com.example.Order .
• Ansicht: Die Views und ViewGroups
• Controller: Die Activity , unter der Annahme, dass der Event-Listener-Code für Ihre View s Teil der Activity ist, was oft der Fall ist.

Nun könnte man auch argumentieren, dass das Obige eher ein Model-View-Presenter-Muster ist, wobei Activity den Part des Presenters spielt, aber dass MVP als eine spezifischere Variante von MVC angesehen werden kann Dies macht das MVC-Mapping nicht unbedingt ungültig.