What's New in the J2ME Wireless Toolkit 2.0

Print-friendly Version

The J2ME Wireless Toolkit contains everything you need to develop MIDP applications. Sophisticated functionality is presented with a simple user interface. Since version 1.0, the toolkit has had the ability to build and package MIDlet suites. Version 1.0.4 added a network monitor, a memory monitor, and other enhancements, described in New Features in the J2ME Wireless Toolkit 1.0.4.

These enhancements were excellent, but version 2.0 of the J2ME Wireless Toolkit is a major upgrade. The obvious change, support for MIDP 2.0, is only the beginning. This article describes the toolkit's many new features in detail. The article will be most useful to you if you're already familiar with MIDP and version 1.0 of the toolkit.

New Emulator Skins

A Big Color Screen

The most obvious visual change is the addition of new emulator skins. The default mobile phone emulator has been updated to reflect constantly evolving technology. The screen, once 96 x 128 pixels and gray-scale, is now 180 x 208 and color. The extra screen space is liberating, but keep in mind that the MIDP 2.0 specification still only requires a minimum display size of 96 x 54.

The J2ME Wireless Toolkit 2.0 includes an entirely new emulator skin, QwertyDevice. Sporting a whopping 640 x 240 pixel color screen and a full keyboard, QwertyDevice represents a wireless communicator, a level beyond a mobile phone.

The Vanguard of MIDP 2.0

The J2ME Wireless Toolkit 2.0 emulator implements the MIDP 2.0 specification, which includes dozens of exciting features, including:

• Secure networking with HTTPS
• Support for playing simple tones and sampled audio data
• The ability to create custom item components for forms
• A game API
• Use of int arrays to represent and manipulate images
• A permission-based security architecture
• A push registry that enables MIDlets to receive incoming network connections

For more information on MIDP 2.0, see What's New in MIDP 2.0.

Check Out the Sound System

One of the new features in MIDP 2.0 is the ability to play sampled audio and simple audio tones. The audio APIs in MIDP 2.0 are a subset of the Mobile Media API 1.0 (MMAPI), a full-featured optional package for playing music and video. MMAPI is defined by JSR 135; the audio subset that's included in MIDP 2.0 is called the Audio Building Block (ABB). For an introduction to MMAPI, see Mobile Media API Overview.

