A full working code example of this post is located on my GitHub account here: http://github.com/donnfelker/FullAndLiteVersionSharedLibrary
I’m in the process of completing an Android app for a client and they needed the ability to have full and lite versions of the same application. The lite version would be free and the full version would be for a small fee (say, $2.99).
The Android Market stores applications based upon their unique Java package name. Therefore you cannot have multiple apps with the same package name. Therefore you’re left to do one of two things-
- Create two Android projects and copy the code, altering/removing/etc whatever is needed for the Lite/Full Version.
- Manually recompile and change the package name each time you want to release each version.
Either way its a real PITA. Which is why I’m writing this post. If you’re application requires Lite and Full versions (or more) then you’ll love this below.
Android Project Libraries
Android now has project libraries. This solves the problem of above. I now have the following package structure –
- com.example.myapp – Android Project Library – This is where my ENTIRE app lives. All the functionality for the FULL and LITE versions.
- com.example.myapp.full – Android Application Project – This is a shell that contains graphics and resources needed for the full version only. Basically it’s a super lightweight shell.
- com.example.myapp.lite – Android Application Project – This is another shell that contains nothing but graphics and resources needed for the lite version. Again, its a super lightweight shell.
How To Determine Lite vs. Full
In the com.example.myapp, I have an Application object that derives from the Android Application object. In this part of the app I check to see the package name contains the word “lite”. If so, then the app is running under a lite version. Here’s the code:
return getPackageName().toLowerCase().contains("lite");</pre>
Whats Happening Here? The library project takes on the package name of the project that is referencing it. Therefore at runtime, the package name equates to-
com.example.myapp.lite
Therefore I know that I’m running under the context of my LITE app. I can now disable/enable a feature based upon that knowledge.
Conclusion
While this may be a quick and simple approach, it works. Now, inside of my main library (com.example.myapp), I can sprinkle if statements all over the place to determine if the app is the full or lite version. That way I can share a common code base and not have to worry about maintaining different, yet similar code bases.