J2ME MIDP Deployment Services
- An Introduction to the MID Profile
- The Client Side
- The Server Side
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
When facing the problem of porting Java to the myriad of handheld and dedicated devices that constitutes the new wave of portable devices while preserving the advantages of the Java platform (portability, security, with an high-level language—widespread among developers), Sun engineers have devised a particular architecture, composed of few configurations for defining the common features for a class of devices (they comprise the virtual machine, core libraries, and some APIs) while leaving the differences of each device described by a so-called profile.
Profiles are thought of as gathering together not only common devices (such as mobile phones, for example), but also common applications.
The two configurations currently provided for the J2ME platform are the following:
Connected Limited Device Configuration (CLDC). This configuration is for devices with constrained hardware resources (principally CPU and memory). Typically, such devices run on either a 16- or 32-bit CPU with 512 Kbytes or less memory available for client applications and the Java platform itself.
Connected Device Configuration (CDC). Essentially, this configuration is designed for next- generation devices with more robust resources than CLDCs. Typically, these devices run on a 32-bit CPU, and have at least 2 Mbytes of RAM totally available for the Java platform and client applications.
A need among device manufacturers is the capability to dynamically change the features provided by the device. That is to say, the software is not hard-coded within the device once and for all, but could be to some extent dynamically loaded. Here, deployment techniques come into play.
The configurations don't address lifecycle issues (installation, launching, and removal), leaving these and other features to their profiles. Therefore, we are obliged to discuss deployment issues on a per-profile basis. The following section discusses the deployment of the Mobile Information Device Profile (MIDP).
Deploying MIDlets
The Mobile Information Device Profile (MIDP) is a set of Java APIs that, together with the Connected Limited Device Configuration (CLDC), provides a complete J2ME application environment defining issues such as user interface, the application model, networking, and persistence storage for mobile devices such as cellular phones and the so-called two-way pagers.
The code proposed here was developed and executed on the J2ME Wireless Toolkit from Sun, available at http://www.javasoft.com/products/j2mewtoolkit/.
The key component in the deployment of MIDlets is the Java Application Descriptor (JAD) file that describes all the deployment-related details for a MIDP executable.
Application Descriptor Files
An application descriptor file is a text file, encoded with Unicode, with the suffix .JAD. It is made up of text lines composed as follows:
[attribute-name]+': '+[value]
Such attributes can be read by MIDlets using the static method MIDlet.getAppProperty. Listing 1 shows an example of a JAD file.
Listing 1 An Example Of a Java Application Descriptor (JAD) File
MIDlet-Name: MIDletApplication MIDlet-Version: 0.0.1 MIDlet-Vendor: myself MIDlet-Jar-URL: http://www.awebsite.biz/apps/app.jar MIDlet-Jar-Size: 1234 MIDlet-Data-Size: 256
Attributes in a JAD file can be divided into two main groups, depending on whether they are required or not. Note that attributes beginning with MIDLet- are thought to be "system" attributes, and are reserved. Application-specific attributes cannot begin with the MIDlet- prefix.
Required attributes in every JAD file are the following:
MIDlet-Name. Specifies the name of the application that will be shown to the user.
MIDlet-Jar-URL. The URL from where the JAR file can be downloaded.
MIDlet-Version. The MIDlet version.
MIDlet-Vendor. The MIDlet vendor.
MIDlet-Jar-Size. The size of the JAR file
Optional attributes for JAD files:
MIDlet-Data-Size. The minimum number of bytes of persistent data required by the MIDlet. The device should ensure this memory to the application to be run, whereas it can provide optionally more.
MIDlet-Description. A brief description for the user.
MIDlet-Info-URL. A link to the application home page.
MIDlet-Icon. An icon that (depending on the particular device) will be associated with the application. The PNG image file format is used.
Application-specific attributes, used to configure the MIDlet via its JAD file. For example, the following line in a JAD file would indicate to the MIDlet to launch the configuration property:
prompt-user-at-startup: true
Other attributes (such as MicroEdition-Profile and MicroEdition-Configuration) together with some of those presented above can be specified in the JAR file itself as an entry in the MANIFEST.MF file.
Now that we have seen the main details of the deployment of MIDP-compliant executables, we will see a complete example of a custom advanced deployment service. Such a service is provided to client MIDlets via an HTTP-based, client-server architecture. We will begin with the client.
An Example
We will show an example of a MIDlet application deployment that uses some extra deployment services; in this case, a license utility for registering unlicensed copies of the software. The application is deployed on the client wireless device, thanks to the JAD file shown in Listing 2.
Listing 2 The Application Descriptor for Our Application
MIDlet-1: zmid, /splash.png, com.marinilli.ZMIDLet MIDlet-Jar-Size: 7296 MIDlet-Jar-URL: zmid.jar MIDlet-Name: ZMIDLet MIDlet-Vendor: Maurosystems MIDlet-Version: 1.0
The application class source is shown in Listing 3.
Listing 3 The ZMIDLet Class
package com.marinilli;
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
/**
* Chapter 5 - A Sample MIDlet
*
*
* @author Mauro Marinilli
* @version 1.0
*/
public class ZMIDLet extends MIDlet implements CommandListener{
private List mainList;
private MIDLicenseManager licenseManager;
/**
* Constructor
*/
public ZMIDLet() {
licenseManager = new MIDLicenseManager(this);
}
/**
* Invoked when the MIDlet is paused
*/
protected void pauseApp() {
}
/**
* for cleaning up resources
*/
protected void destroyApp(boolean b) throws MIDletStateChangeException {
licenseManager = null;
mainList = null;
}
/**
* To launch the MIDlet
*/
protected void startApp() throws MIDletStateChangeException {
mainList = new List("Select a Number",
List.IMPLICIT,
new String[] {"Option 1","Option 2","Option 3","Register"},
null);
Display.getDisplay(this).setCurrent(mainList);
mainList.setCommandListener(this);
}
/**
* handles user commands
*/
public void commandAction(Command c, Displayable d) {
int pos = mainList.getSelectedIndex();
if (pos==3){
licenseManager.register();
}
try {
show("Hello!", "OK?");
}
catch(Exception err) {
show("Error", "general exception");
}
}
/**
* utility method to show modal alerts
*/
private void show(String title, String txt){
Alert a = new Alert(title);
a.setString(txt);
a.setTimeout(Alert.FOREVER);
Display.getDisplay(this).setCurrent(a);
}
}
In Listing 3 (lines 41–49), the MIDlet is started with the standard startApp method, prompting the user with a list of options (the MIDlet main menu). The commandAction method (lines 54–66), similar to the actionPerformed method, handles user commands from the option list (as it registered for at line 48). Some methods pertain the MIDlet lifecycle, such as pauseApp, destroyApp, and startApp.
Only the "register" option triggers a real action (it activates the license registering form in line 57), whereas all other options will show a fake message (line 61). The show method at lines 71–76 simply shows a full-screen message until the user explicitly closes it.
When launched via the Sun MIDlet emulator, our simple program opens up, showing an option list, as shown in Figure 1.
){kind=link}
Figure 1 The sample application at work.
When the user selects the registration option, the MIDLicenseManager is invoked (line 57 in Listing 3) for starting the registration procedure, whose menu is shown in Figure 2.
){kind=link}
Figure 2 The user requests to register its copy.
Note that the MIDLicenseManager class is general-purpose and not bound to the particular application code used for launching it. See below for a discussion of this class.
Getting back to the MIDlet interaction—after the user fills in the registration form, the data is sent (wirelessly or with other device-dependent types of connection) to a Web server, where it is evaluated. If the license id and password are valid, a positive response is returned to the MIDlet and the message shown in Figure 3 is shown to the user.
){kind=link}
Figure 3 The response of the registration procedure.