Researched by: Richard.Marejka@Sun.COM
June 2004
Question
How can a MIDlet be started automatically?
Answer
A MIDlet's life-cycle is managed by the application management software (AMS). At any point a MIDlet is in one of three states: Paused, Active, or Destroyed. The AMS defines four actions as state-transition operations: new, pauseApp, startApp, and destroyApp. While the AMS defines the states and transitions, it does not define the specifics of how the launch of a MIDlet is initiated.
MIDP 1.0 specified only one way to start a MIDlet: manual activation by the user. This lack of choices limited the range of services that a MIDlet could provide; in particular, there was no way to receive new content automatically.
The MIDP 2.0 specification adds two new mechanisms to launch a MIDlet: in response to an incoming connection or at a scheduled time.
The new javax.microedition.io.PushRegistry class handles both.
Launching MIDlets Manually
Manual launch is the only mechanism common to both MIDP 1.0 and MIDP 2.0. The device's interface is used to select a MIDlet within a suite and launch it.
For example, on a Nokia 6100:
- Choose "Applications" (9) from the top-level menu.
- Choose "Select Application" (1) and scroll through the list to the application.
- Choose "Open" (1) from the "Options" menu (left soft key) to start the application.
This method limits content distribution to a "pull" model: To receive content the user must launch the MIDlet explicitly.
Using the Push Registry to Launch MIDlets
The PushRegistry class supports a "push" model of content distribution.
Enabling a MIDlet to launch in response to an incoming connection or at a scheduled time makes whole new classes of services possible.
Specifying a PushRegistry entry requires four items:
- The MIDlet to be launched, specified using the
MIDlet-<n> attribute.
- If the MIDlet suite is signed, a Permissions request, using the
MIDlet-Permissions
attribute. The request must include at least the javax.microedition.io.PushRegistry method.
- An inbound connection URL, required by the
Connector.open() method.
- A filter for inbound connections. The format of the filter is protocol-specific, but the filter "*" matches any string, and "?" matches any single character.
A PushRegistry entry can be specified in either a static or dynamic form.
A static PushRegistry entry is specified in the Java Application Descriptor (JAD) file, the manifest file, or both. The MIDlet, once installed, will always respond to the
specified incoming connection. Add the MIDlet, Push Registry, and Permissions attributes
to the JAD or manifest, as in this example JAD file:
MIDlet-1 : CalPushHandler
MIDlet-Permissions : javax.microedition.io.PushRegistry,
javax.microedition.io.Connector.socket
MIDlet-Push-1 : socket://:5012, CalPushHandler, *
|
These settings will cause the MIDlet CalPushHandler to launch in response to an incoming connection request on port 5012.
A dynamic PushRegistry entry is much the same as a static entry except that you
use the PushRegistry.registerConnection() method to specify the Push Entry
instead of using the MIDlet-Push-<n> attribute.
The MIDlet-<n> attribute is still required in the JAD or manifest,
as is the MIDlet-Permissions attribute, in the case of a signed MIDlet suite.
A dynamic entry can be enabled (and disabled using the
PushRegistry.unregisterConnection() method) after MIDlet suite installation.
An example JAD file would contain:
MIDlet-1 : CalPushHandler
MIDlet-Permissions : javax.microedition.io.PushRegistry,
javax.microedition.io.Connector.socket
|
The MIDlet source code would include:
...
import javax.microedtion.io.PushRegistry;
...
String connURL = "socket://:5012";
String MIDletStr = "CalPushHandler";
String FilterStr = "*";
try {
PushRegistry.registerConnection(connURL,
MIDletStr, FilterStr);
} catch ( ClassNotFoundException cnf ) {
...
} catch ( IOException ioe ) {
...
}
...
|
Using Alarms to Launch MIDlets
The PushRegistry.registerAlarm() method sets up a MIDlet to launch at a
scheduled time. It's similar to the UNIX at(1) facility. The method requires
a MIDlet within the current suite to launch, along with a time. Specify the MIDlet
as a String and the time as a java.util.Date. A sample follows.
In the JAD or manifest file, insert:
MIDlet-1 : AlarmMIDlet
MIDlet-Permissions : javax.microedition.io.PushRegistr
|
In the MIDlet source code include:
...
import javax.microedtion.io.PushRegistry;
...
long prevalarm;
String MIDletname = "AlarmMIDlet";
Date nexttime = new java.util.Date() + 60000;
prevalarm = PushRegistry.registerAlarm( MIDletname, nexttime );
...
|
The MIDP 2.0 specification limits the number of alarms per MIDlet in a suite to one.
Note that the spec doesn't require implementations to support these PushRegistry
features. If they're not supported, a ConnectionNotFoundException exception will be thrown.
An Example
The sample MIDlet suite illustrates use of a static PushRegistry entry and of
the PushRegistry.registerAlarm() method.
Note that the MIDlet suite does not include any UI components.
The MIDlet suite contains two MIDlets and one other class.
The PushMIDlet provides a time-of-day (TOD) service
(see: Internet Engineering Task Force RFC 867) using
the DayTimeServer class. DayTimeServer implements the Runnable
interface, executing the TOD service in a separate thread.
DayTimeServer opens the server connection, accepts the incoming connection
(the event that initiated the MIDlet launch in the first place), responds to the client
with the current time as a string, closes the connections, and exits.
All in all, not very exciting, but illustrative and extensible.
The PushMIDlet also registers the AlarmMIDlet for execution 60 seconds
after the PushMIDlet is launched.
The AlarmMIDlet merely re-schedules itself using PushRegistry.registerAlarm().
The result is recurring launch of the MIDlet, similar to the UNIX cron(1M) facility.
The AlarmMIDlet can easily be extended to include more interesting activities
to be executed periodically.
Conclusion
The two new MIDlet-launching mechanisms that the MIDP 2.0 PuhRegistry class
provides make possible the creation of more content-rich services.
For more information about the push register, see the article
The MIDP 2.0 Push Registry.
| 
Print-friendly Version
