MIDP 3.0 Features: Inter-MIDlet Communication and Events

   
By Bruce Hopkins, October 2009  

This article introduces two major enhancements in the Mobile Information Device Profile (MIDP) 3.0 specification, which is currently in Final Draft stage. The two capabilities that will be the foundation of next-generation mobile applications are Inter-MIDlet Communication and Events.

Contents
 
A Summary of MIDP 3.0 Enhancements
Inter-MIDlet Communication (IMC)
Nonrepetition of Memory-Resident Data
MIDP 3.0 Events
Conclusion
 

As an application developer, you can easily understand the difference between the capabilities of a mobile device as opposed to those of a desktop or server. If you're a Java developer creating mobile applications, you may have experienced some of the limitations of either the handset itself, the mobile operator's network, or the Java ME framework on the device. The Mobile Information Device Profile (MIDP) 2.0 implementation is the most widely deployed Java ME framework, with over 2 billion mobile phones worldwide that are Java technology-enabled.

The next generation of mobile applications will do the following:

If you're interested in creating Java ME applications for this next generation of mobile applications and devices, then you need to get up to speed on the capabilities that the MIDP 3.0 specification offers.

A Summary of MIDP 3.0 Enhancements

As shown in the specification, MIDP 3.0 is expected to provide the following capabilities:

  • Enable and specify proper behavior for MIDlets on each of CLDC, CDC, and OSGi, including:
    • Enable multiple concurrent MIDlets
    • Specify proper firewalling, runtime behaviors, and lifecycle management issues for MIDlets
    • Enable background MIDlets (faceless MIDlets with no UI)
    • Enable auto-launched MIDlets (started at device boot time)
    • Enable inter-MIDlet communications (direct communication, and indirect using events)
  • Enable shared libraries for MIDlets
  • Tighten specifications in all areas to improve cross-device interoperability
  • Increase functionality in all areas, including:
    • Improve UI expressability and extensibility
    • Better support for devices with larger displays
    • Enable MIDlets to draw to secondary display(s)
    • Enable richer and higher performance games
    • Secure RMS stores
    • Removable/remote RMS stores
    • IPv6
    • Multiple network interfaces per device
  • Specify standard ways for doing MIDlet provisioning through other means, for example, OMA (SyncML) DM/DS, Bluetooth, removable media, MMS, and JSR 232
  • Enable extensive device capabilities query
  • Enable localization & internationalization (if appropriate, integrating/augmenting JSR 238 as needed)

Now, let's look into two important capabilities: Inter-MIDlet Communication and Events.

Inter-MIDlet Communication (IMC)

What exactly is Inter-MIDlet Communication (IMC), and why would anyone use it? IMC is a framework that allows MIDlets that reside on the same mobile device to communicate and share data with each other. This is a huge feature, so let's examine the details as stated in the specification.

But wait! Doesn't MIDP 2.0 already provide a capability for MIDlets to communicate indirectly through shared record management store (RMS) data repositories? Yes, MIDlets can communicate indirectly through a shared RMS data repository, and the article Sharing Data Between MIDlet Suites describes how to accomplish that for any mobile device that adheres to the MIDP 2.0 specification. However, indirect communication through a shared repository is not as flexible as direct communication with a "live" running application, which IMC permits.

The following two interfaces in the MIDP 3.0 specification are necessary in order to use IMC:

  • javax.microedition.io.IMCConnection. Implementations of this interface are client-connection objects that adhere to the MIDP 3.0 IMC protocol.
  • javax.microedition.io.IMCServerConnection. Implementations of this interface are server-connection objects that adhere to the MIDP 3.0 IMC protocol.

Figure 1 shows how two MIDlets on a MIDP 3.0 device can communicate through IMC.

 
Figure 1 - The MIDP 3.0 IMC Connection Establishment Process
 
 

As you can see from Figure 1, the MIDlet that acts as a server in the IMC process opens a connection and waits for a client to connect. This paradigm is no different than any other typical client-server environment. However, the great thing about MIDP 3.0 IMC applications is that the server does not need to be running before the client makes a request.

This is a great feature because mobile applications have a fraction of the heap space available to them compared to traditional server applications. Because of this lack of system resources, your IMC server MIDlets cannot always be running on the mobile device.

