Heutzutage ist Kotlin aus der Entwicklung für Android nicht mehr wegzudenken und der Standard für neue Apps. Zumal für die Zögerlichen auch die komponentenweise Migration ein einfacher Weg ist, um neue und bessere Teile in Apps einzubauen. Apps werden in Kotlin zwar auf die gleiche Weise entwickelt wie in Java, aber gleichzeitig zeigt die Beobachtung ganz deutlich: Ich kenne keine Entwicklerin und keinen Entwickler, die einmal in einem längeren Projekt auf Kotlin gesetzt haben und freiwillig wieder zu Java zurückwollten. Warum aber ist Kotlin nun so ein Quantensprung in der Entwicklung? Hierzu habe ich vor allem Hypothesen:
- Kotlin ist die modernere Sprache mit der strikteren Typsicherheit, höheren Funktionen und Lambdas und der größeren Flexibilität durch Extension-Funktionen und Mehrplattformoptionen.
- Android profitiert besonders von den Null-Sicherheits-Features von Kotlin, durch die regelmäßige Interaktion mit volatilen Systemservices und wegen des Datenhandlings in Schnittstellen zu Backends und APIs.
- Stabilität ist zunehmend zu einem Qualitätsfaktor von Apps geworden und hat die Originalität abgelöst. Die Erhöhung der Quellcodequalität trifft daher einen Nerv.
Parallel zu Kotlin hat Google weitere Initiativen ergriffen, um die Qualität von Android-Apps zu verbessern und diese in Form der Android Architecture Components und neuen Unterstützungs-Bibliotheken veröffentlicht. Dadurch hat Kotlin den großen Vorteil, dass es keinen Legacy-Code gibt, der vor der Etablierung dieser sauberen Architekturmuster entstand.
Android-Komponenten
Wie schon in der Einleitung gesagt, besteht eine Android-App in Kotlin mit wenigen Ausnahmen nicht aus anderen Komponenten als eine in Java entwickelte. Die Veränderungen in der Entwicklung einer Kotlin-Android-Anwendung lassen sich auf verschiedenen Ebenen finden:
- Organisation von Klassen und Modulen
- Anpassungen des Codestils innerhalb einzelner Klassen
- Nutzung von Android-Kotlin-Extensions
Package-Level und Überblick
Als erstes Beispiel soll die typische Package-Struktur einer App dienen, die Audioinhalte – genauer Meditationen – in strukturierter Form zur Verfügung stellt. Dafür soll eine Model-View-Presenter-Architektur verwendet werden, die im Wesentlichen mit Bordmitteln von Android arbeitet, ohne dass 3rd-Party Libraries benötigt werden.
Die Aufteilung der Pakete unterscheidet sich nur leicht von einer Java-basierten App. In den Packages extension und views werden Extensions und Komponenten gesammelt, die Android oder Kotlin-Klassen erweitern und die übergreifend von allen Use-Cases verwendet werden können. Dieser Erweiterungsmechanismus bringt neue Konsistenz, die in einer Java-Struktur eher für Zersplitterung gesorgt haben. Der zweite Vorteil ergibt sich auf dieser Ebene vor allem durch das Zusammenfassen mehrerer Klassen in einer Datei. Hier ein kurzer Überblick über das Beispiel und seine Inhalte:
In dem Package data werden sowohl die Daten modelliert, die aus dem Internet geladen werden, als auch die lokal verwendeten ViewModels. Hier soll ein Standardstack mit Retrofit2 und OkHttp zum Einsatz kommen. Auf den Einsatz von Reactive Programming wird dieses Projekt verzichten und die Anbindung der API-Aufrufe über einen Service bzw. mithilfe von Coroutines erledigen. Für die Persistenz soll die Google-Bibliothek Room (auch ein Teil der Architekturkomponenten für Android) eingesetzt werden, in der die Datenbanktabellen und DAOs für den Zugriff auf die Daten gehandhabt werden. Die Datenbankabfragen werden mithilfe von LiveData-Klassen und Observer-Klassen gelöst. In beiden Fällen – sowohl bei Persistenz als auch bei der Kommunikation mit externen APIs – gibt es in der Praxis jedoch kein starkes Argument gegen die Nutzung von Reactive-Patterns und Libraries. Bleiben die usecases, in denen die sicht- und anfassbaren Nutzungsfälle der App gruppiert sind.
In dem Package home werden sich das Onboarding und Convenience-Funktionen befinden, um zum Beispiel schnell den zuletzt gehörten Inhalt zu öffnen oder sich inspirieren zu lassen. Selection vereint alle Aufgaben, die der Navigation zur Auswahl des nächsten Audio-Files dienen, sprich alle Listen. Die Komponente player ist hoffentlich sprechend genug, und last but not least sind dem Kauf von Inhalten (purchase) und den Informationsbereichen (information) jeweils ein Package zugeordnet.
Was auf diese Art wegfällt, sind Packages wie util oder misc, die sich ansonsten in fast jedem App-Paket gefunden haben, und in denen dann Methoden zur Konvertierung von Datenformaten, Empty-String-Checks oder E-Mail-Validation zu finden waren. Auch wenn die meisten Entwickler sie mit einem verschämten »eigentlich sollten wir sowas nicht committen« angelegt haben, war es in der Regel schon aus Notwehr notwendig, in Android-Projekten diese Resterampen anzulegen und in regelmäßigen Abständen ungenutzte Methoden zu entfernen.
Dieser Artikel ist ein Auszug aus dem Buch „Kotlin – Einstieg und Praxis“ von Karl Szwillus. Alle Infos zum Buch, das Inhaltsverzeichnis und eine kostenlose Leseprobe findet ihr bei uns im Shop.
Im Buch werden außerdem folgende Android-Komponenten detailliert erklärt:
- Package-Level und Überblick
- Klassenlevel
- Diverse Bestandteile des Android-Frameworks
- Architektur für größere App-Projekte
- Das Architekturmodell MVP (I)
- Das Architekturmodell MVVM
- Erweiterung von Android-Klassen
- Android und Coroutines
- Delegation für Android