The J2ME Wireless Toolkit 2.0 supports the full Mobile Media API 1.0. If you wish, you can disable this support (leaving only MIDP 2.0's ABB): Just choose Edit -> Preferences... from the KToolbar menu, select the API Availability tab, and uncheck Mobile Media API (JSR 135). This checkbox controls inclusion of the API at both compile time and runtime. The following image shows the API Availability tab in the preferences window.

Seleting Available APIs (Click for the full image.)

MMAPI is quite flexible and allows for a variety of content types, protocols, and recording capabilities. You can control these capabilities using the MMedia tab of the preferences window in KToolbar:

Choosing Multimedia Capabilities (Click for the full image.)

Feel Like a Teenager Again

Short Message Service (SMS) has turned out to be a huge revenue booster for mobile carriers, fueled in part by millions of teenagers sending text messages to each other. The Java platform's motto could be "Yeah, we can do that too." The Wireless Messaging Architecture (WMA) includes support for exchanging SMS and other types of messages from MIDP and other Java platforms. WMA is an optional package, defined by JSR 120. For an introduction to WMA, see The Wireless Messaging API.

The J2ME Wireless Toolkit emulator supports WMA 1.1. As with MMAPI, support for WMA can be enabled or disabled using the API Availability tab in the KToolbar preferences window. Furthermore, the WMA tab in the same window lets you customize the behavior of the WMA implementation:

Setting WMA Attributes (Click for the full image.)

The toolkit also includes a small utility, WMA Console, that allows you to send text messages to the emulator. To run the console, select File -> Utilities... from the KToolbar menu. Then in the WMA box, click on Open console. You'll see the following window:

Utilty for Sending Text Messages

The toolkit's WMA tools make it easy to send messages between different instances of the emulator, or from the console to an emulator. You can also use the console to broadcast messages to all running emulators. You can even use the push registry to catch incoming messages and pass them to your own MIDlets. To learn more about WMA support, try the SMSDemo example that's included with the J2ME Wireless Toolkit.

Setting MIDlet Permissions

Your MIDlet suite JAD should reflect the permissions needed by your MIDlets. MIDP 2.0 defines MIDlet-Permissions and MIDlet-Permissions-opt attributes for this purpose. (The opt permissions are those that aren't absolutely needed for your application to run.) In the MIDP 2.0 specification, all defined permissions relate to various types of network access. Optional packages may define additional permission types as appropriate.

The J2ME Wireless Toolkit 2.0 provides an easy way to add the permission attributes to the JAD. Just press on the Settings... button and select the Permissions tab. Click on one of the Add... buttons and simply select a permission type from the list, as in this screen shot:

Specifying Permissions for a MIDlet Suite (Click for the full image.)

Working with Protection Domains

A protection domain determines whether a permission is granted or denied. Every MIDlet suite gets installed into a specific protection domain on the device. The emulator in the J2ME Wireless Toolkit 2.0 includes an implementation of the protection domain security architecture described in the MIDP 2.0 specification. For simple testing, you can choose the runtime protection domain from the Security tab of the preferences window. The emulator includes four protection domains:

• In the untrusted domain, all permissions are either denied or deferred to the user. You can see this with a simple MIDlet that makes an HTTP connection; the emulator prompts you to allow or deny the connection.
• The trusted domain allows all network and push registry permissions.
• The minimum domain denies all network and push registery permissions.
• Finally, the maximum domain allows all permissions. It is the same as trusted.

When you're developing an application using the toolkit, the application usually runs in whatever protection domain you've selected in the preferences. In practice, on real devices, applications are installed into protection domains based on the device's implementation of the MIDP 2.0 security architecture. The J2ME Wireless Toolkit 2.0 includes an implementation that installs cryptographically signed MIDlet suites into protection domains based on the signing certficiate.

Signing MIDlet Suites

The J2ME Wireless Toolkit is comprehensive; it even includes the tools you need to sign MIDlet suites cryptographically. Of course, signing a MIDlet suite isn't much use unless client devices can verify the signature. In actual distribution, a signed MIDlet suite usually includes a certificate issued by a well-known certificate authority. To spare you the expense of getting a "real" certificate just to test your application, the toolkit maintains a list of root certificates that the emulator accepts for verifying signed MIDlet suites. You can modify this list using one of the toolkit's utilities. Choose File -> Utilities from the KToolbar menu. In the Security box, click on Manage Certificates to bring up the J2ME Certificate Manager:

Managing Root Certificates (Click for the full image.)

You can use this tool to view and manipulate root certificates while you're testing your MIDlets in an emulator. Keep in mind, though, that on a real device you probably won't have that kind of freedom. You'll just have to sign your code and supply a certificate issued by a well-known certificate authority.

To sign a MIDlet suite, choose Project -> Sign. The Sign MIDlet Suite window will pop up, listing all the available signing keys:

Signing a MIDlet Suite

If you ask the toolkit to create a key pair, it prompts you for some information it will place in the corresponding certificate. You also have to decide which protection domain will be used for MIDlet suites signed with the new key pair. The certificate that's generated is self-signed, and is automatically added to the toolkit's list of root certificates. Within the world of your J2ME Wireless Toolkit, you can create signing keys, sign a MIDlet suite, and have it install into the expected domain on the emulator. These features are a big help in your testing. Just remember that real devices won't recognize your self-signed certificate.

What does signing a MIDlet suite entail? All that happens is that a couple of new attributes get added to the MIDlet suite JAR: the signature itself and the certificate. The toolkit handles all the details for you, but if you're curious, open up the JAD file in a text editor. The additional attributes look something like this (backslashes indicate where I've broken the lines for legibility):

MIDlet-Certificate-1-1: MIIB5DCCAU0CBD4fHfowDQYJKoZIhvcNA \ QEEBQAwOTEZMBcGA1UEChMQSm9uYXRoYW4gS \ 251ZHNlbjEcMBoGA1UEBhMTJaFw0wMzA0MTA \ xOTI0NDJaMDkxGTAXBgNVBAoTEEpvbmF0aGF \ uIEtudWRzZW4xHDAaBgNVBAYTE2pvbmF0aGF \ ua251ZHNlbi5jb20wgZ8wDQYJKoZIhvcNAQE \ BBQADgY0AMIGJAoGBAMH3zU4YJpXXQsrP2CL \ jANVeOVjtpS/T8zJxJsbIdFPgh8c/69XjXuL \ UFG7lrySUxbPQRzSVgQfSetiYNB6/BgLMkTw \ XBSD+HCy5U9mBNPtIfXrdYwTPPefH8tGvY2U \ /4nEUmkGwS/b/ArK4ijVrzKOIkooVz2S/1Se \ f0zH73+MRAgMBAAEwDQYJKoZIhvcNAQEEBQA \ DgYEAonv+cjDw7JkI/wVwBlT/jM7Ricj3FGw \ ndy8MhRyj20VNhW+ilAN+ZUirrFALSWFXmO7 \ AKYfCRS1YLiZjJvEPHb1o+doDWvP1v3s0OKG \ 2Cx3trT1LVAh8lIPBO9F0IG4TgUPpHScP6y/ \ wglIR+gcJnQKWfPv2M4VGZpFShCSKzOs= MIDlet-Jar-RSA-SHA1: lWHoiy1Ur0AgM0ZrI/Y46a0hMYUO81Kf6yiI \ lsXi3g4Ubv2gqC4p7VWyF0c6EWYtqpSYgLOV \ /UdSNuADEIcg0QBkTcc0GOf1+ZxQiJRNh/oG \ 4LfCpPJ+y3zUfkPwSJw7+7P4McRiXSpqrBLo \ USUTa9ZTwV5oB7AUpCcm2U+yxg4=

The toolkit records both the signature and the certificate using base64 encoding, which is a fairly efficient way of representing binary data using characters.

A Killer Feature: Run via OTA

MIDP's scope is steadily widening. Verion 2.0's new features, including its security architecture and push registry, make installation testing of a MIDlet suite just as important as runtime testing. The new emulator is up to the job. It provides a second way to run your applications.

When you only need to test basic runtime behavior, as in earlier versions you just click on the Run button or select Project -> Run from the menu. The emulator loads classes directly from the CLASSPATH. The MIDlet is not packaged and you can't test some application features, like the push registry and MIDlet signing. You can set the runtime protection domain using the Security tab in the preferences window.

How do you test installation behavior, the push registry, and signed MIDlets? The answer is a spiffy new option in the Project menu, Run via OTA. This option runs the emulator's Application Management Software (AMS) and allows you to manage the installed MIDlet suites on the device. The AMS uses the most recently packaged version of your application and allows you to walk through the process of installing the MIDlet suite on the emulator. In that process, the emulator verifies signed MIDlet suites as appropriate and places the installed suites into protection domains based on their signing credentials. Once a MIDlet suite is installed, the emulator can catch incoming network connections and activate MIDlets that have registered those connections in the push registry.

When you choose Project -> Run via OTA, the emulator window pops up with a splash screen. Dismiss the splash screen and you're staring at a list of installed MIDlet suites:

List of Installed Suites

Choose Install Application, and you'll see a URL for localhost. This is the toolkit, running a small implementation of an OTA server. Just accept the URL and work through the rest of the prompts to install the application.

Run via OTA is extremely convenient because it allows you to test advanced features, like installation, signing, and the push registry, without setting up an OTA server yourself.

Summary

The J2ME Wireless Toolkit 2.0 is a comprehensive package for creating and testing MIDP applications. Aside from the basics of building and packaging MIDlet suites, the toolkit provides many advanced tools. It optionally supports WMA and MMAPI. It includes tools for setting MIDlet permission attributes, cryptographically signing MIDlet suites, and working with protection domains. Beginning developers will enjoy the J2ME Wireless Toolkit's ease of use and uncluttered interface, while advanced developers will appreciate the powerful and convenient tools available for building and testing MIDP applications.