Kotlin-Kompetenz prüfen

Kotlin Mastery Review bedeutet, dass du dein Kotlin-Wissen nicht nur an Syntax misst, sondern an der Frage: Führt dein Code zu klaren Android-Entscheidungen? In echten Apps reicht es nicht, data class, sealed interface, Flow oder suspend zu kennen. Du musst erkennen, wann diese Werkzeuge dein UI-State-Model, deine Repository-Grenzen, deine Fehlerbehandlung und deine Nebenläufigkeit sauberer machen.

Was ist das?

Ein Kotlin Mastery Review ist eine bewusste Prüfung deiner Kotlin-Praxis im Android-Kontext. Du schaust dir an, ob du idiomatisches Kotlin verwendest, ob deine Datenmodelle fachliche Zustände korrekt ausdrücken und ob dein asynchroner Code kontrolliert, testbar und lebenszyklusbewusst bleibt. Es geht also nicht um eine Liste einzelner Sprachfeatures, sondern um ihre Wirkung auf Architektur.

Der wichtigste mentale Schritt ist: Kotlin ist kein Ersatz für Architektur, sondern ein Werkzeug, mit dem du Architektur präziser ausdrücken kannst. Eine data class macht ein schlechtes Modell nicht automatisch gut. Eine Coroutine macht blockierenden Code nicht automatisch sicher. Ein Flow löst kein Zustandsproblem, wenn unklar bleibt, welche Schicht für welchen Zustand verantwortlich ist.

Für Android-Lernende ist diese Review-Phase wichtig, weil viele Apps ab einem bestimmten Punkt nicht mehr an Syntax scheitern. Sie scheitern an vermischten Verantwortlichkeiten. Die UI kennt plötzlich Netzwerkdetails. Ein ViewModel enthält Formatierungslogik, Retry-Regeln und Datenbankentscheidungen. Fehler werden als String weitergereicht, obwohl eigentlich ein fachlicher Zustand gemeint ist. Kotlin gibt dir starke Mittel, solche Probleme früh sichtbar zu machen.

Die drei Keywords helfen dir bei der Einordnung. Idioms bedeuten: Du schreibst Kotlin so, wie Kotlin gedacht ist, etwa mit Null-Safety, unveränderlichen Daten, Ausdrucksstärke und klaren Scope-Funktionen. Modeling bedeutet: Du bildest Zustände und Daten so ab, dass falsche Kombinationen schwerer entstehen. Async bedeutet: Du behandelst Arbeit im Hintergrund mit strukturierten Coroutines, klaren Scopes und testbaren Datenströmen.

Wie funktioniert es?

Ein Kotlin Mastery Review funktioniert wie ein Architektur-Check mit Kotlin-Brille. Du nimmst einen konkreten Ausschnitt deiner App, zum Beispiel einen Login-Screen, eine Feed-Liste oder einen Detailbildschirm, und prüfst drei Ebenen: Sprache, Modell und Nebenläufigkeit.

Auf der Sprachebene fragst du: Ist der Code idiomatisch? Kotlin-Code sollte nicht wie übersetztes Java aussehen. Du brauchst nicht überall veränderbare Properties, nullable Werte und lange if-Ketten. Oft sind unveränderliche val-Properties, copy, when, map, filter, let und klare Extension-Funktionen lesbarer. Gleichzeitig ist idiomatisch nicht gleich kurz. Eine verschachtelte Kette aus Scope-Funktionen kann schlechter lesbar sein als zwei saubere Zeilen mit sprechenden Namen.

Auf der Modellebene prüfst du, ob deine Typen die Wahrheit über deine App ausdrücken. Ein typischer Anfängerfehler ist ein UI-State mit vielen nullable Feldern: isLoading, errorMessage, items, isEmpty, selectedItem. Solche Modelle erlauben widersprüchliche Zustände, etwa Laden und Fehler gleichzeitig. Besser ist häufig ein geschlossenes Zustandsmodell mit sealed interface, bei dem jeder Zustand explizit ist. Dadurch zwingt dich der Compiler, neue Fälle in when zu behandeln.