If you're having a hard time figuring out what would make a good IMC server application, take a look at Listing 1, which contains the code for the SimpleSessionManager.java MIDlet.

Listing 1. SimpleSessionManager.java MIDlet
package imctest;

import java.io.DataOutputStream;
import javax.micredition.io.IMCConnection;
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;

public class SimpleSessionManager extends MIDlet {


    private boolean loginStatus;    // Is the user logged in?
    private long lastLoginTime;     // What was the last login time?

    public SimpleSessionManager() {
        loginStatus = false;
    }


    public void startApp() {

        //
        // The application has been started, so we will
        // open a connnection for clients to access.
        //

        new Thread() {
            public void run() {


                try {
                    //
                    // Open an IMC connection for users
                    // who want to connect to the sessionManager.
                    //
                    IMCServerConnection imcServerConnection = (IMCServerConnection) Connector.open("imc://:com.abc.sessionManager:1.0");


                    IMCConnection imcConnection = (IMCConnection) imcServerConnection.acceptAndOpen();
                    DataOutputStream dataOutputStream = imcConnection.openDataOutputStream();

                    //

                    // Now that the connection is open,
                    // send the login status.
                    //
                    dataOutputStream.writeUTF(loginStatus);
                    dataOutputStream.flush();


                } catch (Exception e){

                } finally {
                    //
                    // Close all the connections.
                    //
                }

            }

        }.start();

    }

    public void pauseApp() {
    }

    public void destroyApp(boolean unconditional) {
    }
}      

Nonrepetition of Memory-Resident Data

The code in the SimpleSessionManager.java MIDlet allows you to solve a simple problem. If you already have data or knowledge residing in memory somewhere on the mobile device, why should you take the time to repeat the operation to regain that knowledge?

Of course, this makes sense in the case of single sign-on for mobile applications. If you're creating and deploying multiple mobile applications for your user base, and you need to authenticate those users to a back-end system, then there's no need to reauthenticate your users if they are running some of your applications simultaneously.

For instance, let's say that you've created a suite of applications for insurance agents who work for a single insurance company. You've created multiple MIDlets for each type of insurance claim: automobile, boat, home, and life insurance. The users of your insurance-claim applications should be able to assume that, once they have been authenticated to one of the applications, they should not have to present credentials to use any of the other applications.

Upon startup, the SimpleSessionManager.java MIDlet opens an IMC server connection and waits for a client to connect. When an IMC client wants to know whether the user has a valid session, the client application connects to the server, and the answer is sent to the receiving mobile device.

Listing 2 shows the code for a simple IMC client application that requests the log-in status of the user.

Listing 2. A Simple MIDP 3.0 IMC Client Application
package imctest;

import java.io.DataInputStream;
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;

public class SimpleIMCClient extends MIDlet implements CommandListener {


    private Command exitCommand; // The exit command
    private Command loginCommand; // The getlogin command
    private Display display;     // The display for this MIDlet
    private String loginStatus;


    public SimpleIMCClient() {
        display = Display.getDisplay(this);
        exitCommand = new Command("Exit", Command.EXIT, 0);
    }

    public void startApp() {
        TextBox t = new TextBox("Hello", "Hello, World!", 256, 0);


        t.addCommand(exitCommand);
        t.addCommand(loginCommand)
        t.setCommandListener(this);

        display.setCurrent(t);
    }

    public void pauseApp() {
    }

    public void destroyApp(boolean unconditional) {

    }

    public void commandAction(Command c, Displayable s) {
        if (c == exitCommand) {
            destroyApp(false);
            notifyDestroyed();
        } else {
            //
            // Get the log-in status of the user.

            //
            new Thread() {
                public void run() {

                    try {
                        //
                        // Open an IMC connection to the server.
                        //

                        IMCConnection imcConnection = (IMCConnection) Connector.open("imc://*:com.abc.sessionManager:1.0");
                        DataInputStream dataInputStream = imcConnection.openDataInputStream();


                        //
                        // Now that the connection is open,
                        // retrieve the log-in status.
                        //
                        loginStatus = dataInputStream.readUTF();



                    } catch (Exception e){

                    } finally {
                        //
                        // Close all the connections.
                        //
                    }


                }
            }.start();
        }
    }

}
       

