Connectivity Awareness in Android

Connectivity Awareness beschreibt die Fähigkeit deiner App, Netzwerkzustände bewusst zu beobachten, einzuordnen und daraus sinnvolle Entscheidungen abzuleiten. Dabei geht es nicht darum, bei jedem Wechsel zwischen WLAN und Mobilfunk sofort hektisch UI und Datenfluss umzubauen. Es geht darum, realistisch zu behandeln, dass Android-Geräte unterwegs sind, Funklöcher haben, in Hotel-WLANs ohne Internet hängen, durch Energiesparmodi eingeschränkt werden oder Anfragen trotz sichtbarer Verbindung fehlschlagen können. Für moderne Android-Apps mit Kotlin, Jetpack Compose und einer sauberen Datenschicht ist diese Denkweise wichtig, weil Netzwerkzustand, Offline-Nutzung und Retry-Verhalten zusammen geplant werden müssen.

Was ist das?

Connectivity Awareness ist kein einzelner Button, keine einzelne Compose-Funktion und auch kein Ersatz für Fehlerbehandlung. Es ist ein Architekturthema: Deine App kennt grob den aktuellen Netzwerkzustand, zieht daraus aber nur vorsichtige Schlüsse. Der wichtigste Satz lautet: „Verbunden“ heißt nicht automatisch „Internet funktioniert“. Android kann dir melden, dass ein Netzwerk vorhanden ist. Dieses Netzwerk kann trotzdem keinen Zugriff auf deinen Server erlauben, hinter einem Captive Portal stehen, DNS-Probleme haben oder so instabil sein, dass deine Anfrage abbricht.

Für Anfänger ist das mentale Modell oft erst ungewohnt. Man möchte gern eine einfache Verzweigung schreiben: Wenn online, lade Daten; wenn offline, zeige Fehler. In echten Apps reicht das nicht. Besser ist ein zweistufiges Modell. Erstens beobachtest du Netzwerkhinweise, zum Beispiel ob überhaupt ein Netzwerk verfügbar ist. Zweitens behandelst du jede konkrete Netzwerkoperation als unsicher und prüfst ihr Ergebnis. Die Quelle der Wahrheit ist nicht das Symbol in der Statusleiste, sondern das Ergebnis deiner Datenoperationen.

Im Android-Kontext verbindet Connectivity Awareness mehrere Bereiche der Roadmap. Die UI zeigt Zustand an, etwa „Offline“ oder „Synchronisierung ausstehend“. Die Datenschicht entscheidet, ob sie aus Cache, Datenbank oder Netzwerk liest. Retry-Logik behandelt vorübergehende Fehler kontrolliert. Offline-First-Ansätze sorgen dafür, dass Nutzer nicht sofort blockiert sind, nur weil eine Anfrage gerade nicht möglich ist. Compose spielt dabei eine wichtige Rolle, weil Netzwerk- und Ladezustände als State modelliert werden und die Oberfläche darauf reagiert.

Wichtig ist auch die Abgrenzung: Connectivity Awareness ist nicht „baue einen eigenen Netzwerkmonitor und entscheide alles zentral“. Du solltest nicht versuchen, alle Probleme vor einer Anfrage vorherzusagen. Der Netzwerkzustand ist ein Signal, kein Beweis. Eine robuste App nutzt dieses Signal für bessere UX und für sinnvolle Entscheidungen, verlässt sich aber weiterhin auf saubere Fehlerbehandlung bei jeder Operation.

Wie funktioniert es?

Technisch besteht Connectivity Awareness meist aus drei Teilen: Beobachtung, Zustandsmodell und Reaktion. Die Beobachtung kann über Android-Systemdienste erfolgen, etwa über Netzwerk-Callbacks. Daraus leitest du ein kleines Modell ab, zum Beispiel Available, Unavailable oder Unknown. Dieses Modell fließt in deine App-Schichten, meistens über Flow, StateFlow oder eine andere reaktive Struktur. In Compose wird daraus beobachtbarer UI-State, der bei Änderungen automatisch neu dargestellt wird.

Das Zustandsmodell sollte bewusst klein bleiben. Zu viele Detailzustände verführen dazu, falsche Sicherheiten zu bauen. Ob ein Gerät über WLAN oder Mobilfunk verbunden ist, ist für viele Datenoperationen weniger wichtig als die Frage, ob ein letzter Sync erfolgreich war und ob lokale Daten angezeigt werden können. Für die UI reicht oft eine klare Information: Die App arbeitet mit lokalen Daten, ein aktueller Abgleich ist nicht möglich oder ein Retry läuft.

