Clean Architecture layers in Android Kotlin - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Identify the correct Clean Architecture layer for UI logic

In Clean Architecture for Android, which layer should handle user interface logic such as displaying data and capturing user input?

A Framework layer

B Data layer

C Domain layer

D Presentation layer

💡 Hint

Think about where the app interacts directly with the user.

The Presentation layer is responsible for UI logic, managing views and user interactions. The Domain layer handles business rules, Data layer manages data sources, and Framework layer includes external tools.

❓ ui_behavior

intermediate

Effect of violating Dependency Rule in Clean Architecture

What happens if the Data layer directly depends on the Presentation layer in a Clean Architecture Android app?

A The app will crash at runtime due to circular dependencies

B It improves performance by reducing abstraction layers

C It breaks the Dependency Rule, causing tight coupling and harder testing

D It is recommended for faster UI updates

💡 Hint

Consider the direction of dependencies in Clean Architecture.

Clean Architecture enforces that dependencies point inward, from outer layers to inner layers. If Data depends on Presentation, it creates tight coupling and makes testing and maintenance difficult.

❓ lifecycle

advanced

Correct lifecycle owner for ViewModel in Clean Architecture

In an Android app using Clean Architecture, which lifecycle owner should be used to scope a ViewModel in the Presentation layer?

A Activity or Fragment lifecycle

B Application lifecycle

C Domain layer lifecycle

D Data layer lifecycle

💡 Hint

ViewModels are tied to UI components' lifecycles.

ViewModels should be scoped to the Activity or Fragment lifecycle to survive configuration changes and manage UI data properly. Application lifecycle is too broad, and Domain/Data layers do not have lifecycles.

❓ navigation

advanced

Where to handle navigation logic in Clean Architecture

In Clean Architecture, where should navigation logic (e.g., moving between screens) be implemented in an Android app?

A Data layer, to fetch navigation data

B Presentation layer, to handle UI navigation events

C Domain layer, because navigation is a business rule

D Framework layer, to access Android navigation components

💡 Hint

Think about which layer controls user interactions and screen changes.

Navigation is part of UI behavior and should be handled in the Presentation layer. Domain layer handles business rules, Data layer manages data, and Framework layer provides tools but does not contain navigation logic.

🔧 Debug

expert

Diagnose the cause of a runtime crash due to layer violation

An Android app using Clean Architecture crashes at runtime with a ClassCastException when the Data layer tries to cast a Presentation layer class. What is the most likely cause?

A The Data layer depends on Presentation layer classes, violating the Dependency Rule

B The Presentation layer is incorrectly referencing Domain entities

C The Domain layer is missing interface implementations

D The Framework layer is not initialized before use

💡 Hint

ClassCastException often happens when layers depend on each other incorrectly.

If the Data layer depends on Presentation classes, it breaks the Dependency Rule and can cause ClassCastException at runtime due to improper class references.

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