Über unsMediaKontaktImpressum
Prof. Dr. Erik Behrends 15. Mai 2019

Mit Android Jetpack die App-Entwicklung beschleunigen

Im Mai 2018 wurde auf der Entwicklerkonferenz Google I/O Android Jetpack angekündigt [1]. Dadurch haben sich für die App-Programmierung in Android einige Änderungen, Neuerungen und Verbesserungen ergeben.

Dieser Artikel erklärt, worum es sich bei Android Jetpack handelt und stellt wesentliche Bestandteile davon vor.
 

Aufbau und Inhalt von Android Jetpack

Mit Android Jetpack wird keine neue Android-Version bezeichnet, es handelt sich vielmehr um eine Sammlung von Bibliotheken und Werkzeugen, mit denen die Entwicklung von Android-Apps laut offizieller Dokumentation leichter gelingen soll. So ermöglichen es vorgegebene Best Practices, komplexe Vorgehensweisen mit geringerem Aufwand im Programmcode umzusetzen, indem hierfür u. a. weniger Boilerplate-Code benötigt wird. Bewährte Entwicklungsansätze wie Data Binding gibt es schon länger – nur werden diese nun unter der Bezeichnung Android Jetpack zusammengefasst und durch weitere Konzepte laufend ergänzt. Außerdem dient dieser griffige Name wohl der Vermarktung, denn die Übersetzung von Jetpack lautet Raketenrucksack. Damit soll ausgedrückt werden, dass mit diesen Werkzeugen die Programmierung von Android-Apps beschleunigt wird.

Android Jetpack besteht aus vier Kategorien [2]:

  1. Foundation: Das Fundament der App-Entwicklung wird u. a. durch Werkzeuge zur Sicherung der Abwärtskompatibilität und erweiterte Kotlin-Sprachunterstützung mit Android KTX gelegt.
  2. Architecture: Die wichtigen Architekturkomponenten wie ViewModel, LiveData und Room für die Strukturierung moderner Android-Apps sind hier enthalten und werden durch die neuen Ansätze zur Navigation ergänzt.
  3. Behavior: In dieser Kategorie befinden sich Bibliotheken, die das Zusammenspiel mit unterschiedlichen Android-Diensten regeln (z. B. für Benachrichtigungen).
  4. UI: Die UI-Komponenten umfassen die verschiedenen Layouts und weitere Ansätze zur Gestaltung attraktiver Android-Apps.

Insgesamt besteht Android Jetpack aus mehr als 25 Bibliotheken, die sich auf diese vier Kategorien verteilen. Möglicherweise wird diese Sammlung in Zukunft um weitere Bestandteile ergänzt. Aufgrund dieses Umfangs werden wir uns in diesem Artikel auf die Beschreibung bestimmter Komponenten der Kategorien Foundation, Architecture und UI beschränken. Dabei profitieren wir vom modularen Aufbau von Android Jetpack, denn jede dieser Bibliotheken kann einzeln verwendet werden. Ebenso können diese in Projekten für ältere Android-Versionen genutzt werden.

Vorbemerkung zu AndroidX

Für den Einsatz der Komponenten aus Android Jetpack stehen APIs bereit, die im Paket androidx.* bereitgestellt werden, welches häufig mit AndroidX bezeichnet wird. Diese APIs sind somit von denen der Android-Plattform getrennt, welche in android.* liegen. Hierdurch können die Bibliotheken in Jetpack häufiger und unabhängig von den API-Levels aktualisiert werden, was tatsächlich alle paar Wochen geschieht. Wer sich regelmäßig über neue Versionen informieren möchte, der kann aktuelle Änderungen in den Release Notes für AndroidX einsehen [3].

Foundation: Die Basis von Android Jetpack

Seit einigen Jahren steht mit der Support Library eine Bibliothek bereit, mit der Android-Entwickler sicherstellen können, dass eine Android-App auch auf älteren Geräten mit dem erwarteten Aussehen und Verhalten funktioniert. In Android Jetpack wird die Support Library mit AppCompat bezeichnet und durch eine entsprechende Abhängigkeit aus AndroidX eingebunden. Für einzelne Activities bedeutet dies, dass diese von der Superklasse androidx.appcompat.app.AppCompatActivity erben sollten, um die erforderliche Abwärtskompatibilität zu erhalten. Ansonsten entspricht die Funktionalität und Verwendung von AppCompat im Wesentlichen der schon zuvor bekannten Support Library. Musste man früher zwischen verschiedenen Versionen der Support Library wählen (z. B. v4 oder v13), so wird AppCompat nun als Teil von AndroidX in einer einheitlichen Version weiterentwickelt.

Es gibt noch weitere Bestandteile der Foundation-Kategorie wie z. B. Frameworks für das automatisierte Testen von Android-Apps inklusive Unit- und Laufzeit-Tests. Diese Werkzeuge sind ausgereift und stehen Entwicklern schon seit längerer Zeit unabhängig von Android Jetpack zur Verfügung.

