Clean Architecture For Android Apps

Android apps are popular, and increasingly so. At the same time, designing and developing Android apps using the right architecture assumes more importance than ever. A discussion about clean architecture for Android apps is therefore important, and I will do exactly that here.

Contents

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?

The following statistics as of July 2018 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 up front 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?

 

Download Our Project Specification Template

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 “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:

Read How We Helped a Marketing Company to Build a Back-Office Custom Ads Dashboard

  • 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.

Planning to use “Clear 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.

Download Our Project Specification Template