Use cases / Interactors in Android Kotlin - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is the main role of a Use Case (Interactor) in Android app architecture?

Choose the best description of what a Use Case (Interactor) does in an Android app.

A It handles user interface rendering and animations.

B It stores data directly in the database without any processing.

C It manages the app's business logic and coordinates data flow between repositories and UI.

D It handles network requests and responses only.

💡 Hint

Think about where the app's core rules and decisions happen.

Use Cases (Interactors) contain the business logic. They decide how data is processed and passed between data sources and the UI.

❓ ui_behavior

intermediate

How does a Use Case affect UI updates in an Android app?

Which option best describes how a Use Case interacts with the UI layer?

A It directly updates UI elements like buttons and text views.

B It provides processed data to the ViewModel or Presenter, which then updates the UI.

C It listens to UI events and handles user clicks directly.

D It manages UI animations and transitions.

💡 Hint

Consider separation of concerns between business logic and UI rendering.

Use Cases do not manipulate UI directly. They prepare data and pass it to ViewModel or Presenter, which updates the UI.

❓ lifecycle

advanced

When should a Use Case be invoked in the Android app lifecycle?

At which point in the app lifecycle is it best to call a Use Case to fetch data?

A Inside the ViewModel when the UI requests data, typically after the UI is ready.

B Inside the Application class's onCreate method.

C Inside the Activity's onCreate method before setting the content view.

D Directly inside the Repository when the app starts.

💡 Hint

Think about where UI logic and data fetching should be separated.

Use Cases are usually called by the ViewModel after the UI is ready to display data, ensuring separation of concerns and lifecycle safety.

❓ navigation

advanced

Can a Use Case handle navigation logic in an Android app?

Which statement about Use Cases and navigation is correct?

A Use Cases should only handle business logic; navigation should be handled by the UI layer or navigation controllers.

B Use Cases manage navigation by calling Android Navigation components directly.

C Use Cases replace the need for navigation components.

D Use Cases should directly trigger navigation actions to switch screens.

💡 Hint

Consider separation of concerns between business logic and UI navigation.

Use Cases focus on business rules and data. Navigation is a UI concern handled by controllers or navigation components.

🔧 Debug

expert

What is the likely cause if a Use Case returns stale data despite repository updates?

You updated data in the repository, but the Use Case still returns old data. What is the most probable reason?

A The Use Case is incorrectly modifying the repository data.

B The Use Case caches data internally and does not refresh from the repository.

C The UI layer is not calling the Use Case after data changes.

D The repository update method is asynchronous and the Use Case reads data before update completes.

💡 Hint

Think about timing and asynchronous data flow.

If repository updates are asynchronous, the Use Case might read data before the update finishes, causing stale data to be returned.

Practice

1. What is the main purpose of a use case (interactor) in Android app development?

easy

A. To organize app actions and separate business logic from UI

B. To design the app's user interface layout

C. To handle database migrations automatically

D. To manage app permissions and security

Solution

1. Step 1: Understand the role of use cases

   Use cases focus on organizing the app's business logic and actions clearly.

2. Step 2: Differentiate from UI and other concerns

   They separate this logic from the user interface and other layers like database or security.

3. Final Answer:

   To organize app actions and separate business logic from UI -> Option A

4. Quick Check:

   Use cases = organize logic separate from UI [OK]

Hint: Use cases handle app actions, not UI or database [OK]

Common Mistakes:

• Confusing use cases with UI components
• Thinking use cases manage database directly
• Assuming use cases handle permissions

2. Which Kotlin syntax correctly defines a simple use case class with an invoke operator function?

easy

A. class GetUserUseCase { fun call(id: Int): User { /*...*/ } }

B. class GetUserUseCase { operator fun invoke(id: Int): User { /*...*/ } }

C. fun GetUserUseCase(id: Int): User { /*...*/ }

D. object GetUserUseCase { fun invoke(id: Int): User { /*...*/ } }