Wenn man mit Kotlin arbeitet, dann ist die Bibliothek Android KTX besonders interessant. Diese enthält einige Kotlin-Erweiterungen (Kotlin extensions – daher der Name KTX), die gezielt die Verwendung bestimmter Jetpack- und Android-APIs durch kompakten, idiomatischen Kotlin-Code ermöglichen. Ein Beispiel aus der offiziellen Dokumentation zu Android KTX verdeutlicht dies [4]. Oftmals ist in der Android-Programmierung eine Verkettung von Methodenaufrufen nötig, wie hier zu sehen:

sharedPreferences.edit() 
    .putBoolean("myKey", someValue) 
    .apply()

Mit Android KTX kann diese Anweisung in Kotlin wie folgt vereinfacht werden:

sharedPreferences.edit { 
    putBoolean("myKey", someValue) 
}

Durch Android KTX werden also moderne Spracheigenschaften in Kotlin genutzt, um häufige Anwendungsfälle im Code kompakter auszudrücken. Im obigen Beispiel ist dies durch einen Lambda-Ausdruck erfolgt. Geplant ist, dass Android KTX beständig mit weiteren nützlichen Kotlin-Erweiterungen für unterschiedliche Situationen ergänzt wird.

Ein paar Worte zu Kotlin

Seit 2017 kann neben Java auch Kotlin als vollständig unterstützte Programmiersprache für die Entwicklung von Android-Apps eingesetzt werden. Kotlin ist eine elegante Programmiersprache mit einigen modernen Sprachkonzepten, die vieles vereinfacht, was in Java umständlich wirkt. Um nur zwei Beispiele zu nennen: es reicht in Kotlin aus, dass Anweisungen mit einem Zeilenumbruch ohne Semikolon enden und durch die automatische Ableitung von Objekttypen (Typinferenz) kann die Angabe von Typen bei Deklarationen oft weggelassen werden. Außerdem hat Kotlin standardmäßig einen viel strikteren Umgang mit Nullwerten als Java, was zu stabilerem Code führt. Es gibt zudem einige Kotlin-Features, die die Möglichkeiten von Java übersteigen – Data Classes und Extension Functions sind nur zwei Beispiele hierfür.

Laut Google wird Kotlin bereits von der Mehrheit der professionellen Android-Entwickler genutzt. Außerdem wurde im Rahmen der Konferenz Google I/O 2019 angekündigt, dass in der Android-Programmierung in Zukunft Kotlin den Vorzug gegenüber Java erhalten wird und dass neue Jetpack APIs zunächst nur in Kotlin verfügbar sein werden [5]. Deswegen werden wir für die Beispiele in diesem Artikel Kotlin verwenden.

Wer Android-Apps bisher nur mit Java entwickelt hat, dem empfehle ich, neue Projekte mit Kotlin zu beginnen oder einzelne Features in Kotlin umzusetzen, was durch die ausgezeichnete Interoperabilität zu Java gut möglich ist. Dadurch können erste praktische Erfahrungen mit Kotlin gesammelt werden.

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:

1. Data Binding für das Projekt in der Datei build.gradle des App-Moduls aktivieren:

android {
        // ... defaultConfig etc.
        dataBinding {
            enabled true
        }
}

2. Das Layout für den Einsatz von Data Binding konvertieren. Dazu kann in Android Studio auf dem äußersten Element der XML-Datei mit einem Rechtsklick das entsprechende Hilfsmenü ausgewählt werden, wie in Abb. 2 zu sehen.

3. Nun kann im Code bzw. in der Activity die aus dem Layout automatisch generierte Binding-Klasse genutzt werden:

val binding: ActivityMainBinding = DataBindingUtil.setContentView(this, R.layout.activity_main)

4. Die UI-Elemente können hiermit direkt über das in binding referenzierte Objekt angesprochen werden (ohne findViewById):

binding.myText = 'Text durch Data Binding ändern!'

Für den Einsatz von Data Binding muss also keine externe Abhängigkeit eingebunden werden – ein Eintrag im gradle-Skript genügt. Aus dem XML-Layout wird automatisch eine Java-Klasse für das eigentliche Data Binding generiert, die wir im Code verwenden können, um über ein entsprechendes Objekt dieser Klasse direkt auf UI-Elemente zuzugreifen.

Allein dieser einfache Anwendungsfall zeigt den Nutzen von Data Binding, denn Aufrufe von findViewById werden hierdurch nicht mehr benötigt. Allerdings enthält diese Bibliothek noch einige weitere Funktionalitäten. Dazu gehören u. a. Observable-Datentypen, mit denen sich Änderungen in Variablen direkt auf die an sie gebundenen UI-Elemente auswirken, sowie eine mächtige Expression Language und Binding Adapters, mit denen komplexere Verbindungen zwischen XML-Layout und Code ausgedrückt werden können. Weiterhin wird Data Binding häufig im Zusammenspiel mit ViewModel verwendet, indem ein Layout an ein ViewModel-Objekt gebunden wird.

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.

