All articles

Android Clean Architecture Guide

Android Clean Architecture Guide

Interested in an Android clean architecture guide?

You’ve come to the right place.

Choosing the right architecture is key to creating a great software application, this is why it is so important to get it right. Here’re a few amazing case studies of companies who hired DevTeam.Space to build their software products:

  1. ModuleTrade – Healthcare Android and iOS App
  2. MyTime – Scheduling And Payment Web Application
  3. Learning Solution For The Chinese Market – Class Scheduling and eLearning App


How popular are Android apps?
Android app architectural challenges
Why did “Clean Architecture” emerge?
What is “Clean Architecture”?
Advantages of “Clean Architecture”
Why consider “Clean Architecture” in Android development?
“Clean Architecture” has drawbacks too!

How popular are Android apps?

As a Statista report indicates, Android held 71.93% of the mobile operating system (OS) market share in January 2021. The popularity of Android isn’t a flash in the pan though. Android sustains its leading position in the market. More and more organizations are building mobile apps targeting this OS.

 A chart showing the popularity of Android apps

The following statistics indicate how popular Android apps are:

  • Facebook had 4.11 billion downloads;
  • There were 3.4 billion downloads of Facebook Messenger;
  • 97 billion downloads happened for WhatsApp;
  • Instagram had 1.84 billion downloads.

Quite clearly, Android apps are touching a really large number of people every day! Read more statistics on this in “The 20 most popular Android apps in the Google Play Store”.

Android app architectural challenges

Android app development projects encounter architectural challenges like any other software developments projects do. These challenges arise from incorrect decision making. A brief summary of these challenges are as follows:

  • Favoring status quo: Project teams sometimes stick to the status quo despite the architecture not quite working.
  • Over-architecting the solution: The large effort spent upfront on architecture delays the project.
  • Joining the microservices bandwagon: Netflix uses this pattern to great effects. That doesn’t mean all apps will be successful with it. I have earlier explained the pros and cons of the microservices architecture pattern in “10 best practices for building a microservice architecture”.
  • Choosing a pattern just because the team knows it, even though its’ not suitable for the app.
  • Frequent obsolescence of technology.

Read more about these challenges in “Solution architect’s challenges and common mistakes”.

Why did “Clean Architecture” emerge?


An understanding of the reasons that gave rise to “Clean Architecture” is useful up front. So, here we go:

  • “Separation of concerns” has always been a key principle for software architects. An example will help in understanding this.
  • Let’s consider the rule that the business logic should never concern itself with the “User Interface” (UI) logic. Similarly, the UI logic should not concern itself with the business logic.
  • While the above principle makes perfect sense, in practice things turn out quite differently! Business logic code often deals with UI aspects like color and font size.
  • Software architects came up with the “Layered Architecture” pattern to solve this. Here, data enters the top layer. It flows through the intermediate layers, which have their own tasks. The data finally reaches the innermost layer, which is typically the database. Read more about layered architecture in “Large enterprise Java projects architecture”.
  • Let’s assume that we have a layered architecture, with the UI or the presentation layer being the outer layer. The middle layer is where the objects reside, and we can call it the “Business Logic Layer” (BLL). The inner layer has the database.
  • Here, changes to the BLL can dictate changes to UI. While that’s acceptable, small look-and-feel changes to the UI shouldn’t cause changes to the BLL.
  • During the execution, user actions will trigger certain processing in the BLL. As a result, some persistent changes to the data will be saved in the database.
  • However, if you try to manage these same dependencies during the compile-time, you lock yourself in with a specific database vendor. This reduces your choices.
  • Moreover, developers might often mix up data access code with other code performing different calculations. As a result, the testability of the application reduces.

Read more about these challenges in “An introduction to Clean Architecture”. The software architect community needed to find resolutions to these. Enter “Clean Architecture”.

A brief history of “Clean Architecture”

