Application Version Upgrade in MIDP 2.0 and MIDP 1.0
Hey Readers,
First of all very nice good evening to all of you. I really appreciate your love and interest and special thanks to Rochak sir, who believe in my posts. If there is any mistake in my posts then please guide me; I am trying to share my knowledge with all of my readers and this will continue in future.
Today I am going to share version upgrade for mobile application using J2ME in MIDP 2.0 and MIDP 1.0. Being a developer & entrepreneur you always want how to inform user about the application's version upgrade. Because you don't want to loose your customer and want to facilitate user by application's new features. The solution is as follows:-
As a developer or even as a user, I always wish that if there is any version upgrade then please let me know at the startup of application even before Splash Screen appears. You can implement the version upgrade functionality in startApp() method. Even you can also store current version in the RMS. Take a look at the functionality:-
protected void startApp() throws MIDletStateChangeException {
try {
/**Check the record store for available version.*/
//fetch the latest available version from server and compare with stored version in RMS
if (!versionStored.equals(availableVersion) && optionalUpgrade) {
optionalApplicationUpgrade();
} else if (!versionStored.equals(availableVersion) && mandatoryUpgrade) {
mandatoryApplicationUpgrade();
} else if(versionStored.equals(availableVersion)) {
showSplashScreen();
}
}
catch(RecordStoreException rse) {
//If application is fresh installation then at startup you'll receive the RecordStoreException, because no record store available.
/** Open record store and store current version of MIDlet. */
}
}
Now you are thinking what is the purpose of optionalApplicationUpgrade() and mandatoryApplicationUpgrade(); Both of these functions are very useful. Consider a scenario in which you update only the themes for application but it is not mandatory update because there is no functionality upgrade, in this scenario you can use optionalApplicationUpgrade() and ask user to allow upgrade. But user can may be skip this upgrade; whereas in functionality upgrade you can use mandatoryApplicationUpgrade() and user can't skip this upgrade.
Till now we setup all the basic architecture for application upgrade, but how we are going to upgrade this is the basic query in your mind. Let's resolve that:-
protected void updateApplication() {
if (profile == MIDP2.0) {
String applicationUpdateURL = http://www.upgradeurl.com;
platformRequest(applicationUpdateURL);
/** Store the updated version of application in RMS */
} else if(profile == MIDP1.0) {
/** Display information to the user for manually upgrade application or you can also send information to the application server to send a WAP push message. */
}
}
Using updateApplication() method you can handle functionality for both MIDP1.0 and MIDP2.0, because platformRequest() method is not supported in MIDP1.0; so either you display the information to user or you can push the wap push message to user by sending a specific format message to the OTA server.
This is all about J2ME application upgrade, If I miss something or you have any doubt then please let me know. I'll try my best to explain each of your queries.
First of all very nice good evening to all of you. I really appreciate your love and interest and special thanks to Rochak sir, who believe in my posts. If there is any mistake in my posts then please guide me; I am trying to share my knowledge with all of my readers and this will continue in future.
Today I am going to share version upgrade for mobile application using J2ME in MIDP 2.0 and MIDP 1.0. Being a developer & entrepreneur you always want how to inform user about the application's version upgrade. Because you don't want to loose your customer and want to facilitate user by application's new features. The solution is as follows:-
As a developer or even as a user, I always wish that if there is any version upgrade then please let me know at the startup of application even before Splash Screen appears. You can implement the version upgrade functionality in startApp() method. Even you can also store current version in the RMS. Take a look at the functionality:-
protected void startApp() throws MIDletStateChangeException {
try {
/**Check the record store for available version.*/
//fetch the latest available version from server and compare with stored version in RMS
if (!versionStored.equals(availableVersion) && optionalUpgrade) {
optionalApplicationUpgrade();
} else if (!versionStored.equals(availableVersion) && mandatoryUpgrade) {
mandatoryApplicationUpgrade();
} else if(versionStored.equals(availableVersion)) {
showSplashScreen();
}
}
catch(RecordStoreException rse) {
//If application is fresh installation then at startup you'll receive the RecordStoreException, because no record store available.
/** Open record store and store current version of MIDlet. */
}
}
Now you are thinking what is the purpose of optionalApplicationUpgrade() and mandatoryApplicationUpgrade(); Both of these functions are very useful. Consider a scenario in which you update only the themes for application but it is not mandatory update because there is no functionality upgrade, in this scenario you can use optionalApplicationUpgrade() and ask user to allow upgrade. But user can may be skip this upgrade; whereas in functionality upgrade you can use mandatoryApplicationUpgrade() and user can't skip this upgrade.
Till now we setup all the basic architecture for application upgrade, but how we are going to upgrade this is the basic query in your mind. Let's resolve that:-
protected void updateApplication() {
if (profile == MIDP2.0) {
String applicationUpdateURL = http://www.upgradeurl.com;
platformRequest(applicationUpdateURL);
/** Store the updated version of application in RMS */
} else if(profile == MIDP1.0) {
/** Display information to the user for manually upgrade application or you can also send information to the application server to send a WAP push message. */
}
}
Using updateApplication() method you can handle functionality for both MIDP1.0 and MIDP2.0, because platformRequest() method is not supported in MIDP1.0; so either you display the information to user or you can push the wap push message to user by sending a specific format message to the OTA server.
This is all about J2ME application upgrade, If I miss something or you have any doubt then please let me know. I'll try my best to explain each of your queries.
is there any advantage of storing version info in rms instead of reading from jad/manifest like this ?
ReplyDeleteclass MyMidlet extends MIDlet
{
private static String version;
public MyMidlet()
{
version = getAppProperty("MIDlet-Version");
}
public static String getVersion()
{
return version;
}
}
Yep there are some advantages for storing MIDlet version in RMS.
ReplyDeleteTake one scenario, You have an application and you are checking for version upgrade at the application startup. Now if your application want to do some processing in between the application and your requirement is to again check for version upgrade, then again you have to request for OTA server after that request goes to actual server.. which will increase the airtime and cost for the end user. so to avoid this scenario store latest version in RMS and for future reference use the same.
I hope I clear your doubt.. :)
the same scenario i had implemented.. but the case is it is installing newer application instead of replacing the current application..
ReplyDeleteI think MIDlet name is different for you.. that's why it's installing new app.. I used it and it's working fine for me.... The new application update previous one.... Please check the MIDlet/Application name.
ReplyDelete