Use cases / Interactors in Android Kotlin - Build, Publish & Deploy

Build & Publish - Use cases / Interactors

Performance Impact

Use cases or interactors organize business logic in your app. They help keep UI code clean and focused. Proper use of interactors can improve app responsiveness by separating heavy tasks from the main thread. However, if interactors perform long operations on the main thread, it can cause UI jank and dropped frames below 60fps. Efficient use of coroutines or background threads in interactors helps maintain smooth animations and reduces battery drain.

Optimization Tips

To keep your app running at 60fps, ensure interactors run heavy tasks off the main thread using Kotlin coroutines with Dispatchers.IO or Dispatchers.Default. Avoid blocking calls in interactors. Cache results when possible to reduce repeated work. Use dependency injection to provide interactors efficiently and avoid unnecessary object creation. Profiling with Android Studio's CPU and memory tools helps identify bottlenecks in interactors.

App Size and Startup Time

Use cases themselves add minimal size to your app since they are mostly Kotlin classes. However, adding many dependencies or large libraries to support interactors can increase APK size. Keep dependencies lean and modular. Lazy initialization of interactors can improve startup time by delaying work until needed. Avoid loading large data sets in interactors during app launch.

iOS vs Android Differences

On Android, interactors are often implemented as Kotlin classes using coroutines for async work. On iOS, similar patterns use Swift classes or structs with async/await or Combine. Android requires careful thread management with coroutines, while iOS uses Grand Central Dispatch or Swift concurrency. Both platforms benefit from separating business logic from UI, but implementation details differ due to language and framework differences.

Store Review Guidelines

Use cases do not directly affect store guidelines, but indirectly they help maintain app stability and performance, which are critical for approval. Google Play and Apple App Store require apps to be responsive and not freeze or crash. Efficient interactors help meet these requirements. Also, avoid excessive background work in interactors that could drain battery or violate background execution limits.

Self-Check Question

Your app takes 5 seconds to load this screen. What's likely wrong?

• Interactor is performing heavy work on the main thread, blocking UI rendering.
• Interactor is loading large data synchronously instead of asynchronously.
• Interactor is not caching data, causing repeated expensive operations.
• Interactor initialization is done eagerly at startup instead of lazily.

Key Result

Use cases (interactors) improve app structure and performance by separating business logic from UI. Proper async handling with Kotlin coroutines ensures smooth 60fps UI and efficient battery use. Keep dependencies minimal to reduce app size and startup time. Android and iOS differ in concurrency models but share the goal of clean logic separation.

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