We often build one app and sell it to multiple customers. After all, most customers ask for similar things with minor
changes. E.g. if I build a restaurant app and then sell it to one establishment I can then resell it to another with almost
no change at all…
Another common use case is the demo or free version of a paid app, you want to reuse as much of the work as possible
without maintaining two code bases.
This question has come up quite a few times in the forums and most recently again
on stackoverflow.
It’s something we need to document better so here is a brief tutorial.
How does the Appstore “Know”?
The first thing we need to understand is how the appstore identifies your application.
Pretty much all apps use a unique identifier string that is similar to package names, which we map to the main
application package name.
Apple doesn’t allow underscores in these names, Java doesn’t allow the minus character - so avoid both
|
Getting Started
Lets assume we created an app for acme corporation under the package com.acme.apps.supercoolapp
. We
now want to sell a similar app to
Evil Corp. (please no spoilers for those who didn’t see this yet…)
which we will ship as com.evil.apps.supercoolapp
. To do this I need to follow these steps…
Step 1: Create the Acme app as usual
This is pretty strait forward and I’m assuming you all know how to do that…
Step 2: Create the Evil Corp Package
We can just create a new package in the IDE named com.evil.apps.supercoolapp
and place a main class there.
Ideally it should have the same name as the main class we have in com.acme.apps.supercoolapp
, I’ll assume they
are both named Main
.
The cool thing as that one main can derive functionality from another e.g.:
package com.evil.apps.supercoolapp;
public class Main extends com.acme.apps.supercoolapp.Main {
@Override
public void init(Object context) {
super.init(context);
}
@Override
public void start() {
super.start();
}
@Override
public void stop() {
super.stop();
}
@Override
public void destroy() {
super.destroy();
}
}
Notice that I can just write additional logic in every one of these methods or even replace them entirely to provide
unique functionality for Evil Corp.
E.g. I can set the theme to a different theme and some common strings from the resource bundle to different values.
Step 3: Run in the Simulator
The simulator is really just a java class that gets the main class/package as an argument. You can change that
in the project settings under the run section. NetBeans is particularly good with these things as it allows you to define
project configurations and you can switch dynamically between said configurations with just a right click.
Step 4: Build Native App
Just replace all the references to com.acme.apps.supercoolapp
with com.evil.apps.supercoolapp
in the
codenameone_settings.properties
. You will also need to update the certificates/provisioning information depending
on the customer. Make sure to save the provisioning/certificate data of each customer separately so you don’t get
confused…
You might also want to update the title and other properties within the file. Some developers keep multiple versions
of the file and the application icon and just replace them dynamically with a script.
2 Comments
Can you elaborate on how to run in the simulator? I set up a new configuration and put the package/class as the arguments in the run section and it still runs the original Main, not the new Main
Did you select that configuration as the active one?
In which IDE?
Is there output in the console?