• Entwicklung/Architektur
  • Methoden
  • Programmiersprachen
• Betrieb
  • Datenbanken
  • Server
  • IT-Security
  • Speicher
  • Netzwerke
  • Virtualisierung
  • Verfügbarkeit
  • Künstliche Intelligenz
• Management und Recht
  • Projektmanagement
  • Digitalisierung
  • IT-Recht
  • IT-Selbständige
• Aktuelles
• Termine
• IT-Jobs

☰

• Entwicklung/Architektur
• Betrieb
• Management und Recht
• News
• IT-Jobs
• Newsletter

Prof. Dr. Erik Behrends 15. Mai 2019

Mit Android Jetpack die App-Entwicklung beschleunigen

Architecture: Komponenten für eine moderne Android-App

In der Architecture-Kategorie sind die sogenannten Architekturkomponenten (Architecture Components) enthalten. Umgekehrt gibt es jedoch in dieser Kategorie weitere Bibliotheken, die manchmal nicht direkt zu den Architekturkomponenten gezählt werden, wie z. B. die neuen Ansätze zur Navigation. In diesem Abschnitt werden wir einige wichtige – aber bei Weitem nicht alle – Architekturkomponenten wie Data Binding, ViewModel, LiveData und Room behandeln. Diese Bibliotheken sind prinzipiell für alle Arten von Android-Apps nützlich, egal ob es sich um einfache oder komplexe Projekte handelt. Zusätzlich werden wir auf neue Aspekte der Navigation eingehen.

Data Binding vereinfacht das Zusammenspiel von UI und Code

In Android-Projekten haben wir gewöhnlich eine Trennung zwischen der Beschreibung von Benutzeroberflächen durch XML-Layouts und den konkreten Funktionalitäten einer App im Programmcode. Diese Aufteilung bewirkt eine gute Trennung der verschiedenen Belange (separation of concerns), denn es lassen sich beispielsweise verschiedene Layouts im Hoch- und Querformat in XML-Dateien erstellen, ohne dass der Code hiervon etwas wissen muss.

Aus Sicht einer Activity oder eines Fragments ist es dennoch häufig zur Laufzeit nötig, Änderungen in bestimmten UI-Elementen durchzuführen. Haben wir z. B. ein TextView-Element mit der ID myText im XML-Layout deklariert, dann kann durch Aufruf der Methode findViewById eine Referenz auf das konkrete UI-Element hergestellt und einer lokalen Variablen zugewiesen werden:

val myTextView = findViewById<TextView>(R.id.myText)

Bei mehreren zu referenzierenden Views führt dies zu umständlichem, sich ständig wiederholendem Boilerplate-Code. Mit Data Binding lässt sich dies durch wenige Schritte vereinfachen:

Mit ViewModel und LiveData den Lebenszyklus meistern

Android-Apps durchlaufen bei Benutzung verschiedene Lebenszyklen. So kann bereits das Drehen des Handys vom Hoch- ins Querformat bewirken, dass die momentan verwendete Activity beendet und neu gestartet wird. Wenn Programmierer diese Änderungen im Lebenszyklus nicht im Code behandeln, dann kann dies dazu führen, dass der aktuelle Zustand einer Activity, wie z. B. Eingaben in Formularfeldern, verloren geht. Der Umgang mit diesen Lebenszyklen im Code kann ziemlich aufwändig und unübersichtlich werden.

Mit ViewModel steht eine Klasse im Paket androidx.lifecycle zur Verfügung, die die Datenverwaltung in Bezug auf Änderungen im Lebenszyklus vereinfacht. Wird ein Objekt vom Typ ViewModel  z. B. in einer Activity verwendet, dann bleibt dieses Objekt erhalten, auch wenn die Activity beendet und neu gestartet wird, wie es u. a. beim Drehen des Geräts geschehen kann.

Um diese Funktionalität zu nutzen, muss eine eigene ViewModel-Klasse (z. B. MyViewModel) lediglich von ViewModel erben:

class MyViewModel : ViewModel() {
    // Eigenschaften und Funktionen des Models definieren
}

Somit kann ein solches ViewModel-Objekt in der Activity wie folgt deklariert werden:

class MyActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {        
        val viewModel = ViewModelProviders.of(this)
                           .get(MyViewModel::class.java)
    }
}

Durch die Erzeugung via ViewModelProviders wird sichergestellt, dass in der Activity ein ggf. bereits zuvor erstelltes ViewModel-Objekt wiederverwendet wird. Somit bleiben hier Daten und Zustände in einer Variablen viewModel vom Typ MyViewModel über Lebenszyklusänderungen der Activity hinaus erhalten.

