android-data-layer

Android Data Layer

The data layer coordinates data from multiple sources; its public API is repository interfaces, and its internals (DAOs, API services, DTOs) never leak upward. This skill is the canonical home for the error-propagation model, plus the KMP-Room setup. Related: android-skills:android-retrofit (Retrofit service/OkHttp/Hilt wiring), android-skills:android-dev (overall app architecture).

Error propagation — the layered model

The goal: data-layer errors (IOException / HttpException / SQLiteException) must never reach the ViewModel. Map them to a domain error type at the repository boundary. If the project already has an error convention, match it; otherwise a sealed DataError hierarchy is a reasonable default:

sealed class DataError(message: String, cause: Throwable? = null) : Exception(message, cause) {
    class Network(cause: Throwable) : DataError("Network error", cause)
    class Server(val code: Int, message: String?) : DataError("Server error $code: $message")
    class Local(cause: Throwable) : DataError("Local storage error", cause)
}

// repository = error boundary: catch platform exceptions, return Result<T> (no domain layer) or throw DataError (with one)
suspend fun refreshNews(): Result<Unit> = withContext(io) {
    try { newsDao.insertAll(newsApi.fetchLatest().map(NewsDto::toEntity)); Result.success(Unit) }
    catch (e: IOException) { Result.failure(DataError.Network(e)) }
    catch (e: HttpException) { Result.failure(DataError.Server(e.code(), e.message())) }
}

The boundary moves outward by one layer when a domain layer exists:

1. Data sources throw platform/library exceptions (IOException, HttpException, SQLiteException).
2. Repository is the error boundary — catch those and remap to DataError; never let raw platform types leak. Without a domain layer (simple MVVM): the repository returns Result<T> directly and the ViewModel handles it without knowing about platform exceptions.
3. Use cases (when present) are the Result boundary — the repository instead throws DataError, and the use case catches it and returns Result<T> with a domain-specific error model. Use cases never catch platform exception types.
4. ViewModels handle Result<T> and map it to UI state (explicit loading / success / error).