Moderne Android-Architekturen

Im Herbst 2018 hat Google die ersten als stabil gekennzeichneten AndroidX-Bibliotheken veröffentlicht. Seitdem sind viele Komponenten hinzugekommen. Ganz neu ist Jetpack Compose, ein deklaratives UI-Framework, das den klassischen View-basierten Ansatz ablösen soll. Überhaupt wird deutlich, dass sich die Entwicklung von Android-Apps immer mehr von den Plattformbestandteilen löst. Aber welche Bibliotheken sollten Sie verwenden? Wie lassen sie sich kombinieren? Und klappt das Zusammenspiel immer reibungslos? Thomas Künneth stellt in seinem Vortrag die wichtigsten Jetpack-Bestandteile vor und entwickelt daraus eine Architektur für moderne Android-Apps.
https://rheinwerk-kkon.de/programm/kuenneth-moderne-android-architekturen/

Transcript

1. Moderne Android- Architekturen Thomas Künneth, MATHEMA GmbH
2. Inhalt Ein bisschen Geschichte Zusammenspiel Plattform und Jetpack Tipps für moderne App-Architekturen Fazit
3. thomas@thomaskuenneth.eu @tkuenneth @tkuenneth https://thomaskuenneth.eu/ @tkuenneth
4. Ein bisschen Geschichte https://unsplash.com/photos/9T346Ij4kGk
5. • Schnelle Entwicklung der Plattform • Anfangs mehrere Versionen pro Jahr • Viele neue Funktionen in kurzer Zeit • Geräte wurden nicht konsequent aktualisiert • Entwickler hatten Schwierigkeiten, Schritt zu halten • Weichen im Code • Macht Code unübersichtlich
6. • Erste Version Support Libraries März 2011 • Ursprünglich Bibliothek, um neue APIs unter alten Geräten nutzen zu können • Wurden Stück für Stück ergänzt und erweitert • Komponenten / Views • Layouts • Hilfsklassen • Debugging-Hilfen
7. • Im Laufe der Jahre Bibliotheks-Zoo entstanden • Schwer nachvollziehbar, welche Funktion in welcher Lib steckt • Versionswirrwarr • Unterschiedliche Jars je nach API-Level • Version in Paketnamen kodiert (...v4...) • Erst mit Android P (API-Level 28) einheitliches Versionierungs- und Packetierungsschema für Support-Bibliotheken
8. • Keine Architekturrichtlinien • Entwickler haben UI-, Fach- und Lifecycle-Logik miteinander verwoben • Je größer die App, desto... • unübersichtlicher der Code • schlechter wartbar • fehleranfälliger
9. • Apps kein monolithischer Block • Sammlung von lose gekoppelten Komponenten • Entscheidung, wann Komponenten aktiviert / deaktiviert werden, trifft… • Benutzer (Navigation) • andere App oder Komponente • System (Speichermangel, Drehung des Geräts)
11. • Android Architecture Components: Komponenten und Best Practices • Wurden auf der I/O 2017 vorgestellt • Mehrere Bestandteile, u. a. • Lifecycle • LifeData • ViewModel
12. Zusammenspiel Plattform und Jetpack https://unsplash.com/photos/CCjgYjUudxE
13. • I/O 2018: Jetpack/AndroidX wird vorgestellt • Sammlung von Bibliotheken und Best Practices • Damals vier Bereiche • UI • Foundation • Behavior • Architecture https://android-developers.googleblog.com/2018/05/use-android-jetpack-to-accelerate-your.html
14. • September 2021 > 80 Jetpack-Komponenten • Google bietet Filterung nach Typen an https://developer.android.com/jetpack/androidx/explorer (derzeit Beyond phones, Data, Graphics, Lifecycle, Media, Navigation, Security, Performance/Test, UI) • Beispiel Lifecycle • lifecycle: „Build lifecycle-aware components that can adjust behavior based on the current lifecycle state of an activity or fragment.“ • loader: „Load data for your UI that survives configuration changes.“
15. • Welche Jetpack-Komponente kann, welche muss ich verwenden? • Wie eng sind Plattform und Jetpack verzahnt? https://unsplash.com/photos/UQ2Fw_9oApU
16. • Einige Bibliotheken gelten als veraltet legacy, localbroadcastmanager, percentlayout • Andere wurden durch neue Implementierungen abgelöst media (media2), emoji (emoji2), viewpager (viewpager2) • preferences nicht veraltet; dennoch „Nachfolger“ • security: „Safely manage keys and encrypt files and sharedpreferences.“ • datastore: „Store data asynchronously, consistently, and transactionally, overcoming some of the drawbacks of SharedPreferences“
17. • android.app.Activity • ...Dialog(): API-Level 15 • ...ManagingCursor(): API-Level 15 • startActivityFrom...(): API-Level 28 und 30 • android.app.Fragment (API-Level 28) • android.preference.Preference (API-Level 29) • android.app.IntentService (API-Level 30) • androidx.activity.ComponentActivity • startActivityForResult() • android.app.LoaderManager (API-Level 28) @Deprecated
18. • fragment: „Segment your app into multiple, independent screens that are hosted within an Activity.“ • loader: „Load data for your UI that survives configuration changes.“ • preference: „Build interactive settings screens without needing to interact with device storage or manage the UI.“ • work: „The WorkManager API makes it easy to schedule deferrable, asynchronous tasks that must be run reliably. These APIs let you create a task and hand it off to WorkManager to run when the work constraints are met.“ • activity: „Access composable APIs built on top of Activity.“
19. • Sind Plattform-Klassen/Pakete veraltet, nach Möglichkeit auf geeignete Jetpack-Komponente migrieren • Fun fact: manchmal verweist Framework-Doku auf veraltete Support-Bibliotheken https://unsplash.com/photos/7esRPTt38nI
20. • Ratsam, sich Liste der Bibliotheken gut anzusehen • Einstiege in die Doku • Komponentenname bekannt: https://developer.android.com/jetpack/androidx/versions • Paketname bekannt: https://developer.android.com/reference/androidx/packages
21. • Häufig verwendet • CameraX (androidx.camera.*) mächtige Alternative zur Plattform-API • Room (androidx.room.*) Persistenzschicht oberhalb von SQLite mit Entities und DAOs • Exoten • Exifinterface (androidx.exifinterface.media) liest und schreibt EXIF-Tags • Palette (androidx.palette.graphics) extrahiert repräsentative Farben aus Grafiken
22. • Bitmap erzeugen/laden, z.B. ImageDecoder.decodeBitmap().asShared() • Instanz einer Palette: Palette.Builder().generate() • Auf relevante Farben zugreifen, z. B. getDominantColor(), getVibrantColor() • Auswahl der Farben kann über Target beeinflusst werden • Swatch liefert passende Vorder- und Hintergrundfarben
23. Tipps für moderne App-Architekturen
24. • Von Kotlin-Features profitieren • Null-Sicherheit • Echte Getter/Setter • Schlanke Syntax • Aktuelle Build Tools verwenden • Unterstützung von Java 11 • Auch Vorteile unter Kotlin • Legacy-Code modernisieren • Falls sinnvoll, nach Kotlin portieren • Code mit modernen Java-Features stabiler machen
25. • Compose neues deklaratives UI Framework • Soll das alte View-System ablösen • Kann mehrere Bibliotheken überflüssig machen cardview, coordinatorlayout, customview, gridlayout, recyclerview, slidingpanelayout, swiperefreshlayout, viewpager2 • Beginn der Arbeiten 2017 • Ende Juli 2021 erste stabile Version
26. • Funktioniert nur mit Kotlin • Grundbausteine „composable functions“ • Keine klassischen Komponenten • Keine Layoutdateien • Aus Sicht des Entwicklers keine Objektgraphen (kein findViewById())
28. • Setzt weiterhin auf Activities • Integration mit setContent • „Mischbetrieb“ möglich (ComposeView, CustomView) • Activty-nahe Konzepte werden obsolet • Action Bar / Toolbar • Burger • Bestehende Architektur-Best Practices bleiben (mit Anpassungen) bestehen
29. • Schon immer viele Formfaktoren und Bildschirmgrößen • Neue Geräteklasse „Foldable“ • Faltbare Anzeigen • Bildschirm besteht aus zwei „Teilen“ • Für optimale Darstellung Abfragen/Anpassungen nötig • Neue Bibliothek Jetpack WindowManager
30. • Einstieg über windowInfoRepository() (androidx.window.layout.WindowInfoRepository) • Abfrage der Fenstergröße mit currentWindowMetrics • Abfrage von DisplayFeatures • Derzeit gibt es „nur“ FoldingFeature • API basiert auf Kotlin Flows
32. • Mit Android 12 systemweit einheitliche Splash Screens • Erste Ansätze seit Oreo • Viele Apps hatten eigene Implementierungen
35. • Mit Android 12 kommt systemweite Volltextsuche • Mehrsprachig • Lokale Speicherung • Ideal für die Indizierung von Daten in der Cloud • Mit Jetpack AppSearch Nutzung unter älteren Plattform-Versionen
36. Walkthrough
37. Fazit https://unsplash.com/photos/uqeaZXZkquw
38. • Durch @Deprecated von Plattform-Paketen Nutzung von Jetpack ein Muss • Kein offizieller „roter Faden“ • Viele Jetpack-Komponenten erhalten kaum Updates • Versionierung und Namensgebung einheitlich • Konzepte innerhalb der Bibliotheken nicht
39. • In Community hitzige Diskussionen bzgl. Nutzung „alter“ Jetpack-Komponenten • Unterstützung von Tablets und Foldables wichtiger als „a oder b“ • Nicht nur neue Bibliotheken nutzen, sondern vorhandenen Code konsequent refactoren
40. • Jede Bibliothek macht die App größer • Noch häufiger Updates als Plattform • Jetpack bereichert Android-Entwicklung • „auf dem Laufenden bleiben“ zeitaufwendig
41. @tkuenneth @tkuenneth @tkuenneth Vielen Dank https://github.com/PacktPublishing/Android-UI-Development-with-Jetpack-Compose/tree/main/chapter_03/ColorPickerDemo https://github.com/tkuenneth/android-demos/tree/master/misc/WindowManagerDemo2 https://github.com/tkuenneth/android-demos/tree/master/misc/JetpackSplashScreenDemo https://github.com/tkuenneth/android-demos/tree/master/misc/PaletteDemo