Auf der Async-Ebene schaust du, ob Hintergrundarbeit zur richtigen Schicht gehört. In moderner Android-Architektur startet die UI keine Netzwerkanfragen direkt. Das ViewModel koordiniert UI-nahe Arbeit, ruft Use Cases oder Repositories auf und stellt beobachtbaren State bereit. Repositories kapseln Datenquellen. Coroutines sollten strukturiert sein: Ein viewModelScope passt zu Arbeit, die mit dem ViewModel endet. Langlebige App-Arbeit braucht einen anderen Scope. suspend-Funktionen sollten keine heimlichen globalen Jobs starten, die du nicht mehr abbrechen oder testen kannst.

Bei Flow ist die Denkweise besonders wichtig. Ein Flow ist ein Strom von Werten über Zeit. Er passt gut zu Daten, die sich ändern können: Datenbankinhalte, Suchergebnisse, Einstellungen oder UI-State. Für eine einmalige Aktion reicht oft eine suspend-Funktion. Wenn du alles als Flow modellierst, wird dein Code nicht automatisch besser. Du erhöhst nur die Komplexität, wenn kein echter Datenstrom vorliegt.

Ein gutes Review beachtet außerdem Fehler. Kotlin macht Fehler nicht automatisch typisiert. Du entscheidest, ob du Exceptions intern behandelst, ein Result zurückgibst oder fachliche Fehler als eigene Typen modellierst. Für Android ist wichtig, dass die UI nicht aus technischen Exceptions erraten muss, was angezeigt werden soll. Ein IOException ist ein technisches Detail. Ein Zustand wie Offline oder CouldNotLoadProfile ist für die UI deutlich brauchbarer.

In der Praxis

Stell dir vor, du baust einen Screen, der eine Profilübersicht lädt. Eine schwache Version könnte mehrere mutable Felder im ViewModel halten: loading, profile, error. Das wirkt am Anfang übersichtlich, aber die Kombinationen werden schnell unklar. Ist profile != null und error != null erlaubt? Was passiert beim erneuten Laden? Bleibt alter Inhalt sichtbar? Wird ein Fehler zusätzlich angezeigt?

Ein besseres Kotlin-Modell beschreibt die UI-Zustände ausdrücklich:

sealed interface ProfileUiState {
    data object Loading : ProfileUiState
    data class Content(val profile: UserProfile) : ProfileUiState
    data class Error(val message: String) : ProfileUiState
}

