Use cases / Interactors in Android Kotlin - UI Render Trace

Component - Use cases / Interactors

This component represents the Use Case or Interactor layer in Android app architecture. It acts like a helper that handles specific tasks or business rules, separate from the UI or data storage. Think of it as a friendly assistant who knows exactly how to do one job well, like fetching user info or saving data.

Widget Tree

UseCaseInteractor
├── InputParameters
├── BusinessLogic
└── OutputResult

The UseCaseInteractor is the main component. It receives InputParameters, processes them with BusinessLogic, and produces an OutputResult. This structure keeps the app organized by separating what the app does from how it looks or stores data.

Render Trace - 3 Steps

Step 1: UseCaseInteractor

Step 2: BusinessLogic

Step 3: OutputResult

State Change - Re-render

Trigger:Calling the UseCaseInteractor with new input

Before

Idle, no current processing

→

After

Processing input and producing output

Re-renders:No UI components re-render because this is a logic layer without direct UI

UI Quiz - 3 Questions

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

A To handle specific business tasks separate from UI and data storage

B To display buttons and text on the screen

C To store data permanently on the device

D To manage network connections directly

Key Insight

Use Cases or Interactors help keep your app clean and easy to understand by separating the 'what to do' from the 'how to show it'. They do not create UI but prepare data and actions for the UI to display or use.

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