Chained Work in Android

Chained Work bedeutet, dass du mehrere Arbeitsschritte nicht zufällig startest, sondern bewusst in eine Reihenfolge bringst. In Android ist das besonders wichtig, sobald Daten geladen, geprüft, gespeichert, synchronisiert oder für die UI vorbereitet werden. Du denkst dabei nicht nur an einzelne Funktionen, sondern an eine kleine Arbeitskette mit klaren Abhängigkeiten: Was muss zuerst passieren, was darf parallel laufen, und welcher Schritt entscheidet über Erfolg oder Abbruch?

Was ist das?

Chained Work ist die koordinierte Ausführung mehrerer Aufgaben, bei denen ein Schritt vom Ergebnis eines anderen Schritts abhängen kann. Ein typisches Beispiel ist eine Synchronisierung: Erst lädst du Daten vom Server, dann validierst du sie, danach speicherst du sie lokal, und erst danach informierst du die Oberfläche über den neuen Zustand. Jeder Schritt hat eine Aufgabe, aber der Nutzen entsteht durch die korrekte Verbindung dieser Schritte.

Für Android-Lernende ist das ein wichtiger Wechsel im Denken. Am Anfang schreibst du oft eine einzelne suspend-Funktion oder reagierst auf einen Button-Klick. In echten Apps reicht das selten aus. Ein Login kann ein Token liefern, das danach für ein Profil-Request gebraucht wird. Ein Import kann mehrere Dateien parallel lesen, muss aber erst nach erfolgreicher Prüfung in die Datenbank schreiben. Eine Compose-Oberfläche soll nicht jedes Zwischenergebnis ungefiltert anzeigen, sondern einen stabilen UI-State erhalten.

Das mentale Modell ist eine Kette aus Knoten und Pfeilen. Ein Knoten ist ein Arbeitsschritt. Ein Pfeil ist eine Abhängigkeit. Wenn ein Pfeil von A nach B zeigt, darf B erst starten, wenn A abgeschlossen ist oder ein brauchbares Ergebnis geliefert hat. Gibt es keinen Pfeil zwischen zwei Schritten, können sie möglicherweise parallel laufen. Dieses Modell hilft dir, Code nicht als lange Folge von zufälligen Aufrufen zu sehen, sondern als gezielte Verarbeitung von Zuständen.

Im Kontext moderner Android-Entwicklung liegt Chained Work oft in der Schicht unter der UI: in Repositorys, Use Cases, ViewModels oder Hintergrundkomponenten. Kotlin Coroutines geben dir dafür die Sprachelemente: suspend, coroutineScope, async, await, strukturierte Nebenläufigkeit und kontrollierte Dispatcher. Flow ergänzt das, wenn Ergebnisse als Strom von Werten entstehen, etwa bei Datenbankupdates, Netzwerkstatus oder Suchanfragen. Wichtig ist: Chained Work ist kein Ersatz für Architektur. Es ist eine Denkweise, mit der du Arbeitsschritte innerhalb deiner Architektur sauber koordinierst.

Wie funktioniert es?

Die einfachste Form ist eine Sequenz. Du rufst mehrere suspend-Funktionen nacheinander auf. Das liest sich fast wie normaler synchroner Code, blockiert aber keinen UI-Thread, wenn du Coroutines korrekt verwendest. Der zweite Schritt bekommt das Ergebnis des ersten Schritts. Wenn der erste Schritt eine Exception wirft, startet der zweite Schritt nicht. Dadurch entsteht eine klare Fehlergrenze.

Eine zweite Form ist parallele Arbeit mit anschließendem Zusammenführen. Dafür nutzt du zum Beispiel coroutineScope und async. Innerhalb von coroutineScope startest du unabhängige Aufgaben parallel. Danach wartest du mit await() auf die Ergebnisse und verarbeitest sie gemeinsam weiter. Der entscheidende Punkt ist die Unabhängigkeit: Parallelität ist nur sauber, wenn die gestarteten Aufgaben nicht heimlich dieselbe veränderbare Ressource beschreiben, keine Reihenfolge voraussetzen und sich bei Fehlern kontrolliert abbrechen lassen.

Strukturierte Nebenläufigkeit ist dabei dein Sicherheitsnetz. Eine Coroutine sollte nicht irgendwo ungebunden gestartet werden, nur damit Arbeit “nebenbei” läuft. Wenn du eine Kette in einem ViewModel startest, gehört sie typischerweise in viewModelScope. Wenn du innerhalb eines Repositorys mehrere parallele Schritte koordinierst, kapselst du sie in coroutineScope. So bleibt klar, wer die Arbeit besitzt und wann sie abgebrochen wird. Das ist wichtig, weil Android-Komponenten Lebenszyklen haben: Eine Oberfläche kann verschwinden, eine Anfrage kann nicht mehr relevant sein, und ein Nutzer kann denselben Vorgang erneut starten.

