MVP und Dolch 2 - Android Application Skeleton - Teil 1

Dieser Artikel richtet sich an Anfänger in der Android-Entwicklung und soll dabei helfen, die minimal erforderliche Anwendungsstruktur zu erstellen.

So kam es, dass ich vor relativ kurzer Zeit mit der Programmierung für Android begann. Nach einem Monat ohne Projekt in dem Unternehmen, in dem ich arbeite, wurde ich dem mobilen Entwicklungsteam im uruguayischen Büro von Tata Consultancy Services zugewiesen. Im Gespräch mit dem Teamleiter wurde mir ein Stapel geäußert, mit dem ich mich erst vertraut machen und dann meistern musste. Unter anderem gab es das Dagger 2-Framework für DI und MVP als Architekturmuster. Und Kotlin. Aber ein anderes Mal über ihn :)

Also begann ich zuerst die Grundlagen des Android SDK und dann den gesamten zugehörigen Stack zu studieren. Es gab keine Probleme mit dem SDK selbst - es gibt mehr als genug umfassende Informationen im Netzwerk, angefangen von der offiziellen Dokumentation bis hin zu den Tutorials (das Startandroid-Projekt hat dabei besonders geholfen), aber es gab einige Schwierigkeiten mit Dagger 2 und MVP in Bezug auf die Android-Entwicklung aufgrund einer ziemlich kurzen Dokumentation des ersten und zu diesem Zeitpunkt unzureichendes Verständnis des zweiten. Tatsache ist, dass ich vor der mobilen Entwicklung Microservices in Java mit Spring Boot / MVC durchgeführt habe und bereits eine gute Vorstellung davon hatte, was Dependency Injection ist und was MVC ist. Darüber hinaus deutet sogar der Name „Spring MVC“ selbst darauf hin, dass dieses Muster in die Projektarchitektur eingebettet ist und seine Verwendung offensichtlich ist. Von Dolch 2 erwartete ich die gleiche „Magie“ wie im Frühjahr und die gleichen ausgearbeiteten Dokumentationen und Tutorials. Und brach ab: P.

Trotzdem ist bei ausreichender Ausdauer und Ausdauer nichts unmöglich, und das Ergebnis der Forschung war die Umsetzung meiner langjährigen Idee, die selbst in jenen Tagen entstand, als ich nicht einmal an die Android-Entwicklung dachte. Sie können die Idee bewerten, indem Sie die Anwendung aus dem Google Store installieren

In diesem Artikel möchte ich einen trockenen Überblick über das Ergebnis meiner Suche geben - eine Schritt-für-Schritt-Anleitung zum Erstellen des Skeletts einer Android-Anwendung mit MVP und Dagger 2. Beginnen wir also.

1.1 Abstracts

Erstellen Sie zunächst das Abstracts-Paket im Stammverzeichnis des Projekts und lassen Sie es com.caesar84mx.mymvcapp.abstracts sein. Wir werden 2 Schnittstellen darin erstellen: view.BaseView und presenter.BaseMvpPresenter. Wie folgt:



Dies sind die grundlegenden Architekturelemente, die später in der Anwendung verwendet werden. Öffnen Sie als Nächstes BaseView und deklarieren Sie die darin enthaltenen showView () getContext () -Methoden:

interface BaseView { fun showView(view: View, isShown: Boolean) { view.visibility = if (isShown) View.VISIBLE else View.GONE } fun getContext(): Context } 

Öffnen Sie nun BaseMvpPresenter und bearbeiten Sie es wie folgt:

 interface BaseMvpPresenter<V: BaseView> { var isAttached: Boolean fun attach(view: V) fun detach() } 

Erstellen Sie im Ansichtspaket eine abstrakte BaseCompatActivity-Klasse, erben Sie sie von AppCompatActivity und implementieren Sie die neu erstellte BaseView-Schnittstelle. Innerhalb der Klasse deklarieren wir die abstrakte init-Methode (savedInstanceState: Bundle?) Und implementieren die getContext () -Methode aus BaseView:

 abstract class BaseCompatActivity: AppCompatActivity(), BaseView { override fun onCreate(savedInstanceState: Bundle?, persistentState: PersistableBundle?) { super.onCreate(savedInstanceState, persistentState) init(savedInstanceState) } protected abstract fun init(savedInstanceState: Bundle?) override fun getContext(): Context = this } 

Von dieser Klasse werden wir in Zukunft alle Aktivitäten erben.

Fahren wir nun mit dem Präsentator fort: Erstellen Sie eine BasePresenter-Klasse, die die BaseMvpPresenter-Schnittstelle implementiert, und implementieren Sie die Schnittstellenmethoden wie folgt:

 open class BasePresenter<V : BaseView> : BaseMvpPresenter<V> { protected var view: V? = null private set override var isAttached = view != null override fun attach(view: V) { this.view = view } override fun detach() { this.view = null } } 

Nun, wir haben die grundlegenden Architekturelemente identifiziert. Kommen wir nun zu den Komponenten, aus denen unsere Anwendung erstellt wird.

