Sun’s New Wireless Toolkit Keeps Up with the Mobile Joneses

s the holiday season wraps up, many of you might have received new cell phones, PDAs, or other electronic gadgets. Many are probably equipped with J2ME. The ever-increasing capabilities in these small devices never cease to amaze. The boundaries that used to classify these consumer electronic devices also continue to fade. Are smartphones more PDA than phone or vice versa?

The J2ME development world endeavors to keep up with the increasing capabilities in the electronic consumer device. Sun’s latest tool help for J2ME developers is the new version of the J2ME Wireless Toolkit (WTK), which has been renamed to the Java Wireless Toolkit. The new name is in order “to standardize Sun’s Java ME products to be consistent with the rest of Sun’s products” according to E-ming Saung, Sun Microsystems’ Java ME Product Manager.

Along with a number of bug fixes and enhancements, version 2.3 of WTK also provides J2ME developers with a means to develop and test MIDlet applications using three new J2ME APIs. Namely, version 2.3 of the Java Wireless Toolkit supports the Location API for J2ME, Security, and Trust Services API for J2ME (SATSA), and the J2ME Content Handler API (CHAPI). Table 1 lists the appropriate JSRs that define these APIs.

Table 1. JSR Reference: Three new Java Specification Requests (JSR) are now supported in the Wireless Toolkit, version 2.3.

J2ME API

JSR #

URL

Location API for J2ME

JSR 179

http://jcp.org/en/jsr/detail?id=179

Security and Trust Services API for J2ME (SATSA)

JSR 177

http://java.sun.com/products/satsa/

J2ME Content Handler API (CHAPI)

JSR 211

http://java.sun.com/products/chapi

Currently available in beta form, Sun now boasts that more than 1.5 million copies of the WTK have been downloaded by J2ME developers. Again, according to Saung, a second beta is expected with support for even more APIs around JavaOne 2006 (May) with a new final release scheduled shortly thereafter. Why two betas for this release? The number of APIs being added to the WTK is a big factor in the release of the two betas this year. According to Saung, “the rationale behind two beta releases is that we wanted to include support for quite a few new JSRs in the toolkit (about 10 new JSRs from WTK 2.2) to make sure developers have access to all the latest Java ME APIs. The simplest way for us for us to do this is by releasing two betas with good quality, and have one final release with excellent quality. These betas are good enough for developers to use from day-to-day; we just like to guarantee an even higher level of quality in our final release.”

The current WTK 2.3 beta is only available for Windows platforms. Let’s explore what is in this 2.3 beta release.

Figure 1. Addition of HTTP Basic Access Authentication: WTK 2.3 has added the ability to provide username and password for use with HTTP Basic Access Authentication. Note the addition in the Network Configuration tab in the emulator preferences dialog window in 2.3 (left) vs. 2.2 (right).

Developer Enhancements
A number of small, yet helpful, features have been added to the IDE to assist developers in the creation and testing of MIDlet and MIDlet suites. First of all, Sun has added authentication to access the HTTP proxy server via the emulator. When testing MIDlets that make an HTTP connection, the emulator uses the desktop network connection and if your desktop makes connections through a proxy server, your emulator will need to use the same proxy server. Figure 1 shows the Network Configuration tab on both the Emulator Preferences windows in both the WTK 2.2 and 2.3 versions. Note the addition of an authentication username and password for when your proxy server uses the Basic Access Authentication scheme.

This version of WTK also comes with the ability to create a new project out of an existing J2ME application descriptor (JAD) and MIDlet Suite Java archive (JAR) file (see Figure 2). This is particularly useful when you want to take an existing MIDlet suite, copy it, and then modify its descriptor?say for example, to sign the JAR. You could do this manually with previous versions of the WTK, but it was a messy and tedious job.

Figure 2. Create a Project from JAD/JAR: After copying and renaming the JAD and JAR file, you can edit the new JAD file and then create a new WTK project using the new JAD and JAR. To create a new project from the copied JAD/JAR, select Create project from JAD/JAR from the File menu, and then select the new JAD file in the file browsing dialog window as shown above.

A complaint about previous versions of the WTK (and, frankly, other IDEs as well) was the fact that the IDE did not live up to J2ME API constraints. For example, both the Mobile 3D Graphics API and the Location API work on CLDC 1.1 and not CLDC 1.0. Both APIs cannot be used with CLDC 1.0 because of, for one, the need for floating point data types. In the WTK 2.2, a project can be configured to violate this specification constraint?much to the confusion of less experienced developers. For example, you canset up a project to use the Mobile 3D Graphics API and CLDC 1.0. The latest version of the WTK IDE prohibits the inclusion of APIs based on the version of CLDC selected as shown in Figure 3.

