MVP und Dolch 2 - Android Application Skeleton - Teil 2

Dieser Artikel ist das Ergebnis von Recherchen, deren Nebenprodukt die Verkörperung einer langjährigen Idee in einer sehr nützlichen und einmal fehlenden Android-Anwendung war - My Location Notifier , mit der der Empfänger automatisch über die Ankunft eines Benutzers benachrichtigt werden soll (siehe detaillierte Beschreibung hier ).

Im ersten Teil haben wir das Hauptskelett der Android-Anwendung gemäß der MVP-Architektur erstellt. Jetzt fangen wir an, Dolch 2 daran zu schrauben.

2.1. Voreinstellung

Wechseln Sie zunächst zur Datei build.gradle (Projekt: mymvcapp) und fügen Sie dem Buildscript-Abschnitt die folgende Zeile hinzu:

ext.dagger2_version = "2.8" 

Zum Zeitpunkt dieses Schreibens ist dies die neueste Version von Dagger 2. Wechseln Sie als Nächstes zur Datei build.gradle (Modul: App) und fügen Sie die Zeile am Anfang hinzu:

 apply plugin: 'kotlin-kapt' 

Dies ist notwendig, damit in Dolch 2 der Code beim Kompilieren generiert werden kann. Später wirst du verstehen warum.

Fügen Sie nun die erforderlichen Abhängigkeiten hinzu:

 implementation "com.google.dagger:dagger:$dagger2_version" kapt "com.google.dagger:dagger-compiler:$dagger2_version" 

2.2. Injektionsvorbereitung

Wir werden das Projekt synchronisieren und zur MainScreen-Komponente zurückkehren. Erstellen Sie eine Klasse di.MainScreenModule im Backstage-Paket und markieren Sie sie mit der Modulanmerkung. In der neuen Klasse deklarieren und implementieren wir die Methode adsPresenter (): MainScreenPresenter = MainScreenPresenter und markieren sie mit Annotationen Provides und Singleton . Nun wird unsere Klasse aussehen:

 @Module class MainScreenModule { @Provides @Singleton fun providesPresenter(): MainScreenPresenter = MainScreenPresenter() } 

Jetzt gehen wir zur MainScreenCompatActivity-Klasse und ersetzen die Modifikatoren der Presenter-Variablen durch lateinit var, löschen die Wertzuweisung und markieren sie mit der Inject- Annotation:

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

Beachten Sie, dass wir jetzt beim Zugriff auf diese Variable kein Fragezeichen mehr benötigen.
Es scheint, dass alles eingespritzt ist, die Aufgabe ist erledigt. Aber nein. Jetzt müssen wir Dagger dazu bringen, den notwendigen Code zu generieren, um unsere erste Abhängigkeit einzufügen. Aus diesem Grund haben wir das Kotlin-Kapt-Plugin zum obigen Build-Skript hinzugefügt. Erstellen Sie im Paket com.caesar84mx.mymvcapp das Paket di.config, in dem wir die AppDiComponent-Schnittstelle erstellen.



Jetzt deklarieren wir die Schnittstelle als Komponente und als Singleton und als miserabel , registrieren unser Modul darin und deklarieren die Inject-Methode (mainScreenActivity: MainScreen) innerhalb der Schnittstelle:

 @Component( modules = [ MainScreenModule::class ] ) @Singleton interface AppDiComponent { fun inject(mainScreenActivity: MainScreen) } 

Und jetzt müssen Sie Dagger endlich dazu bringen, den gesamten erforderlichen Code zu generieren. Dazu erstellen wir die MyMvpApp-Klasse im config.di-Paket, erben sie von der Application-Klasse und registrieren die Klasse in AndroidManifest.xml, indem wir die Zeile android: name = ". Config.di.MyMvpApp" in das Application-Tag schreiben. Deklarieren Sie als Nächstes die Variable lateinit var injor: AppDiComponent, setzen Sie sie auf einen privaten Setter und definieren Sie die onCreate () -Methode neu. Und starte die Magie:

 class MyMvpApp: Application() { lateinit var injector: AppDiComponent private set override fun onCreate() { super.onCreate() injector = DaggerAppDiComponent.builder() .mainScreenModule(MainScreenModule()) .build() } } 

