Retrofit mit Coroutines und sauberer Fehlerbehandlung
Eine suspend-Funktion in Retrofit, ausgeführt auf dem IO-Dispatcher und in ein Result gekapselt – so trennst du Netzwerkfehler, HTTP-Fehler und Erfolg sauber voneinander.
Netzwerkaufrufe schlagen fehl – WLAN weg, Server down, 500er. Deshalb kapsle ich jeden Retrofit-Aufruf in ein Result und fange die drei wichtigen Fälle getrennt ab: erfolgreiche Antwort, HTTP-Fehler und Verbindungsabbruch. Ab Retrofit 2.6 kannst du suspend-Funktionen direkt im Service deklarieren.
Der Retrofit-Service
data class User(val id: Int, val name: String)
interface ApiService {
@GET("users/{id}")
suspend fun getUser(@Path("id") id: Int): User
}Aufruf mit Fehlerbehandlung
Ich verlagere den Aufruf mit withContext(Dispatchers.IO) auf einen Hintergrund-Thread und unterscheide HttpException (Server hat geantwortet, aber mit Fehlercode) von IOException (gar keine Antwort).
import retrofit2.HttpException
import java.io.IOException
sealed interface ApiResult<out T> {
data class Success<T>(val data: T) : ApiResult<T>
data class Error(val message: String) : ApiResult<Nothing>
}
suspend fun loadUser(api: ApiService, id: Int): ApiResult<User> =
withContext(Dispatchers.IO) {
try {
ApiResult.Success(api.getUser(id))
} catch (e: HttpException) {
ApiResult.Error("Serverfehler ${e.code()}")
} catch (e: IOException) {
ApiResult.Error("Keine Verbindung. Prüfe dein Netzwerk.")
}
}Im ViewModel rufst du das dann in viewModelScope.launch { } auf und mappst das ApiResult auf deinen UI-State. Der Trick ist die Reihenfolge der catch-Blöcke: HttpException zuerst, sonst würde sie von einem breiteren Exception-Block verschluckt.
So halte ich die Netzwerkschicht in Kundenprojekten testbar und robust. Brauchst du eine App, die auch bei wackligem Netz nicht abstürzt? Schreib mir auf bymw.de.
Quellen
Du brauchst mehr als ein Snippet?
Ich entwickle Android-Apps in Kotlin und moderne Websites für Selbstständige und kleine Unternehmen — von der ersten Idee bis zum Release.
Projekt anfragen →Verwandte Snippets
Einstellungen speichern mit DataStore – der moderne Ersatz für SharedPreferences
SharedPreferences ist alt, blockiert den Main-Thread und kennt keine Coroutinen. DataStore macht dasselbe – nur asynchron, typsicher und als Flow. So speicherst du Nutzer-Einstellungen richtig.
Parallele Netzwerkaufrufe mit async/await – zwei Requests, halbe Wartezeit
Wenn ein Screen zwei unabhängige Daten braucht, musst du nicht erst auf den einen und dann auf den anderen Request warten. Mit async und coroutineScope laufen sie parallel – strukturiert und sicher.
Mehrere Flows mit combine() verbinden – Live-Validierung ohne Wirrwarr
Wenn ein Ergebnis von mehreren sich ändernden Werten abhängt – z. B. ob ein Formular abgeschickt werden darf – verbindest du die Flows mit combine(). Das reagiert automatisch, sobald sich irgendeiner ändert.