March 20, 2019
Hot Topics:

Getting to Know J2ME Polish

  • December 20, 2005
  • By Robert Virkus
  • Send Email »
  • More Articles »
Over-the-Air Provisioning

The only standardized way to deploy your J2ME application is the over-the-air (OTA) download. In this scenario, you need a web server that delivers the JAD and JAR files of your application.

In a simple case, you can use a simple Wireless Markup Language (WML) page like the one in Listing 5-1. That page can be accessed with the Wireless Application Protocol (WAP) browser of the device and just provides a link to the JAD file. When the device reads the JAD file, it will forward the control to the Application Manager System (AMS). The AMS then shows some details (title, vendor, and size of the application) and prompts the user to download the actual application file (the JAR).

Listing 5-1. Sample WML Page That Links to a JAD File

<?xml version="1.0"encoding="ISO-8859-1"?>
   <card title="Download"id="main">
         <a href="myapplication.jad">Download Application</a>

Most web servers are already configured to handle JAR and JAD files correctly. If your device does not recognize those files, you just need to add the text/vnd.sun.j2me.app-descriptor MIME type for .jad files and the application/java type for .jar files to the configuration of your web server.

If you have problems accessing the WML page, check your connection settings on your device. Some WAP gateways do not allow ports other than 80, so test this port as well if you encounter difficulties.

In a more complex scenario, you can generate the WML pages on the fly for the current device by evaluating the USER_AGENT HTTP header and using a server-side scripting technology such as JavaServer Pages (JSP) or PHP. You could also send links to the JAD files via binary short messages (as a WAP link) or with simple text messages.

Also, third-party OTA servers are available. These usually offer different provisioning technologies, device recognition, and payment solutions.

Note: Using OTA in the development phase is a pain, since you need to copy the application first to the web server, and then download it from the server again. This takes quite a lot of time and can be costly as well. So check if there are other installation options available for your device.
Multimedia Message Provisioning

Some devices can also receive J2ME applications by using the Multimedia Messaging Service (MMS). Users find this much more convenient than bothering with normal OTA downloads, since no additional interaction is required (apart from selecting the application and the device on a web page). You will need a Short Message Service (SMS) center to send those messages for you.

Tracking Your Installations

If you publish your application on the Internet, it isn't easy to find out how many times it has been installed. Fortunately, the J2ME standard allows notifications at each installation as well as removal of your application. The optional JAD attribute MIDlet-Install-Notify contains the HTTP address, which should be invoked after the application has been installed. The device will try to call the given address and report the status in its content, such as 900 Success. If the web server sets a cookie during the installation, this cookie might also be returned in the installation notification, as demonstrated in Listing 5-2.

Listing 5-2. A Notification of a Successful Installation

POST http://foo.bar.com/status HTTP/1.1
900 Success

Table 5-1 lists the possible status codes.

Table 5-1. Status Codes of the Installation Notification

Status Code Status Message
900 Success
901 Insufficient Memory
902 User Cancelled
903 Loss of Service
904 JAR Size Mismatch
905 Attribute Mismatch
906 Invalid Descriptor
907 Invalid JAR
908 Incompatible Configuration or Profile
909 Application Authentication Failure
910 Application Authorization Failure
911 Push Registration Failure
912 Deletion Notification

You can also track the deletion of your application by setting the JAD attribute MIDlet-Delete-Notify. The device will then try to send a POST request stating 912 Deletion Notification upon removal.

You can specify MIDlet-Install-Notify and MIDlet-Delete-Notify by defining the <info> attributes installNotify and deleteNotify in J2ME Polish. You'll learn more about setting attributes in Chapter 7.

Caution: Do not rely on receiving each installation or deletion notification. Network failures and user interactions can suppress this mechanism.

Updating Your Application

Updates are quite important for business applications, but they can be equally desirable for long-running networked games. Update options depend on the platform.

MIDP 1.0 Platforms

Unfortunately, on MIDP 1.0 platforms, there is no way to trigger an update from within your application. Here are a few update strategies to consider:

  • Query the current version whenever you make your first handshake with the server-side application. Depending on the business requirements, you could then notify the user that an update is available, or the server can deliver content specific to the version of your client J2ME application. When an active user chooses to update the application, you could send an SMS text message containing the link to the latest JAD file on the server. Most devices can now identify HTTP-based links in SMS messages and start the WAP browser directly.
  • Send a binary message that contains a WAP-link to the user. The user can then save and invoke that link.
  • Send the complete application via an MMS message to the user's handset. This is the most user-friendly way, but not all devices support deployment via MMS.
MIDP 2.0 Platforms

On MIDP 2.0 platforms, you can start the update process directly from within your application by issuing a platform request. Since platform requests are handled differently by real-world devices, you should prepare to exit your application after requesting an update. In any case, your application will be shut down before the update is actually put into place. Listing 5-3 shows an example of a MIDlet that persists its current version in a RecordStore so that it can detect updates.

Listing 5-3. Issuing an Update Request from Your Application (MIDP 2.0)

package com.apress.update;
import javax.microedition.io.ConnectionNotFoundException;
import javax.microedition.midlet.MIDlet;
import javax.microedition.midlet.MIDletStateChangeException;
import javax.microedition.rms.RecordStore;
import javax.microedition.rms.RecordStoreException;

public class UpdateMidlet extends MIDlet {
   private static final int VERSION =125;  //1.2.5
   public UpdateMidlet(){
protected void startApp()throws MIDletStateChangeException {
   try {
      RecordStore versionStore =RecordStore.
         openRecordStore("version",false );
      byte [] versionData == versionStore.getRecord(
                             versionStore.getNextRecordID()-1 );
      String versionStr = new String(versionData );
      int version = Integer.parseInt(versionStr );
      if (version != VERSION ){
         //app has been updated:
         //remove version record store:
   }catch (RecordStoreException e){
      //no update has been requested
protected void requestUpdate(){
   //#ifdef polish.midp2
      try {
         //request update:
         //#if updateUrl:defined
         //persist current version:
         RecordStore versionStore = RecordStore.openRecordStore(
                                    "version",true );
         byte [] versionData ==Integer.toString(VERSION ).getBytes();
         versionStore.addRecord(versionData,0,versionData.length );
      }catch (ConnectionNotFoundException e){
         //#debug error
         System.out.println("Unable to issue update request"+e );
      }catch (RecordStoreException e){
         //#debug error
         System.out.println("Unable to persist current version"+e );
   protected void showMainMenu(){
      //TODO implement showMainMenu
   protected void showUpdateMessage(){
      //TODO implement showUpdateMessage
   protected void pauseApp(){
   protected void destroyApp(boolean unconditional)throws
             MIDletStateChangeException {
      //exit gracefully

Devices should ask users whether they want to keep the data when an update is installed. In most cases, it is at least possible to keep the data that has been stored in the record store. Depending on your application's needs, you should also consider storing the user data on the server before an update is requested. You can then add the user's ID to the JAD file that is used for the update. When your application is started and there is no user data, you can check that ID and download the data from the server.

Obviously, there are some security risks here, because JAD files can be changed very easily. So you need to ensure both that the user is really the intended user (authentication) and that any valid user who ended up with an invalid ID for some reason can change that ID.


The chapter introduced you to the general architecture of J2ME Polish. You gained an insight in the four main layers: the build framework, client framework, IDE plug-ins, and stand-alone tools. You also learned about the life cycle of wireless Java applications and how J2ME Polish can help you in each phase.

Pro J2ME Polish: Open Source Wireless Java Tools Suite
by Robert Virkus for Apress

# # #

Page 2 of 2

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date