All MIDP (Mobile Information Device Profile) 2.0 mobile phones implement the "PushRegistry" functionality, which lets the phone automatically launch an application in response to an incoming connection.
 
In addition, support for the Wireless Messaging API (WMA, JSR 120) makes it possible to write MIDlets that send and receive SMS messages. Working together, this dynamic duo opens up a whole new area of interesting possibilities where incoming SMS's automatically launch a MIDlet.

To show the basic steps of developing for SMS and PushRegistry, the attached sample MIDlet suite PingPong consists of two MIDlets. The first one, "Ping", is used for sending SMS messages while the other, "Pong", automatically is launched when an incoming SMS is present. When launched, Pong simply displays the message contained in the SMS.

Requirements for running PingPong
You will need two phones supporting WMA and MIDP 2.0. We recommend the Sony Ericsson P900 with Organizer software version R2* or newer.

Depending on the way the AMS (Application Management Software) is implemented, it may be possible to run the application on a single device.

Note that PingPong must be installed via OTA (Over The Air) to work with the emulator in KToolbar. Choose "Run via OTA" from the KToolbar project menu to do this. OTA is not needed when installing PingPong on real phones.

Configuration
While you will be able to configure the phone number of the receiving device at runtime, it is recommend that you edit the .jad file to contain the proper number instead.

To do so, change the key "PhoneNumber: 07311112233" to the number of you receiving device.

How it works
The line

MIDlet-Push-1: sms://:16555, Pong, *

in the jad file registers inbound SMS's on port 16555 to the class Pong.

In Ping, the config menu allows the user to define the destination port and phone number for the SMS. The defaults are read from the jad's definition for the keys "PhoneNumber" and "PortNumber".

In the Operation screen, the user can send the SMS. The steps of the operation are reported on the screen. Due to this and in order to let the application be responsive, the send operation is run in its own thread.

On the P900 Organizer Software R2* or newer, or on a similar device with the MIDP 2.0 security framework, the user will be prompted to allow or deny access to certain restricted parts of the API. For the developer, this means that certain calls to the restricted API now might throw java.lang.SecurityException. The send method is such an example. If the user denies access to use the connection, the operation will fail.

When Pong is launched, the call to
 

      PushRegistry.listConnections(true)

returns a list with all connections with available data. The fact that data is available at the moment of launch is used as an, although somewhat uncertain, indicator that Pong was launched automatically. If no such connections are found, a call to

      PushRegistry.listConnections(false)

returns connections where data is not yet available, an indicator that Pong was launched manually. The two cases are treated equally in our sample code besides a line of text on the main screen telling whether or not we think that Pong was launched automatically.

Rather than to thread the process of waiting over each open connection, and because so many examples of that technique already exist on the web, we decided that the low traffic which the application generates would be well suited to a MessageListener.

      MessageConnection mc = (MessageConnection)
      Connector.open(connections[i]);
      mc.setMessageListener(this);
      listeners.addElement(mc);

This way, whenever a new message comes, a call to notifyIncomingMessage is made, with the connection containing the message to process.