Android — Clean Architecture, MVVM, UseCase
Hello everyone. In this article, I will give information about Clean Architecture, MVVM structure and UseCase for Android developers and explain with examples.
In fact, Clean Architecture, MVVM are terms that all developers now know and apply perfectly. Besides, since I’ve just learned, I would like to tell you about what Use Case does, why and how we use it.
My publications have always been a note for me. When I get stuck somewhere, I first get help from my own publications and notes. At this step, when I look back, I would like to make a small note about a general Android structure. I hope you can find useful information in this article. :)
What is Clean Architecture?
Firstly, Clean Architecture is actually an important concept for all software developers, not just Android developers. It is a principle that we must apply in all programming languages, in all the codes.
I must say at the outset that Clean Architecture is not a design pattern. It is a code development approach and a structure that adopts SOLID principles.
The purpose of Clean Architecture is to minimize code complexity by preventing implementation complexity. Although it is not of great importance in small projects, it has a critical value in large projects.
Owing to Clean Architecture, we can write clean, testable and maintainable, refactorable code. You can easily apply the Clean Architecture rules with MVVM, which is the architecture most used by us, Android developers. But Clean Architecture can be used not only with MVVM but also with all other design patterns.
Advantages
Some advantages of using Clean Architecture are;
- Write clean, readable and interpretable code.
- Easy testability.
- Write maintainable code.
- Reducing complexity in package and class structure.
- To progress more easily, effectively and quickly in teamwork.
- It is independent of interface, database and framework.
- It avoids code duplication.
Disadvantages
- Contains lots of classes and packages. For that, it may not be very convenient for small projects that are not very complex.
- Because it is made up of layers, it may take time to understand how all layers work with each other.
- Learning without practice can be difficult.
Layers
Clean Architecture basically consists of 5 layers.
- Presentation: Layers that interact with the user. This layer includes Activity, Fragment, ViewModel classes etc.
- Use Cases: The layer where the user’s work is defined. You can find a detailed explanation of this title in the following sections of the article.
- Domain: The layer where logic operations are performed. For example, entities, value object, exceptions, and logic operations are in this layer.
- Data: It is the layer where the source of all abstract data is. All data and models that the application can use are located in this layer.
- Framework: The layer that interacts with the SDK or framework. So that is, it implements the interaction with the Android SDK and provides custom implementations for the data layer.
What is MVVM?
With MVVM, the works in the interface and the works in the background are separated from each other and the code complexity is minimized. Each class defines and performs only its own tasks.
Among the reasons why MVVM is more widely used than other design patterns is that it offers more modularity, is easy to test, and is a good renderer between the View and Model layers, reducing code repetition and complexity thanks to its layered structure.
The MVVM structure has three main layers. These are;
- Model: It is the layer where data sources are abstracted. It allows the ViewModel layer to work with the data here and send it to the View.
- View: This layer is only responsible for reporting user actions to the ViewModel. For example, when a user presses any button, the ViewModel class is informed and taken an action.
- ViewModel: It is the layer responsible for processing and transmitting all kinds of information to be presented to the user in the View layer. It establishes the connection between the View and the Model, processes the data from both and sends it back to the View layer.
What is Use Case?
All operations within the MVVM structure are defined in the ViewModel classes. In this case, after a certain point, there will be too many ViewModel classes. And all the business logic, the whole load of work starts to get scattered in the ViewModel classes. In fact, after a point, the same things are located in different ViewModel classes. To avoid this complexity, we create various UseCase classes to reduce the burden of ViewModel classes and reduce code duplication and complexity.
For example, let’s imagine a profile page. Whether pulling user information, updating information and deleting information are performed in the profile page. Instead of squeezing all these operations into a single ViewModel class and creating code confusion, we can create a separate UseCase class for each and write an appropriate model class, and complete each operation with a few lines of code in the ViewModel class. Moreover, if the user wants to delete, update or view their data from another screen, not from the profile page, we would not write the same codes in more than one ViewModel class. Thanks to a single UseCase class, we can do these operations wherever we want.
Let’s consider a profile page as an example. This profile page should include the user’s occupation information, personal information, and family information. All three depend on different services.
For this, we first need to create an interface class to define our services and send a request. Let’s create a repository class besides the class we call the services. Sample codes should be as follows.
As seen in the codes above, post requests are made. Let’s assume that the request and response models required for requests are created.
Next, let’s write a UseCase class to get only the user’s occupation information. A UI model class is needed for this Use Case class. Thanks to this class, the data to be displayed to the user in the UI can be set and used directly in the ViewModel. In fact, what we do here is only to make the response data from our request compatible for the UI. For this, we just need to create a simple model class as follows.
After creating the model class, the getJobDetail() method from the repository class is called within the execute function. Then, it maps the data that comes with the response2UI() method and makes it ready for use in the ViewModel.
Then, in the ViewModel class, by calling the UseCase class, all the data is obtained with a single method. By setting the defined jobTitle, userSalary, userExperience and userCompany values in the XML file, the data returned from the service are displayed to the user one by one without any action in the View class.
Result
Thank you very much for reading my post.
In this article, I briefly talked about the Clean Architecture structure, the MVVM structure, and the UseCase structure, which is a very important feature for MVVM architecture. My aim was not to give too much detail, but to touch on the structure in general and to enable the readers to experience the UseCase structure by practicing or applying it to their code. I hope it was useful.