1.2. Komponenten

Erstellen Sie zunächst das Paket com.caesar84mx.mymvcapp.components, darin das Mainscreen-Paket, in dem wiederum die UI- und Backstage-Pakete enthalten sind, und übertragen Sie die MainScreen-Klasse in das UI-Paket:



Jetzt entfernen wir aus der MainScreen-Klasse die Implementierung der onCreate () -Methode, die beim Erstellen des Projekts automatisch generiert wurde, sowie die Vererbung von AppCompatActivity und erben sie von BaseCompatActivity. Jetzt implementieren wir die zuvor in der Basisklasse deklarierte Methode init (). Den gesamten Code, den wir früher in die onCreate () -Methode eingefügt haben, haben wir eingefügt (wie wir uns erinnern, wird die init () -Methode in der onCreate () -Methode der Basisklasse aufgerufen):

 class MainScreen : BaseCompatActivity() { override fun init(savedInstanceState: Bundle?) { setContentView(R.layout.activity_main_screen) } } 

Großartig, das Ansichtselement des MVP-Musters wird erstellt. Gehen wir nun zur Backstage unserer Komponente über - dem Backstage-Paket. Erstellen wir die MainScreenContract-Schnittstelle - den sogenannten Vertrag, über den wir unser Muster implementieren. Erstellen Sie in dieser Oberfläche zwei Subschnittstellen - Presenter und View:

 interface MainScreenContract { interface Presenter: BaseMvpPresenter<MainScreenContract.View> interface View: BaseView } 

Fahren wir nun mit dem Präsentator fort und erstellen die MainScreenPresenter-Klasse:

 class MainScreenPresenter : BasePresenter<MainScreenContract.View>(), MainScreenContract.Presenter { } 

Das Anwendungsskelett ist fast fertig, ein paar Berührungen bleiben. Fügen Sie in der MainScreen-Klasse die Implementierung der MainScreenContract.View-Schnittstelle hinzu, erstellen und initialisieren Sie die Presenter-Variable: MainScreenPresenter, und hängen Sie die Ansicht in der init () -Methode wie folgt an den Presenter an:

 class MainScreen : BaseCompatActivity(), MainScreenContract.View { val presenter: MainScreenPresenter? = MainScreenPresenter() override fun init(savedInstanceState: Bundle?) { setContentView(R.layout.activity_main_screen) presenter?.attach(this) } } 

Daher haben wir einen Präsentator erstellt und ihm unsere Ansichtsinstanz hinzugefügt (nicht zu verwechseln mit android.view.View), die im Präsentator zum Bearbeiten der Ansicht verwendet wird.

1.3. Abschluss des ersten Teils

Wir haben also die abstrakten Grundelemente des MVP-Musters geschaffen, die jedoch nicht direkt auf der Stirn, sondern über das sogenannte verwendet werden. Vertrag - das Grundelement jeder Komponente der Anwendung, das sowohl die Aktionen des Ansichtselements als auch die Aktionen des Präsentatorelements kombiniert. Ein Vertrag ist ein ziemlich flexibles Element, dessen Zusammensetzung von Komponente zu Komponente unterschiedlich ist und Komponenten innerhalb einer einzigen Architektur unauffällig miteinander verbindet.

Es sollte beachtet werden, dass gemäß dem Konzept von MVP das Ansichtselement so stumpf wie möglich sein sollte. Darin führen wir nur elementare Aktionen aus, wie zum Beispiel Text ein- / ausblenden, den Hintergrund oder die Farbe des Textes ändern, das Ladesymbol ein- / ausblenden usw. d. Die diesem Element entsprechenden Methoden definieren wir in der Unterschnittstelle des View-Vertrags. Während wir uns in einem Präsentator mit Logik befassen - Geschäftslogik, Datenmanipulation (CRUD), Starten von Hintergrundaufgaben usw. Darin entscheiden wir, wann bestimmte Elemente auf dem Bildschirm angezeigt werden sollen. Dies unterscheidet sich von dem im Frühjahr implementierten MVC-Konzept, bei dem zwischen der Geschäftslogik und der Ansicht ein dummer Controller steht, der nur Anforderungen aus der Ansicht empfängt und einen Dienst aufruft, der Daten zurückgibt oder andere von der Geschäftslogik definierte Aktionen ausführt. Die dem Präsentator entsprechenden Methoden sind in der Unterschnittstelle des Präsentatorvertrags definiert.

Bei der Implementierung des Präsentators wird die Ansicht über die Ansichtsvariable der BasePresenter-Superklasse bearbeitet, während die der Ansicht entsprechenden Methoden in der Aktivitätsklasse implementiert werden.

Sie fragen, wo ist Dolch 2 hier und warum hat er sich uns ergeben? Wird die DI-Implementierung in Android eine Eule auf den Globus ziehen? Die Antwort auf die zweite Frage lautet nein, wird es nicht. Und warum und warum es gebraucht wird - im zweiten Teil meines Artikels;)