Repository pattern in depth in Android Kotlin

Introduction

The repository pattern helps organize data access in your app. It acts like a middleman between your app and data sources, making your code cleaner and easier to manage.

When your app needs to get data from multiple places like a database and a web service.

When you want to keep your UI code simple and separate from data handling.

When you want to easily change where your data comes from without changing the whole app.

When you want to test your app by replacing real data sources with fake ones.

When you want to cache data locally to improve app speed and offline use.

Syntax

Android Kotlin

interface UserRepository {
    suspend fun getUser(userId: String): User
    suspend fun saveUser(user: User)
}

class UserRepositoryImpl(
    private val localDataSource: UserLocalDataSource,
    private val remoteDataSource: UserRemoteDataSource
) : UserRepository {
    override suspend fun getUser(userId: String): User {
        val localUser = localDataSource.getUser(userId)
        return localUser ?: remoteDataSource.getUser(userId).also {
            localDataSource.saveUser(it)
        }
    }

    override suspend fun saveUser(user: User) {
        localDataSource.saveUser(user)
        remoteDataSource.saveUser(user)
    }
}

The UserRepository interface defines what data actions are possible.

The UserRepositoryImpl class handles where data comes from and where it is saved.

Examples

A simple repository interface for products.

Android Kotlin

interface ProductRepository {
    suspend fun getProduct(productId: String): Product
}

Implementation tries local data first, then remote if needed.

Android Kotlin

class ProductRepositoryImpl(
    private val localDataSource: ProductLocalDataSource,
    private val remoteDataSource: ProductRemoteDataSource
) : ProductRepository {
    override suspend fun getProduct(productId: String): Product {
        return localDataSource.getProduct(productId) ?: remoteDataSource.getProduct(productId)
    }
}

A fake repository for testing without real data sources.

Android Kotlin

class FakeUserRepository : UserRepository {
    private val fakeData = mutableMapOf<String, User>()
    override suspend fun getUser(userId: String): User = fakeData[userId] ?: User(userId, "Fake User")
    override suspend fun saveUser(user: User) { fakeData[user.id] = user }
}

Sample App

This example shows a repository that first checks local storage for a user. If not found, it fetches from remote and saves locally. It also saves users to both places.

Android Kotlin

data class User(val id: String, val name: String)

interface UserLocalDataSource {
    suspend fun getUser(userId: String): User?
    suspend fun saveUser(user: User)
}

interface UserRemoteDataSource {
    suspend fun getUser(userId: String): User
    suspend fun saveUser(user: User)
}

interface UserRepository {
    suspend fun getUser(userId: String): User
    suspend fun saveUser(user: User)
}

class UserRepositoryImpl(
    private val localDataSource: UserLocalDataSource,
    private val remoteDataSource: UserRemoteDataSource
) : UserRepository {
    override suspend fun getUser(userId: String): User {
        val localUser = localDataSource.getUser(userId)
        return localUser ?: remoteDataSource.getUser(userId).also {
            localDataSource.saveUser(it)
        }
    }

    override suspend fun saveUser(user: User) {
        localDataSource.saveUser(user)
        remoteDataSource.saveUser(user)
    }
}

// Fake implementations for demo
class FakeLocalDataSource : UserLocalDataSource {
    private val storage = mutableMapOf<String, User>()
    override suspend fun getUser(userId: String): User? = storage[userId]
    override suspend fun saveUser(user: User) { storage[user.id] = user }
}

class FakeRemoteDataSource : UserRemoteDataSource {
    private val storage = mutableMapOf<String, User>("1" to User("1", "Alice"))
    override suspend fun getUser(userId: String): User = storage[userId] ?: User(userId, "Unknown")
    override suspend fun saveUser(user: User) { storage[user.id] = user }
}

suspend fun main() {
    val local = FakeLocalDataSource()
    val remote = FakeRemoteDataSource()
    val repo = UserRepositoryImpl(local, remote)

    val user = repo.getUser("1")
    println("User name: ${user.name}")

    repo.saveUser(User("2", "Bob"))
    val user2 = repo.getUser("2")
    println("User2 name: ${user2.name}")
}

Important Notes

Repository pattern helps keep your app's data logic clean and testable.

Use interfaces so you can swap real and fake data sources easily.

Remember to handle errors and loading states when fetching data.

Summary

The repository pattern separates data access from UI code.

It can combine multiple data sources like local and remote.

It makes testing easier by allowing fake data sources.

Practice

1. What is the main purpose of the Repository pattern in Android Kotlin development?

easy

A. To separate data access logic from UI components

B. To handle user interface animations

C. To manage app navigation between screens