Figure 3. API Constraints: Note that certain APIs (Mobile 3D Graphics and Location APIs) cannot be included in the project when CLDC 1.0 (left image) is chosen over CLDC 1.1 (middle image). In the 2.2 version of the WTK 2.2, Mobile 3D Graphics is selected with CLDC 1.0 selected?a violation of the J2ME specifications.

These constraints are based on J2ME specifications and not device specifications. This means that certain configurations may not work when deployed to the device based on the specific implementation details. For example, Sun’s own reference implementation of the Web Services API indicates it “should be used in combination with the CLDC 1.0.4 RI and the MIDP 2.0 RI.” However, Sun’s reference implementation suggestion can be violated in the new WTK. Many of the APIs supported by WTK are optional. Because they are optional, not all devices and J2ME implementations will include/use them. Obviously, the WTK cannot constrain the development environment for these types of implementation situations.

Another small but useful addition to the emulator is that you can now use your desktop’s copy and paste utility to enter text into emulator text fields. This is a very helpful addition when repeatedly testing MIDlets.

The WTK release notes and Web site also indicate that additional improvements have been made to the MIDlet signing tools. I was unable to find the difference when compared to version 2.2, but may just have overlooked something obvious.

Figure 4. The External Event Generator: The EEG window allows developers to send simulated location and orientation information to their MIDlets running in the WTK emulators.

Location API Support
With many devices now containing Global Position System (GPS) receivers or other means?like the use of triangulation from a radio network to obtain the location of the device,the WTK now includes support for the Location API. The Location API gives MIDlet applications access to a device’s present geographic location and orientation, and access to databases of known landmarks stored on the device. The Location API is an optional J2ME package that can be used with many J2ME profiles. As indicated above, however, it must be used with CLDC 1.1.

What might be the neatest thing about WTK’s support for the Location API is the built-in test facility to simulate the device providing location and orientation information to the application. Using the External Event Generator window (see Figure 4), developers can either set the location/orientation of the device directly or run a script mimicking the device on the move.

Figure 5. Code Download Location: After downloading the example application, you can unzip the contents right into the WTK23/apps directory. As shown here, you should have a new WayPointCollector directory containing all the code and associated build files.

To help demonstrate WTK’s support of the Location API and the External Event Generator (EEG) window, I have created a small demonstration application that you can download and run. The zip file associated with this article should be extracted right into the apps directory of your WTK 2.3 directory. When extracting the code, a WayPointCollector folder will be created for you in your Wireless Toolkit directory. Your WTK23/apps directory should look something similar to what is found in Figure 5.

When I was in the military, before the era of GPS and Loran systems, the only way to obtain your location and elevation was via Army provided maps. Setting aside the human error factor, if the map you were using was poor, then the location and elevation information you were reporting was also usually less than exact. This is something you were never quite happy about when having to provide information to guys firing artillery.

The demonstration MIDlet suite provided in this article would certainly have been handy to have running on a cell phone back in my military days. It simply allows the operator to push a button and record the device’s (and presumably the user’s) location and elevation (called a waypoint) along with a note/comment entered by the user. There are two MIDlets in the suite. The first MIDlet, called WayPointCollector, allows users to enter a note or comment about the waypoint to be collected and then marks the location obtained through the device with that note or comment. To run and test this MIDlet, you will need to use the EEG.

Once you have successfully loaded the project, run the MIDlet suite. When the emulator is started, you will need the External Event Generator up to provide location and elevation data to the MIDlet as if it was coming from the device. On the emulator window, select External Events from the MIDlet menu option at the top of the emulator. This will cause the EEG window to appear (see Figure 6).

Figure 6. Starting the EEG: After starting the emulator (by running a project from WTK 2.3), you can start the External Event Generator window by selecting the MIDlet window and picking the External Events option. This should cause the EEG window to appear (as shown in Figure 4).

Now, launch the WayPointCollector MIDlet. Enter a comment or note in the Way Point Note/Comment field on the emulator window and also enter a latitude, longitude, and altitude on the EEG window. Back on the emulator running the WayPointCollector MIDlet, you can now push the Mark Point button (see Figure 7). This will cause the MIDlet to collect location and altitude information from the EEG (as if it was coming from a real device) and, in this case, store the location and altitude information in a LocationStore (LocationStore is a device database and is another feature of the Location API) for later retrieval.

The second MIDlet in the suite, called WayPointLister, allows you to see the waypoints that were collected and stored by the WayPointCollector MIDlet. Run this MIDlet to see the waypoints you saved, with the location and altitude information obtained from thee EEG, in the devices Location Store (see Figure 8).


Figure 7. Collecting Location Data: MIDlets that need simulated geo-information while in testing, get it from the External Event Generator. In the case of this sample MIDlet, WayPointCollector stores the lat/long and altitude obtained from the EEG with the note/comment field when the Mark Point button is pressed.
 
Figure 8. The WayPointLister MIDlet is provided for completeness of the demonstration. It allows you to pull back the waypoints stored on the device and see that the lat/long and altitude information obtained via the EEG has been successfully saved.

The EEG window can also be used to run a script that changes the simulated geo-information provided to the emulator over time. This is particularly useful when building MIDlets that have location listeners constantly looking for and reacting to changes in location. The EEG scripts are actually quite easy to write as they are written in XML and consist of a set of waypoints that are read and fed to the emulator, as you require. A small script example is provided below:

	  	   	   	    

WTK 2.3 comes with a nice demo application called CityGuide that demonstrates the use of a location script with the EEG.

Figure 9. The SATSA Preference Tab: A new tab in the emulator Preferences window allows developers to associate a socket port number to a simulated slot. The emulator then uses socket protocol to communicate with the application on that port. Default ports are 9025 and 9026 respectively for simulated slots 0 and 1.

Security and Trust Services API Support
Many wireless phones now contain smart cards?SIM cards in GSM phones, UICC cards in 3G phones, and RUIM cards in CDMA phones. The Security and Trust Services API (SATSA) was developed to allow J2ME applications use of smart card and WIM functions, secure storage and cryptographic operations. It, like the Location API, is an optional J2ME package.

Devices that actually have smart cards will have one or more smart card “slots” or compartments. The WTK 2.3 emulator, therefore, provides a new emulator Preference tab for specifying up to two simulated slots. Each slot is given a socket port number. The emulator then communicates with the smart card applications via socket protocol (see Figure 9).

Figure 10. Setting Up Monitoring: To set up network monitoring between the smart card application running in the Cref simulator and a MIDlet running on the WTK emulator, open the Emulator Preferences window, select the Monitor Tab and make sure to enable network monitoring as shown.

WTK 2.3 also ships with the Java Card Platform Simulator. It is the cref.exe application located in the WTK’s in directory. With the SATSA slots and port numbers defined, you can test MIDlets running in the WTK emulator that communicate with Java smart card applications running on the Java Card Platform Simulator via the socket protocol. Of course, since it is just socket communications, a proxy can be set up to allow your MIDlets to talk with real smart card hardware and applications. In general, however, you would start cref.exe with the Java Card application you want to test, then start the WTK emulator and launch the appropriate MIDlet. The WTK emulator will use socket communications to exchange information with the cref.exe emulator and smart card application.

When the Java Card emulator is started, it too must be told to use the same port for communications. When starting cref.exe, pick the slot port (as set up in the emulator) that you want to give to the smart card application and provide it as a parameter to the start up command. In the example command to start the smart card emulator below, the default port for slot 0 (namely 9025) is associated with the smart card application.

cref –p 9025 –i  myapplication.eeprom

The network monitor built into the WTK can be used to monitor data exchanged between the simulated smart card application and MIDlet running in the emulator. This can be quite helpful for debugging. To start a network monitor, open the WTK emulator Preferences window, select the Monitor tab and make sure the ‘Enable network monitoring’ is checked (see Figure 10).

Figure 11. The Network Monitor: Network traffic involved in the data exchanged between the smart card application running in the Java Card simulator and the MIDlet running in the WTK emulator will appear in the APDU tab of the Network Monitor.

Now, run the MIDlet suite and launch a MIDlet in the emulator and the monitor window should appear. The data exchanged between the smart card simulator and the MIDlet emulator can be found on the APDU (which stands for Application Protocol Data Units) tab of the Network Monitor (see Figure 11).

WTK 2.3 comes with a MIDlet suite that demonstrates the SATSA API and WTK’s support for SATSA. The demonstration suite is called Mohair (located in the apps directory of the WTK 2.3 download) and it has five MIDlets (each with associated smart card applications) for showing off the four packages of the Security and Trust Services API. Developing Java Card applications is beyond the scope of this article, but more information is available via the Java Card information link provided with this article.

