Clean Architecture for Android with Kotlin

There are many approaches to build complex systems with good architecture. Despite the small differences in these approaches they have a lot in common. Of course, they all ask how the application is divided on separate modules. In this case, each system has at least modules that contain business logic of the application, and modules to display data. Each approach ultimately allows you to build a system that meets the following principles:

The architecture should work independently from any frameworks and build-ups. Of course, in today’s world we can’t do without some libraries that allow you to solve problems faster and more efficiently than we have done in the case of self-realization. But it is important to understand that the library should be built into your architecture but it shouldn’t form the whole structure. When you use the library which forces you to alter the application architecture, you will always face certain limitations of the library and you couldn’t rebuild the architecture to fit well for your system. You need to use the library only as auxiliary tools.

The system must be tested. In this case, you should be able to test either particular modules, and test the interaction of these modules with each other and their integration into the system. Additionally, you must test the system without the UI, the real server and work with the database, that is, the architecture should be independent of the environment.

Let’s smoothly come to the next principle, which says that your application should be independent of everything from the UI to database workflow, from the server and to other elements of the environment. Architecture independence from the environment is very important, as it allows you to change the various components of the environment without changing the architecture. What is meant by changing the components of the architecture?

It must be said that the architecture of Android-applications usually is not too complicated, so perhaps, the Clean Architecture scheme can be simplified without losing quality. And this scheme in any case, must somehow be adapted for specific use in Android.

The most critical in terms of app testing is business logic or business rules that define the essence of the application. And they must be primarily independent of other elements and tested.

In order to achieve the independence and the ability to test, it is suggested to split the application into 3 key layers:

  • Layer data (Data Layer)
  • Business logic layer (Domain Layer)
  • Presentation layer (Presentation Layer)

At the same time, these layers have their own independent data models that are built in the way to interact with each other.

VRG Soft team uses this technology in one of the project so we can show you more. We have a project Get Goal that helps you to follow new habits day by day until you get it. If you want to view it right now here is the link

Data layer

UI  —  Android code related to user interface.

Storage —  specific Database code use for accessing data and storage data(implements the interface our Interactors).

Network  — Retrofit thing.

Presentation layer

Presenters —  The UI events are handled by presenter and serve as callback from the Interactors.

Business Logic layer

Interactors  —  Here are the classes which usually contains your logic code and serve using callback, as well. These classes also called UseCases by the most of developers.

Models  —  These are your models that you handle in your logic.

Repositories  —  Contains only interfaces that the database or some other outer layer implements. These interfaces are used by Interactors to access and store data.

Executor  —  Contains code for making Interactors run in the background by using a worker thread executor.

Our professionals know how to compose different technologies in one perfect structure. During the last 5 years we gathered strong native mobile app development tools in order to make product development process run smoothly.


Leave a Reply

Your email address will not be published. Required fields are marked *