data class UserProfile(
    val id: String,
    val displayName: String,
    val avatarUrl: String?
)

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

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

    fun loadProfile(userId: String) {
        viewModelScope.launch {
            _uiState.value = ProfileUiState.Loading

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

interface ProfileRepository {
    suspend fun loadProfile(userId: String): UserProfile
}

Dieses Beispiel zeigt mehrere Review-Punkte auf einmal. Das UI-State-Modell ist geschlossen. Die UI muss nur when (uiState) auswerten und bekommt klare Fälle. Das Repository bietet eine suspend-Funktion für eine einmalige Ladeoperation. Das ViewModel nutzt viewModelScope, damit die Arbeit beendet wird, wenn das ViewModel nicht mehr gebraucht wird. Die technischen Details der Datenquelle bleiben außerhalb der Composable-Funktion.

In Compose könnte der Screen diesen Zustand sammeln und darstellen. Wichtig ist dabei, dass die Composable nicht selbst die Datenquelle kennt. Sie reagiert auf State und ruft Ereignisse zurück an das ViewModel. So bleibt die UI leichter testbar und du vermeidest, dass Renderlogik und Datenlogik ineinanderlaufen.

Eine praktische Entscheidungsregel lautet: Wenn ein Zustand im UI sichtbar ist, gib ihm einen eigenen Typ oder einen klaren Platz im UI-State. Verwende nullable Felder nicht als Ersatz für Zustandsmodellierung. Nullable Werte sind sinnvoll, wenn ein Wert wirklich fehlen darf, etwa avatarUrl. Sie sind problematisch, wenn sie heimlich einen Screen-Zustand codieren, etwa profile == null bedeutet mal „lädt“, mal „Fehler“, mal „noch nicht gestartet“.

Eine zweite Regel betrifft Async-Code: Starte Coroutines dort, wo du ihre Lebensdauer erklären kannst. Im ViewModel ist viewModelScope meist passend für UI-nahe Arbeit. In einem Repository ist eine suspend-Funktion oft klarer als ein eigener Scope. Vermeide GlobalScope, weil du damit Arbeit vom Lebenszyklus der App entkoppelst und Tests schwerer machst. Wenn du einen externen Scope brauchst, sollte er bewusst injiziert werden und einen klaren Zweck haben.

Eine typische Stolperfalle sind zu viele Scope-Funktionen. Kotlin bietet let, run, also, apply und with. Diese Funktionen sind nützlich, aber sie können Code verschleiern, wenn it und this mehrfach wechseln. In einem Review fragst du deshalb nicht: „Kann ich das kürzer schreiben?“, sondern: „Kann ein anderer Android-Entwickler den Ablauf ohne Raten verstehen?“ Lesbarer Kotlin-Code ist oft kompakt, aber nicht kryptisch.

Eine weitere Stolperfalle ist falsche Fehlerabstraktion. Wenn du überall Result<T> zurückgibst, aber nie zwischen Netzwerkfehler, leerem Ergebnis und fehlender Berechtigung unterscheidest, hast du nur eine Verpackung gebaut. Besser ist ein Modell, das zur Entscheidung der UI passt. Manchmal reicht eine allgemeine Fehlermeldung. In anderen Fällen braucht die UI eine konkrete Aktion, etwa „Erneut versuchen“, „Einloggen“ oder „Berechtigung öffnen“.

Beim Testen zeigt sich, ob dein Kotlin-Modell trägt. Ein gutes UI-State-Modell lässt sich ohne Android-Framework prüfen. Du kannst ein Fake-Repository verwenden, das Erfolg oder Fehler liefert, und dann testen, ob das ViewModel den passenden State setzt. Für Coroutines nutzt du Test-Dispatcher, damit dein Test kontrolliert abläuft. Wenn dein Test viele Wartezeiten, echte Threads oder unklare Nebenwirkungen braucht, ist das ein Hinweis, dass dein Async-Design zu stark verstreut ist.

Auch Code-Review ist hier wertvoll. Bitte nicht nur um Feedback zur Formatierung. Frage gezielt: Sind die Zustände vollständig? Ist der Coroutine-Scope begründet? Sind Exceptions an der richtigen Stelle behandelt? Gibt es nullable Werte, die eigentlich eigene Zustände sein sollten? Diese Fragen bringen dich schneller von Anfänger-Syntax zu professioneller Android-Entwicklung.

Fazit

Kotlin Mastery Review ist deine Brücke zwischen Sprachwissen und belastbarer Android-Architektur. Prüfe bei jedem größeren Feature, ob deine Kotlin-Idioms die Lesbarkeit erhöhen, ob deine Modelle ungültige Zustände verhindern und ob dein Async-Code klare Lebensdauern hat. Nimm dir als Übung einen vorhandenen Screen, zeichne seine UI-Zustände auf, ersetze unklare nullable Kombinationen durch ein explizites Modell und teste mindestens einen Erfolgs- und einen Fehlerfall. Danach lies den Code im Review-Modus: Wenn du erklären kannst, welcher Typ welche Entscheidung schützt und welche Coroutine wann endet, hast du Kotlin nicht nur verwendet, sondern sinnvoll eingesetzt.