Why bother with a repository if I already have an API service and a DAO?

I get this question a lot. When you're first starting, it feels like you're just adding a "middleman" layer that doesn't actually do anything except call another function. But here's the thing: your ViewModel shouldn't care where the data comes from. It shouldn't know if you're using Retrofit for network calls or Room for a local database.

Imagine you decide to switch your local storage from Room to Realm, or you change your API from REST to GraphQL. If your ViewModel calls the DAO directly, you're hunting through your UI logic to fix data plumbing. By using a Repository, the ViewModel just asks for getUser(id), and the Repository handles the "how." It becomes the single source of truth for your data logic.

Where should I actually put the withContext(Dispatchers.IO) call?

This is a common point of friction. You'll see some people putting the dispatcher in the ViewModel and some putting it in the Repository. In my experience, the best approach is to make your Repository functions "main-safe." This means a developer should be able to call any function in your repository from the Main thread without freezing the UI.

I always put the withContext inside the Repository (or even further down in the data source). This keeps the threading concerns encapsulated. Here is how I usually structure it:

class UserRepository(
    private val apiService: UserApiService,
    private val userDao: UserDao
) {
    suspend fun refreshUser(userId: String): User {
        return withContext(Dispatchers.IO) {
            // We are now on a background thread
            val user = apiService.fetchUser(userId)
            userDao.insertUser(user)
            user
        }
    }
}

Now your ViewModel can just call repository.refreshUser(id) inside a viewModelScope.launch without needing to worry about which dispatcher to use.

How do I handle the "network-first, then cache" logic without it getting messy?

This is where the Repository pattern actually earns its keep. Instead of putting if/else blocks all over your UI code to check if the network is down, you wrap that orchestration inside a suspend function. I like to use a pattern where I try the network, and if it fails, I fall back to the local database.

Check out this implementation for a user profile:

suspend fun getUserProfile(userId: String): User {
    return withContext(Dispatchers.IO) {
        try {
            // Try to get the freshest data from the web
            val remoteUser = apiService.fetchUser(userId)
            userDao.insertUser(remoteUser) // Update cache
            remoteUser
        } catch (e: Exception) {
            // Network failed? Grab whatever we have in the DB
            userDao.getUserById(userId) 
                ?: throw Exception("No cached data available and network is down")
        }
    }
}

By doing this, the ViewModel stays clean. It just observes the result and updates the UI, regardless of whether the data came from a server in Virginia or a SQLite file on the device.

📋 Practical Task

Build a Synchronized Product Catalog Repository

Your task is to implement a ProductRepository that manages a list of products. You are provided with a ProductApiService (for remote calls) and a ProductDao (for local storage). Both of these interfaces have suspend functions.

Implement the following requirements in your ProductRepository class:

• Create a function getProducts() that is "main-safe" (uses the correct dispatcher).
• Inside getProducts(), attempt to fetch the product list from the ProductApiService.
• If the network call is successful, save the list to the ProductDao and return the list.
• If the network call fails (throws an exception), catch the error and return the list from the ProductDao.
• If the local database is also empty, throw a custom NoDataException.

Provided Interfaces:

interface ProductApiService {
    suspend fun fetchAllProducts(): List<Product>
}

interface ProductDao {
    suspend fun getAllProducts(): List<Product>
    suspend fun clearAndInsertProducts(products: List<Product>)
}

data class Product(val id: Int, val name: String, val price: Double)
class NoDataException : Exception("No data available")