18

I have an Android app that's downloaded primarily from Android Market (now, Google Play). We made a few tweaks to the source and also submitted to the Amazon App Store to see what sort of traction it gets. I'm now looking for a sustainable way to develop from a common code base and yet build so that I can submit to either/both.

Amazon's store has some restrictions about available APIs, and hence I'd like to conditionally remove/modify features from that version. Since Java doesn't support traditional conditional compilation, and conditionally including files in Eclipse doesn't seem trivial (is it even possible?), I wanted to ask what others are doing to solve this.

Admittedly, I'm no Eclipse/Java expert so feel free to school me.

What I'm looking for in a solution:

  • Building/debugging using Eclipse.
  • Static code files, with environment/settings toggles to control what to build.
  • No duplicate code or conditional logic in code to pick code flow at runtime

Is this something you've solved for Android apps specifically, or for other Java/Eclipse based projects? Suggestions for where to begin?

psychotik
  • 38,153
  • 34
  • 100
  • 135
  • 1
    Eclipse ADT plugin has a quite inflexible build life cycle IMO which doesn't provide much configuration options. Consider adopting some command-line build tools like Ant and Maven, where you can gain a lot more micro-control in each step during build process(compiling, dexing, packaging and etc.) – yorkw Mar 22 '12 at 01:10

4 Answers4

10

It's quite easy to do in the newest versions of ADT (version 17), though I do find it makes compilation a bit longer:

  1. Create a new Android project (proj-A)
  2. Go to Project->Properties, select Android, and check "Is Library"
  3. Move all your common code to proj-A, import all the necessary libraries
  4. Create a new Android project for Google Play (proj-B)
  5. Go to Project->Properties, select Android, and add Proj-A to the Library
  6. Repeat #4&5 for the Amazon version

If you have some variables that should be set differently for each sub project (i.e. boolean GOOGLE_PLAY_VERSION to enable Google Play specific functions), you have to create another project to contain these values since you can't have projects that reference one-another in a circular fashion. You can solve this by adding the following steps:

  1. Pull all of your sub-project specific variables into one or more Classes that just serves as container(s) for these variables
  2. Create a "dummy" Java project (dummy)
  3. Config proj-A to add a new Source link to the bin directory of dummy
  4. Add the config Classes in each sub-project with project-specific changes
  5. Profits!

Note that the variables in dummy should not be set as final, otherwise it will override sub-project's setting.

This may seem like quite a bit of up-front work, but has worked quite well for me as far as version control goes.

Edit: Now with Google's move to Android Studio & Gradle, it may be better to move to that if you are starting a new project if you want to support multiple APKs, see Android dev site's Building Your Project with Gradle#Work with build variants. It definitely doesn't hurt to evaluate that option before deciding.

Kai
  • 15,284
  • 6
  • 51
  • 82
  • This works well but you have to maintain separate copies of the manifest and embedded assets and use different package names for each app. – Twisted May 10 '12 at 15:11
  • For the manifest, it's not that bad as it shouldn't change very often once your app stabilized. For the different package names, what I do is: 1. Create a wrapper class for each Activity/Service that exists in manifest by simply extending the original Activity class, 2. Create have a ClassProvider class that simply provides the correct Class instance. – Kai May 11 '12 at 03:31
  • For example, if my "base" package name is com.test with an Activity called `com.test.MainActivity`, and I have a version with the package name `com.test.version_one`, I'll then create `com.test.version_one.MainActivity` that simply extends `com.test.MainActivity`. And I'll all create a Class called `com.test.version_one.ClassProvider` with a `public Class getMainActivity()` method with the code `return com.test.version_one.MainActivity.class`. Finally for all the instances where I need MainActivity.class, I call `com.test.version_one.ClassProvider.getMainActivity()` – Kai May 11 '12 at 03:38
  • It may sound a bit convoluted, but it's all simple boiler plate code, and it allows me to keep all the version-independent code in one place. And once it's set up for the first project, it's just copy-paste the project and let Eclipse fix any error automatically (caused by using a different package name for the new project). For the asset, I've got nothing on it, best advice is to put a copy in your first project so it'll be copied over the new ones, and maybe write a simple script to auto update them on command in the future... – Kai May 11 '12 at 03:42
  • If it helps I can provide a sample screen shot of my project setup. – Kai May 11 '12 at 03:47
1

Unfortunately, it's sort of a convention in Android to change flow at runtime based on what would be in C/C++-land conditional compilation.

Our app has to maintain different behavior for different API levels, so we've created some application-level constants that are initialized statically based on API-level information available to us, and used throughout the code. This is the way that Google does things in their examples (for example, see the ActionBarCompat compatibility library, and in particular the factory method used here).

You could create an interface CustomBuild, and implement it in AmazonBuild and GooglePlayBuild, then use a static getBuild() method to switch functionality as necessary:

if(getBuild().shouldEnableFeatureX()){
    doStuff();
} else {
    doDifferentStuff();
}

Then all you've got to worry about switching between builds is a line or two of code in the factory along with maintaining which things you want enabled in which versions. Or you could include a different version of a static class CustomBuild for each build.

I'm going to second the suggestion of others above re: switching to something like Maven for building; it should make your life much easier once you have it set up.

I'm also going to say you should make the core of the app a library as suggested above, and have two different modules (one for amazon, one for play store) that depend on the library but each only contain the one custom factory file (or just a static class for each type of build that contains the same "should I do this thing?" methods... once you have the infrastructure it's just a matter of preference).

Jon O
  • 6,532
  • 1
  • 46
  • 57
0

I haven't actually tried this yet, but it's something I've thought about.

How about using Eclipse's ability to link to files from a directory outside your workspace?

Start with one Eclipse project: for the sake of argument, say it's the Google Play version.

Now build a second project, beginning with asking Eclipse to link (not copy) the source files from your first project.

To develop the second project, add classes that subclass ones from the original project to realize your modifications. For resources, you can use some combination of includes, attribute overrides, and selectors.

Where it's not possible to subclass or extend, then obviously you'll have to just copy the original source file and hack on it. If you're really OCD about it, you can probably just maintain a patch set rather than a whole redundant set of files.

What do you think, will it work?

Sparky
  • 8,437
  • 1
  • 29
  • 41
  • Maintaining duplicate files sucks, but even if that is overcome there isn't anything here which helps with conditionally enabling/disabling features in either flavor of the project (except at runtime, which is not a good solution). That's one of the three major scenarios I'm looking to address, and I don't think this solution helps. – psychotik Mar 26 '12 at 21:35
-1

You may create manually two projects in Eclipse pointing to the same source folders but with different inclusion/exclusion filters and different target directories.

Then two Ant targets using properties to switch excluded files from javac fileset are enough to generate corresponding jar files.

The aim is to get a clean application for each target, without any code from the other one.

With features listed as pluggable behaviors in a property file or XML configuration, your runtime will adapt itself with the addition of menu entries.

Yves Martin
  • 10,217
  • 2
  • 38
  • 77
  • Is it possible to know the reason of the down vote so that I can improve my answer ? – Yves Martin Mar 28 '12 at 06:13
  • I didn't downvote so I can just speculate. I have no idea what "features listed as pluggable behaviors in a property file or XML configuration" means, and also I don't know if jar vs apk matters (Android apps are APKs not JARs, but I'm guessing that's irrelevant). As the OP though, I have no clue how to actually do what you're suggesting (Eclipse novice here) so I can't mark this as the answer either. – psychotik Mar 29 '12 at 19:19