MVP und Dolch 2 - Android-Skelettanwendung - Teil 1

  • Tutorial
Dieser Artikel richtet sich an Neueinsteiger in die Android-Entwicklung und soll dazu beitragen, die minimal erforderliche Anwendungsstruktur zu erstellen.

So kam es, dass ich vor kurzem mit dem Programmieren für Android angefangen habe - nach einem Monat ohne ein Projekt in der Firma, in der ich arbeite, wurde ich dem Mobile-Entwicklungsteam im Büro von Tata Consultancy Services in Uruguay zugewiesen. Während eines Gesprächs mit dem Teamleiter wurde ich von dem Stack geäußert, mit dem ich mich erst vertraut machte und dann beherrschen musste. Unter anderem gab es das Dagger 2-Framework für DI und MVP als Architekturmuster. Und Kotlin. Aber über ihn ein anderes Mal :)

So begann ich, zunächst die Grundlagen des Android-SDKs zu studieren und dann den gesamten Companion-Stack. Es gab keine Probleme mit dem SDK selbst - es gibt mehr als genug umfassende Informationen darüber im Netzwerk, angefangen bei der offiziellen Dokumentation bis hin zu den Tutorials (besonders das Startandroid-Projekt hat geholfen), aber bei Dagger 2 und MVP gab es einige Schwierigkeiten bei der Android-Entwicklung Dokumentation des ersten und zu dieser Zeit unzureichendes Verständnis des zweiten. Tatsache ist, dass ich vor der mobilen Entwicklung Java-Mikrodienste mit Spring Boot / MVC ausgeführt habe und bereits eine gute Vorstellung davon hatte, was Dependency Injection ist und was MVC ist. Selbst der Name „Spring MVC“ lässt darauf schließen, dass dieses Muster in die Architektur des Projekts eingebettet ist und dessen Verwendung offensichtlich ist. Von Dagger 2 habe ich erwartet, dass es genauso ist wie in Spring "magic" und als ausführliche Dokumentation und Tutorials. Und abgebrochen: P

Trotz ausreichender Ausdauer und Ausdauer ist nichts unmöglich, und das Ergebnis der Recherche war die Umsetzung meiner langjährigen Idee, die in den Tagen entstand, als ich noch 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 Ihnen das Ergebnis meiner Suche trockendrücken - eine Schritt-für-Schritt-Anleitung zum Erstellen eines Gerüsts einer Android-Anwendung mit MVP und Dagger 2. Also, beginnen wir.

1.1 Zusammenfassungen


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



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

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 ihn wie folgt:

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

Im Ansichtspaket erstellen wir die abstrakte Klasse BaseCompatActivity, übernehmen sie von AppCompatActivity und implementieren die neu erstellte BaseView-Schnittstelle. Deklarieren Sie innerhalb der Klasse die abstrakte init-Methode (savedInstanceState: Bundle?) Und implementieren Sie die getContext () - Methode von 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.

Lassen Sie uns nun zum Präsentator übergehen. 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
    }
}

Toll, wir haben die grundlegenden architektonischen Elemente definiert. Nun kommen wir zu den Komponenten, aus denen unsere Anwendung erstellt wird.

1.2. Komponenten


Um damit zu beginnen, erstellen Sie eine com.caesar84mx.mymvcapp.components Paket, es Hauptseite - Paket, das, wiederum, ui Pakete und hinter der Bühne und auf das Paket ui Klasse Mainscreen übertragen:



jetzt aus der Klasse entfernt Hauptseite automatisch generiert , wenn Sie ein Projekt Implementierungsmethode erstellen onCreate () sowie von AppCompatActivity erben und von BaseCompatActivity übernehmen. Jetzt implementieren wir die zuvor in der Basisklasse deklarierte Methode init (). Den gesamten Code, den wir zuvor in die onCreate () -Methode eingefügt hätten, fügen wir ihn ein (die init () -Methode wird in der onCreate () -Methode der Basisklasse aufgerufen):

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

Toll, das View-Element des MVP-Patterns wird erstellt. Nun kommen wir zur Backstage-Komponente unserer Komponente - dem Backstage-Paket. Erstellen Sie die Schnittstelle MainScreenContract - den sogenannten Vertrag, über den wir unser Muster implementieren. In dieser Oberfläche erstellen wir zwei Subinterfaces - Presenter und View:

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

Lassen Sie uns nun zum Pretner übergehen und die MainScreenPresenter-Klasse erstellen:

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

Die Skelettapplikation ist fast fertig, es gibt einige Striche. Fügen Sie in der MainScreen-Klasse die Implementierung der MainScreenContract.View-Schnittstelle hinzu, erstellen und initialisieren Sie die Presenter-Variable: MainScreenPresenter-Variable, und hängen Sie in der Methode init () die Ansicht 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 Presenter erstellt und unsere View-Instanz hinzugefügt (nicht zu verwechseln mit android.view.View), die im Presenter zur Manipulation der Ansicht verwendet wird.

1.3. Abschluss des ersten Teils


Wir haben also die grundlegenden abstrakten Elemente des MVP-Musters erstellt, die jedoch nicht direkt verwendet werden, sondern durch das sogenannte Ein Vertrag ist ein grundlegendes Element jeder Komponente einer Anwendung, das sowohl die Aktionen des view-Elements als auch die Aktionen des Presenter-Elements kombiniert. Ein Vertrag ist ein ziemlich flexibles Element, dessen Zusammensetzung von Komponente zu Komponente variiert und die Komponenten innerhalb einer Architektur unauffällig miteinander verknüpft.

Es sollte beachtet werden, dass das view-Element gemäß dem MVP-Konzept so dumm wie möglich sein sollte, indem nur elementare Aktionen ausgeführt werden, z. B. Text ein- / ausblenden, Hintergrund- oder Textfarbe ändern, Download-Symbol ein- / ausblenden usw. d. Die Methoden, die diesem Element entsprechen, definieren wir in der Subschnittstelle Ansicht des Vertrages. Während wir uns mit der Logik des Präsentators beschäftigen - Geschäftslogik, Datenmanipulation (CRUD), Ausführen von Hintergrundaufgaben usw. Darin entscheiden wir, wann und welche Elemente auf dem Bildschirm angezeigt werden sollen. Dies steht im Gegensatz zu dem im Frühjahr implementierten MVC-Konzept, bei dem sich zwischen einer Geschäftslogik und einer Ansicht ein dummer Controller befindet, der nur Anforderungen aus der Ansicht empfängt und einen Dienst aufruft, der Daten zurückgibt oder andere durch die Geschäftslogik definierte Aktionen ausführt. Für den Moderator geeignete Methoden

Beim Implementieren eines Präsentators wird die Ansicht über die Sichtvariable der BasePresenter-Superklasse bearbeitet, während die der Ansicht entsprechenden Methoden in der Aktivitätsklasse implementiert werden.

Sie fragen sich vielleicht, wo Dagger 2 hier ist und warum hat es uns aufgegeben? Würde die DI-Implementierung auf Android nicht die Eule auf den Globus ziehen? Die Antwort auf die zweite Frage lautet nein. Und warum und warum ist es nötig - im zweiten Teil meines Artikels;)

Jetzt auch beliebt: