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.
Related
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 have developed an android application and am planning to publish it on play store.
However when i went to discuss it with a few people, i got custom requirements specific to their needs.
My question is, is it possible to generate two different apk files from the same code. One would have the extra custom code and one without it. If so please guide me as to what approach needs to be taken for this or if there's tutorials for this, tell me what i need to look for.
Please read about Flavors in Android.
It should be exactly an answer to your problem. this is mainly used for "free VS paid" use-cases but can be a perfect match for you.
Flavors works by defining two package names for the same code.
After setting 2 different Flavors, you can simply query with an if-else on the Flavor and do what you need depending on the "project" you are working on.
Android Flavors
Configure Build Variants
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.
I would like to add two versions of my app to the Android Market, one for a few cents, and one free version, with ads. That's a very common practice.
I'm currently building AdMod into my app, and it seems I'll have to change quite a few files, so it seems best to make a separate version of my app for this.
How do you achieve that? A branch? A different repository? Has anyone found a way to keep both apps in the same repository in a reasonable manner?
The title is not misspelled, I do mean "realise", i.e. how people manage the two versions, not how they add them to the Market.
This kind of thing is a complete nightmare - unfortunately the Android build system doesn't really support it in any good way.
We do it by having 99% of the code of our application in a library project. We then create one application project for each different version of the app, each of which use that library.
Where we need different versions of the app to behave differently, we currently achieve that by having different resources that are queried at runtime. We are in the process of moving to using Dependency Injection via RoboGuice, however.
There are elements of this that work reasonably well, and others that don't. It's necessary, for example, to duplicate the AndroidManifest.xml file, which can be error-prone (it's easy, for example, to add a new activity to one manifest and forget to do so in the others). It's a mess, unfortunately, but the least-bad solution we've found.
Personally speaking, I would strongly advise against using branches to achieve this effect. They can work well initially, but will rapidly become a maintenance nightmare.
One side benefit of using a library is that we've found that it makes testing considerably easier. For an example of how to set this up, see:
http://www.paulbutcher.com/2010/09/android-library-project-with-tests-step-by-step/
People usually upload them twice(like two different programs) and just modify the title for adding something like Ad-Free, Donate and things like that. And on the free version just add the Free label and also put on the description that it's Ad-Supported.
Here is an example with the SMS Popup application:
For the Android Market, they are considered different programs, but for us it's the same, but one is Ad-Supported and the other isn't.
I'm building a suite of applications, meaning that I have a single set of code that gets customized via a single change of an API key. This means that all of the applications have the same activities, same behaviors, but different icons, package names, and application names depending on the client I am building for.
Unfortunately, I haven't figured out a clean way to do this. Because the package name is what the Android Marketplace uses, I've been changing it to com.nilobject.productname.clientname. However, this changes the package for all of the activities to no longer be in the package of the application, since they live in "com.nilobject.productname." Additionally, the autogenerated "R" moves, so all of the references to R in com.nilobject.productname break.
Has anyone else dealt with this problem? I'm using Eclipse for development. Should I just refactor the activities with each build to be in the same package? Is there a system for this that I don't know about?
Thanks for any ideas and help!
I've been down this road with 3 different projects. One app needed "regular" and "pro" versions, another needed a versions of the same app for each of the US States, and another project involved delivering the same app to 3 different clients with each having slightly different graphics and colors.
Anyway, this is the approach that has worked best for me, and I've used it in all 3 of the multi-target projects I've been working on...
http://developer.android.com/guide/developing/eclipse-adt.html#libraryProject