In Google I / 0 19 they talked about creating a modular Android application architecture. They emphasize the fact that developers must be separated to specialize in various aspects when developing the application to provide a clean and organized application.
If you have a folder with monolithic layouts, it is very difficult to look at it and understand what is going on
Instead, it will be so much easier if you group these layouts. If you search for something, you will find it there.
By the way, you have this monolithic application on the left and the modularized application on the right, if you want to change the same file in both scenarios, this is how it becomes invalid.
It is possible to make your continuous integration service work faster by having small modules that have larger modules, depending on them. For example, if you need to test module 5; you only need to run the modules that depend on it. Because the other modules are not affected, it makes no sense to use another module
It has been determined from the Play Store statistics that the number of users decreases between the time they install the app and the time they can start using the app. To prevent this; you can modulate your application with an app bundle to reduce the installation size
The packaging concept of the Android App bundle includes both the larger library modules and the dynamic function modules. For example, we can have a basic app that depends on module 1, also known as the Android library. This means that the app can reach the code and sources of module 1. Furthermore, we can have other modules, i.e., module 2 and module 3, which can be the dynamic function modules. These can be used for on-demand loading of codes via dynamic delivery.
Developers can decide on the dynamic function module based on the 80/20 principle that stands; "80% of users use 20% of the app". In this way it is wise to look at the unused 80% functions that are not part of the app's core flow. These unused functions can be downloaded and / or deleted later, which would make the on-demand false and clear up more space in the app.
We have two options to modularize our applications. One is based on functions, the other uses layer modularization. The two options have different advantages. Let me put it this way, function modularization offers you encapsulation, and also the option of delivery on request. On the other hand, layer modularization offers you isolation, you can isolate your dependencies from third parties or the layers in your app and it brings structure to your app. By the way, you can use them both together, but if you have a monolithic application for your app, you must first use layer modularization, then add the function modularization over time.
Working with dynamic function modules entails a number of challenges, even if you use on-demand delivery. One of these challenges is with navigation. For example, we have the MainActivity and want to navigate to the AboutActivity
Normally you can navigate something like above, but you get a compile error. To fix this, you can simply use Intent.setClassName and pass on the component name.
I know this seems a bit strange because it is hard coded. And indeed, it means that when you have to change your code, you must ensure that you also update this string.
You can browse through the structure that I will tell you through the following images. For example, we have a search activity that is part of the search module and we want to be able to find news in designer news and dribble. Designer News, Dribble and search are three completely different modules, for this reason we do not know how to do it.
When you start modularizing your application, you are likely to encounter problems with databases, which you can solve in two different ways. An option is that you can only have one database for all your applications, which you usually do when you are in a monolithic application. The other option is to create a core database for general functionality and then separate databases for your features.
Free Android modules have advantages and disadvantages, the first of the benefits is that you can use the modules again. We only need to implement a unit test for having free Android modules.
When you read about architecture and clean architecture theory, one of the things you'll see is one of the guidelines that you should minimize dependencies to ensure that you are not dependent on classes that you are not using . This also means that you can make a clear separation of concerns and ensure that your business logic is not dependent on UI classes.
Article shared by Android training in Chandigarh
