![]() ![]() You can publish some of your libraries and receive contribution of the community.You can create experimental app modules, and test any new library here before you put it in your real app module.You can configure your gradle for cache builds, do parallelism & more!. ![]() Nothing more, nothing less, just what the module need. Each module now implements ONLY the libraries it uses.( Also, the modules that implement this module, but the benefit is still there). Faster build times, because if there is a change in some module.The differences between them is that the modularized project have no longer the problems we listed above. Monolithic project on the left, modularized project on the right.Īren’t they se same □?… Kind off. Let me show an example of a monolithic and a modularized project ( BTW IMHO the monolithic one is very well organized and it’s highly probably to be modularized easily). The modules you are going to create can be android libraries, pure kotlin/java libraries, more app modules, wearable modules, auto modules etc. You can think of modularization like turn some of your packages into small reusable pieces of code across your application. Modular programming is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality. How can we solve all the problems listed before and even improve our code quality □? Modularization □ They are mostly used for hide classes that the modules that implement it doesn’t need to access.Īnd the list can keep growing and growing, but I think you already understood where I want to go. If you are using Kotlin you can’t benefit of modifiers like internal, protected, etc.If there are more developers working on the same project, the probabilities to break something are higher as you all can touch something that is HIGHLY coupled to the rest of the project.And believe, if you have thousands of features, uses dagger, etc. If you modify only one of your features, the whole app module will be recompiled.As I stated before, probably only a few or just one of your features uses certain library, but like we only have one module, and all our features live inside that module, all of them can access to any library that is implemented here, even if they don’t use/need it.Something like FeatureA calling FeatureB and vice-versa (I ’ll be addressing you why this is bad for your project later). You probably didn’t realize but it is very likely that you have circular dependencies between your features.Let me know in the comments if we thought the same points. ![]() I’m going to address you some of the things that DEFINITELY gonna happen when your project grows. What happens when my project start growing □? Let me ask you a question, what do you think is going to happen in your monolithic app on that case□? ( Take a few seconds and think about it). What if our app start growing till the point it now has like +60 screens, some of this screens have complex UI, or some of them use specific libraries like Lottie, only some of them have sockets connection, etc… We put networking stuff, repositories stuff, data sources stuff, and any other stuff/libraries you can think off, we just put it all there, in our awesome app module. Yeah… it looks very familiar isn’t it? Yes, that’s the default project structure A.S give you when you create a new project. Default monolithic project structure (1 single module) ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |