Repository pattern in Android Kotlin - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

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

Choose the best explanation for why developers use the Repository pattern in Android apps.

A To store user preferences and settings only.

B To directly connect UI components to the database without any abstraction.

C To handle all UI animations and transitions in the app.

D To separate data access logic from UI logic, making code easier to manage and test.

💡 Hint

Think about how to keep your app organized and easy to change.

The Repository pattern acts as a middle layer between data sources and the UI, helping to keep code clean and testable.

❓ ui_behavior

intermediate

How does the Repository pattern affect UI updates when data changes?

In an Android app using LiveData and Repository, what happens when data in the repository changes?

A The UI automatically updates because LiveData observes the data changes from the Repository.

B The UI must be manually refreshed by the user to see new data.

C The Repository directly modifies UI elements to show new data.

D The app crashes because Repository cannot notify the UI.

💡 Hint

Think about how LiveData helps UI react to data changes.

LiveData observes data in the Repository and notifies UI components to update automatically.

❓ lifecycle

advanced

What lifecycle benefit does the Repository pattern provide in Android apps?

How does using a Repository help manage data during configuration changes like screen rotations?

A Repository only works with static data and ignores lifecycle events.

B Repository resets all data when the screen rotates, forcing a reload.

C Repository keeps data consistent and survives configuration changes, avoiding unnecessary reloads.

D Repository causes memory leaks during lifecycle changes.

💡 Hint

Think about how ViewModel and Repository work together during rotations.

Repository combined with ViewModel keeps data stable across lifecycle changes, improving performance.

❓ navigation

advanced

How should the Repository pattern be used with Navigation components?

When navigating between fragments, how does the Repository pattern help with data sharing?

A Repository provides a single source of truth that multiple fragments can access for consistent data.

B Each fragment should create its own Repository instance with separate data.

C Repository should be tightly coupled to navigation actions to control screen changes.

D Repository replaces the Navigation component to handle screen transitions.

💡 Hint

Consider how to share data easily between screens.

A shared Repository allows fragments to access the same data source, ensuring consistency during navigation.

🔧 Debug

expert

What error occurs if Repository returns null LiveData and UI tries to observe it?

Given this Kotlin code snippet, what error will happen? val data: LiveData? = repository.getData() data.observe(viewLifecycleOwner) { value -> println(value) } Options:

A No error; the UI will just not update.

B NullPointerException because data is null and cannot be observed.

C IllegalStateException because LiveData must be initialized before observing.

D ClassCastException because LiveData type is incorrect.

💡 Hint

What happens if you call a method on a null object in Kotlin?

Observing a null LiveData causes a NullPointerException because you cannot call observe on null.

Practice

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

easy

A. To separate data access logic from UI and business logic

B. To handle user interface animations

C. To manage app navigation between screens

D. To store UI layout XML files

Solution

1. Step 1: Understand the role of Repository

   The Repository pattern is designed to manage data operations and provide a clean API to the rest of the app.

2. Step 2: Identify separation of concerns

   It separates data handling from UI and business logic, making the app easier to maintain and test.

3. Final Answer:

   To separate data access logic from UI and business logic -> Option A

4. Quick Check:

   Repository pattern = separation of data logic [OK]

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

Common Mistakes:

• Confusing Repository with UI components
• Thinking Repository manages navigation
• Assuming Repository stores layout files

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

easy

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

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

C. fun UserRepository() { return User }

D. val UserRepository = object { fun getUser(id: Int): User }

Solution

1. Step 1: Identify interface syntax in Kotlin

   Interfaces in Kotlin are declared with the interface keyword followed by function signatures without bodies.

2. Step 2: Match the correct declaration

   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 an interface. Options A, B, and C have incorrect syntax.

3. Final Answer:

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

4. Quick Check:

   Interface declaration uses interface keyword [OK]

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

Common Mistakes:

• Using class instead of interface for Repository
• Incorrect function syntax inside interface
• Trying to instantiate interface directly

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

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

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

medium

A. Unknown\nAlice

B. Alice\nUnknown

C. 1\n2

D. Alice\nAlice

Solution

1. Step 1: Analyze getUserName function logic

   The function returns "Alice" if id is 1, otherwise "Unknown".

2. Step 2: Trace the calls in main()

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

3. Final Answer:

   Alice\nUnknown -> Option B

4. Quick Check:

   id==1 returns Alice, else Unknown [OK]

Hint: Check condition for id==1 to get 'Alice' [OK]

Common Mistakes:

• Mixing up return values for different ids
• Assuming both calls return 'Alice'
• Confusing id with returned string

4. Identify the error in this Repository implementation:

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

Assuming name is not defined anywhere.

medium

A. User class is not imported

B. Missing return type for getUser function

C. Variable 'name' is undefined causing a compilation error

D. Function getUser should be abstract

Solution

1. Step 1: Check variables used in return statement

   The function returns User(id, name), but name is not declared or passed.

2. Step 2: Identify compilation error

   Using an undefined variable causes a compilation error in Kotlin.

3. Final Answer:

   Variable 'name' is undefined causing a compilation error -> Option C

4. Quick Check:

   Undefined variables cause compile errors [OK]

Hint: Check all variables are defined before use [OK]

Common Mistakes:

• Ignoring undefined variables
• Assuming missing imports cause error here
• Thinking function must be abstract

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. Call the local database and remote API directly from the UI layer

B. Store all user data in the UI components for quick access

C. Create separate Repository classes for local and remote and call both from UI

D. Create a Repository class that decides whether to fetch from local or remote and exposes a single method to get user data

Solution

1. Step 1: Understand Repository responsibility

   The Repository should act as a single source of truth and hide data sources from the UI.

2. Step 2: Choose approach that centralizes data logic

   Create a Repository class that decides whether to fetch from local or remote and exposes a single method to get user data centralizes data fetching logic inside the Repository, deciding between local and remote sources.

3. Step 3: Avoid direct data calls in UI

   Options A and C expose data sources to UI, breaking separation of concerns. Store all user data in the UI components for quick access mixes data with UI, which is bad practice.

4. Final Answer:

   Create a Repository class that decides whether to fetch from local or remote and exposes a single method to get user data -> Option D

5. Quick Check:

   Repository centralizes data access [OK]

Hint: Repository hides data sources behind one interface [OK]

Common Mistakes:

• Calling data sources directly from UI
• Splitting data logic across UI and multiple classes
• Storing data inside UI components