Use cases / Interactors in Android Kotlin

Introduction

Use cases help organize app actions clearly. They keep your app's logic simple and easy to change.

When you want to separate app logic from the user interface.

When you need to reuse the same action in different parts of your app.

When you want to make your app easier to test.

When your app has multiple steps or rules for a task.

When you want to keep your code clean and organized.

Syntax

Android Kotlin

class SomeUseCase {
  fun execute(param: Type): ResultType {
    // business logic here
    return result
  }
}

Use cases are simple classes with one main function, often called execute.

They focus on one task or action your app does.

Examples

This use case checks if login details are correct.

Android Kotlin

class LoginUseCase {
  fun execute(username: String, password: String): Boolean {
    return username == "user" && password == "pass"
  }
}

This use case returns a list of items.

Android Kotlin

class FetchItemsUseCase {
  fun execute(): List<String> {
    return listOf("Apple", "Banana", "Cherry")
  }
}

Sample App

This program creates a use case to add two numbers. It then runs it and prints the result.

Android Kotlin

class AddNumbersUseCase {
  fun execute(a: Int, b: Int): Int {
    return a + b
  }
}

fun main() {
  val useCase = AddNumbersUseCase()
  val result = useCase.execute(3, 4)
  println("Sum is: $result")
}

Important Notes

Use cases keep your app logic in one place, making it easier to update.

They help you write tests for your app actions without the UI.

Keep use cases focused on one job for clarity.

Summary

Use cases organize app actions clearly and simply.

They separate logic from the user interface.

Use cases make your app easier to test and maintain.

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