17

I have built a free version of a game app which is now on the market with a name like com.mycompany.myfreegame. Now I want to make a paid version. There will no doubt be tweaks and bug-fixes to both versions required for years to come so I want to encapsulate the encoding of the free vs paid information in as compact a way possible so that I can essentially fix bugs in both versions simultaneously.

If the entirety of the differences between the two versions was handled at runtime then I could set a single flag in the source code and that would be the end of the problem. Unfortunately there are two other things to consider,

  1. The name of the package needs to be different between the two versions.
  2. Some xml needs to be different. For example the free version needs linear Layouts for holding ads, the paid version does not.

What is the simplest way to achieve this goal?

Mick
  • 8,284
  • 22
  • 81
  • 173
  • Wouldn't it be easier to handle the registration state of the application? This would allow you to have a single project, and all you would have to do is simply "hide" the ads, if its the paid version. – Security Hound May 08 '12 at 14:20
  • or using the market's `in app purchasing`? – Eonasdan May 08 '12 at 14:34

5 Answers5

7

I think the first approach I'd try is using 3 projects in Eclipse: one for either version of the game, and a library project with all of the shared code. The library project would be where all the code for your core gameplay goes, and the version specific projects manage loading different layouts, putting ads in the free version, and adding levels/features/hats to the paid version.

You might be able to accomplish your goal of a single code base with a compiler flag using an ant task, but that's beyond me.

dwemthy
  • 471
  • 3
  • 9
  • 2
    This is the solution that I have always gone for in the past. Though nowadays, I would seriously consider in app purchasing for upgrades. – Michael A. May 09 '12 at 13:07
4

I think what you're looking for is a Library Project http://developer.android.com/guide/developing/projects/index.html#LibraryProjects

From that web page:

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.

Another question, very similar to this one, seems to have a decent discussion and answer: Multiple Apps with a shared code base

Edit: Here is a link on how to implement a library project. http://developer.android.com/guide/developing/projects/projects-eclipse.html

In regards to different versions being slightly different, a library project can accomodate. The library project is built first, then the parent (the project that uses the library) is built last and they are merged together. Both projects can define the same resource identifiers and the project built last (parent project), gets priority (overwrites). So essentially, you can override strings/layouts (possibly more, not sure?) in the parent/calling application.

For example: Say you have two projects, free and paid.You could create a string with a default implementation (free version) and override it in your paid version (parent app).

Code in shared libraries Strings.xml file:

<string name="AppName">My Application (Free)</string>

Code in parent app Strings.xml file:

<string name="AppName">My Application Premium</string>
Community
  • 1
  • 1
Gophermofur
  • 2,101
  • 1
  • 14
  • 14
3

I would go with Maven. You can define a parent project with three sub-projects, say:

  • Common
  • Paid
  • Free

Maven allows to have different configuration files, while having the same code base.

For example, I currently have a project where two databases are used, so all the app config files remain on a common project, where the database configuration files and classes remain on each project folder. When I do a build in the parent, every child project is built, unit tests passed, etc...

Moreover, this is only one of the thousand advantages of maven!

EDIT: I just found out, you have an android-plugin for maven, with cool features also

Eugenio Cuevas
  • 10,858
  • 3
  • 29
  • 51
  • 1
    +1 - I use Maven to manage my android apps' build steps and dependency management... it was slightly harder to configure initially but it works great now that I have it all setup. – Jesse Webb May 08 '12 at 14:21
1

May be the best way now is to use Android Studio + gradle. This case allows to build both paid and free versions with one command in console. More details are in this post: https://stackoverflow.com/a/17286142/1705370

Community
  • 1
  • 1
galex
  • 593
  • 7
  • 10
  • As someone who's done this, Gradle integration in Android Studio (especially the Mac OS version!) is flaky, unreliable and FAR, FAR, FAR from Beta quality. Do not use it yet. It will get there but it isn't there yet. – Delyan Jun 24 '13 at 22:48
  • Yes, there are many bugs yet, but it is possible to use it in production. – galex Jun 24 '13 at 22:53
  • For example Android Studio is successful used in production with our product [Glextor AppManager](http://glextor.com/products/appmanager/). The product is buit as paid, free and some partners versions in one step with Gradle. But we had to be used templating of menifest and some java files for it. – galex Jul 19 '13 at 09:21
0

I think you are looking for something similar to this:

Multiple Android Application Package .apk files from single source code

Basically, the easiest approach here is to have two different manifest files and two different main activities and switch the compilation using Ant, though the latter is optional.

Hope it helps.

Community
  • 1
  • 1
Luis Ollero
  • 383
  • 1
  • 2
  • 8