Entwicklertagebuch: Kennzeichner #4: Jetzt wird’s mobil

News-Bote

Ich bring die Post
Entwicklertagebuch: Kennzeichner #4: Jetzt wird’s mobil

Dr. Windows Entwicklertagebuch KMM Kennzeichner App GitHub Android iOS


Nachdem wir in den letzten Artikeln den Grundstock für die eigentlichen mobilen Applikationen gelegt haben, geht es nun mit diesen selbigen los! Den Anfang macht Android, da wir hier im gleichen Ökosystem von Kotlin und Co. zunächst bleiben können.

Für alle, denen diese Artikelreihe noch unbekannt ist – das habt ihr bislang verpasst, könnt euch aber natürlich nachträglich einlesen:

Wieso mit Android beginnen?​


Ich habe beim Kennzeichner (GitHub) Android gegenüber iOS den Vorzug gegeben, da ich etwas benötigte, um das shared Module während der Entwicklung testen können – Unit-Tests und Co folgen. Das ist unter Android bequemer, da ich nicht die Entwicklungsumgebung von Android Studio auf Xcode wechseln muss. Und außerdem schneller, da kein separates iOS-Framework gebaut werden muss, somit fiel mir die Wahl der „ersten“ App-Plattform leicht.

Technologieauswahl​


Meine Kenntnisse in Richtung Android App Entwicklung sind gelinde gesagt weniger stark ausgeprägt als im Vergleich zu iOS. Somit können verwendete Technologien gegebenenfalls nicht richtig ausgewählt oder falsch verwendet werden. Falls also etwas omnipräsent ist, hinterlasst bitte gerne ein Issue auf GitHub.

Jetpack Compose​


Zur Entwicklung der Oberfläche wird Jetpack Compose verwendet, welches wie das im späteren Projektverlauf verwendete SwiftUI einen deklarativen Stil in der Beschreibung der jeweiligen Oberflächen ermöglicht. Vereinfacht gesagt bedeutet dies, dass man Ansichten in der App mit derselben Programmiersprache definiert, in welcher die Programme auch geschrieben sind. In der Vergangenheit war dies oft unterteilt, so hatte Android Java und XML und iOS hatte Swift oder ObjectiveC und den proprietären Interface-Builder, um der Logik ein Aussehen zu verleihen.

Ein weiterer Grund für Jetpack Compose ist, dass hierfür die gefühlte Lernkurve motivierender ist als der alte Weg über XML-Dateien, Activities, Fragments und Adapters.

Natürlich ist ein Hintergedanke auch, dass ich in diesem Projekt in der Zukunft versuchen möchte, die in Jetpack Compose entwickelte Oberfläche wie auch die Datenlogik aus dem Shared-Modul zwischen beiden Apps teilen zu können.

Für moderne Apps unausweichlich ist ein Light-, aber auch ein Dark-Mode, welcher sich an das System anpasst. Dank der Möglichkeit, mit sogenannten Themes – also Beschreibungen von Farben, Schriften und Formen – zu arbeiten, ist der Aufwand dafür gering.

Des Weiteren sollte man Compose nicht nur als UI-Framework, sondern auch als eine Art State-Flow-Machine ansehen. Hierzu bin ich jedoch noch nicht gekommen, denn man sollte erst das Fundament kennen, bevor man die Antenne auf das Dach setzt – meiner bescheidenen Meinung nach.

Koin als Dependency Injection​


Heutzutage ist Dependency Injection, DI, nicht mehr aus der modernen Softwareentwicklung wegzudenken. Koin ist hier der de facto Standard für Kotlin-basierte Android Projekte.


DI ermöglicht es, auf wichtige Helfer wie Services, Repositories und Co. zuzugreifen, ohne dabei langwierige, kaskadierende Variablen übergeben zu müssen. Für jene, die es interessiert, ist “Dependency inversion” das Buzzword und es sei der passende Artikel von Microsoft Learn als Lektüre empfohlen.

In Microsofts .NET beinhaltet diese Funktionalität selbst und benötigt für DI keine externen Bibliotheken.

Material Design 2​


Für meinen ersten Versuch, eine Android-App gestalterisch zu entwickeln, verwendete ich die in der damaligen Projektvorlage hinterlegten Abhängigkeiten zu Komponenten aus dem Material Design 2 Ökosystem. Mich wunderte, dass hierbei nicht auf die bald ein Jahr alten Material Design 3 Komponenten zurückgegriffen wird. Ein Grund hierfür könnte sein, dass trotz des Alters von MD3 noch nicht alle Komponenten verfügbar sind. Android Kenner können hierzu gerne einen Kommentar hinterlassen.

