WebSockets bewusst einsetzen

WebSockets helfen dir, Daten nahezu sofort zwischen App und Server auszutauschen. In Android-Projekten solltest du sie aber nicht als Standardlösung für Networking behandeln. Eine dauerhafte Verbindung kostet Akku, Datenvolumen, Speicher, Server-Ressourcen und Aufmerksamkeit im Code. WebSockets Awareness bedeutet deshalb: Du erkennst, wann eine persistente, bidirektionale Verbindung fachlich nötig ist, und wann normale HTTP-Requests, Push-Nachrichten oder periodische Synchronisation besser passen.

Was ist das?

WebSockets Awareness ist kein einzelnes Android-API, sondern eine Architektur-Fähigkeit. Du verstehst, was WebSockets leisten, welche Kosten sie verursachen und wie sie sich in eine App einfügen, die Kotlin, Jetpack, Compose, Coroutines, Flow und eine saubere Datenebene nutzt.

Ein WebSocket ist eine dauerhaft geöffnete Verbindung zwischen Client und Server. Anders als bei klassischen HTTP-Anfragen wartet die App nicht nur darauf, selbst eine Anfrage zu starten. Beide Seiten können Nachrichten senden, solange die Verbindung lebt. Das passt zu Chats, Live-Statusanzeigen, kollaborativen Bearbeitungen, Lieferverfolgung oder Handelsdaten. Es passt weniger gut zu Daten, die nur gelegentlich aktualisiert werden, etwa Profilinformationen, Einstellungen oder eine Liste von Artikeln, die beim Öffnen einer Ansicht geladen wird.

Das mentale Modell für Anfänger ist: Ein normaler Request ist wie ein gezielter Besuch am Schalter. Du fragst etwas an, bekommst eine Antwort und gehst wieder. Ein WebSocket ist wie eine offene Leitung. Diese Leitung kann sehr nützlich sein, muss aber aktiv gepflegt werden. Du musst wissen, wann sie geöffnet wird, wann sie geschlossen wird, was bei Netzverlust passiert, wie du alte und neue Daten zusammenführst und wie die UI darauf reagiert.

Im Android-Kontext ist besonders wichtig, dass Apps nicht dauerhaft im Vordergrund laufen. Nutzer wechseln Apps, Bildschirme werden rotiert, Prozesse können beendet werden, Netzwerkqualität ändert sich, und der Akku ist begrenzt. Eine WebSocket-Verbindung, die direkt an einen Compose-Screen gebunden ist, wird schnell fragil. Eine Verbindung, die ohne fachlichen Grund im Hintergrund offen bleibt, ist ebenso problematisch. Gute Android-Architektur trennt deshalb UI, Domänenlogik und Datenzugriff. Die Datenebene entscheidet, wie Daten geladen, gespeichert und aktualisiert werden. Die UI beobachtet nur einen Zustand, zum Beispiel als StateFlow.

Die zentrale Regel aus dieser Roadmap lautet: Verwende persistente Verbindungen nur, wenn das Produktproblem ihre Kosten rechtfertigt. “Echtzeit” klingt attraktiv, ist aber kein Selbstzweck. Frage zuerst: Muss der Nutzer diese Änderung wirklich sofort sehen? Muss die App auch Nachrichten senden, ohne vorher einen Request zu starten? Gibt es eine akzeptable Verzögerung von einigen Sekunden oder Minuten? Wenn ja, ist ein WebSocket oft zu viel.

Wie funktioniert es?

Technisch beginnt ein WebSocket meist mit einem HTTP-Handshake. Danach bleibt eine Verbindung offen, über die Client und Server Nachrichten austauschen. Auf Android würdest du dafür typischerweise eine Netzwerkbibliothek wie OkHttp nutzen und die empfangenen Events in Kotlin-Flows übersetzen. Die konkrete Bibliothek ist aber nur ein Detail. Wichtiger ist die Struktur: WebSocket-Code gehört nicht in ein Composable und auch nicht direkt in einen Button-Click-Handler. Er gehört in eine Datenquelle oder ein Repository, das klar beschreibt, welche Datenströme es liefert.

In einer modernen Android-App kann der Datenfluss so aussehen: Eine Remote-Datenquelle hält die WebSocket-Verbindung und übersetzt rohe Nachrichten in Kotlin-Modelle. Ein Repository kombiniert diese Live-Daten mit lokal gespeicherten Daten, etwa aus Room. Das ViewModel beobachtet das Repository über Flow oder StateFlow. Compose sammelt den UI-Zustand lifecycle-bewusst ein, zum Beispiel mit collectAsStateWithLifecycle. Dadurch bleibt die Oberfläche einfach: Sie zeigt den aktuellen Zustand und sendet Nutzeraktionen zurück an das ViewModel. Sie muss nicht wissen, ob die Daten über HTTP, WebSocket oder lokalen Cache kommen.