In einer sauberen Architektur sitzt die Entscheidung nicht direkt in einem Composable. Ein Composable sollte nicht selbst wissen müssen, wie Netzwerkzustände geprüft werden oder wann eine Anfrage wiederholt wird. Es zeigt State an und sendet Nutzeraktionen nach oben. Die Daten- oder Repository-Schicht koordiniert dagegen lokale Daten, Remote-Quelle, Fehler und Retry-Regeln. Das passt zur Android-Empfehlung, die Datenschicht als Ort für Datenzugriff und Datenpolitik zu behandeln.

Ein typischer Ablauf sieht so aus: Das Repository liefert zunächst lokale Daten aus einer Datenbank. Parallel oder bei Bedarf versucht es, neue Daten vom Server zu laden. Wenn das Netzwerk nicht verfügbar wirkt, kann es den Versuch verschieben oder eine kurze Meldung an den UI-State geben. Wenn eine Anfrage fehlschlägt, speichert es den Fehlerzustand und bietet einen kontrollierten Retry an. Die UI zeigt weiterhin die vorhandenen lokalen Daten, wenn das fachlich vertretbar ist.

Retry ist dabei ein eigenes Thema, aber eng verbunden. Ein Retry ist sinnvoll bei vorübergehenden Fehlern, etwa Zeitüberschreitungen oder kurz fehlender Verbindung. Ein Retry ist nicht sinnvoll bei fachlichen Fehlern wie ungültigen Zugangsdaten, fehlenden Rechten oder fehlerhaften Eingaben. Connectivity Awareness hilft dir also nicht nur zu erkennen, dass eine Wiederholung möglich sein könnte, sondern auch, wann du sie nicht automatisch auslösen solltest.

Compose kommt ins Spiel, sobald du diese Zustände sichtbar machst. Ein StateFlow<UiState> kann beispielsweise enthalten, ob Daten geladen werden, ob lokale Daten angezeigt werden, ob ein Netzwerkhinweis sichtbar ist und ob ein Retry möglich ist. Compose sammelt diesen State und rendert die Oberfläche. Entscheidend ist: Die Oberfläche reagiert auf einen Zustand, sie erfindet ihn nicht selbst.

In der Praxis

Stell dir eine App vor, die eine Liste von Artikeln anzeigt. Die App soll nicht leer erscheinen, nur weil der Nutzer gerade im Zug sitzt. Gleichzeitig soll sie nicht behaupten, alles sei aktuell, wenn der letzte Abgleich fehlgeschlagen ist. Eine praktikable Regel lautet: Lies für die Anzeige zuerst lokal, synchronisiere separat, und behandle Netzwerkstatus nur als Hinweis für Meldungen und Retry-Entscheidungen.

Ein vereinfachtes Modell könnte so aussehen:

sealed interface NetworkState {
    data object Unknown : NetworkState
    data object Available : NetworkState
    data object Unavailable : NetworkState
}

data class ArticleListUiState(
    val articles: List<Article> = emptyList(),
    val isRefreshing: Boolean = false,
    val networkState: NetworkState = NetworkState.Unknown,
    val syncError: String? = null,
    val canRetry: Boolean = false
)

class ArticleViewModel(
    private val repository: ArticleRepository,
    private val networkMonitor: NetworkMonitor
) : ViewModel() {

    val uiState: StateFlow<ArticleListUiState> =
        combine(
            repository.observeArticles(),
            networkMonitor.networkState,
            repository.syncState
        ) { articles, network, sync ->
            ArticleListUiState(
                articles = articles,
                isRefreshing = sync is SyncState.Running,
                networkState = network,
                syncError = (sync as? SyncState.Failed)?.message,
                canRetry = sync is SyncState.Failed
            )
        }.stateIn(
            scope = viewModelScope,
            started = SharingStarted.WhileSubscribed(5_000),
            initialValue = ArticleListUiState()
        )

    fun retrySync() {
        viewModelScope.launch {
            repository.refreshArticles()
        }
    }
}

