Repository pattern in depth in Android Kotlin - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Repository Role

What is the main purpose of the Repository pattern in Android app development?

A To abstract data sources and provide a clean API for data access

B To manage network requests directly in the UI layer

C To handle UI rendering and user interactions

D To store UI state and lifecycle events

💡 Hint

Think about separating data logic from UI logic.

The Repository pattern abstracts the data sources (like databases, network, cache) and provides a clean API for the rest of the app to access data without knowing where it comes from.

❓ ui_behavior

intermediate

Repository and LiveData Interaction

Given a Repository that returns LiveData from a Room database, what happens in the UI when the database data changes?

A The UI automatically updates because LiveData notifies observers of changes

B The UI crashes because LiveData cannot be observed

C The UI must manually refresh data by calling the Repository again

D The UI shows stale data until the app restarts

💡 Hint

LiveData is lifecycle-aware and updates observers automatically.

LiveData observes the database and notifies the UI when data changes, so the UI updates automatically without manual refresh.

❓ lifecycle

advanced

Repository and ViewModel Lifecycle

Which statement best describes the lifecycle relationship between a Repository and a ViewModel in Android?

A The Repository is destroyed before the ViewModel to free resources

B The Repository typically outlives the ViewModel and can be shared across multiple ViewModels

C The ViewModel and Repository have the same lifecycle and are always created and destroyed together

D The Repository is recreated every time the ViewModel is accessed

💡 Hint

Consider how many ViewModels might use the same data source.

Repositories are often singleton or scoped to the application, so they can be shared and outlive ViewModels, which are tied to UI lifecycle.

❓ navigation

advanced

Repository Impact on Navigation Flow

How does using a Repository pattern affect navigation between screens that share data in an Android app?

A It prevents data sharing and requires passing data via intents only

B It forces each screen to reload data independently, causing delays

C It allows screens to share data easily by accessing the same Repository instance

D It causes navigation to fail if the Repository is not passed explicitly

💡 Hint

Think about centralized data access and sharing.

A shared Repository instance provides a single source of truth, enabling multiple screens to access and update data consistently without redundant reloads.

🔧 Debug

expert

Debugging Repository Data Inconsistency

You notice your UI shows outdated data even though the Repository fetches fresh data from the network. Which is the most likely cause?

Android Kotlin

class UserRepository(private val api: ApiService, private val dao: UserDao) {
  val users = dao.getUsersLiveData()

  suspend fun refreshUsers() {
    val response = api.fetchUsers()
    if (response.isSuccessful) {
      dao.insertUsers(response.body() ?: emptyList())
    }
  }
}

A The dao.insertUsers method does not insert data into the database

B The LiveData from dao.getUsersLiveData() does not notify observers on database changes

C The API fetchUsers method returns cached data instead of fresh data

D The refreshUsers function is not called or awaited properly, so data is not updated in the database

💡 Hint

Check if the network refresh is triggered and completed before UI update.

If refreshUsers is not called or awaited, the database is not updated, so LiveData emits old data causing UI to show outdated info.

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