Für die Erstellung solcher Single Activity Apps steht in Android Studio ein neuer grafischer Editor zur Verfügung, mit dem Navigationsgraphen auf intuitive Weise erstellt werden können.

Wie auch bei Layouts für Benutzeroberflächen in einzelnen Screens liegt einem Navigationsgraphen eine XML-Datei zugrunde. Der Ansatz der Single Activity App im Zusammenspiel mit dem Navigationseditor könnte in Zukunft für neue Android-Projekte eine robuste Navigation ermöglichen und einen deutlichen Produktivitätsgewinn in der App-Programmierung bewirken.

UI: Komponenten für attraktive Android-Apps

Die UI-Kategorie enthält einige Bibliotheken, die für das Aussehen einer App und attraktive Benutzeroberflächen zuständig sind. Beispiele hierfür sind Animationen, Farbpaletten und Emojis für ältere Android-Versionen.

Bedeutende Änderungen hat es im Zusammenhang mit den verfügbaren XML-Layouts gegeben. Android-Programmierer können bisher aus einer Reihe verschiedener Arten von Layouts wählen (LinearLayout, FrameLayout, usw.), um verschiedene Anordnungen von UI-Elementen umzusetzen. Inzwischen gibt es mit ConstraintLayout ein mächtiges und flexibles Layout, das die meisten Anwendungsfälle abdeckt.

Mit ConstraintLayout lassen sich responsive Benutzeroberflächen für unterschiedliche Displaygrößen und Ausrichtungen entwickeln. Dies wird u. a. durch dynamische Abstände und verkettete UI-Elemente erreicht. Hierfür stehen ausgezeichnete Werkzeuge im Layout-Editor zur Verfügung, sodass ein ConstraintLayout sich vollständig und zuverlässig durch die grafischen Tools bearbeiten lässt.

Wenn in Android Studio ein neues Projekt erstellt wird, dann besteht das vordefinierte Layout aus einem solchen ConstraintLayout. Allein hieraus kann die wichtige Bedeutung dieses Layout-Typs abgeleitet werden.

ConstraintLayout wird fortlaufend weiterentwickelt und führt mit MotionLayout in Version 2.0 ein weiteres interessantes Layout als Subklasse ein. MotionLayout ermöglicht es, komplexe Animationen für Benutzeraktionen im Layout zu konfigurieren.

Verwendung von Android Jetpack in App-Projekten

Um Android Jetpack in neuen Projekten einzusetzen, muss im entsprechenden Dialog in Android Studio die Verwendung der AndroidX-Artefakte durch Auswahl einer Option ausdrücklich angezeigt werden.

Dadurch stehen AppCompat und ConstraintLayout im neuen Projekt zur Verfügung. Wird außerdem noch Kotlin verwendet, dann wird auch Android KTX enthalten sein. Weitere Bibliotheken werden gemäß Dokumentation durch Anpassungen der gradle-Skripte eingebunden.

Es ist auch möglich, Android Jetpack in bestehenden App-Projekten zu nutzen. Dazu muss das Projekt für die Verwendung von AndroidX umgestellt werden, wozu Android Studio die nötigen Werkzeuge bereitstellt, wie in der Dokumentation zu AndroidX beschrieben [10].

Fazit und Ausblick

Durch Android Jetpack ist die App-Programmierung in Android stark modernisiert und vorangebracht worden. Dabei gibt es viele nützliche Neuerungen auf allen Ebenen der Android-Programmierung: vom verbesserten Umgang mit Datenbanken durch Room bis zur Erstellung responsiver UIs mit ConstraintLayout. Entwickler können durch die Vielzahl nützlicher Konzepte und Tools in Android Jetpack ihre Produktivität steigern und die Qualität der erstellten Apps erhöhen.

Im Laufe der letzten Monate kamen einige neue Bibliotheken zu Android Jetpack hinzu und die bestehenden Komponenten werden beständig weiterentwickelt. Somit wird es bestimmt auch in Zukunft interessante Neuigkeiten rund um das Thema  Android Jetpack geben.

Jetzt durchstarten!

Falls Sie Android Jetpack in Ihren App-Projekten einsetzen wollen, dann könnte Ihnen mein Video-Kurs zu diesem Thema weiterhelfen. Dort lernen Sie schrittweise, wie eine Android-App in Kotlin mit Konzepten aus Android Jetpack entwickelt wird. Der Kurs ist auch für Programmierer geeignet, die noch nie eine Android-App entwickelt haben.

Android Kompaktkurs für den Einstieg mit Jetpack und Kotlin
(incl. Rabatt für Informatik-Aktuell-Leser)

Autor

Prof. Dr. Erik Behrends

Erik Behrends ist Professor für Informatik an der DHBW Lörrach (Duale Hochschule Baden-Württemberg) mit mehr als 15 Jahren Erfahrung in der Softwareentwicklung.
>> Weiterlesen
botMessage_toctoc_comments_9210