In Compose würdest du diesen State sammeln und daraus UI ableiten. Du könntest oben eine schmale Offline-Meldung anzeigen, wenn networkState auf Unavailable steht. Gleichzeitig zeigst du weiter die vorhandenen Artikel. Wenn syncError gesetzt ist, bietest du einen Retry-Button an. Der Button ruft retrySync() auf, aber die Entscheidung, was beim Retry passiert, bleibt im Repository.

Die typische Stolperfalle ist eine harte Vorabprüfung nach dem Muster: „Wenn Netzwerk verfügbar, dann API aufrufen, sonst abbrechen.“ Das wirkt ordentlich, ist aber zu grob. Zwischen Prüfung und Anfrage kann sich der Zustand ändern. Außerdem kann eine verfügbare Verbindung trotzdem nicht zu deinem Backend führen. Deshalb brauchst du immer beides: einen beobachteten Netzwerkzustand für bessere UX und robuste Fehlerbehandlung bei der eigentlichen Anfrage.

Eine zweite Stolperfalle ist zu aggressive automatische Wiederholung. Wenn deine App bei jedem Netzwerkwechsel sofort alle fehlgeschlagenen Requests wiederholt, kann sie Akku, Datenvolumen und Server unnötig belasten. Besser ist eine klare Retry-Strategie: kurze automatische Wiederholungen nur bei passenden technischen Fehlern, längere Arbeit über geplante Hintergrundmechanismen, und sichtbare manuelle Wiederholung dort, wo der Nutzer direkt auf ein Ergebnis wartet.

Für eine Lern-App oder eine News-Liste könnte deine Entscheidungsregel so aussehen: Wenn lokale Daten vorhanden sind, zeige sie immer an. Wenn ein Sync fehlschlägt, markiere den Stand als möglicherweise veraltet. Wenn keine lokalen Daten vorhanden sind und keine Verbindung nutzbar ist, zeige eine leere Fehleransicht mit Retry. Wenn eine Anfrage trotz verfügbarer Verbindung fehlschlägt, zeige nicht „Du bist offline“, sondern eine neutralere Meldung wie „Daten konnten nicht geladen werden“.

Auch im Code-Review kannst du Connectivity Awareness prüfen. Frage dich bei jeder Netzwerkstelle: Wird ein API-Fehler behandelt? Gibt es einen Unterschied zwischen leerem Inhalt, Ladezustand und Fehlerzustand? Bleibt die UI mit vorhandenen Daten nutzbar? Wird der Netzwerkstatus als Signal verwendet, oder blockiert er pauschal alle Operationen? Diese Fragen finden oft mehr echte Probleme als die Suche nach einer perfekten Netzwerkprüfung.

Testen kannst du das Thema sehr praktisch. Schalte im Emulator WLAN oder mobile Daten aus, aktiviere den Flugmodus, verwende ein Test-WLAN ohne Internet oder simuliere Fehler in deiner Remote-Datenquelle. Für Unit-Tests kannst du NetworkMonitor als Interface modellieren und im Test verschiedene NetworkState-Werte senden. Ebenso kannst du das Repository so testen, dass es bei einem fehlgeschlagenen Refresh weiterhin lokale Daten liefert und einen passenden Sync-Fehler veröffentlicht.

In Compose solltest du außerdem darauf achten, dass State stabil und verständlich bleibt. Ein Bildschirm sollte nicht flackern, nur weil ein Netzwerk-Callback kurz mehrere Zwischenzustände meldet. Nutze einen klaren UiState, sammle ihn lifecycle-bewusst und lasse die UI nur die Zustände darstellen, die für den Nutzer relevant sind. Nicht jeder technische Netzwerkwechsel muss sichtbar werden.

Fazit

Connectivity Awareness hilft dir, Android-Apps zu bauen, die mit echten mobilen Bedingungen umgehen: Verbindungen wechseln, Anfragen scheitern, Daten können veraltet sein, und Nutzer erwarten trotzdem eine brauchbare Oberfläche. Merke dir vor allem: Netzwerkstatus ist ein Hinweis, kein Erfolgsversprechen. Prüfe dein Verständnis, indem du einen vorhandenen Screen nimmst, lokale Daten, Fehlerzustand und Retry-Verhalten bewusst trennst, dann im Emulator mehrere Netzwerkfehler simulierst und deinen Code im Review auf falsche Online-Annahmen untersuchst.