As you can see, IMC is a great way for two applications to communicate in a MIDP 3.0 implementation. However, what can you do if you need to communicate with several applications at the same time on the mobile handset? Additionally, what if you want to be notified when something "special" happens?

The solution is MIDP 3.0 Events.

MIDP 3.0 Events

IMC is great, but unfortunately, it's not well suited for all intradevice communication.

For instance, IMC comes in very handy when you want to implement single sign-on for the mobile device. But what do you do when the user has signed off, or when the session has expired? If you have multiple applications that have used the single sign-on framework, how can your session manager communicate to all the applications that the user's session is now invalid? IMC does not work well when the server needs to push data out to multiple clients at the same time.

The good news, however, is that the Event framework in the MIDP 3.0 specification was created to handle these issues. The MIDP 3.0 Event framework is a publish and subscribe architecture that scales well when you need to push the same dataset to multiple MIDP 3.0 client applications on the same handset. The following classes and interfaces are necessary in order to use the MIDP 3.0 Event framework.

  • javax.microedition.event.EventData. The EventData class is one of the core elements of the MIDP 3.0 Event framework. The EventData class is used to encapsulate the data passed from the publisher to the subscriber, and it can be used for both user and system events. Following are some system events:
    • AUDIO_MUTE
    • BACKLIGHT_OFF
    • BACKLIGHT_ON
    • BATTERY_CHARGING
    • DATA_NETWORK
    • NETWORK_802DOT11
    • SCREENSAVER_MODE_ACTIVATED
    • SYSTEM_STATE_SHUTDOWN
    • VOICE_CALL
  • javax.microedition.event.EventDataListener. The EventDataListener interface allows your class to receive EventsData objects from the EventManager, as consistent with the Observer pattern. To implement this interface, you class must include the handleEvent() method.
  • javax.microedition.event.EventManager. Event publishers and subscribers both must use the EventManager class to send and receive event data as EventData objects in a MIDP 3.0 implementation. To instantiate the EventManager class, call the EventManager.getInstance() method. Publishers send their data by using the EventManager.post() method, and subscribers add themselves to the notification list by calling the EventManager.addEventListener() method.
  • javax.microedition.event.EventPermission. Use the EventPermission class to gain access to system events.

Figure 2 shows how client MIDlets can subscribe to events from an event publisher.

 
Figure 2 - MIDP 3.0 Event Architecture
 
 

As you can see from Figure 2, the MIDP 3.0 Event architecture is consistent with many other publish and subscribe architectures: The consumer creates a subscription to be notified of a certain event, and the producer sends the event data to a single destination -- in this case, the EventManager -- which has the responsibility to send the event data to the appropriate subscribers. In the case of Figure 2, please note the following:

  • MIDlets A and B are consumers in the eventing architecture.
  • The Event Publisher can be either another MIDlet or the system itself.

Additionally, Figure 2 illustrates that both MIDlet A and MIDlet B are subscribed to a particular event. However, their callback method, handleEvent(), is called if they have sufficient permission.

Conclusion

The MIDP 3.0 API includes several new features that enable Java ME developers to create the next generation of mobile applications. The MIDP 3.0 specification empowers developers to create sophisticated and compelling mobile applications.

The communication path that the IMC framework has opened enables MIDP 3.0 applications to communicate and collaborate among themselves. The MIDP 3.0 Event framework is a publish and subscribe architecture that allows MIDlets to push data to all authorized subscribers. The Event framework not only allow MIDlets to push data among themselves, but it also allow MIDlets to subscribe to specific system events such as network status, battery level, and system state. These are exciting enhancements for Java mobile application developers.

For More Information

JSR 271: Mobile Information Device Profile 3
Java Platform, Micro Edition (Java ME)
Sharing Data Between MIDlet Suites (MIDP 2.0)

Rate This Article
 
 
Discussion

We welcome your participation in our community. Please keep your comments civil and on point. You can optionally provide your email address to be notified of replies—your information is not used for any other purpose. By submitting a comment, you agree to these Terms of Use.