Modell = Inhaltsanbieter.

Controller = Aktivität, Fragment oder Service.

Anzeigen = XML-Layouts.

MVC ist bereits in Android implementiert

View = Layout, Ressourcen und integrierte Klassen wie Button abgeleitet von android.view.View.

Controller = Aktivität und Fragment

Model = die Klassen, die die Anwendungslogik implementieren

Das Hauptziel der Implementierung des MVC-Patterns ist, dass Sie dann später eines von ihnen "herausziehen" und ein neues einfügen können, ohne dass es zu einer Änderung der beiden anderen kommt.

Modell : Alles über die Daten. Was ist manipuliert, was wird gespeichert und wie.

Anzeigen : Alles über die Benutzeroberfläche oder die Präsentation. Was wird angezeigt und wie.

Controller : Der Event-Handler. Diktiert, wenn die anderen beiden als Reaktion auf Ereignisse ausgeführt werden.

In Android hat diese Implementierung von MVC den Controller in Form einer Klasse, die die Aktivitätsklasse erweitert. Schließlich erhält diese Klasse zunächst die "Ereignisse", die den Lebenszyklus einer Android-Aktivität ausmachen (z. B. onStart (), onCreate (), onSuspend (), onStop (), onResume (), onDestroy). Dieser Lebenszyklus wird sich wahrscheinlich mit der Entwicklung von Android ändern, sodass es sinnvoll ist, ihn als Controller-Komponente des MVC-Musters darzustellen.

Auch hier kann ich mit dieser MVC-Implementierung eine der drei Komponenten herausziehen und im Wesentlichen eine ganz neue Schnittstelle (View) oder eine ganz neue Datenbank (Model) oder einen neuen Activity Lifecycle (Controller) mit einbauen keine Änderung zu den anderen beiden. Die einzige Notwendigkeit besteht darin, dass jede Komponente die unten aufgelistete Mustervorlage einhält.

In dieser Implementierung werden die drei MVC-Komponenten getrennt durch drei Java-Klassen dargestellt: appView.java, appController.java, appModel.java

Beachten Sie beim Überprüfen jeder Klasse die Mitgliedsvariablen mController, mAppView und mAppModel und sehen Sie, wie und wann sie in jeder Java-Datei referenziert werden. Diese Membervariablen sind "die Hooks", die es jeder Komponente erlauben, sich gegenseitig zu referenzieren.

Außerdem werden Sie bemerken, dass mAppModel noch weiter zerfällt und eine zusätzliche Klasse namens dbHelper verwendet. Auf diese Weise können Sie unterscheiden, welche Daten manipuliert werden und wie diese Daten manipuliert und gespeichert werden.

Der Controller, appController, implementiert die meisten der "Aktivitätslebenszyklus" -Methoden und ruft wiederum Methoden in der Ansicht appView auf. Das bedeutet, dass die standardmäßigen Lifecycle-Methoden onStop, onResume, onDestroy usw. nicht nur im Controller, sondern auch im View-Teil dieses MVC-Patterns implementiert sind. Du wirst später sehen, dass das auch im Model-Teil zutrifft.

Sie können unten in der View-Implementierung, appView, die Membervariable mController sehen, um auf Activity-Methoden zuzugreifen und dennoch die Trennung der Aktivität (Controller) von der Benutzeroberfläche (Layout, Menü usw.) zu ermöglichen. .

Das Modell ist unten aufgeführt. Sehen Sie, wie diese Klasse die Ansicht und den Controller in ihrem Konstruktor aufnimmt. Der Controller wird als Typ Context und nicht als Aktivität aufgenommen. Dadurch können Sie jedes Objekt vom Typ Context und nicht unbedingt ein Activity-Objekt einbeziehen.

Außerdem wird eine Helper-Klasse namens dbHelper im Konstruktor eingeführt.

Wie Sie unten sehen können, ist SQLite die in dieser Anwendung verwendete Datenbank. Allerdings schalten Sie diese Hilfsklasse, dbHelper, aus und Sie können eine komplett andere Datenbank verwenden und die anderen Komponenten sind keine klüger.

Im Folgenden finden Sie einige rudimentäre Methoden (Öffnen, Schließen usw.), um eine Vorstellung von den hier ausgeführten Funktionen zu erhalten. Beachten Sie außerdem, dass die Methode onDestroy () hier die Datenbankverbindung schließt. Es wird von der View aufgerufen, die wiederum vom Controller aufgerufen wird, wenn es zerstört wird.

Es ist diese Hilfsklasse, die die Namen der Felder in der Datenbank kennt. Bei dieser Implementierung müssen die Ansicht, der Controller und sogar das Modell nicht wirklich den Typ der verwendeten Datenbank oder sogar die Feldnamen kennen.

Nicht wirklich MVC, sondern mehr MVC mit Room und LiveData

Im klassischen MVC geht es dem Controller um Entscheidungsfindung, welche Aktion als nächstes ausgeführt wird. Die Ansicht liest die Daten aus dem Modell und aktualisiert ihre eigenen Felder.

In Android-Aktivitäten tun beide, sie treffen Entscheidungen, welche Aktion als Antwort auf ein Ereignis ausgeführt werden UND sie legen die Felder der Layouts fest. Sie lesen auch Daten aus dem Modell und verdrahten Widgets. Die Aktivitäten kombinieren die logischen Aufgaben der klassischen Steuerung UND der klassischen Sichtweise.

Deshalb würde ich in den meisten Fällen nicht von MVC sprechen. Es gibt keine saubere Trennung zwischen Controller und Ansicht. Es gibt eine saubere Trennung zwischen Java-Code und XML-Ressourcen. Dies ist sinnvoll, da in größeren Teams unterschiedliche Personen für das visuelle Layout und die Programmierung verantwortlich sind.

Sie können weiterhin Ihre eigenen Ansichtskomponenten codieren und diesen Teil des Codes als Ansicht adressieren. Es ist nur der passive Teil der klassischen Ansicht, während die Logik dem Controller innerhalb der Aktivitäten und Fragmente beigetreten ist. Ich würde nicht von einer Sicht sprechen, sondern von Komponenten oder Widgets. Je intelligenter Widgets sind, desto mehr Logik der klassischen Sichtweise nehmen sie wieder auf.

Auf der anderen Seite, wenn Sie Bibliotheken wie Raum Android anwenden, wird wieder viel mehr MVC. Room und LiveData ermöglichen Ansichten, um Änderungen im Modell bis hin zu Änderungen in der Datenbank zu beobachten. Wenn Sie die Ansichten sauber trennen und Controller zur Entscheidungsfindung hinzufügen, können Sie Ihre Architektur so strukturieren, dass sie den Namen MVC wirklich verdient.

Untere Zeile

Das hängt vom Entwickler ab. Es ist möglich, echte MVC auf Android anzuwenden, aber das ist nicht der Standardfall.