I'm searching for differences between modules and flavor.
I've read those posts:
Android difference between module vs flavor
When to use android flavours vs separate projects
But it's still a bit blur about the differences and how to choose between one and another.
So far the only differences, I manage to get out of it is:
Different structure
Modules can do everything that a Flavor does.
My first question is, what's the difference and what's so good about flavor that you don't use modules ?
Also, is flavor adapted for 2 applications where Application-1 and Application-2 share same code base (i.e. API, models, utils, service), but deviate from each other in terms of features and UI?
When to use modules:
When your project can be separated into smaller independent parts.
I've don'e this to my project, and my compile time went from 50+ seconds per iteration to less than 10 per iteration.
Because when I change code in 1 module, the others dont change and that's why the compile time is faster.
When to use flavours:
When you want to publish apps to different stores, and they need to have different applicationId
for example you want to publish to google play, and amazon store, and some other store that no one has heard of.
When you want to have part of your app available under certain build time conditions
When you want to whitelabel your app - basically it has the same logic but different UI, so in practice it is a completely different app, only... it's not.
Related
I'm developing and app which will (during the development and testing process but NOT in the final version) require slightly different functionality in different .apk release files.
There are few issues in this particular case:
different "testing" APK versions shouldn't contain ANY of the code and resources (so no shared strings and images) from other APK versions (for security/reverse engineering reasons cause different people will have access to different APK versions)
at the end of the development process the app will contain all/most of the features from the "testing" builds.
the app uses multiple modules (developed by different teams)
there might be a few (between 3 and 10) of those versions, all developed concurrently by multiple developers in the same project on the same repository.
The goal is to make it as easy to maintain (including UI/integration tests and CI) as possible. Is there any way to achieve this? We did some experiments with different build variants and flavours + no-op modules/methods but it seems a little bit complex. Any alternative suggestion will be welcomed.
Your question is indeed too broad, I think there is no general solution to your problem because it's too complex, and without knowing the details of the project it's even more difficult to tackle. Actually, your problem sounds much more like an organizational one rather than a programming-related one, the only "solution" I see is to address specific issues.
1. No VCS, no party
there might be a few (between 3 and 10) of those versions, all
developed concurrently by multiple developers in the same project on
the same repository.
I would start by defining your VCS flow, because without a version control system I'm afraid you and your team(s) aren't going anywhere. If you were to use git (don't know how this would be done with other VCS), you would have a few options:
Each feature (team) has its own, long-living, feature-branch. The common code shared by all teams is kept on a develop-branch, on which each feature-branch periodically rebase. You would need to setup your CI to build test apks and run automated tests for each branch. At the end of the development process everything gets merged into master (or develop, or whatever). The advantage would be that each feature (team) would work on a sealed portion of the project and will be able to handle test releases and automated tests autonomously. The disadvantage would be that the common part of the codebase (develop-branch) needs to be handled very carefully, otherwise you might get conflicts-hell.
The whole project is developed on a common develop-branch. Each feature is developed with small increments, each member of each team branches from develop-branch and merges every iteration back on develop-branch. The advantage would be: different features can potentially depend on each other, conflicts are less likely to occur, CI has simpler configuration. Disadvantage: teams are less independent, releasing different apks requires a strategy.
2. Define dependencies
In order to choose a proper strategy, it is crucial to define clearly the dependencies between the features. Would it be possible to have truly parallel development of each feature?
This depends entirely on the specification of the project. For instance, if you were to develop an e-commerce app, you might end up having feature domains like user account, products catalog, orders processing... If all of these features depend on common local storage layer, how are you going to develop them truly in parallel?
Once you've defined the dependencies, you will be able to decide in what degree the features can be developed in parallel. Do different teams need to agree on common interfaces? Could a feature be completed even if other teams are still at 0?
3. Build variants are your friend
different "testing" APK versions shouldn't contain ANY of the code and
resources (so no shared strings and images) from other APK versions
(for security/reverse engineering reasons cause different people will
have access to different APK versions)
Flavors are meant to do exactly what you're looking for, that is, build different apks from the same project but using different subsets of code and/or resources.
Keep in mind that you can have flavors in multiple dimensions (and build types). For instance, you could have one flavor dimension called "network", with 2 flavors "mockedNetwork" and "actualNetwork". Then you could have another dimension "feature", with "featureA", "featureB", "featureC". You could then easily build and release 6 types (well 12 if you have also debug and release build types) of apks, one for each combination (mockedNetworkFeatureA, actualNetworkFeatureA, mockedNetworkFeatureB etc.).
With flavors you could easily replace chunks of the app that you don't want your tester to have. For instance, you could have a strings.xml file with only lorem ipsum strings and then keep actual texts strings only for internal use.
What I would do is to use git. The master branch is kept clean for production and each team can have one or multiple branches to work on. They can change the package name in their branch so your APKs will all be different. The only problem with this approach will be the merges into the master branch that might cause conflicts. But this could be a solution to your problem.
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'm currently developing an app which is actually available in Google Play and it has two different versions. One of them has full functionality and runs without any advertisement.The other one instead cannot access every feature and shows ads.
I'm managing these two versions with two different android studio projects and
two different repositories.
I just wanted to know how could I manage better the development of these two versions of the same app. I've read something about flavors in gradle but I don't really know if they could be useful in my case. Other thing I've thought about is that maybe I could just have one repository with a branch where I just have different files for those features which are not the same, remaining always the common files update.
So, which is the better way to deal with this situation? Any other ideas are welcomed.
Thanks in advance for your help
Gradle flavors are what you are looking for. With them you can have all the common code and resources in one place, so there is no need to copy it, and the code and resources that differ in another place. Flavors also provide a convenient way to build several versions of the app.
From what you describes it seems that both your versions of the app are almost the same, so in your case you simply need a boolean to differentiate between them:
if (FULL_VERSION) {
unlockFeature();
}
else {
showAd();
}
You could implement this by creating a class for each flavor, one with the constant set to true and one with constant set to false. A more object oriented design would be to have a class that unlocks the feature for one flavor and another that shows an ad for the other.
Note that flavors produce an APKs with different package names, so you can't have an in-app purchase that would unlock features and remove ads.
I just finished watching Xavier Ducrohet presentation about gradle, and I am about to start using flavors. I want to understand what are their big advantage over libraries?
I know that android library can have it's own manifest / resources and of course sources, and so does flavors. But what else is there? Why should I use them?
Flavors and libraries aren't really comparable.
A library is typically a discrete piece of functionality that you can reuse across multiple projects. It might provide a piece of functionality that you use frequently or it might provide a custom View that you find yourself using in a lot of applications.
Product flavors are slightly different versions of the same application. The most common example is a paid vs. free app- with product flavors you can have a single codebase that generates both versions. Another more simplified example would be an app that is available in two colors- you might have a red product flavor and a blue product flavor. In this case the only difference might be a single color string in your resources.
Where I think the confusion is coming from is that you can use a library to accomplish the goals of the product flavor system. That is, you can take your common functionality and place it in a library project that you include in each of the versions of your application. This is a messy way to accomplish the goal of having two apps with only minor variation between them, and if this is your goal, you should use product flavors instead.
From the Gradle Plugin User Guide:
If the answer to “Is this the same application?” is yes, then this is probably the way to go over Library Projects.
So I have an interesting question more or less to the high level design of using Android Libraries vs product flavors vs product variants etc.
Right now my problem is that I am trying to build a second Android application (after building my first) one where in many cases I can reuse a majority of my non UI code (IE activities, styles etc.) and reuse a small portion of the UI code.
Right now I see two different strategies, one being make a new application + Android library for the shared code (resulting in basically my POV two new GIT repos along with two corresponding projects) or take my original application and write a few productFlavor / productVariants and sort of tweak things as needed (this would allow me not to have to make two new GIT repos + project setups).
What do folks usually do in this situation?
Update:
Maybe a project with each submodule would work best as separate apps while moving the central library (shared code) to a library module.