Wireless Messaging with J2ME

Wireless Messaging with J2ME

By Mark Balbes, Ph.D., OCI Principal Software Engineer 

May 2003

Introduction

Messaging has become an important piece of the wireless technology landscape. Simple text messages are relatively easy to send from a mobile device and vendors have discovered that messaging provides a consistent source of revenue from teenagers and business users. Although many wireless service plans are now providing unlimited text messaging, some vendors may still charge per message. For example, on some plans Verizon charges 10 cents to send a message and 2 cents to receive a message.

Similar in use to instant messaging, wireless messaging has the advantage of being asynchronous and having guaranteed delivery. In other words, the sender and receiver do not have to be on line at the same time and the message is guaranteed to be delivered when the receiver does get on line. As such, it is more similar to messaging services like the Java Message Service API (JMS) than instant messaging or email, which is asynchronous but not guaranteed.

The Wireless Messaging API (WMA) is specified by the Java Community Process in JSR 120. It is an optional API that can be implemented on any Java 2 Micro Edition (J2ME) profile. As such, it can be incorporated into mobile devices running the Mobile Information Device Profile or into more capable PDAs running the Personal Profile.

The API supports two types of messages. The more familiar is the Short Message Service (SMS). This is the service often advertised as text messaging. The API supports both sending and receiving SMS messages. The second type of message is the Cell Broadcast short message Service (CBS). This is a means of broadcasting a message to all devices within range of a given cell tower. The API only supports receiving CBS messages.

The Wireless Messaging API

The WMA is relatively straightforward, consisting mostly of interfaces in the javax.wireless.messaging package. These interfaces are:

MessageConnection  - factory for messages, both incoming and outgoing
MessageListener - notified of incoming messages
Message - base interface for different types of messages
TextMessage - plain text message
BinaryMessage - message containing binary data


In addition, the Generic Connection API provides the mechanism to create a MessageConnection. The Connector class will create a message connection if the URL is constructed with an "sms://" or "cbs://" protocol.

The following code creates a connection and sends a simple text message.

  1.     String url = "sms://+5550000:12345";
  2.     MessageConnection conn = (MessageConnection)Connector.open(url);
  3.     TextMessage msg = (TextMessage)
  4.         conn.newMessage(MessageConnection.TEXT_MESSAGE);
  5.     msg.setPayloadText("Hello World");
  6.     conn.send(msg);

In the above example, the MessageConnection is created in client mode. It can only be used to send SMS messages to the specified URL. Attempts to send a CBS message will result in an IOException being thrown.

A MessageConnection can also be created in server mode, in which case it can both send and receive messages.

The following code creates a connection in server mode and uses it to receive the SMS message sent above.

  1.     String url = "sms://:12345";
  2.     MessageConnection conn = (MessageConnection) Connector.open(url);
  3.     TextMessage message = (TextMessage)conn.receive();
  4.     String receivedText = message.getPayloadText();

Similarly, a CBS message can be received by using an appropriate URL, e.g. cbs://:12345. Of course, the above example is greatly simplified. For instance, it is possible for the message to be a binary message in which case the payload will be an array of bytes. To distinguish the type of message, use the instanceof operator.

Rather than block a thread with MessageConnection.receive() in order to wait for a message, MessageConnection supports a single MessageListener. This listener is informed when a new message is available at which point it can then receive the message. Because multiple messages may arrive in a short span of time, the listener should not perform long operations and instead delegate to another thread. Otherwise, performance of the application may suffer.

Building Messaging Applications

The J2ME Wireless Toolkit 2.0

The newly-released J2ME Wireless Toolkit 2.0 provides built-in support for creating wireless applications. Each phone emulator is assigned a unique phone number, starting with 5550000. This allows us to send text messages between two or more running emulators. The wireless toolkit also contains demo applications that provide examples of how to send and receive messages.

Device support

Because WMA is so new, no commercial devices currently support it, nor do any downloadable commercial implementations for PDAs. However, it is a good bet that support will quickly appear in the PDA market where new software can be easily installed. It may take longer for less capable mobile devices (e.g. phones) to provide support.

What Can We Build?

Having SMS messaging on a wireless device opens up a lot of possibilities. We now have the ability to send asynchronous messages not just to standard SMS programs but between custom programs that both produce and consume messages. It is tempting to use WMA in a similar way to that of JMS in a J2EE application. However, we must be careful in doing so.

There are two reasons not to use WMA as a J2ME replacement for JMS and both are related to cost. First, as was pointed out at the beginning of this article, it may cost the user real money (i.e. significant fractions of a dollar rather than inconsequential fractions of a cent) to either send or receive a text message. Therefore, the cost to the user to use an application that relies heavily on SMS messaging could be too high for practical use. Second, because sending a text message does incur a price, device manufacturers will typically ask the user whether it is ok to send the message, presumably by displaying some kind of dialog box. This introduces a usability issue for any application whose flow is continually interrupted by these requests. The alternative to using WMA for messaging is to use the new MIDP 2.0 Push Architecture, which allows a device to accept inbound connections using a variety of protocols.

We've talked a lot about what we should not do with text messaging and how it doesn't make sense to use it as an underlying communication protocol between applications. But there is a lot that we can do with text messaging as well. Given the cost constraints, it makes sense to continue to use wireless messaging for its original purpose, to allow people to communicate more easily.

For example, in a corporate environment that has a large fleet it might be useful to have a simplified text messaging application that allows drivers to quickly send their status. Rather than typing in a different message every time, a simple WMA-enabled application can predefine specific messages to send. A delivery service might have predefined messages like "Package picked up" or "Package delivered". The driver would simply select the message to send and, most likely, also key in some package identification number. This message would automatically be sent to a server that tracks the packages.

Summary

The Wireless Messaging API is a good tool in our J2ME arsenal. As Java developers, it allows us to tap into a highly-used segment of the wireless market. The API is simple to learn and can be used with any J2ME profile. The caveat is that the vendors must support it in their Java runtime environments. Although support is not currently available, it seems likely that devices that already support text messaging will support WMA in the near future.

Update on the PDA Profile

In a previous JNB article The Next Generation of Java 2 Micro Edition, we discussed the new PDA Profile specification, then in public review. Since then a lot has changed.

In March, the proposed final draft of the specification was released. The result is that the PDA Profile no longer exists. The specification has been renamed PDA Optional Packages for the J2ME Platform and split into two optional packages, the Personal Information Management Optional Package and the File Connection Optional Package. The first package provides access to PIM databases such as address books and calendars. The second package provides access to virtual file systems such as memory cards. Gone is the notion of a PDAlet and the tight integration with MIDP applications, including applications that take advantage of both the MIDP LCDUI GUI components and the AWT. Also gone is the ability to access the infrared port on the PDA through a standard interface.

It remains to be seen whether the split in the API is for the better. Certainly one of the strengths of defining optional packages is that the functionality can be accessed through more than one J2ME profile. For example, PIM capabilities make sense both in the MID Profile and the Personal Profile. However, without specifying well-defined and integrated profiles, the portability of J2ME applications may be compromised. Personally, I believe this will turn out to be a non-issue since most vendors will attempt to implement as many APIs as possible on their targeted devices.

References

Software Engineering Tech Trends (SETT) is a regular publication featuring emerging trends in software engineering.

secret