Der Lebenszyklus ist der kritischste Teil. Eine Verbindung sollte nicht unkontrolliert leben. Du brauchst klare Antworten auf drei Fragen. Erstens: Wann wird verbunden? Typisch ist der Moment, in dem ein Nutzer einen Bereich öffnet, der Live-Daten wirklich braucht, etwa einen Chat-Raum. Zweitens: Wann wird getrennt? Wenn der Bereich verlassen wird, die Session endet oder die App längere Zeit nicht aktiv ist, sollte die Verbindung geschlossen werden. Drittens: Was passiert nach einer Unterbrechung? Mobilfunkwechsel, WLAN-Probleme und Server-Neustarts sind normal. Deine App braucht eine Wiederverbindungsstrategie, aber keine aggressive Endlosschleife, die alle paar Millisekunden neu verbindet.

Dazu kommt Offline-First-Denken. WebSockets liefern Live-Events, ersetzen aber keinen stabilen lokalen Zustand. Wenn deine App nur WebSocket-Nachrichten im Speicher hält, verliert sie beim Prozessende den Kontext. Besser ist oft: Der Server sendet Events, die du in der Datenebene verarbeitest und lokal speicherst. Die UI liest aus dem lokalen Modell. Beim erneuten Start synchronisiert die App den Stand über normale APIs und nutzt den WebSocket danach für Änderungen. So kann der Nutzer auch bei instabilem Netz noch sinnvolle Daten sehen.

Auch Qualität und Release-Praxis hängen daran. WebSockets machen Fehlerbilder schwerer reproduzierbar als einfache Requests. Du solltest Logs für Verbindungszustände haben, Metriken für Verbindungsabbrüche prüfen und Tests für Parser, Repository-Verhalten und Reconnect-Logik schreiben. Im Code-Review sollte auffallen, wenn ein Screen eine Verbindung selbst öffnet, wenn Fehler verschluckt werden oder wenn es keinen Plan für App-Hintergrund, Logout und Token-Ablauf gibt.

In der Praxis

Stell dir eine App mit einem Support-Chat vor. Hier ist ein WebSocket sinnvoll: Nachrichten sollen ohne manuelles Aktualisieren erscheinen, und der Nutzer sendet selbst Nachrichten zurück. Trotzdem würdest du die Verbindung nicht direkt im Compose-Code verwalten. Du kapselst sie in einer Datenquelle und gibst dem Rest der App einen stabilen Stream.

Ein stark vereinfachtes Beispiel kann so aussehen:

interface ChatRealtimeDataSource {
    fun observeMessages(roomId: String): Flow<ChatEvent>
    suspend fun sendMessage(roomId: String, text: String)
    suspend fun close()
}

class ChatRepository(
    private val realtime: ChatRealtimeDataSource,
    private val localStore: ChatLocalStore
) {
    fun observeRoom(roomId: String): Flow<List<ChatMessage>> {
        val liveEvents = realtime.observeMessages(roomId)
            .onEach { event ->
                when (event) {
                    is ChatEvent.MessageReceived -> localStore.upsert(event.message)
                    is ChatEvent.MessageDeleted -> localStore.markDeleted(event.messageId)
                }
            }

        return merge(
            localStore.observeMessages(roomId),
            liveEvents.flatMapLatest { localStore.observeMessages(roomId) }
        ).distinctUntilChanged()
    }

    suspend fun send(roomId: String, text: String) {
        val draft = ChatMessage.createPending(roomId, text)
        localStore.upsert(draft)

        try {
            realtime.sendMessage(roomId, text)
        } catch (error: IOException) {
            localStore.markFailed(draft.id)
        }
    }
}

Das Beispiel ist bewusst nicht vollständig. Es zeigt die Architektur-Idee: Der WebSocket liefert Ereignisse, aber der UI-Zustand kommt aus einem Repository, das lokale Daten berücksichtigt. Der Nutzer sieht seine gesendete Nachricht sofort als ausstehend. Wenn das Senden fehlschlägt, kann die UI einen Fehlerzustand anzeigen. Das ist robuster als eine Oberfläche, die nur auf erfolgreiche WebSocket-Antworten wartet.

Im ViewModel würdest du daraus einen UI-State bauen:

class ChatViewModel(
    private val repository: ChatRepository,
    savedStateHandle: SavedStateHandle
) : ViewModel() {
    private val roomId: String = checkNotNull(savedStateHandle["roomId"])

    val uiState: StateFlow<ChatUiState> =
        repository.observeRoom(roomId)
            .map { messages -> ChatUiState(messages = messages) }
            .stateIn(
                scope = viewModelScope,
                started = SharingStarted.WhileSubscribed(5_000),
                initialValue = ChatUiState()
            )

    fun send(text: String) {
        viewModelScope.launch {
            repository.send(roomId, text)
        }
    }

    override fun onCleared() {
        viewModelScope.launch {
            repository.closeRoomIfNeeded(roomId)
        }
    }
}