Dispatcher sind ein weiterer Baustein. Netzwerk- und Datenbankoperationen dürfen nicht auf dem Main-Thread laufen. Eine gute Praxis ist, Dispatcher nicht hart in jeder Funktion zu verstecken, sondern sie bei Bedarf injizierbar zu machen. Dadurch kannst du Tests kontrollierter schreiben. Für Lernende ist die Regel einfach: UI-State wird auf der UI-nahen Ebene aktualisiert, rechen- oder I/O-lastige Arbeit gehört auf passende Dispatcher, und suspend bedeutet nicht automatisch, dass alles auf einem Hintergrundthread läuft.

Flow kommt ins Spiel, wenn eine Arbeitskette nicht nur ein Ergebnis liefert, sondern über Zeit mehrere Zustände. Beispiel: Du zeigst erst einen Ladezustand, dann lokale Cache-Daten, danach frische Netzwerkdaten. Operatoren wie map, flatMapLatest, combine oder catch drücken Abhängigkeiten zwischen Datenströmen aus. Auch hier geht es um Chained Work: Ein Eingabewert löst Folgeschritte aus, veraltete Arbeit kann abgebrochen werden, und die UI sammelt am Ende einen klaren Zustand ein.

Eine typische Stolperfalle ist die Verwechslung von Sequenz und Parallelität. Wenn Schritt B das Ergebnis von Schritt A braucht, darfst du beide nicht parallel starten. Umgekehrt ist es unnötig langsam, zwei unabhängige Requests nacheinander auszuführen, nur weil der Code dann einfacher aussieht. Du brauchst also nicht maximale Parallelität, sondern passende Parallelität. Die beste Kette ist die, deren Abhängigkeiten im Code sichtbar sind.

Eine weitere Stolperfalle ist fehlerarmes Schönwetter-Denken. Chained Work muss beantworten, was bei Fehlern passiert. Brichst du die ganze Kette ab? Kann ein Teilergebnis weiterverwendet werden? Zeigst du einen Fehlerzustand in Compose? Wiederholst du nur einen Schritt oder die gesamte Kette? Diese Entscheidungen gehören nicht zufällig in catch-Blöcke verstreut. Sie sind Teil des Designs.

In der Praxis

Stell dir eine Profilansicht vor. Nach dem Öffnen soll die App ein Benutzerprofil laden und dazu zwei unabhängige Zusatzdaten abrufen: Einstellungen und Statistiken. Das Profil selbst wird zuerst benötigt, weil daraus die Nutzer-ID kommt. Einstellungen und Statistiken können danach parallel geladen werden. Am Ende baust du daraus einen UI-State für Compose.

class ProfileRepository(
    private val api: ProfileApi,
    private val ioDispatcher: CoroutineDispatcher
) {
    suspend fun loadProfileScreen(userName: String): ProfileScreenData =
        withContext(ioDispatcher) {
            val profile = api.fetchProfile(userName)

            coroutineScope {
                val settingsDeferred = async {
                    api.fetchSettings(profile.id)
                }

                val statsDeferred = async {
                    api.fetchStats(profile.id)
                }

                ProfileScreenData(
                    profile = profile,
                    settings = settingsDeferred.await(),
                    stats = statsDeferred.await()
                )
            }
        }
}

An diesem Beispiel siehst du drei Dinge. Erstens ist fetchProfile() sequenziell vorgegeben, weil ohne profile.id die nächsten Schritte nicht möglich sind. Zweitens laufen Einstellungen und Statistiken parallel, weil sie nur dieselbe ID brauchen, aber nicht voneinander abhängen. Drittens ist die parallele Arbeit an coroutineScope gebunden. Wenn eine der beiden parallelen Aufgaben fehlschlägt, wird die andere in der Regel ebenfalls abgebrochen, und der Fehler wandert nach außen. Das ist oft sinnvoller als halb gefüllte Zustände, die später schwer zu erklären sind.

Im ViewModel würdest du diese Kette nicht direkt mit UI-Details mischen. Das ViewModel startet den Vorgang, wandelt Erfolg und Fehler in UI-State um und stellt ihn Compose bereit. So bleibt die Kette testbar und die UI muss nicht wissen, welche Netzwerkschritte in welcher Reihenfolge laufen.

