Is it advantageously to have multiple modules in an Android Studio Project over having only a single large app-module?
I know about Android Modules in general and the advantages of SOLID so my focus is especially considering build performance. As gradle can do incremental builds, and if only one module changes, those other modules don't need to be processed?
Is this noticeable or is there even a considerable amount of overhead?
It is of great advantage to have multiple modules rather than to create a single large app-module. Following are the key points:
If you find the compile time is taking longer then you can disable the module from gradle you are not working upon temporarily and compile it faster.
A module helps us to divide project into discrete units of functionality also. You can create one data module which contains all pure java beans and can be used by multiple app if you are in same domain. Eg. Finance domain can have two applications one for viewing policies for customer and other can be for an insurance agent for viewing the same data. But the data module can be shared across all apps and even the data module can be borrowed from server or API team. Data module can be tested individually without any android dependencies and any one knows about java can write test cases.
Each module can be independently build, tested, and debugged.
Additional modules are often useful when creating code libraries within your own project or when you want to create different sets of code and resources for different device types, such as phones and wearables, but keep all the files scoped within the same project and share some code.
Also Android app module and Library module are different.
You can keep two different versions of module based on the API releases as from ASOP.
You can have a look for more on android developer resource
How modularization can speed up your Android app’s built time
App modularization and module lazy loading at Instagram and beyond
Modularizing Android Applications by Mauin
Survey on how Android developers were modularising their apps
There was an article on Medium yesterday, which exactly adresses my question:
https://medium.com/#nikita.kozlov/how-modularisation-affects-build-time-of-an-android-application-43a984ce9968#.at4n9imbe
tl;dr:
First and most important, the hypothesis was correct, modularising project can significantly speed up build process, but not for all configurations.
Second, if splitting is done in a wrong way, then build time will be drastically increased, because Gradle build both, release and debug version of library modules.
Third, working in test-driven way is much easier for a project with multiple modules, because building a small library module is way faster then the whole project.
Forth, doing many things in parallel slows down the build. So having more powerful hardware is a good idea.
Below you can find results of all experiments described in this article
Update
Addressed at Google I/O '17: https://youtu.be/Hx_rwS1NTiI?t=23m17s
i have to setup an android maven build for a customer, which previously was based on ant.
The base app is a white label implementation and the app is distributed to several third party customers. Each of those customer versions uses the same source code and a set of shared resources. But every customer also has some resources specific to their company (constants, assets, etc).
The structure of my android project looks like this. I only included relevant files/folders and the structure is remained from the ant build:
App
|--src
|--res
|--res-customer1
|--res-customer2
|--pom.xml
This means i have to build multiple .apk artifacts from the same source with different resources. What is the best approach to do this?
The first thing i tried was to use different profiles in my main projects pom for every customer. Then i wrote a shell script to execute all maven builds (1 per customer).
Then i came up with using only one release profile in my main project and passing the customer specific properties via command line. Properties are passed via a shell script, similar to my first approach.
But i'm not happy with that, so i thought about using multiple modules. One per customer. But my problem here is, how i can build those from the same source without copying the source from my main project over to all modules?
Or do i have to setup an android project for every customer and refer to my main project as apklib? Will this merge the shared and the customer specific resources?
Is there a best practice to do something like this?
Any other approach is also very welcome.
For only small differences it can be sufficient to just use profiles and a few different properties with resource filter. Profiles however are a bit of a bad pattern in the Maven world and can be hard to work with.
Your hunch to use separate modules for each customer and have the base application be an apklib is correct. I know of several people that have reported on the maven android developers list that this is what they use and works for them. I would personally use that approach in your case as well.
In general I would suggest to ask or at least mention this question on the mailing list.
Since it's popular to have both a free and a paid version in the android market of the same app, I had decided to do the same. Initially I just duplicated the complete codebase and adapted some code here and there (added ads, built in some limitations etc) since there was no option to do library projects at that time, but that left me with two projects that are horrific to manage fixes to bugs as I need to do those twice.
Since r14 we can use library projects with resources, so that would be a great solution to this particular problem as far as I can tell. Therefore I've read up on library projects and conciderations, and I'm curious to know what the minimum amount of files needed in the projects of the different versions are. My questions therefore are;
Could I have all of the code in the shared project, and have bare bone project with basically just a manifest?
If so, should I? is this the optimal way conceptually? (so apart from the fact that it depends on my code base)
How should I deal with library package naming, are there specific rules?
Are there tools about that can compare code from two different projects and perhaps merge them auto-magically or auto-manually, and which one is preferred?
If I understand your problem correctly, you want to create multiple Android apps that are similar to one another (i.e., have a lot of the same source code), but which are different in particular (minor) ways, and you want each of these apps to have a distinct package, so that it can be separately uploaded and distributed on an app store such as Google Play. A Project Library is an excellent facility for accomplishing those goals.
I'm assuming that the differences between your various versions are minor, involving things like resources and the app name and package, and a switch that turns on certain features for a paid version while leaving them off for a free version.
Even if that is not the case, by using polymorphism in the ways described below, your various apps could differ in significant ways and still share a common Project Library.
A Project Library can be defined in Eclipse in the same way as any Android project can be defined, but it is marked as a Project Library (by checking the "Is Library" box near the bottom of the Android page of the library's Project Properties dialog) and cannot be compiled and run on its own. Instead, it is intended to be included by reference in one or more other projects which are actual apps (by adding a reference to it on the Android page of each such app's Project Properties dialog). These apps will use the Project Library, and thus will share its code and capabilities.
Each such referencing app will have its own manifest file (where their respective, different packages can be declared), and they can also define their own classes (including classes derived from the Activity and/or Application classes of the Project Library), so that these classes can be specialized polymorphically for each app that uses the Project Library (e.g., by overriding methods or by providing definitions for methods that are defined as abstract within the Project Library's Activity- or Application-derived classes), although you can also use those Library classes without modification (provided that they are not abstract) by simply referencing them within the manifest file (e.g., in an activity or application tag) of each app that uses the Library, just as you would reference Activity or Application-derived classes defined within the app itself.
If you decided to use this approach, then you would put your main source files in a Project Library, and would create a separate project for each app you want to produce, each of which would reference the Project Library. The manifest file of the Project Library would be overridden by the manifest of whatever project is being created using that Library (actually, I think that the Project Library's own manifest is completely ignored, not just overridden, but nonetheless it is useful to create a manifest for the Library, so that you can manually template - copy and edit - the manifest of each project that uses it from the Library's own manifest).
I have used this approach to create multiple android apps that share some of the same capabilities, and it has worked very well for me.
Regarding package naming, any old package name will work for a library project, but of course it makes sense to use the same prefix for the Library Project's package as you use for your various individual (e.g., free vs. paid) apps that use it, with something like ".library" as the last part of the name, while the various apps could have endings like ".myappfree" and ".myapppaid". Naturally, you would want to use your reverse domain name convention for the library's package prefix to prevent conflicts, just as you would for a package name of a released app.
In Windows, a nice, open-source tool for comparing code bases is WinMerge:
http://winmerge.org/
If I were in your position, however, I would only use this tool to manually identify differences, and would not attempt to use it to automate the refactoring of your code into a Library Project. That would be best done under your own (manual) control.
Finally, as an alternative, you might consider using a single app that is free and that has your free app's capabilities by default, with an option to upgrade to your full app's capabilities (delivered within the same APK) via an in-app payment, rather than having separate free and paid apps. In-app payments have improved a great deal in the past several months (with the release of version 3 of IAB), and although there are still some glitches, they have become a more practical alternative to the free/full dichotomy than they were at first.
Yes, you can have a project that is basically just a manifest specifying app name, name space, icon etc, with all the actual code and 99% of the resources in the library project.
Yes, I think you should use this approach. It's very common to use library projects to deal with the Free/Paid app problem.
I've not had any problems with naming, though you should be careful with any resources in separate projects to avoid using the same names.
I'm not aware of any tools, and if it were me I'd want to do it manually to be sure I'm merging what needs merging and keeping separate what needs to be separate. you've one significant refactor to do, but once all the duplication is removed I'm sure it'll be much easier.
I developed pretty large Paid app for Android. It has many sections and plenty of images and videos. Now, I want to create a LITE version which will have only few section available (with some disabled functions and changed UI) and only some images and videos (80% less resources than the Paid version).
My question to you guys is what would be the best way to handle this problem. Obviously, I can just copy the project and remove unnecessary sections,resources, etc. However, it will make the project hard to maintain (for every bug I would have to fix two project independently). I know that in XCode for iPhone you can set targets and specify which resources can be disabled. Is there anything similar in Eclips?
Thanks
I was playing around with this earlier, because I also had a paid/free combination on a couple of apps and the manual process seemed too tedious.
I created a workspace with three projects
1. A library project with all the common code and resources
2. Free version
3. Paid version
All you have to do in the actual installable projects is register the activities. They can live in the common library project, but you just have to register them with fully qualified names in your app projects' manifests (same goes with a custom application class if you use one).
You can use the PackageManager to determine the fully qualified name of the running app and turn functionality on or off.
I'm producing an application for multiple clients. Each of these apps only slightly differs (in the ui presentation) from the others and almost all of the other code is identical.
In the best case scenario I would brand something like a boot-strap app for each client so they could have their logo on a separate app in the market. Once a user installed a client's app it would download the core functionality, set some prefs and launch as if it had come from a single download. This way I could get the benefit of updating for bug fixes once rather than for each application (slated for 20-30 by end of year.) I've read that this isn't possible because of security measures though (and additional visits to the market place for the second download or having to allow installation from unknown sources isn't acceptable.)
I'm thinking that worst-case/only-case might be to include this shared code in each application and create some batch build and deploy once updates are ready.
I'm looking for a .dll like approach for economy of effort and safety.
I'd appreciate any input on this.
Thanks!
The java equivalent of a dll is a jar file. You can extract all of your shared functionality into a library project that compiles into a jar and then include that as a library in your other projects.