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.
Related
I want to build an app with different configurations. Let's say there are two flavors, A and B, which depend on different third-party libraries to perform similar tasks. I want to offer a default configuration on Google Play which comes with a separate launcher for each flavor. Both launcher instances should share local data. However, I also would like to keep the option to build and ship just one of the flavors without including the third-party libraries required for the other one.
From what information I've found, I could either use a single flavor with two launchers, losing the option to build just for one of the third-party libraries. Or I could use two flavors, but would have to separate the whole project into multiple apps with separate ids which would have to be updated separately, presumably require more storage and require some kind of workaround for sharing local data.
So, is there a way to build multiple flavors into a single app bundle with separate launchers or a similar solution for these requirements?
is there a way to build multiple flavors into a single app bundle with separate launchers
I am assuming that by "flavors" you mean product flavors in the Android build system. If that is correct, then... no, sorry, there is no simple option for this.
or a similar solution for these requirements?
It might be possible to pull off something like this with a careful subdivision of your app into modules. You would have three app modules — I will call them a, b, and ab after your naming system. Those would be as small as possible. Most of your code would reside in a series of library modules. In particular, code tied to each third-party SDK would be isolated in its own library (or libraries). a would link to library modules tied to one SDK (plus common modules), b would link to library modules tied to the other SDK (plus common modules), and ab would link to (probably) everything.
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.
I'm currently developing an Android app that needs to be distributed as separated apk to the store for n customers. All having same features, only the design differs or text sometimes.
How would you manage this? Which best practices would you recommend? I can definitely start from scratch again. It's a side project, so best practices first :)
You can use Flavors, For complete detail you can refer this Official doc.
Seems you need flavors. You can define for each flavor different versions of the files that vary either code or resources.
https://developer.android.com/studio/build/build-variants.html
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.
This is more of a fundamental question I suppose. I currently have in the market one app that I have separated in two projects. One project (with it's unique package name, obviously) does not have Google Ads and is not free. The other project has Google Ads and it's free.
Both projects are exactly the same. Same functionalities.
When I want to add a new functionality, I have to work on both projects, making then the release of my app slower, since I am basically control-c/control-v what I did in one project onto another. And sometimes I just forget something, so I have to fix the issues...
So, basically, I am wondering if there's a better way I have to manage that?
Maybe creating a rather intelligent script that will build the application depending on what I want (i.e: if it's ad based version, should use the AndroidManifest that declares the AdMob Activity)
Or maybe create a library? But I don't think this approach would work.
Looking forward for inputs.
Regards,
Felipe Caldas
Yes, a library project is exactly what you want. Put all the functionality in a library, and have two very thin shells for each of your app types that make calls into the library. As you noticed, duplicating the code is error prone and at best just extra work you shouldn't have to do.
See: Managing Projects for details. That page even mentions your exact scenario:
If you are creating an application that exists in both free and paid
versions. You move the part of the application that is common to both
versions into a library project. The two dependent projects, with
their different package names, will reference the library project and
provide only the difference between the two application versions.