Dies ist schon eine ziemlich nützliche und praktische Unterstützung im Umgang mit Lebenszyklen und oftmals muss sich ein Entwickler hierbei nun nicht mehr um die vielen zugehörigen Details kümmern. Allerdings bietet ViewModel noch weitere Vorteile, denn eine Kapselung der UI-Logik in einer ViewModel-Klasse außerhalb einer Activity führt zu einer erhöhten Wiederverwendbarkeit und Testbarkeit dieser Funktionalitäten und ermöglicht schlankeren Code in der Activity. Insbesondere kann mit ViewModel eine MVVM-Architektur umgesetzt werden (MVVM steht für Model-View-ViewModel). Ansätze mit MVVM haben sich im Umfeld der Android-Entwicklung in den letzten Jahren als bewährte Konvention etabliert, was durch den Quellcode einiger von Google bereitgestellten Referenz-Apps verdeutlicht wird [6]. Außerdem spielt ViewModel eine zentrale Rolle in der empfohlenen Architektur von Apps, die Android Jetpack einsetzen [7].

Um ViewModel in einem Android-Projekt einzusetzen, muss eine zusätzliche Abhängigkeit zu einem Paket in androidx.lifecycle im gradle-Skript deklariert werden. Hierfür gibt es einige Varianten und dies kann etwas unübersichtlich wirken, da ViewModel einerseits einzeln oder in Kombination mit LiveData eingebunden werden kann und andererseits zügig weiterentwickelt wird. Hierbei kann die Dokumentation der ViewModel-Releases helfen [8].

Ein weiterer Bestandteil von androidx.lifecycle ist LiveData. Diese Bibliothek stellt eine vielseitige und ausgefeilte Implementierung des in der Android-Programmierung allgegenwärtigen Observer-Patterns dar. Ebenso wie ViewModel kümmert sich LiveData automatisch um die Abläufe im Lebenszyklus. Wird ViewModel im Zusammenhang mit Data Binding eingesetzt, d. h. wird ein Layout an ein ViewModel gebunden, dann können relevante Eigenschaften des ViewModels mit LiveData-Typen deklariert werden, damit Änderungen an diesen sich direkt auf die entsprechenden UI-Elemente auswirken. Auch in Bezug auf Daten, die mit Hilfe der Bibliothek Room aus einer Datenbank gelesen werden, kann LiveData von großem Nutzen sein, denn Änderungen an der Datenbank können durch LiveData automatisch direkt an das UI übermittelt werden.

Room räumt den Umgang mit lokalen SQL-Datenbanken auf

Wer für seine Android-App Daten in einer lokalen Datenbank speichert, der verwendet häufig SQLite und kann dazu den Datenbankzugriff direkt mit SQL-Code programmieren, der in Java oder Kotlin eingebettet wird. Bei komplexeren und sich weiterentwickelnden Datenbankstrukturen können Anpassungen an den SQL-Anweisungen einen hohen Aufwand mit sich bringen. Außerdem wird die Korrektheit der SQL-Befehle im Programmcode nicht überprüft, was eine erhöhte Anfälligkeit für Fehler im Code bewirken kann.

In anderen Programmierumgebungen, wie z. B. in der Entwicklung von Webanwendungen, werden häufig ORM-Frameworks eingesetzt (ORM bedeutet Object-Relational-Mapping). Durch diese werden die relationalen oder tabellenartigen Strukturen der SQL-Datenbank weitestgehend automatisch auf die objektorientierten Klassen der verwendeten Programmiersprache abgebildet. Mit Room steht ein entsprechender Ansatz für Android-Projekte zur Verfügung, wodurch der Umgang mit SQLite-Datenbanken wesentlich komfortabler und robuster geworden ist, da Room eine Abstraktion oberhalb der expliziten SQLite-APIs darstellt. Vereinfacht gesagt kümmert sich Room fast vollständig um die Verwaltung der Tabellen in der Datenbank und den Zugriff auf die darin enthaltenen Daten, sodass Entwickler nur relativ wenig eigenen SQL-Code schreiben müssen, der außerdem direkt bei Eingabe in Android Studio auf Korrektheit überprüft wird.

Room macht starken Gebrauch von Annotationen, sodass bei der Einbindung ins Projekt in der Datei build.gradle diese zwei Abhängigkeiten deklariert werden sollten (kapt ist der Annotationsprozessor für Kotlin):

dependencies {
    def room_version = "2.0.0-beta01"
    implementation "androidx.room:room-runtime:$room_version"
    kapt "androidx.room:room-compiler:$room_version"
    // ... weitere Abhängigkeiten des Projekts ...
}

Auch Room wird ständig weiterentwickelt und es erscheinen regelmäßig neue Versionen, sodass die gewünschte, aktuelle Version durch einen Blick in die offiziellen Release Notes von Room ermittelt werden sollte [9].

Wir betrachten nun ein Beispiel für die Verwendung von Room anhand einer einfachen Tabelle für die Speicherung von Filmen. Die Tabelle besteht aus zwei Spalten für eine eindeutige ID als Primärschlüssel und den Namen des Films. Zur besseren Lesbarkeit werden die import-Anweisungen nicht aufgeführt.