D. To define the app's theme and styles

Solution

1. Step 1: Understand the role of Repository

   The Repository pattern abstracts data sources and provides a clean API for data access.

2. Step 2: Identify separation of concerns

   This pattern separates data handling from UI code, improving maintainability and testability.

3. Final Answer:

   To separate data access logic from UI components -> Option A

4. Quick Check:

   Repository pattern = separation of data and UI [OK]

Hint: Repository separates data logic from UI code [OK]

Common Mistakes:

• Confusing Repository with UI or navigation components
• Thinking Repository manages UI animations
• Assuming Repository handles app styling

2. Which of the following is the correct way to declare a Repository interface in Kotlin?

easy

A. object UserRepository { val user = User() }

B. class UserRepository { fun getUser(id: Int): User }

C. fun UserRepository() { return User }

D. interface UserRepository { fun getUser(id: Int): User }

Solution

1. Step 1: Identify interface syntax in Kotlin

   Interfaces use the interface keyword and declare functions without bodies.

2. Step 2: Check each option

   interface UserRepository { fun getUser(id: Int): User } correctly declares an interface with a function signature. class UserRepository { fun getUser(id: Int): User } is a class, not interface. fun UserRepository() { return User } is invalid syntax. object UserRepository { val user = User() } is an object, not an interface.

3. Final Answer:

   interface UserRepository { fun getUser(id: Int): User } -> Option D

4. Quick Check:

   Kotlin interface syntax = interface UserRepository { fun getUser(id: Int): User } [OK]

Hint: Interfaces use 'interface' keyword with function signatures [OK]

Common Mistakes:

• Using class instead of interface for Repository declaration
• Writing invalid function syntax inside interface
• Confusing object declaration with interface

3. Given this Kotlin code snippet, what will be printed?

class UserRepository {
  fun getUserName(id: Int): String {
    return if (id == 1) "Alice" else "Unknown"
  }
}

fun main() {
  val repo = UserRepository()
  println(repo.getUserName(1))
  println(repo.getUserName(2))
}

medium

A. 1\n2

B. Unknown\nAlice

C. Alice\nUnknown

D. Alice\nAlice

Solution

1. Step 1: Analyze getUserName function

   If the id is 1, it returns "Alice", otherwise "Unknown".

2. Step 2: Trace main function calls

   Calling getUserName(1) returns "Alice". Calling getUserName(2) returns "Unknown".

3. Final Answer:

   Alice\nUnknown -> Option C

4. Quick Check:

   id=1 returns Alice, else Unknown [OK]

Hint: Check if condition for id equals 1 [OK]

Common Mistakes:

• Mixing up return values for different ids
• Assuming numeric output instead of strings
• Confusing order of print statements

4. Identify the error in this Kotlin Repository implementation:

class UserRepository {
  fun getUser(id: Int): User {
    return User()
  }
}

class User(val name: String)

fun main() {
  val repo = UserRepository()
  val user = repo.getUser(1)
  println(user.name)
}

medium

A. getUser function should return String, not User

B. User() requires a name parameter but none provided

C. UserRepository class must be an interface

D. println cannot print user.name

Solution

1. Step 1: Check User class constructor

   User class requires a name parameter in its constructor.

2. Step 2: Check UserRepository getUser return

   getUser returns User() without passing name, causing a compile error.

3. Final Answer:

   User() requires a name parameter but none provided -> Option B

4. Quick Check:

   Missing constructor argument causes error [OK]

Hint: Check constructor parameters when creating objects [OK]

Common Mistakes:

• Ignoring required constructor parameters
• Thinking class must be interface for Repository
• Assuming println can't print properties

5. You want to create a Repository that fetches user data from both a local database and a remote API. Which approach best follows the Repository pattern principles?

hard

A. Create a Repository that combines local and remote data sources and exposes a unified API

B. Call the local database directly from UI and ignore remote API

C. Make UI components call remote API and local database separately

D. Use only remote API and discard local data storage

Solution

1. Step 1: Understand Repository role with multiple data sources

   The Repository should abstract and combine data from local and remote sources.

2. Step 2: Evaluate options for separation and abstraction

   Create a Repository that combines local and remote data sources and exposes a unified API correctly combines data sources and exposes a clean API. The other options break separation or ignore data sources.

3. Final Answer:

   Create a Repository that combines local and remote data sources and exposes a unified API -> Option A

4. Quick Check:

   Repository unifies data sources for UI [OK]

Hint: Repository unifies multiple data sources behind one API [OK]

Common Mistakes:

• Accessing data sources directly from UI
• Ignoring one data source completely
• Mixing data calls in UI instead of Repository