1. UI-Controllers
In Android gibt es 2 Arten von UI-Controllern: * Activities * Fragments
Änderungen am Android-System führen im Allgemeinen dazu, dass UI-Controller zerstört und wieder neu erstellt werden Man hat im allgemeinen keinen Einfluss auf diese Vorgänge… Das passiert einfach bei:
-
User Aktionen
-
Rotation
-
Zurück-Button
-
…
-
-
System Events
-
Konfigurationsänderungen
-
Zu wenig Speicher
-
…
-
| Handys raus, App starten und dann rotieren, pausieren, App switchen, etc… Was glaubt ihr passiert hier wohl mit den Applikationen im Hintergund und warum kommen die zum Beispiel beim Switchen wieder zurück an genau die richtige Stelle? |
Daten sollten daher NICHT direkt in Activities oder Fragments gespeichert werden! Diese wären dann nämlich einfach weg.
2. Lifecycles
-
Unterschiedliche Elemente in Android können unterschiedliche Lifecycles haben.
-
Diese bestimmen die Events, die automatisch vom System ausgelöst werden.
-
Das System kann damit die Lebensdauer von Elementen verwalten.
Beispiel: Benötige eine Applikation mit höherer Priorität mehr Speicher, werden pausierte Activities einfach gelöscht.
Dabei verliert man das jeweilige Element natürlich.
Man ist selbst dafür verantwortlich, dass die Daten dieses Prozedere überleben und das Element später wieder aufgebaut werden kann.
2.3. Daten Persistieren
Es gibt die Methoden:
-
onSaveInstanceState()
-
onRestoreInstanceState()
Diese werden automatisch aufgerufen, wenn das System die Daten speichern oder wiederherstellen will. Das ist für kleinere Datenmengen gedacht und funktioniert auch ganz gut.
Für große Datenmengen oder Daten, die schwierig zu serialisieren sind, ist das aber weniger geeignet. Außerdem gibt es noch asynchrone Aufrufe, die noch laufen können, obwohl diese Methoden schon aufgerufen wurden und der UI-Controller gerade zerstört wurde. Dafür brauchen wir dann doch eine andere Lösung.
Ohne System wird das ganze ziemlich schnell unübersichtlich.
3. ViewModel
-
Teil der Android Architektur
-
Speichert und managed UI-Daten unter Berücksichtigung des Activity-Lifecycles
-
Wird bei Konfigurationsänderungen NICHT zerstört!
-
Erlaubt dadurch der Applikation Konfigurationsänderungen zu überstehen
Im ViewModel werden auch externe Datenquellen angebunden (Datenbank, Webservices…)
3.1. ViewModel Lifecycle
-
Das ViewModel wird erst zerstört, wenn die Applikation komplett beendet wird.
Ihr verwendet das ViewModel mit remember() oder mutableStateOf().
|
3.2. Shared Viewmodel
Ein gängiges Problem ist, dass sich zwei Fragments Daten teilen müssen.
-
Das erste selektiert zum Beispiel ein List-Item (z.B. ein Land)
-
Das zweite zeigt Daten zum vom ersten ausgewählten Item an (z.B. das Bundesland)
Hier ist ein ViewModel sehr hilfreich, auf das beide Fragments Zugriff haben.
4. LiveData
-
LiveData ist ein Observable Datenhalter
-
Wird von Android bereitgestellt
-
Wird von ViewModels verwendet, um Daten zu speichern
-
Wird von Activities und Fragments verwendet, um auf Daten zu reagieren
4.1. Observer Pattern
-
ViewModels sollten nichts vom View wissen
-
Der View trägt sich beim LiveData im ViewModel ein, damit er updates bekommt
-
Der View kann Methoden im ViewModel aufrufen, falls ein Benutzer eine Aktion ausführt
4.2. Livecycle-Awareness
-
Schickt nur Updates an aktive Abonnenten (STARTED oder RESUMED)
-
Beim Abonnieren wird ein LifeCylce-Objekt übergeben
-
Wenn dieses Objekt auf DESTROYED wechselt, wird das Abonnement automatisch entfernt
4.3. Vorteile
-
UI zeigt sicher immer den Data-State an
-
Keine Mem-Leaks
-
Keine Crashes wegen gestoppter Activities
-
Kein manuelles Lifecycle-Handling
-
Immer Up-To-Date (auch nach Aufwachen, Config-Änderungen, …)
-
Resourcen teilen (singleton LiveData)
Ihr verwendet LiveData mit observeAsState() oder observe().
|