Chapter   9

The Application Management System

This chapter describes how to port and customize the application management system (AMS), which manages MIDlet suites on a device or device emulator. AMS loads, installs, lists, updates, and removes MIDlet suites. On development platforms it performs these functions either from a command line or from a graphical user interface.

The AMS implementation has both a native layer and a Java™ programming language layer (Java layer). The files for the native layer are in the
src/share/native/kvm directory and include the files main.c, midpServices.c, JarReader.c, and ResourceInputStream.c. The Java layer includes the packages com.sun.midp.dev, and com.sun.midp.midletsuite.

In addition to its own files, the AMS implementation requires persistent storage. This chapter assumes that you have ported it as described in Chapter 4, "Persistent Storage.” The AMS implementation also depends the modules com.sun.midp.security, com.sun.midp.publickeystore, and com.sun.midp.midlet.

This chapter contains the sections:

Porting main.c
Customizing AMS

9.1 Porting main.c

The start up and initialization of the AMS runtime environment is implemented in the src/share/native/kvm/main.c file. The functions in the file parse the command line and initialize the command state structure that holds internal information. It sets up a command loop for the Java program com.sun.midp.Main, and then starts and stops the virtual machine (VM). (The VM is restarted between AMS commands.) The functions in main.c also clean up and reset the classpath between VM invocations.

The command state structure that main.c uses for its initialization is updated within Main.java, in order to save state between successive launches of the virtual machine. (For example, Main.java saves information for the push functionality. See Section 10.2 "Porting the Native Layer" for more information on push.)

As main.c carries out its tasks, its functions use the native storage interface. See Chapter 4, "Persistent Storage” if you have not yet ported the storage module. If you have changed the native calls for persistent storage, you must update main.c to match it.

If your implementation has a different way of specifying command line parameters, change main.c so that it can parse the new command line syntax.

Other changes, such as adding or removing commands or command options are part of customizing the AMS. Customization is covered in the next section.

9.2 Customizing AMS

There are many ways to customize AMS. For example you could:

Remove one or more commands or command options from the midp command
To make the smallest number of code changes, remove the commands or command options from main.c.
To make the MIDP executable as small as possible, remove the commands or command options from both main.c and Main.java.
Change the way the midp executable processes commands (for example, to enable users of the emulator to do part of a MIDlet installation on the command line and part using the graphical user interface on the emulator)

To do this, replace the com.sun.midp.main.CommandProcessor class. In addition, you might also change parts of the com.sun.midp.midletsuite package, such as the Installer class, or the com.sun.midp.dev package, such as the GraphicalInstaller class.

Incorporate native functionality into the user experience for over-the-air provisioning (for example, to use a native browser for fetching documents using HTTP connections, checking for appropriate MIME types of returned resources, and so on)

To do this, rewrite the MIDlet that provides the functionality. The MIDlet is implemented in the com.sun.midp.dev.GraphicalInstaller.java class. (You might do this work as part of changing the way that MIDP processes commands, described previously.)

Change the network protocol used to download MIDlets onto the device from HTTP to some other protocol

To do this, modify the com.sun.midp.midletsuite.Installer class. It implements the MIDlet suite interface the scheduler uses.

Incorporate native functionality into the user experience for AMS. (for example, to have MIDP provide data on the installed MIDlets to the device operating system, which could then display the MIDlets with its native applications; in this scenario, if the user launched a MIDlet, MIDP could accept the storage name from the device operating system and use it to launch the MIDlet)

To do this, change main.c and Main.java.

Replace one or more graphical application management screens (such as the one shown in Using MIDP that lists the MIDlets installed on the device)

To do this, change the MIDlet that provides the functionality. The MIDlet is implemented in the com.sun.midp.dev.Manager class.

Replace AMS with a new Java layer to provide a different user experience with portable code that can be used in multiple devices

To do this, consider providing a new com.sun.midp.midlet.Selector class, which provides the user experience for selecting a MIDlet or MIDlet suite to run when using the GUI, or a new com.sun.midp.midlet.GraphicalInstaller class, which provides the user experience for downloading and installing a MIDlet suite when using the GUI.

Replace AMS with native code (for example for a resource constrained device, as suggested in Chapter 4, "Persistent Storage.”)

To do this, replace the following packages with native code:

com.sun.midp.midlet
com.sun.midp.dev
com.sun.midp.midletsuite
Change the user experience when the push functionality launches a MIDlet.

Update the com.sun.midp.io.j2me.PushRegistryImpl class, or, to update the messages shown to the user, update the com.sun.midp.main.Main class.

Change the text or presentation of the security questions that users might be asked when they install a MIDlet suite.

To update the text, change the strings in the com.sun.midp.security.Permissions class. To change the layout of the messages to the user, or the text of the answers to the security questions, update the com.midp.security.SecurityToken class.

Completely remove the Java Application Manager (JAM)

Removing JAM means removing the command-line interface, the graphical user interface code, the installer, and MIDlet suite storage, to replace it with device-specific functionality. In other words, it means removing all of the application management system except the scheduler. To do this you would remove:

main.c
midpStartup.c
commandState.*
com.sun.midp.main.*
com.sun.midp.dev.*
com.sun.midp.midletsuite.*
com.sun.midp.midlet.Selector

The following classes will have code that is no longer used. You should remove the unused code but not the entire class.

com.sun.midp.security.SecurityToken
com.su.midp.security.Permissions
com.sun.midp.io.j2me.push.PushRegistryImpl

The following classes rely on being initialized by the first class started in the virtual machine (com.sun.midp.main.Main). You should make sure to that your new implementation also initializes them.

com.sun.midp.rms.RecordStoreFile
com.sun.midp.publickeystore.WebPublicKeyStore
com.sun.midp.io.j2me.http.Protocol
com.sun.midp.io.j2me.https.Protocol
com.sun.midp.io.j2me.ssl.Protocol
com.sun.midp.io.j2me.datagram.Protocol
com.sun.midp.lcdui.DisplayManagerFactory
com.sun.midp.midlet.MIDletState

Whatever customizations you make, you should also remove code you are no longer using. Concentrate your search in the following packages:

com.sun.midp.midletsuite
com.sun.midp.midlet
com.sun.midp.dev

Porting MIDP MIDP Reference Implementation, Version 2.0 FCS

Copyright © 2002 Sun Microsystems, Inc. All rights reserved.