We have now summarized the challenges of traditional architecture patterns, as follows:

  • Unwieldy coupling of UI with other layers;
  • Coupling of the business logic layer to factors such as persistent storage;
  • Diminishing testability.

Robert C. Martin, also known as “Uncle Bob” presented the solution in 2011, and he called it “Clean Architecture”. Read his article in “Clean architecture”. In 2012, he expanded on his solution definition and presented the schematic diagrams to explain it. Read “The clean architecture” for more information.

What is “Clean Architecture”?

a diagram illustrating clean architecture

A “Clean Architecture” is a pattern where the code layers look like an onion. The dependency rule is such that the inner layer shouldn’t concern about the outer layer. No code in an inner layer can directly reference any code from the outer layer.

On the contrary, an outer layer can talk to the inner layer. In other words, the dependencies point inwards. Read this Quora Q&A thread for more information.

In practice, this would mean the following:

  • The outermost layer, consisting of frameworks and drivers, talks to the next inner layer.
  • Let’s assume that this second layer is made up of the interface adapters.
  • This second layer will then talk to the next inner layer. This will be the layer of application business rules.
  • The third layer then talks to the innermost layer, where entities reside.

Advantages of “Clean Architecture”

“Clean Architecture” provides you with the following advantages:

  • Communication and clarity: As you can see, business use cases are most easily visible. This provides excellent clarity.
  • Flexibility: You are no longer tied to frameworks, database vendors, or application server providers. You can change any of these without any adverse impact.
  • Clean architecture helps in “Domain-driven design” (DDD). DDD is important for complex projects since the focus is on the core domain and associated logic.
  • Testing becomes easier since you can set up the scope of testing according to your requirements. You can test all the interfaces and outside interactions.

Read more about these advantages in “Clean architecture is screaming”.

Why consider “Clean Architecture” in Android development?

Let’s now narrow down our discussion to Android development. Why should you consider “Clean Architecture” here? The reasons are as follows:

  • “Separation of concerns” was the most fundamental design premise that we had started off with. By now, you can see how “Clean Architecture” addresses this.
  • This pattern makes the package structure easy to navigate.
  • Testers of Android apps find their job easier with “Clean Architecture”. There is a noticeable increase in test coverage.
  • The code is easier to maintain.
  • Having neatly compartmentalized the presentation layer, business logic layer, and entities, the project team finds it easier to move forward with their work.
  • Classes, including test classes, are focused.
  • Changes to UI can continue as the business requirements demand. These changes and their testing can continue in a stable environment.
  • Future strategic changes are easier since there is no dependence on the framework or database vendors.

Read more about these reasons in “A quick introduction to clean architecture”.

“Clean Architecture” has drawbacks too!

No software architecture pattern is without drawbacks. “Clean Architecture” has its’ share of pitfalls too, as follows:

  • Complexity: The plain reality with many apps is that most of the time the app just deals with data consumption. This means that there is not much business logic at play. Most operations are “Read” queries on a database, whereas some are “Write” operations. “Clean Architecture” stresses on use cases. If the software architect creates use cases for each of these “read” and “write” operations, then the number of use cases will be really high! In other words, you are likely introducing much more complexity than the app calls for.
  • Confusing “Clean Architecture” with modularity: Okay, sometimes there are real business logic and not just CRUD operations. Even then, if making your design modular is what your concern is, you have other ways to do so. You will still be able to separate the code between layers, and testability will still be okay. Even here, you can avoid the complexity of “Clean Architecture”, and just write modular code.
  • Boilerplates: Many software development experts urge us to avoid boilerplates. Now, it’s inevitable with “Clean Architecture” that you will introduce more boilerplates. Once again, the key question is whether you need them?
  • Duplicate models: This is closely related to the above pitfalls. You will end up creating similar models under each layer. You should once again ask whether you indeed need this complexity.

Read more about these drawbacks in “Downsides of clean architecture”.

Planning “Clean Architecture” for Android

