Creation of a demo and full version of the application based on one database / code project

Question

I developed one Android application in the same project with Eclipse - it is structured (from the iPhone), so one constant determines whether this is a demo or a full version.

Now I have a problem that every time I want to create a demo, I need to change the constant, but I also need to make a copy of the project with a different package name.

Obviously, the code change in the original full version must be copied to the demo version or I will have to re-create the creation of the demo application every time I submit my application.

I see three possible approaches:

1. Although I studied library projects, it is still not clear to me how this really gives a good solution in this case.

For example, if I have a full version with an activity structure:

A1 A2 A3 

using utility classes U1, U2

Of course, U1 and U2 can be in the library project and refer to both projects - but the actions, strings.xml, graphics, layouts should be duplicated (or is there another way that I do not see?) This does not seem to be a good step forward and, unfortunately, it was not explained in similar questions on this topic when this approach was proposed.

2. Another way is to create different package names based on different build settings (similar to iPhone), but this is not possible in Eclipse, and not using external scripts (which, frankly, I avoid, because it seems more error prone), but compilation must also be called outside of Eclipse

3. Probably the most direct approach (as well as currently with little effort) is to simply manually copy the project, change one constant, rename the package and compile / export every time I submit. This, however, seems to be pretty “basic” and, of course, does not look professional (compared to setting up the iPhone / xCode / build solution as a target).

What would be the best approach (requiring minimal changes and still stable and easy to use)?

Thank you very much!

EDIT

For everyone who tried tim, it works just fine, however I ran into a problem with custom attributes.

Check this out: How do I set custom attributes for Android libraries and reassign package names at build time? it will allow isse for libraries

Answer 1

I am doing it now in eclipse and it is not complicated.

• Convert an existing source project to a library.

• Create two new projects, free and paid.

• Include the library project in free and paid projects.

No need to have a separate action or resource inside projects with free / pay. All you need is a manifest for everyone that references actions from your library. In my free and complete projects, there are currently no java, resource or layout files of any kind, this is just a manifest that references actions from the library.

I use the same code for both projects, and I distinguish them by saying:

 if(getApplicationContext().getPackageName().equals("full version package name")) { //do full stuff } else { //do free stuff } 

Some errors that I hit, especially if you have already released your application on the market:

• If you change the full name / path of any activity, it will disappear from your desktop. Therefore, if your library has a different package name than the existing version, you will lose any desktop icons. They can be replaced by the user, but this is not ideal.
• Similarly for appwidgets, if you change the recipient name, they will disappear during the upgrade.
• Under no circumstances can you change the package name of an released application.

If you have already released the free and pro version, this is somewhat unsuccessful, because the activity path should change to the general path to the library, and you cannot rename the released package in accordance with the library path. Therefore, someone will have to lose the existing icons.

In my case, I just released the free version before breaking it, and I was able to name the library with the same package name as the free version. I was skeptical that you would be allowed to include a library with the same package name as the wrapper package, but apparently this is possible (works fine for me).

So, in my case, I have three projects:

• Main library: package name: com.myname.myapp
• Free version: package name: com.myname.myapp
• Pro Version: package name: com.myname.myapp.Pro

In the free and full versions, actions are added that are called com.myname.myapp.ActivityA or com.myname.myapp.ActivityB , which exist only in the library project.

Answer 2

I see that the simplest approach would be to have three projects:

• demo
• full
• library

Demos and complete projects will have their own unique package name, as defined in their Manifest file. Their activities are simply ports that send information in a package for the main activity to the library project. A task in the library project will read the transferred package for the necessary parameters that determine whether it was launched by a demo activity or a full action. Then he will act accordingly.

So the logic is this:

The user starts the demo activity → Demo activity creates a Bundle with information that says that the demo activity → Demo Activity starts the library activity, which then runs the rest of the program in demo mode.

OR

The user starts full activity → Full action creates a package with information that says full activity → Full activity starts library activity, which then runs the rest of the program in full mode.

Answer 3

It is very simple using build.gradle in Android Studio. Read about productFlavors . This is a very useful feature. Just add the following lines to build.gradle:

 productFlavors { lite { packageName = 'com.project.test.app' versionCode 1 versionName '1.0.0' } pro { packageName = 'com.project.testpro.app' versionCode 1 versionName '1.0.0' } } 

In this example, I add two products: first for the lite version, and the second for the full version. Each version has its own versionCode and versionName (for publication on Google Play).

In the code, just check BuildConfig.FLAVOR:

 if (BuildConfig.FLAVOR == "lite") { // add some ads or restrict functionallity } 

To run and test on the device, use the "Build Variants" tab in Android Studio to switch between versions: