MIDP 3.0 Features: Inter-MIDlet Communication and Events

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.

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.

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.