Eine Migration auf die nun neuste Variante Designsystem, Material You (Material Design 3), ist angedacht, jedoch nicht von hoher Priorität meinerseits.

Entwicklung​


Für alle Android App-Entwickler unter euch wird der aktuelle Stand der App eine Aufgabe weniger Stunden sein, dennoch bin ich sehr zufrieden, wie es für mich als Neuling ausgegangen ist. Elementar für mich bei solch Bastel- und Lernprojekten wie dem Kennzeichner ist, dass der Quelltext simpel, zielführend und vor für mich als Lernender verständlich ist.

Dies bedeutet natürlich auch, dass in gewissen Punkten man Dinge kürzer oder prägnanter hätte schreiben können oder weniger ausladend Dinge hätte kommentieren müssen. Nur wie zuvor erwähnt, ich bin als Nerd ein Egoist, und wenn in einem Bastelprojekt für mich etwas ein Mehrwert bietet, priorisiere ich dies höher als den ultimativen Syntax-Sugar. Im Folgenden möchte ich auf wenige, dafür zentrale Stellen im Quelltext der Android App eingehen.

RegionsScreen.kt​


Dieser Screen oder auch Page vom Kennzeichner ist abhängig von zwei Statuswerten. Ist die App gerade noch im Prozess des Datenladens, so wird eine Ladeanimation angezeigt, ist dieser abgeschlossen, springt der Status um und es wird der eigentliche Inhalt der View dargestellt. In dieser werden alle verfügbaren Regionen in einer Liste aufgezeigt, sie bietet eine Suche und Filterung und ermöglicht es zur Detailseite einer Region zu springen.

Hierbei legte ich viel Wert auf die Wiederverwendung von bestimmten Oberflächenbestandteilen, welche auch an anderen Stellen in der App zum Einsatz kommen. Ein Beispiel hierfür ist das Composable `RegionInformation(region: Region)`, was nicht nur in einem Listeneintrag angezeigt wird, sondern auch in der Detail- und in der Kartenansicht Verwendung findet.

MapScreen.kt​


Die Kennzeichner App für Android baut natürlich stark auf Google Maps auf. Spannend war zu sehen, wie das System oder Google Maps damit klarkommen, wenn man mehrere hundert Marker, auch Pins genannt, auf einen Blick darstellen möchte. Natürlich ist das heutzutage kein Problem mehr – in meiner Anfangszeit wäre das ein Ding der Unmöglichkeit gewesen, Windows Mobile 5 lässt grüßen.

Was mir bisher noch nicht gelang, ist die Bearbeitung, wie der Pin aussieht. Momentan wird der Standard-Marker mit der Akzentfarbe der App verwendet. Ich hätte gerne eine Art Pseudo-Ortseingangschild gehabt. Mal sehen, ob ich das während der Laufzeit des Projektes noch herausfinde.

Angemerkt sei, dass anders als beispielsweise bei Apple Maps auf iOS für die Verwendung von Google Maps auf Android ein API-Key erstellt werden muss und dieser ein Maximum an Anfragen pro Zeitabschnitt besitzt. Mit dem Kennzeichner werden wir wohl sicherlich nie an diese anstoßen.

Kein Surface Duo Support​


Ich habe mich sehr darauf gefreut und nun bin ich wirklich, wieder einmal, hart enttäuscht worden von Microsoft. Mit dem “dahin vegetieren lassen” des Surface Duo ergibt es nicht einmal mehr für mich als Bastler Sinn, das SDK noch einzubauen. Persönlich habe ich wirklich daran geglaubt und bereits erste Schritte unternommen, doch bis Microsoft hier ein Lebenszeichen oder eine Absichtserklärung abgibt, ist dieses Feature nicht mehr eingeplant.

Kommende Schritte​


Der nächste Schritt wird sein, dass die iOS-App das Licht der Welt erblickt. Hierdurch werden sicherlich etliche Schwachstellen an der Shared-API auffallen, welche beseitigt werden möchten, bevor weitere Funktionalität in den Kern wandert. Schlussendlich sollte natürlich auch an die Dokumentation gedacht werden.

Welche Funktion würdet ihr gerne im Kennzeichner sehen? Wie kann man euch, falls ihr auch mit der Android App-Entwicklung beginnen, wollt, die Berührungsängste mit dieser Thematik nehmen? Lasst es mich wissen, entweder in den Kommentaren oder mailt mir an tobias@drwindows.de.

Der gesamte Quelltext liegt wie immer auf GitHub offen für jede/n bereit! Lasst uns weiterhin gemeinsam dieses spannende Bastelprojekt weiterführen. Auf das nächste Dutzend! Vielen Dank für euer stetes Interesse.

zum Artikel...
 
Oben