By now, you have seen both the advantages and disadvantages of “Clean Architecture”. It’s now clear to you that “Clean Architecture” needs careful thinking. You need to plan for the following, in the context of Android development:

  • Plan how the data will flow.
  • Determine the dependency rules between different layers, e.g., presentation layer, domain layer, and data layer.
  • Plan to incorporate only the core of your application in the domain layer. This can’t have dependencies with any other layers.
  • Now, focus on the data layer. Here, you need to concentrate on repositories implementation and data sources.
  • Your data strategies will change based on the data source. For e.g., you need to plan whether to return cache or to refresh the cache.
  • The planning for the presentation layer is closely related to your planning for the UI. This will only execute the user actions and display data as a result of this.

Read “Clean Architecture guide (with tested examples): data flow != dependency rule” to know more about this planning process.

Languages, tools, and resources to implement “Clean Architecture” in Android

Implementing “Clean Architecture” in Android requires a good deal of strategizing. Therefore, you should consider using languages/tools/resources that can expedite your development project. This will benefit the overall project. Consider using/reviewing the following:

  • Android Studio: This popular Android “Integrated Development Environment” (IDE) hardly needs an introduction. However, if you need guidance, visit its webpage.
  • Google Firebase: “Mobile Backend as a Service” (MBaaS) providers handle many aspects like the cloud infrastructure, 3rd party API integration, persistent storage, security, user management, push notification, scalability, etc. I have explained the benefits of using them in “How to choose the best Mobile Backend as a Service (MBaaS)?”. Google Firebase is a reputed MBaaS provider, consider using it in your project.
  • Kotlin language: Kotlin is the modern Android development language. This open-source language has concise syntax, therefore, developers can code less, yet accomplish their objectives. It supports functional programming. Kotlin is lightweight, therefore, you can write fast apps. It provides sophisticated ways to handle common errors such as null pointer exceptions, which facilitates bug-free programming. The code is highly maintainable, and developers experience higher productivity. It’s fully interoperable with Java and has excellent community support. I have explained these advantages in “Kotlin vs Java: which is the best choice?”.
  • Java: When it comes to Java, “Old is still gold”! Java remains one of the most popular programming languages decades after it emerged. It was the preeminent language for Android development before the advent of Kotlin, and Java still remains very popular with the Android developers. Java helps in making your app scalable. The language is highly portable due to the JVM concept. Java has powerful memory management features, moreover, it supports multi-threading. Security, rich ecosystem, and availability of skilled developers are the other advantages of Java. I have explained these advantages in “Why should you use Java for your backend infrastructure?”.
  • Sample apps using “Clean Architecture”: Before you implement “Clean Architecture” in your Android project, you would do well to view sample apps where developers have implemented it. This GitHub repository is an excellent resource! It has several sample apps.

Key factors to keep in mind when implementing the “Clean Architecture”

Bear the following key factors in mind when implementing the “Clean Architecture” in your Android app:

1. Using MVVM (Model-View-ViewModel) along with the “Clean Architecture” can help.

MVVM helps to separate the views from the business logic of an app. While this helps in small projects, the “ViewModel” starts bloating if the codebase is large. Consider using MVVM along with the “Clean Architecture” in such cases. This approach separates the responsibilities of your code base.

You might think of combining the “Clean Architecture” pattern with the MVP (Model-View-Presenter) architecture. You don’t need this though since the Android architecture components include a built-in “ViewModel” class.

2. Using “Dagger 2” for dependency injection can help.

You need to think of how to inject dependencies, which is a key aspect. We recommend you use a popular dependency injection framework like Dagger 2. Look for programmers that know this since Dagger 2 has a learning curve. 

3. Using interactors with “Clean Architecture”

Interactors are small chunks of reusable pieces of code. They can abstract logic from presenters. This simplifies your app and makes it easier to change the app later. Interactors can help when you use the clean architecture approach, however, refrain from overusing them. Too many interactors can make debugging harder.

