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
Related
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.
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.
Should I publish the Android and iOS versions of my app under the same package name, or is there some benefit in using different package names?
i.e. should I use com.mycompany.myapp for the Android and iOS versions of my app, or should I separate them as com.mycompany.myapp.ios and com.mycompany.myapp.android?
I can't think of any technical reason right now to use separate packages, but as this would be horrendous to change later I'm tempted to use different packages.
I agree with the other answers that it's entirely your own choice, but I will also go against the other answers and state that, personally, I feel it's unnecessary to use specific ios and android packages/namespaces.
Both platforms have their own ideologies and structures and I generally play to them when it comes to naming classes and packages/namespaces.
Take these examples:
Android:
com.company.app;
com.company.app.listeners;
com.company.app.adapters
com.company.app.ui;
iOS
com.company.app;
com.company.delegates;
com.company.ui;
It's simple, neat and easy to follow. Obviously there are crossovers and there can always be a bit of confusion ... but the languages and IDEs themselves are different enough to keep your head in the game.
So, as stated; personal choice.
It's arbitrary. But personally I would use different packages:
com.mycompany.android.myapp
com.mycompany.ios.myapp
Agreed. In Android itself, you should use the same package name for the app and for its classes (wherever possible), but don't use the same package across iOS and Android. It's not a technical limitation, it's just that it will help you avoid dumb mistakes.
There is no technical requirements to use same bundle/package name. A good practice is stick to iOS/Android recommendations
I know there are a lot of questions out there about multiple Android versions pertaining to free/paid versions but this might be a little different.
My app currently uses AdMob for advertising and it's published on the Android Market and on the Samsung App Store. Unfortunately, the Samsung store will require everyone to migrate to their own Ad Network in the future, Samsung AdHub. Both AdMob and AdHub have their own libraries, their own SDKs.
I'm looking for a solution to build 2 different versions, one including AdMob the another including AdHub (and all the necessary code). What solutions do I have to easily build 2 versions without much hassle when it's time for a new version release?
Lots of solutions recommend to move the main project into a library project and then build 2 other apps which include the library project (the base project). But I'm not very fond of that solution (I prefer to keep my app in one single project, if possible) and I'm trying to look for alternatives and then make up my mind about which one is better for my needs.
I'd think you should make this possible in your code using the Strategy design pattern. It suites well and can be switched at any trigger your like (even on runtime). If you make a facade for each jar file you will be able to change the dependencies while building, having the same source code.
Other option with this method is just making some configuration in your application that determines which library to use.
Some interesting solutions can be found here:
https://groups.google.com/d/topic/android-developers/8pRugcnzR_E/discussion
The way to go now is to use Android Studio and use different Gradle flavors for each app. Thus, if you fix core functionality, you can quickly do a build for each appstore with it's own ad network.
Library Projects is the way to go. Create a base project where you implement all the common stuff and then create two separate project that use the common one as a "Library". then just implement the rest needed to make the Apps behave differently.
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.