Im Code benötigen wir zunächst eine Entity-Klasse, mit der wir eine Zuordnung zu einer Tabelle in der Datenbank festlegen:

@Entity(tableName = "movies")
data class Movie(
    @PrimaryKey(autoGenerate = true) val id: Int,
    val name: String
)

Hierbei sehen wir die bereits erwähnte Verwendung von Annotationen (@Entity und @PrimaryKey). Durch den Zusatz tableName = "movies" legen wir fest, dass die Tabelle movies heißen soll (ansonsten würde sie den Namen movie erhalten). Für den Primärschlüssel geben wir zusätzlich an, dass dessen eindeutige Werte automatisch bei Erstellung neuer Filmeinträge generiert werden sollen. Das Erstellen der entsprechenden Tabelle movies in der Datenbank übernimmt Room.

Danach benötigen wir ein Dao-Interface (Dao steht für Data access object), mit dem wir die gewünschten Funktionen für den Zugriff auf die Daten deklarieren:

@Dao
interface MovieDao {
    @Query("SELECT * FROM movies")
    fun loadAll(): LiveData<List<Movie>>

    @Query("SELECT * FROM movies WHERE name LIKE :name LIMIT 1")
    fun findByName(name: String): LiveData<Movie>

    @Insert
    fun insert(movie: Movie)

    @Delete
    fun delete(movie: Movie)
}

Room sorgt dafür, dass automatisch eine Klasse erzeugt wird, die dieses Interface implementiert. In den @Query-Annotationen geben wir an, welche SQL-Anweisungen auszuführen sind, wenn diese Funktionen aufgerufen werden. Hierbei werden in Android Studio Fehlermeldungen angezeigt, falls wir eine falsche Syntax oder inkorrekte Spalten- bzw. Tabellennamen angeben. Bei den mit @Insert und @Delete annotierten Funktionen erstellt Room automatisch die entsprechenden SQL-Anweisungen. Im Beispiel-Code ist zu sehen, dass bereits LiveData genutzt wird, um die Ergebnisse bei Änderungen direkt ans UI und andere interessierte Aspekte im Code weiterzureichen.

Eine weitere Klasse (z. B. MyDatabase), die eine Subklasse von RoomDatabase sein muss, repräsentiert für Room auf Code-Ebene die Datenbank. Diese wird mit @Database und einer Liste der relevanten Entities annotiert und stellt das konkrete MovieDao-Objekt für den Datenzugriff durch eine abstrakte Funktion bereit (für die automatische Implementierung dieser Funktion ist erneut Room zuständig):

@Database(entities = arrayOf(Movie::class), version = 1)
abstract class MyDatabase : RoomDatabase() {
    abstract fun movieDao(): MovieDao
}

Nun können wir eine Instanz der Room-Datenbank wie folgt anfordern und beispielhaft einen Film in die Datenbank eintragen:

val db = Room.databaseBuilder(
            applicationContext,
            MyDatabase::class.java, "my-db-name"
        ).build()

db.movieDao().insert(Movie(name="Mein erster Film"))

Diese vereinfachten Beispiele deuten an, dass Room einen bequemen und soliden Ansatz für den Umgang mit SQLite-Datenbanken in Android darstellt. Room ist eine mächtige Bibliothek, die viele weitere Einsatzmöglichkeiten enthält und auch komplexere Anwendungsfälle unterstützt.

Navigation

Die zuvor besprochenen Komponenten Data Binding, ViewModel, LiveData und Room werden zu den Architekturkomponenten gezählt. Navigation ist ein Beispiel einer weiteren Bibliothek in der Architecture-Kategorie von Android Jetpack. Sie enthält Best Practices für Navigationsstrukturen in Android-Apps und erweitert Android Studio um einen neuen grafischen Editor, mit dem Navigationsgraphen erstellt werden können.

Besteht eine Android-App aus mehreren Screens, dann ermöglicht Navigation, dass diese von Nutzern der App erreicht werden können (evtl. auf verschiedene Weisen). Hierfür bietet Android einige Ansätze, wie das Wechseln von einer Activity zu einer anderen mittels Intents oder den Austausch von Fragmenten innerhalb der Activities.

Navigation in Android Jetpack favorisiert einen Ansatz, der Single Activity genannt wird. Eine App besteht demnach nur aus einer einzigen Activity und mehreren Fragmenten, die jeweils in dieser Activity dargestellt werden. Die Navigation im UI kann durch ein ausklappbares Seitenmenü (navigationdrawer) oder Registerkarten (tab navigation) erfolgen, aber letztendlich wird bei einem Navigationsschritt lediglich das aktuell angezeigte Fragment durch ein anderes ersetzt.

Verwendung von Android Jetpack in App-Projekten

Autor