Solution

1. Step 1: Identify correct class and operator syntax

   Use cases are often classes with an operator fun invoke to call them like functions.

2. Step 2: Check each option's syntax

   class GetUserUseCase { operator fun invoke(id: Int): User { /*...*/ } } correctly defines a class with operator fun invoke. fun GetUserUseCase(id: Int): User { /*...*/ } is a function, not a class. class GetUserUseCase { fun call(id: Int): User { /*...*/ } } uses fun call, not invoke. object GetUserUseCase { fun invoke(id: Int): User { /*...*/ } } uses object but lacks operator keyword.

3. Final Answer:

   class GetUserUseCase { operator fun invoke(id: Int): User { /*...*/ } } -> Option B

4. Quick Check:

   Use case class with operator invoke = class GetUserUseCase { operator fun invoke(id: Int): User { /*...*/ } } [OK]

Hint: Use operator fun invoke inside class for use cases [OK]

Common Mistakes:

• Defining use case as a simple function instead of class
• Missing operator keyword for invoke function
• Using object without operator fun invoke

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

class AddNumbersUseCase {
  operator fun invoke(a: Int, b: Int): Int = a + b
}

fun main() {
  val add = AddNumbersUseCase()
  println(add(3, 4))
}

medium

A. 7

B. 34

C. Error: invoke requires one parameter

D. null

Solution

1. Step 1: Understand operator fun invoke with two parameters

   The invoke function takes two Ints and returns their sum.

2. Step 2: Call add(3, 4) executes invoke(3, 4) returning 7

   Printing this result outputs 7.

3. Final Answer:

   7 -> Option A

4. Quick Check:

   3 + 4 = 7 [OK]

Hint: Invoke operator calls function with parameters directly [OK]

Common Mistakes:

• Thinking parameters concatenate as strings
• Assuming invoke only takes one parameter
• Expecting null or error output

4. Identify the error in this use case implementation:

class MultiplyUseCase {
  operator fun invoke(a: Int, b: Int): Int {
    return a * b
  }
}

fun main() {
  val multiply = MultiplyUseCase()
  println(multiply.invoke(5))
}

medium

A. println cannot print Int values

B. Missing return statement in invoke function

C. MultiplyUseCase should be an object, not a class

D. invoke function called with wrong number of arguments

Solution

1. Step 1: Check invoke function parameters

   invoke expects two Int parameters: a and b.

2. Step 2: Analyze call multiply.invoke(5)

   Only one argument is passed, causing a compile-time error for wrong argument count.

3. Final Answer:

   invoke function called with wrong number of arguments -> Option D

4. Quick Check:

   invoke needs 2 args, call has 1 [OK]

Hint: Check function parameter count matches call arguments [OK]

Common Mistakes:

• Ignoring parameter count mismatch
• Thinking classes must be objects for use cases
• Assuming println can't print Int

5. You want to create a use case that fetches user details and then logs the action. Which approach best follows use case principles?

hard

A. Put fetching logic in UI code and logging in a separate utility class

B. Combine fetching, logging, and UI updates all inside the use case invoke function

C. Create a use case class that fetches user data and calls a logger inside invoke

D. Use a use case only for logging, and fetch data directly in the UI

Solution

1. Step 1: Understand use case responsibility

   Use cases should handle business logic like fetching and related actions such as logging.

2. Step 2: Evaluate options for separation and clarity

   Create a use case class that fetches user data and calls a logger inside invoke keeps fetching and logging together in use case, separating UI concerns. Others mix UI and logic or split related logic incorrectly.

3. Final Answer:

   Create a use case class that fetches user data and calls a logger inside invoke -> Option C

4. Quick Check:

   Use case = business logic + related actions [OK]

Hint: Keep related logic inside use case, UI handles display only [OK]

Common Mistakes:

• Mixing UI code with business logic
• Splitting related logic across unrelated classes
• Using use case only for one small task