4. Should you use LiveData?

LiveData in Android is an observable data holder class. It’s a lifecycle-aware observable. You might plan to use it since it’s one of the popular Android architecture components. However, you shouldn’t use in the following scenarios:

  • There’s backpressure in your app.
  • You need to use many operators on your data.
  • Your app doesn’t involve UI interactions with data.
  • The app involves one-shot asynchronous operations.
  • Your app doesn’t need to persist cached data into the UI.

5. Take the advantages offered by Kotlin.

If you are using Kotlin for Android development, then consider taking the advantage of the powerful features offered by this modern language. One example is the “data class”. A “data class” in Kotlin is a class that only contains state. It doesn’t perform any operations. You can reduce the coding effort since Kotlin generates code for data classes. 

The concept of coroutines in Kotlin is another example. Coroutines make asynchronous programming easier. Kotlin offers other powerful features too, e.g.:

  • Override function (“Override Fun”);
  • The ability to declare members inside a class as “private” by using the “private val” keywords.

6. Keep the constraints of mappers in mind.  

You could face challenges due to mappers while implementing the “clean architecture”. Mapping two entities can be error-prone when you are developing a large application. It’s hard to track entities when they keep changing. Creating mappers between domains and data models can be hard.

7. Look for developers experienced in implementing the “Clean Architecture” in Android apps  

You need developers with hands-on experience in implementing the clean architecture approach while developing Android apps. They should know about the following:

  • The “ViewModelFactory” class;
  • Using constructors;
  • Build tools like Gradle and scripts like “Build.gradle”;
  • Popular type-safe HTTP clients like Retrofit;
  • Popular libraries for reactive programming, e.g., RxJava 2;
  • Using Android app modules;
  • Using Android domain modules;
  • Using relevant tools and frameworks for unit tests;
  • Maintaining performance, scalability, maintainability, etc. while delivering new features;
  • The knowledge of popular architecture patterns like MVC (Model-View-Controller).

Planning to use “Clean Architecture” in your Android project?

“Clean Architecture” offers several advantages, however, it’s not the proverbial magic wand. First of all, you need to analyze whether your app is complex enough to merit this architectural approach. You should undertake a careful analysis of the use cases, CRUD operations, dependencies, etc. before you plan to use this approach.

Thereafter, you should pay enough attention to plan the various aspects such as the data flow, and various layers. The domain layer is clearly the most important, however, you can’t cut corners while planning the other layers. Keeping all dependencies focusing inwards isn’t an easy task either.

You need the required software architecture expertise. That’s a niche skill! Consider engaging a reliable software development partner. You can read our guide “How to find the best software development company?” before engaging such a development partner.

Further Reading

Here are a few articles that might also interest you:

How to Write a Product Requirements Document [Step-by-Step]

How to Write a Functional Specifications Document

How to Build a Scalable Blockchain Database?

How to Use Blockchain Technology for Identity

Frequently Asked Questions

What is Android clean architecture?

This term refers to a set of practices that result in high quality apps with the following characteristics: Testable. UI-independent functionality, Database independence, frameworks, external agencies, and libraries.

Which architecture is best for Android?

For small apps use MVVM. However, for larger apps, MVVM combined with clean architecture. For more information, read this article.

What is the Android application architecture?

This refers to the design plan of an Android app. Essentially, it is a plan or map that relates to how the app and its respective parts or functions interact.


Hire Expert Developers

DevTeam.Space is a vetted community of expert dev teams supported by an AI-powered agile process.

Companies like Samsung, Airbus, NEC, and startups rely on us to build great online products. We can help you too, by enabling you to hire and effortlessly manage expert developers.

LinkedIn LinkedIn Facebook Facebook Twitter Twitter Facebook Messenger Facebook Messenger Whatsapp Whatsapp Skype Skype Telegram Telegram