Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Moderne Android-Architekturen

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/

Thomas Künneth

September 14, 2021
Tweet

More Decks by Thomas Künneth

Other Decks in Technology

Transcript

  1. • 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
  2. • 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
  3. • 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
  4. • 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
  5. • 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)
  6. • Android Architecture Components: Komponenten und Best Practices • Wurden

    auf der I/O 2017 vorgestellt • Mehrere Bestandteile, u. a. • Lifecycle • LifeData • ViewModel
  7. • 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
  8. • 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.“
  9. • Welche Jetpack-Komponente kann, welche muss ich verwenden? • Wie

    eng sind Plattform und Jetpack verzahnt? https://unsplash.com/photos/UQ2Fw_9oApU
  10. • 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“
  11. • 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
  12. • 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.“
  13. • 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
  14. • 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
  15. • 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
  16. • 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
  17. • 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
  18. • 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
  19. • Funktioniert nur mit Kotlin • Grundbausteine „composable functions“ •

    Keine klassischen Komponenten • Keine Layoutdateien • Aus Sicht des Entwicklers keine Objektgraphen (kein findViewById())
  20. • 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
  21. • 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
  22. • 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
  23. • Mit Android 12 systemweit einheitliche Splash Screens • Erste

    Ansätze seit Oreo • Viele Apps hatten eigene Implementierungen
  24. • 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
  25. • 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
  26. • 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
  27. • Jede Bibliothek macht die App größer • Noch häufiger

    Updates als Plattform • Jetpack bereichert Android-Entwicklung • „auf dem Laufenden bleiben“ zeitaufwendig