Newsletter sign-up

View all newsletters

Sign up for our Enterprise Java Newsletter

Enterprise Java

Push messages that automatically launch a Java mobile application

Add MIDP 2.0's push registry feature to your device application

By Srijeeb Roy, JavaWorld.com, 04/17/06

Mobile technology continues to grow in popularity. And Java Micro Edition, or Java ME (Sun's new name for the J2ME platform), is one of the most prevalent technologies for developing mobile applications. Using Java ME, we can run many wireless applications in handheld devices that use either a JVM or KVM.

Included with Java ME is the Connected Limited Device Configuration (CLDC), which targets those devices that have limited resources and use a KVM. Also included in Java ME is the Mobile Information Device Profile (MIDP), a CLDC-based profile for running applications on cell phones. The application component, which runs in the mobile device, is a MIDlet, a MIDP application. A MIDlet is basically a set of classes designed to be run and controlled by the application management software (AMS) inside a mobile device.

The latest version of MIDP, 2.0, has introduced many new features for helping developers build robust enterprise applications, with one of the more important being the push registry. In Java ME applications, sometimes we need to push data from the server and launch a mobile application automatically in the device, without the device being explicitly started by the user. Imagine a situation where a user must be automatically notified when a work item has been created against his/her name and must respond to the work item as soon as possible. Java ME's push registry easily pushes a message to a Java ME application and automatically launches the application. In this article, I will show you how you can add the push registry feature to your mobile application.

The push registry's behavior can be described in the following three steps:

1. The MIDlet registers a port along with the protocol name in the mobile device such that, if any message arrives in the specified port with the protocol mentioned, the AMS delivers it to the MIDlet. The registration is done statically using the Java ME application descriptor (JAD) file. The program can also perform dynamic registration using an API inside the application.
2. From the server, a message is sent to the specific mobile device using the particular protocol and port where the MIDlet application is registered to listen.
3. After the message is delivered to the mobile device, the AMS calls the MIDlet application, which has registered to listen to that particular port and particular protocol. Once the message is delivered to the MIDlet, it is the application's responsibility to process the message accordingly. Typically, an application may choose to open a screen, depending on the message, and allow the user to do some server transaction.

To push the message from the server, in this article's example, we will use a GSM (global system for mobile communication) modem. Figure 1 describes at a high level the exact scenario we will achieve in this article.

Figure 1. High-level scenario of SMS push to a mobile device from the server

Each push registration entry in the jad file contains the following information: MIDlet-Push-<n>: <ConnectionURL>, <MIDletClassName>, <AllowedSender>.

• MIDlet-Push-<n>:: The push registration attribute name. Multiple push registrations can be provided in a MIDlet suite. The numeric value for <n> starts from 1 and must use consecutive ordinal numbers for additional entries. The first missing entry terminates the list. Any additional entries are ignored.
• ConnectionURL: The connection string used in Connector.open().
• MIDletClassName: The MIDlet responsible for the connection. The named MIDlet must be registered in the descriptor file or the jar file manifest with a MIDlet-<n> record.
• AllowedSender: A designated filter that restricts which senders are valid for launching the requested MIDlet.

The MIDP 2.0 specification defines the syntax for datagram and socket inbound connections. When other specifications define push semantics for additional connection types, they must define the expected syntax for the filter field, as well as the expected format for the connection URL string.

A typical example of push registry in the jad file, using socket connection, resembles the following: MIDlet-Push-1: socket://:77, com.sample.SampleApplication, *. This sample descriptor file entry reserves a stream socket at port 77 and allows all senders.

Pushing the message from the server to the mobile device leads to some issues: If we want to send a message to a particular device that has registered to listen to the socket stream on a specific port, we must know the mobile phone's wireless network IP. As many phones do not use the always-connected environment in the wireless network (sometimes the provider does not support the device's static IP inside its network), sending a message to such a device is problematic. If we do not know the device's wireless IP, we will not be able to send a message to the device using the socket connection from the server.

Short message service (SMS) comes in handy for this situation. With SMS, we specify the destination device's phone number; so in this situation, we do not need to know the device's IP address. But using SMS as a trigger also involves some issues: Since the MIDP 2.0 specification defines the syntax for datagram and socket inbound connections and not for SMS connections, it is not guaranteed that all the devices supporting MIDP 2.0 will be able to use SMS as a trigger for the push registry. But the Wireless Messaging API (WMA 1.1)—an optional package over MIDP, which can support SMS—is now supported by many mobile devices, so there is a better chance that SMS will be supported by many devices as a trigger to the push registry. For this article, I use a Nokia 6600 mobile handset, which supports SMS as a push registry trigger.

In addition, sending an SMS message from the server to the device is not straightforward, since multiple approaches are available. SMS service providers provide the APIs (or expose service URLs) through which you can send messages to the designated mobile phone from your server-side application. But this approach requires a dependency on the SMS service provider and its special plans. The alternate way is to use a GSM modem, where you need to interface the GSM modem with your server-side application. In this article, I use an open source product, SMSLib for Java v1.0 (formerly jSMSEngine), which interfaces the GSM modem with the Java server-side application.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.