Die konkrete Schließlogik hängt von deiner App ab. Wenn mehrere Screens dieselbe Verbindung nutzen, darf ein einzelnes ViewModel sie nicht voreilig schließen. Dann brauchst du eine zentrale Session-Komponente oder ein Repository mit Referenzzählung. Wenn nur ein Chat-Raum aktiv ist, kann das ViewModel das Ende der Nutzung signalisieren. Entscheidend ist, dass die Verantwortung sichtbar und testbar bleibt.

Eine praktische Entscheidungsregel lautet: Nutze einen WebSocket nur, wenn du mindestens zwei Bedingungen erfüllst. Erstens muss der Nutzer einen echten Nutzen aus sehr schnellen Updates ziehen. Zweitens müssen Client und Server während einer Sitzung mehrfach in beide Richtungen kommunizieren. Wenn nur der Server selten etwas mitteilen soll, prüfe Push-Nachrichten. Wenn der Nutzer nur beim Öffnen einer Seite aktuelle Daten braucht, nutze HTTP und Cache. Wenn Daten gelegentlich im Hintergrund aktualisiert werden sollen, prüfe WorkManager oder eine andere geplante Synchronisation.

Eine typische Stolperfalle ist das Koppeln an den falschen Lebenszyklus. Wenn du die Verbindung in einem Composable mit LaunchedEffect startest und bei jeder kleinen Zustandsänderung neu initialisierst, erzeugst du doppelte Verbindungen, verlorene Nachrichten oder schwer erklärbare Bugs. Compose darf Effekte auslösen, aber die eigentliche Netzwerkverantwortung sollte in der Architektur darunter liegen. Ebenso gefährlich ist ein globaler WebSocket, der nach dem Login startet und nie stoppt. Bei Logout, Token-Ablauf oder Nutzerwechsel kann er falsche Daten empfangen oder senden.

Eine zweite Stolperfalle ist fehlende Wiederherstellung nach Netzverlust. Viele Lernende testen nur im stabilen WLAN. In echten Apps wechseln Nutzer zwischen Funkzellen, fahren in den Tunnel oder aktivieren den Flugmodus. Teste deshalb bewusst mit deaktiviertem Netzwerk. Prüfe, ob deine UI den Verbindungsstatus sinnvoll darstellt, ob ausstehende Aktionen erhalten bleiben und ob nach dem Reconnect kein doppelter Datenbestand entsteht. Besonders wichtig sind eindeutige IDs und idempotente Verarbeitung: Wenn dasselbe Event zweimal ankommt, sollte es nicht zweimal als neue Nachricht erscheinen.

Eine dritte Stolperfalle betrifft Akku und Serverlast. Jede offene Verbindung muss verwaltet werden. Wenn tausende Clients verbunden sind, kostet das auch serverseitig Ressourcen. Auf dem Gerät können häufige Heartbeats, aggressive Reconnects und große Nachrichten den Akku belasten. Darum gehört WebSocket Awareness auch in Produktentscheidungen. Du solltest mit Product Ownern oder Backend-Entwicklern klären, welche Latenz wirklich erwartet wird. Manchmal reicht eine Aktualisierung alle 30 Sekunden. Manchmal ist eine Live-Verbindung fachlich korrekt. Der Unterschied liegt nicht im Geschmack, sondern in konkreten Anforderungen.

Für Tests kannst du die Datenquelle als Interface modellieren und im Repository eine Fake-Implementierung verwenden. So prüfst du, ob ein eingehendes MessageReceived-Event lokal gespeichert wird, ob ein Sendefehler den Status korrekt markiert und ob doppelte Events sauber behandelt werden. Für Debugging helfen strukturierte Logs: verbunden, getrennt, Reconnect geplant, Authentifizierung fehlgeschlagen, Nachricht empfangen, Nachricht verworfen. Achte aber darauf, keine sensiblen Inhalte zu loggen. Im Code-Review kannst du gezielt fragen: Wer besitzt die Verbindung? Wann endet sie? Was passiert offline? Welche Datenquelle ist für die UI maßgeblich?

Fazit

WebSockets sind in Android-Apps wertvoll, wenn du echte bidirektionale Echtzeit-Kommunikation brauchst. Sie sind aber keine allgemeine Abkürzung für moderne Datenaktualisierung. Behandle sie als Teil der Datenebene, kombiniere sie mit lokalem Zustand, respektiere den App- und Screen-Lebenszyklus und plane Fehlerfälle von Anfang an ein. Prüfe dein Verständnis praktisch: Baue einen kleinen Chat- oder Status-Prototyp, simuliere Netzabbrüche, beobachte die Logs, schreibe Repository-Tests und achte im Code-Review darauf, ob die Verbindung einen klaren Besitzer und einen klaren fachlichen Grund hat.