Use cases / Interactors in Android Kotlin - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a Use Case (Interactor) in Android app architecture?

A Use Case, also called an Interactor, is a class that contains the business logic of the app. It handles a specific task or action, like fetching data or processing user input, separate from UI or data layers.

beginner

Why should Use Cases be separate from UI and data layers?

Separating Use Cases keeps business logic independent. This makes the app easier to test, maintain, and change without affecting UI or data code.

intermediate

In Kotlin, how might a simple Use Case class look?

A Use Case class usually has a single public function, like `execute()`, that performs the task. It can use repositories to get or save data.

intermediate

What role do repositories play in Use Cases?

Repositories provide data to Use Cases. Use Cases ask repositories for data or tell them to save data, keeping data access details hidden from the business logic.

intermediate

How do Use Cases improve app testing?

Because Use Cases contain business logic separate from UI and data, you can test them easily by giving fake data sources and checking the results without running the full app.

What is the main responsibility of a Use Case (Interactor)?

A Handle user interface rendering

B Store data in a database

C Handle network communication

D Manage business logic for a specific task

Use Cases focus on business logic, not UI or data storage.

Why do we separate Use Cases from UI code?

A To make UI code more complex

B To mix data and UI logic

C To keep business logic testable and independent

D To slow down app performance

Separating Use Cases keeps business logic independent and easier to test.

Which layer typically provides data to Use Cases?

A UI layer

B Repository layer

C Network layer

D ViewModel layer

Repositories provide data to Use Cases, hiding data source details.

What is a common function name in a Use Case class?

A execute()

B render()

C saveData()

D loadUI()

Use Cases often have an execute() function to run their task.

How do Use Cases help with app testing?

A By making business logic independent and testable

B By mixing UI and data code

C By requiring the full app to run

D By hiding business logic inside UI

Use Cases separate business logic so it can be tested without UI or data dependencies.

Explain what a Use Case (Interactor) is and why it is important in Android app architecture.

Think about how your app handles tasks behind the scenes, separate from what the user sees.

Describe how Use Cases interact with repositories and why this separation matters.

Imagine a waiter (Use Case) asking the kitchen (repository) for food without knowing how the kitchen works.

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