Android Clean Architecture

Android Clean Architecture is a layered software design pattern proposed by Andrew Kinnell. Its core concept divides an application into three independent layers: the Domain Layer, the Data Layer, and the Presentation Layer. This structure not only enhances code testability and maintainability but also ensures that business logic is decoupled from specific technical implementations, thereby extending the longevity of the application.

In Android development, Clean Architecture achieves this goal by defining clear dependency relationships. The key principle is that the Presentation Layer depends only on the Domain Layer, while the Data Layer depends on both the Domain Layer and the Presentation Layer. This unidirectional data flow ensures that core business rules remain unaffected by external changes (such as database modifications or UI framework updates).
The first step in implementing Clean Architecture is to create three independent modules or packages, each responsible for specific duties:

  • Domain Layer

    • Houses core business logic, data models, and rules.
    • Contains no external dependencies, such as the Android SDK, networking libraries, or UI frameworks.
    • Is fully controlled by developers and represents the most stable part of the architecture.

  • Data Layer

    • Responsible for retrieving and storing data from external sources (such as local databases or REST APIs).
    • Can depend on the Domain Layer to map data models.
    • Implements specific data source logic, such as using Room or Retrofit.

  • Presentation Layer

    • Handles user interface interactions, including Activities, Fragments, or ViewBinding.
    • Communicates with the Data Layer through a Repository.
    • Depends on the Domain Layer and the Data Layer but does not directly depend on external libraries.

Separation of Data Flow and Control Flow

In Clean Architecture, data flow and control flow must be strictly separated. The Presentation Layer is responsible for control flow (e.g., user clicking a button), while the Data Layer handles data flow (e.g., fetching information from a server). They communicate via the Repository pattern, where the Repository acts as an abstract interface for data sources.

For example, in a user login scenario:

  1. The user enters a password in an Activity and clicks the "Login" button.
  2. The Activity calls the login() method of the Repository.
  3. The Repository selects between the local database or remote API based on configuration.
  4. Upon returning a result, the Activity updates the UI state.

This design encapsulates business logic (such as password validation rules) entirely within the Domain Layer, ensuring that core logic remains unaffected even when data sources are changed.

Decoupling Using the Repository Pattern

The Repository is a key component of Clean Architecture; it serves as a unified interface for data sources, shielding the complexity of underlying implementations. Through the Repository, the Presentation Layer does not need to know which specific data source is being used.

Here is a simple example of a User Data Repository:

interface UserRepository {
    fun getUser(id: Int): Result<User>
    fun saveUser(user: User)
}

class LocalRepositoryImpl(private val database: Database) : UserRepository {
    override fun getUser(id: Int): Result<User> {
        return database.getUser(id).mapSuccess { user -> Result.Success(user) }
            .mapFailure { Result.Failure(it.message!!) }
    }
    
    override fun saveUser(user: User) {
        database.saveUser(user)
    }
}

class NetworkRepositoryImpl(private val api: UserServiceApi) : UserRepository {
    override fun getUser(id: Int): Result<User> {
        return api.getUser(id).mapSuccess { user -> Result.Success(user) }
            .mapFailure { Result.Failure(it.message!!) }
    }
    
    override fun saveUser(user: User) {
        // Implement network save logic
    }
}

class RepositoryImpl(private val localRepo: UserRepository, private val networkRepo: UserRepository) : UserRepository {
    override fun getUser(id: Int): Result<User> {
        return when {
            id == -1 -> networkRepo.getUser(id)
            else -> localRepo.getUser(id)
        }
    }
    
    override fun saveUser(user: User) {
        // Implement save logic
    }
}

Key Considerations in Practice

When applying Clean Architecture to Android projects, keep the following points in mind:

  • Avoid Circular Dependencies: Ensure the Data Layer does not depend on the Presentation Layer to prevent circular references.
  • Test First: Since the Domain Layer has no external dependencies, it is ideal for unit testing. Write test cases for core logic first.
  • Incremental Refactoring: Do not attempt to rewrite the entire project at once. Start by applying Clean Architecture principles to one module and gradually expand to other parts.
  • Configuration Management: Use configuration files (such as config.json) to switch between local and remote data sources, avoiding hardcoding.

By following these principles and practices, you can build more robust and maintainable Android applications. Although Clean Architecture requires a higher initial investment, it significantly improves code quality and team collaboration efficiency, making it a wise long-term technical investment.