Wie Sie sehen können, ist die DaggerAppDiComponent-Klasse noch nicht vorhanden. Sie wird beim Erstellen der Anwendung generiert. Sowie die Implementierung unserer Komponente. Der Klassenname besteht aus dem Wort „Dolch“ + dem Namen der als Komponente gekennzeichneten Schnittstelle. Die mainScreenModule () -Methode wird auch während der Erstellung des Projekts generiert. Der Name muss aus dem Klassennamen des injizierten Moduls in lowerCamelCase kompiliert werden.

Wir bauen das Projekt zusammen (Build → Make Project). Genießen Sie die automatische Codegenerierung und fahren Sie fort.

2.3. Injektion

Achtung: Außerdem werden einige Tänze mit einem Tamburin mit Elementen des Pornos präsentiert. Die Aufforderung, Kinder und nervöse Personen vom Bildschirm zu entfernen.

Für erfolgreiche Injektionen benötigen wir einen Verweis auf die Injektorvariable. Stimmen Sie zu, dass das Erstellen einer Instanz von MyMvpApp in jeder Klasse, in die wir injizieren, nicht die beste Lösung ist. Daher werden wir Folgendes tun:

 class MyMvpApp: Application() { lateinit var injector: AppDiComponent private set override fun onCreate() { super.onCreate() INSTANCE = this injector = DaggerAppDiComponent.builder() .mainScreenModule(MainScreenModule()) .build() } companion object { private var INSTANCE: MyMvpApp? = null @JvmStatic fun get(): MyMvpApp = INSTANCE!! } } 

Ausgeatmet, kehrte zur MainScreen-Klasse zurück. Fügen Sie nun unseren Präsentator in die init () -Methode ein. Vergessen Sie nicht, dass diese Aktion vor dem ersten Zugriff auf die injizierte Variable ausgeführt werden muss. Jetzt sieht unsere Klasse so aus:

 class MainScreen : BaseCompatActivity(), MainScreenContract.View { @Inject lateinit var presenter: MainScreenPresenter override fun init(savedInstanceState: Bundle?) { setContentView(R.layout.activity_main_screen) MyMvpApp.get().injector.inject(this) presenter.attach(this) } } 

Und hier ist die gesamte Grundstruktur unserer Anwendung:



2.4. Fazit

Wir sind also bereit für die minimale Struktur der Anwendung, an der nur die Elemente hängen bleiben. Benötigen Sie eine neue Aktivität? Wir stellen es als eine Komponente dar, die die Benutzeroberfläche von Backstage trennt. Für jede Komponente bestimmen wir, welche Abhängigkeiten wir benötigen (Minimum, Präsentator in Aktivität oder möglicherweise in der Präsentator-API selbst für die Interaktion mit einem Remotedienst oder beispielsweise eine Repository-API für die Arbeit mit einer Datenbank). Registrieren Sie das Modul mit Abhängigkeiten, registrieren Sie das Modul in der Komponente, registrieren Sie sich im Builder, erstellen Sie das Projekt neu, fügen Sie bei Bedarf Abhängigkeiten ein und wiederholen Sie die Iteration für jede neue Komponente.

Natürlich kann sich die Frage stellen: Warum brauchen wir Dolch? Immerhin haben sie hervorragende Arbeit geleistet, oder? Großartig, während die Anwendung klein ist. Wenn es mit Dutzenden von Aktivitäten, Fragmenten, Adaptern, Serveranforderungen, Daten-Caching und anderen Wundern voll wird, gibt es viele Abhängigkeiten, die in einer großen Anwendung schwer zu verfolgen sind, wenn Sie Dependency Injection nicht verwenden. Das Dagger DI-Framework vereinfacht die Implementierung und Nachverfolgung.