Clean Architecture and Repositories

# CHAPTER 22

Clean Architecture and Repositories #

1. Introduction #

2. Learning Objectives #

• Understand the principles of the Repository Pattern in MVVM.

• Decouple data fetching logic from the UI Controller and ViewModel.

• Implement a Single Source of Truth caching strategy.

• Construct a Repository class that abstracts Room DAOs and Retrofit APIs.

• Pass Repository dependencies cleanly into the ViewModel.

3. The Problem: Bloated ViewModels #

• The user opens the app.

• The ViewModel checks if the internet is connected.

• If yes, the ViewModel calls Retrofit to download articles.

• The ViewModel then saves the articles into Room.

• If no, the ViewModel queries Room to get cached articles.

4. The Solution: The Repository #

5. Single Source of Truth Strategy #

1. 1. The ViewModel observes the Room Database via the Repository. (The database is the "Single Source of Truth").

1. 2. Simultaneously, the Repository asks Retrofit for fresh data from the server.

1. 3. Retrofit downloads the fresh data.

1. 4. The Repository saves the fresh data directly into the Room Database.

1. 5. Because Room is being observed (returning LiveData), the database updates instantly, which automatically pushes the fresh data up to the ViewModel and finally to the screen.

6. Building the Repository #

package com.example.repositorydemo

import androidx.lifecycle.LiveData

// The Repository abstracts the data sources!
class UserRepository(private val userDao: UserDao, private val apiService: ApiService) {

    // 1. The ViewModel observes THIS. It always comes straight from the local DB!
    val allUsers: LiveData<List<UserEntity>> = userDao.getAllUsers()

    // 2. The ViewModel calls this to trigger a network refresh
    suspend fun refreshUsersFromNetwork() {
        try {
            // Fetch fresh data from the internet
            val networkUsers = apiService.getUsers()
            
            // Convert network models to database entities (Mapping)
            val userEntities = networkUsers.map { user ->
                UserEntity(id = user.id, name = user.name, email = user.email)
            }
            
            // Delete old data and insert new data into the DB!
            // The LiveData will automatically notify the UI that the DB changed!
            userDao.deleteAllUsers()
            userDao.insertAll(userEntities)
            
        } catch (e: Exception) {
            // Handle no internet connection (the UI will just keep showing the old DB data!)
            println("Network error, relying on cache.")
        }
    }
}

7. Refactoring the ViewModel #

import android.app.Application
import androidx.lifecycle.AndroidViewModel
import androidx.lifecycle.LiveData
import androidx.lifecycle.viewModelScope
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.launch

class UserViewModel(application: Application) : AndroidViewModel(application) {

    // The ViewModel only needs to talk to the Repository!
    private val repository: UserRepository
    val users: LiveData<List<UserEntity>>

    init {
        // Initialize DAO and Network
        val dao = UserDatabase.getDatabase(application).userDao()
        val api = RetrofitClient.apiService
        
        // Pass them to the Repository
        repository = UserRepository(dao, api)
        
        // Connect the LiveData
        users = repository.allUsers
    }

    // Triggered by a "Pull to Refresh" or Activity launch
    fun refreshData() {
        viewModelScope.launch(Dispatchers.IO) {
            repository.refreshUsersFromNetwork()
        }
    }
}

8. The Complete MVVM Flow #

1. 1. Activity/Fragment: Captures user clicks and renders the UI. Observes the ViewModel.

1. 2. ViewModel: Survives rotation. Holds LiveData. Delegates actions to the Repository.

1. 3. Repository: The data traffic controller. Decides when to fetch from API vs. DB.

1. 4. Room DAO (Local): The SQLite database cache (Single Source of Truth).

1. 5. Retrofit (Remote): The internet API.

9. Common Mistakes #

• Bypassing the Repository: Often, developers will write a quick database query directly inside an Activity because it's "faster" than creating a function in the Repository and ViewModel. This instantly breaks the architecture. All data operations MUST strictly flow: Activity -> ViewModel -> Repository -> Data Source.

• Memory Leaks via Context: Passing an Activity Context into a Repository. Repositories should ideally be context-agnostic. If Room requires a context, pass the ApplicationContext via the AndroidViewModel, never the Activity context.

10. Best Practices #

• Dependency Injection (Hilt/Dagger): In our example, the ViewModel manually created the Repository. In enterprise apps, the Repository is "Injected" into the ViewModel constructor automatically using a framework like Hilt. This makes mocking and Unit Testing significantly easier.

• Data Mapping: An API might return a JSON object with 50 fields, but your Database only needs 5 fields. The Repository is the perfect place to execute Data Mapping, converting a complex NetworkUserDto into a lean LocalUserEntity before saving it to Room.

11. Exercises #

1. 1. Draw a flowchart on a piece of paper illustrating the MVVM Repository pattern. Label the arrows denoting where data flows, and where LiveData is observed.

1. 2. In your own project, create a NoteRepository that takes a NoteDao. Move the insertNote logic out of the ViewModel and into the Repository.

12. Coding Challenges #

13. MCQ Quiz with Answers #

14. Interview Questions #

• Q: Explain the Single Responsibility Principle as it relates to the decoupling of the ViewModel and the Repository. Why is it an anti-pattern for a ViewModel to instantiate a Retrofit client directly?

• Q: Detail the "Single Source of Truth" caching paradigm. How does returning LiveData directly from a Room DAO facilitate seamless offline-first synchronization during a network fetch?

• Q: Describe the concept of Data Mapping (DTOs to Entities). Why is it architecturally beneficial for the Repository to perform this mapping rather than the ViewModel or the UI controller?

15. FAQs #

16. Summary #

17. Next Chapter Recommendation #