Content Handler API Support
The last of the new APIs supported by WTK 2.3 is the Content Handler API (CHAPI). CHAPI is another optional package meant to work with Mobile Information Device and Personal Basis Profiles. Similar to the way Windows allows you to associate particular applications on the desktop to certain file types (for example double clicking on a file with an .html extension causes the browser to start and display the HTML file), the CHAPI API allows MIDlets on a device to be associated with a specific type of content. When the device encounters content of a specific type, it can call on one of the associated MIDlets to take action with the content.

For example, a certain MIDlet can be associated with MIME type image/png. When the device encounters content of image/png type, it can call on the MIDlet to help display or modify the content.

CHAPI provides the means to invoke a content handler (a MIDlet) and get a response, register a content handler (a MIDlet) on the device with content type, query registrations, and respond to an invocation. If you are wondering where you might use this functionality, the CHAPI specification provides eight use cases to illustrate how CHAPI might be used (see Table 2).

Table 2. CHAPI Use Cases: The CHAPI specification provides eight use cases or illustrations of how CHAPI might be useful to J2ME developers. See the JSR-211 Specification for more details on these use cases.

Use Case 1: Distributing new game levels

Use Case 2: Sending coupons to customers

Use Case 3: Receiving a snapshot

Use Case 4: Buying a Music-Clip

Use Case 5: Upgrading software with new features

Use Case 6: Invoking content stored on the device

Use Case 7: Invoking a specific application

Use Case 8: Getting an email address from a local or remote phone book

How does the new WTK support CHAPI? A new tab in the Project Settings dialog window (see Figure 12) allows you to associate or “register” MIDlets with content types and file suffixes.

The WTK 2.3 comes with a CHAPI demonstration application. It is called CHAPIDemo and it can be found in the apps directory of the WTK 2.3 download. This application provides an example of how to launch MIDlet viewers based on the request for a certain type of file. The CHAPIDemo has two viewers: an image viewer for image/png files and a text viewer for text/plain content. Based on the selection of particular URLs from the demonstration application, the viewers for a particular file are launched in order to open and view the content requested. Figure 13 shows how the two MIDlet viewers are registered in the Content Handler API.


Figure 12. The Content Handler Tab: The Project Settings dialog window has a new Content Handlers tab (shown on the left) that depicts which MIDlets have been associated to various content and file types. The Add button on this tab allows you to register a MIDlet with content or file types in the “Enter content handler details” window (on the right).
 
Figure 13. Registered Viewers for Text and PNG Files: The CHAPI Demo application that comes with WTK 2.3 provides an example of how to register and use MIDlets to view text or images in an appropriate viewer based on the content request.

NetBeans Integration
If you use the NetBeans IDE (see my earlier article, “Mobile Java Gets a Much-needed Boost from Sun’s New Mobility Toolkit,” for more on NetBeans), you might be familiar with the fact that NetBeans allows the selection/use of an emulator engine. While not officially integrated yet, the latest version of NetBeans allows you to use WTK 2.3 as the NetBeans emulator. To integrate NetBeans with WTK 2.3, open a J2ME project’s properties dialog in NetBeans, push the Manage Emulators button and use the Java Platform Manager to point NetBeans to the WTK 2.3 directory (see Figure 14). You can also add the emulator through Tools | Java Platform Manager.


Figure 14. NetBeans Integration: To select WTK 2.3 as the emulator for NetBeans J2ME projects, open a project’s Properties dialog box, as shown, and press the “Manage Emulators…” button.
 
Figure 15. NetBeans Integration: In the next dialog box, select the “Add Platforms…” button and point NetBeans to the WTK 2.3 directory.

The final release of Mobility Pack 5.0 (expected any day now) is anticipated to have improvements that will help you find and add a new SDK like WTK 2.3.

Wrap Up
As mentioned earlier in this article, Sun plans to release another beta version of the Java Wireless Toolkit 2.3 in early 2006 and then have a final release in the second quarter. Plans are to have WTK also support the new Mobile Service Architecture for CLDC (JSR 248), SIP API (JSR 180), Scalable 2D Vector Graphics API (JSR 226), Payment API (JSR 229), Advanced Multimedia Supplements (JSR 234), and the Mobile Internationalization API (JSR 238); a lot of new capability for a single release. As devices grow more capable, so too must our development and emulation testing environments grow. Hail to the WTK and other IDEs for trying to keep up.

Share the Post:
Share on facebook
Share on twitter
Share on linkedin

Overview

Recent Articles: