Clean Architecture layers in Android Kotlin - Build, Publish & Deploy

Build & Publish - Clean Architecture layers

Performance Impact

Using Clean Architecture layers helps keep your Android app organized and maintainable. However, adding multiple layers (like presentation, domain, and data) can introduce slight overhead in method calls and data transformations. This usually does not affect frame rate if done properly, so your UI can still run smoothly at 60fps or higher.

Memory usage is generally stable because each layer handles specific tasks and data flows efficiently. Battery consumption remains normal as long as background tasks and data fetching are optimized.

Optimization Tips

To keep your app running at 60fps with Clean Architecture:

• Minimize heavy work on the main thread by using Kotlin coroutines or background threads in the data layer.
• Use efficient data mapping between layers to avoid unnecessary object creation.
• Cache data smartly in the data layer to reduce network calls and speed up UI updates.
• Keep UI logic in the presentation layer simple and reactive to state changes.

App Size and Startup Time

Clean Architecture itself does not add significant size to your app bundle. The main size impact comes from libraries you use in each layer (e.g., networking, database, dependency injection).

Startup time can be slightly longer if you initialize many components at launch. To reduce this, initialize layers lazily or on demand.

iOS vs Android Differences

On Android, Clean Architecture is commonly implemented with Kotlin, using layers like ViewModel (presentation), UseCases (domain), and Repositories (data). Android apps use Jetpack libraries to support this structure.

On iOS, similar layering is done with Swift and frameworks like Combine or SwiftUI, but the patterns and tools differ. iOS apps rely on UIKit or SwiftUI for UI and use protocols and dependency injection differently.

Both platforms benefit from separation of concerns, but Android's architecture components and Kotlin coroutines provide specific tools to optimize layer communication.

Store Review Guidelines

• Google Play: Ensure your app complies with performance guidelines to avoid ANRs (App Not Responding) by keeping UI responsive through proper layer separation.
• Apple App Store: While this is Android Kotlin focused, similar principles apply. Keep your app stable and responsive to pass review.
• Follow privacy and data handling rules in the data layer to meet store policies.
• Use proper error handling and user feedback in the presentation layer to improve user experience and reduce crashes.

Self-Check Question

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

• Too much work is done on the main thread in the presentation or domain layer.
• Data fetching or mapping in the data layer is blocking UI updates.
• Initialization of layers is done all at once instead of lazily.
• Unoptimized network or database calls delaying data availability.

Key Result

Clean Architecture layers improve app maintainability with minimal performance cost when optimized properly, enabling smooth 60fps UI and manageable memory use on Android.

Practice

1. Which layer in Clean Architecture is responsible for business rules and logic?
domain, data, or presentation?

easy

A. Presentation layer

B. Domain layer

C. Data layer

D. UI layer

Solution

1. Step 1: Understand the role of each layer

   The domain layer contains business rules and logic, independent of UI or data sources.

2. Step 2: Match the layer to its responsibility

   Since business logic is in the domain layer, it is the correct answer.

3. Final Answer:

   Domain layer -> Option B

4. Quick Check:

   Business logic = Domain layer [OK]

Hint: Business rules live in domain layer, not UI or data [OK]

Common Mistakes:

• Confusing data layer with domain layer
• Thinking UI handles business logic
• Mixing presentation with domain

2. Which Kotlin syntax correctly defines a repository interface in the domain layer?

?

easy

A. interface UserRepository { fun getUser(id: Int): User }

B. class UserRepository { fun getUser(id: Int): User }

C. fun UserRepository() = User()

D. val UserRepository = object { fun getUser() = User() }

Solution

1. Step 1: Identify interface syntax in Kotlin

   Interfaces use the keyword interface followed by function signatures without bodies.

2. Step 2: Check each option

   interface UserRepository { fun getUser(id: Int): User } correctly declares an interface with a function signature. Others define classes or objects incorrectly for an interface.

3. Final Answer:

   interface UserRepository { fun getUser(id: Int): User } -> Option A

4. Quick Check:

   Kotlin interface syntax = interface UserRepository { fun getUser(id: Int): User } [OK]

Hint: Interfaces use 'interface' keyword with function signatures [OK]

Common Mistakes:

• Using class instead of interface for repository
• Defining function bodies inside interface
• Using val or fun incorrectly for interface

3. Given this code snippet in the data layer:

class UserRepositoryImpl(private val api: UserApi) : UserRepository {
  override fun getUser(id: Int): User {
    return api.fetchUser(id)
  }
}

What does getUser(5) return?

medium

A. Null because fetchUser returns nothing

B. An error because UserRepositoryImpl lacks a constructor

C. A User object fetched from the API with id 5

D. A compile-time syntax error

Solution

1. Step 1: Understand class and method behavior

   UserRepositoryImpl implements UserRepository and calls api.fetchUser(id) to get a User.

2. Step 2: Analyze getUser(5) call

   Calling getUser(5) returns the User object fetched by api.fetchUser(5), assuming api works correctly.

3. Final Answer:

   A User object fetched from the API with id 5 -> Option C

4. Quick Check:

   Method calls API and returns User [OK]

Hint: Implementation calls API method and returns result [OK]

Common Mistakes:

• Assuming missing constructor causes error
• Thinking fetchUser returns null by default
• Confusing syntax errors with runtime behavior

4. Identify the error in this presentation layer code snippet:

class UserViewModel(private val repo: UserRepository) {
  fun loadUser(id: Int) {
    val user = repo.getUser(id)
    println(user.name)
  }
}

medium

A. UserViewModel should not call repository directly

B. User object might be null causing a crash

C. No error; code is correct

D. UserRepository interface is not implemented

Solution

1. Step 1: Recall Clean Architecture dependencies

   The presentation layer (ViewModel) should depend on use cases in the domain layer, not directly on repository interfaces.

2. Step 2: Identify the violation

   Directly injecting and calling UserRepository in ViewModel bypasses use cases, mixing concerns and violating layer separation.

3. Final Answer:

   UserViewModel should not call repository directly -> Option A

4. Quick Check:

   ViewModel -> UseCase -> Repository [OK]

Hint: ViewModels call UseCases, not Repositories directly [OK]

Common Mistakes:

• Focusing on null safety (type system prevents null here)
• Thinking no architecture error in the code
• Assuming missing interface implementation

5. You want to add caching to your app using Clean Architecture. Where should the cache logic be placed?
Options:
A) In the domain layer
B) In the data layer
C) In the presentation layer
D) In the UI components

hard

A. Domain layer to keep business rules

B. UI components for faster display

C. Presentation layer to update UI directly

D. Data layer to manage data sources including cache

Solution

1. Step 1: Understand caching responsibility

   Caching is a data management concern, related to how data is stored and retrieved.

2. Step 2: Match caching to Clean Architecture layer

   The data layer handles data sources like network, database, and cache, so caching logic belongs here.

3. Final Answer:

   Data layer to manage data sources including cache -> Option D

4. Quick Check:

   Cache logic = Data layer [OK]

Hint: Cache belongs in data layer managing data sources [OK]

Common Mistakes:

• Putting cache in domain layer (business logic)
• Adding cache in UI or presentation layers
• Mixing UI concerns with data management