class ProfileViewModel(
    private val repository: ProfileRepository
) : ViewModel() {

    private val _uiState = MutableStateFlow<ProfileUiState>(ProfileUiState.Loading)
    val uiState: StateFlow<ProfileUiState> = _uiState.asStateFlow()

    fun load(userName: String) {
        viewModelScope.launch {
            _uiState.value = ProfileUiState.Loading

            _uiState.value = try {
                val data = repository.loadProfileScreen(userName)
                ProfileUiState.Content(data)
            } catch (exception: IOException) {
                ProfileUiState.Error("Profil konnte nicht geladen werden.")
            }
        }
    }
}

Die Praxisregel dazu lautet: Schreibe zuerst die Abhängigkeiten auf, bevor du async verwendest. Frage dich bei jedem Schritt: Braucht dieser Schritt ein Ergebnis aus einem vorherigen Schritt? Verändert er dieselbe Ressource wie ein anderer Schritt? Muss sein Fehler die gesamte Kette abbrechen? Erst wenn diese Fragen beantwortet sind, entscheidest du über Sequenz oder Parallelität.

Bei dauerhaftem Hintergrundverhalten, etwa Uploads, periodischen Syncs oder Arbeit, die auch nach dem Schließen der App zuverlässig weiterlaufen soll, reicht ein ViewModel nicht aus. Dann gehört die Verarbeitung in eine geeignete Hintergrundlösung der Android-Plattform, häufig mit einer Komponente, die Arbeit planen, wiederholen und Abhängigkeiten verwalten kann. Trotzdem bleibt das gleiche Denkmodell gültig: klare Voraussetzungen, klare Reihenfolge, klare Fehlerbehandlung. Der Unterschied liegt darin, wer die Arbeit besitzt und wie lange sie leben darf.

Für Tests ist Chained Work besonders dankbar, weil du konkrete Erwartungen formulieren kannst. Du kannst prüfen, dass ein abhängiger Schritt nicht ausgeführt wird, wenn der erste Schritt fehlschlägt. Du kannst testen, dass zwei unabhängige Schritte beide gestartet werden und das kombinierte Ergebnis korrekt ist. Mit injizierten Dispatchern und Fake-APIs bleibt dein Test stabil. In einer Continuous-Integration-Pipeline lohnt sich das, weil Nebenläufigkeitsfehler sonst oft erst sporadisch auffallen.

Auch im Code-Review kannst du Chained Work sichtbar prüfen. Suche nach ungebundenen launch-Aufrufen, nach async ohne klaren Nutzen, nach Daten, die aus mehreren Coroutines gleichzeitig verändert werden, und nach Fehlerbehandlung, die zu früh alles verschluckt. Ein häufiger Fehler ist ein try/catch, das eine Exception protokolliert und danach mit leeren Daten weiterläuft. Für die UI sieht das dann wie ein erfolgreicher Zustand aus, obwohl ein wichtiger Schritt gescheitert ist. Besser ist ein expliziter Fehlerzustand oder eine bewusst definierte Teilanzeige.

Ein zweiter Fehler ist zu viel Logik in Compose-Funktionen. Compose sollte Zustände darstellen und Ereignisse weitergeben. Die eigentliche Kette gehört in ViewModel, Use Case oder Repository. Wenn du in einer Composable-Funktion mehrere abhängige Netzwerkaufrufe koordinierst, wird der Code schwer testbar und kann bei Recomposition unerwartet erneut starten. Nutze UI-seitige Effekte gezielt, aber halte die fachliche Arbeitskette außerhalb der Darstellung.

Ein dritter Fehler ist fehlende Beobachtbarkeit. Wenn eine Kette aus mehreren Schritten besteht, brauchst du beim Debugging Orientierung. Benenne Funktionen nach ihrem fachlichen Zweck, protokolliere an sinnvollen Grenzen und prüfe im Debugger, welcher Schritt welches Ergebnis liefert. Du musst nicht jeden Zwischenschritt in Logs kippen. Aber wenn ein Nutzer meldet, dass eine Synchronisierung hängen bleibt, solltest du erkennen können, ob der Fehler beim Laden, Validieren, Speichern oder Veröffentlichen des Zustands entsteht.

Fazit

Chained Work hilft dir, mehrstufige Android-Aufgaben kontrolliert zu bauen: erst die echten Abhängigkeiten erkennen, dann Sequenzen und Parallelität passend ausdrücken, anschließend Fehler und Abbruch sauber behandeln. Übe das an einer kleinen Funktion mit drei Schritten: ein abhängiger Start, zwei parallele Folgeaufrufe und ein gemeinsamer UI-State. Prüfe die Kette im Debugger, schreibe mindestens einen Fehlerfall als Test, und achte im Code-Review darauf, ob die Reihenfolge auch ohne zusätzliche Erklärung erkennbar bleibt.