I am working on a project and have planned the following architecture within one single Android Studio project:
1) Eight custom library modules which I intend to reuse in future projects.
2) Three closely related apk modules which complement each other's functionality.
3) Five shared modules which would be used in above apk modules.
Is this the recommended approach to keep the project architecture modular, and reuse of modules in multiple projects, while ensuring performance of Android Studio.
You need to have more RAM for bigger projects , atleast 8 GB .
Lets say you have 2 apk modules and 1 library module that is being used by the 2 apk modules. If you find the compile times taking longer you can disable the apk module you are not working on temporarily and compile it faster .
Related
I recently learned that I could add modules to an IntelliJ (or Android Studio) project. This provided me with a solution to the problem of showing multiple projects using the IntelliJ Code With Me plugin. I had hoped to use this single multi-module project to independently develop all the projects but I quickly saw that the initial project settings.gradle.kts file was modified, thus breaking independence, much to my chagrin.
The development model that I want to impose would have a single Android app that pretty much only uses Android classes. This app would depend on multiple sub-projects (provided in a Gradle dependencies block) each of which is a single, simple project developed using IntelliJ, persisted to GitLab and deployed to Maven Central. Thus all modules are independently developable and deployable.
From time to time, during a remote meetup or review session, I would like to use the Code With Me plugin to view the app project and all its sub-projects together.
My next attempt will be to create a shadow project which is only used by the Code With Me plugin that contains the app project and all the sub-projects as modules. I will need to git update each module. That is not too onerous but if there is a better way, I'm all ears.
You are right about creating a shadow project. The workaround is to create an "Empty Project" project type in the IDEA and add these projects as modules (File | New | Module/Module from Existing Source from the main menu) into this project.
Feel free to watch the related issue: https://youtrack.jetbrains.com/issue/IDEA-65293/
If I have multiple modules in my android project and I add a library dependency (like dagger or appcompat) in (say) 2 of those modules, will that library add twice of its size to the final APK size or will there be just one copy of the library in the final APK?
Also what if I use different versions of the library in different modules, how much will the APK size increase?
I have the same question which you asked so I tested this scenario and create a project with more then one module and place the pdf dependency
implementation 'com.github.barteksc:android-pdf-viewer:2.8.2'
in different module and then build the apk but there is no change in size of apk either to put dependency in one module or more then one module.
I have to add a 3rd party library to my project.
Let's say the library is called XLib and it is made by vendor A.
I already have in my project a library with same name (XLib) but it is made by vendor B and they are 2 different things, I need them both.
how do I handle this scenario in Android Studio?
Thanks,
how are you importing these libraries? are they library modules or gradle dependencies?
if they are library modules, and you have the source, i would recommend renaming the modules XLib-VendorA and XLib-VendorB. Assuming they don't also have overlapping package structures, that may be all you need.
if they are gradle dependencies, then they should originate from different group names, so you would only be concerned about package collisions at that point.
I have two 'android application modules' in one project and they create independent apks.
But I want to combine these two modules into one hence creating dependencies between the modules so that one apk can be generated and one 'android application module' can invoke activities from another 'android application modules'.
Most of the examples suggests me to convert one 'android application module' into a 'library module' but I don't want to do that.
Document here suggests that there can exist more than one 'android application module' in one project but never could I find an example that does that.
Please suggest some ideas.
So guys I figured the right way to handle this problem.
So I created a placeholder library module under the project that had 2 android application modules and modified the build.gradle(i.e. I introduced android SourceSet objects) of that library module to point to sources(src and res folders) of the other application module that I wanted to merge into other application module.
In this way both the application module may coexist under the same project and you never have to touch your application module(that you wanted to convert to a library module).
The only difference would be that the manifest file of this library module will not be having a 'LAUNCHER' intent filter for any of its activity since an application module can not have more than one LAUNCH activities.
So this way you can still have 2 independent apks and continue to develop the applications independently and if you want to include one in the other then use a placeholder library module to point sources of the app modules.
Each application module creates a separate APK. What you may want to do is to create a library module to contain code common to both APKs and then add a dependency between them.
I wonder, is it possible to create agile project structure for large android project?
Now project is organized as single android_module. And compile time depresses me. Project contains ~350 xml layouts, ~800 small images, so R.java generation and packaging takes very long, even if I changed only one xml layout for one activity.
My goal - allow fast complie and testrun for one single part of project
Split the project up into Modules (hopefully you're doing this anyway, just structure it this way for IntelliJ too).
Then add module dependencies where required and you can Make Module - which will only recompile the parts you are interested in.