New Features in the J2ME Wireless Toolkit 1.0.4

The J2ME Wireless Toolkit version 1.0.4 offers several compelling new features to help you create MIDlets that are compact, efficient, and easy to use:

• Support for obfuscation in the build cycle
• Method profiling
• Memory monitoring
• Network monitoring
• Device speed emulation

If you aren't already familiar with the J2ME Wireless Toolkit, the Wireless Development Tutorial Part I will get you started. The user's guide that comes with the toolkit is another excellent resource (the file is docs/UserGuide.pdf under the installation directory).

Adding Obfuscation to the Build Cycle

MIDP developers frequently rely on the services of an obfuscator to reduce the sizes of packaged MIDlet suites. Version 1.0.4 of the toolkit supports inserting an obfuscation step into the MIDlet build cycle. Support for Retrologic's Retroguard is already included, but you can add any obfuscator you want. The toolkit's Basic Customization Guide, located at docs/BasicCustomizationGuide.pdf, describes how to marry any obfuscator to version 1.0.4.

Using Retroguard is suprisingly easy. The new toolkit includes the necessary glue; all you need to do is download retroguard.jar and install it in the bin directory of the J2ME Wireless Toolkit 1.0.4 installation directory. In KToolbar, select Project > Package > Create Obfuscated Package to use the obfuscator in the build cycle.

MIDlet Profiling

The J2ME Wireless Toolkit 1.0.4 includes a profiler, a tool that collects statistics on your application as it runs. After the run ends, you can see which methods in your application were called, how many times they were called, and how much time these calls took.

First open an existing project. You can choose one of the examples that comes with the toolkit or use one of your own. To turn on the profiler, in KToolbar's menu choose Edit > Preferences. Then click on the Monitoring tab and check Enable Profiling. Click on OK.

Now run the project. It will run in the emulator just as it usually does. When you close the emulator, however, a new window will pop up. This window shows all the profiling information that was collected while your application was running:

Method profiler (Click for the full image.)

The method profiler window has two panes. To the left is the call graph, a hierarchical list of every method that was called while your application was running. Contained methods are those called from a certain method. For example, the screen shot reports that PeekAndPick's startApp() method contains PeekAndPick's initialize() method, indicating that startApp() called initialize().

One special pseudo-method, <root>, contains every method that was called.

You may not recognize many of the methods listed in the call graph, because they are methods of the MIDP reference implementation classes. If you dig deep enough, though, you will find your own code. For example, one of the top-level methods is the event-handling loop; look inside and eventually you'll find your application's event handlers, like commandAction() or paint(). The Find button makes it easy to locate a specific method or package name, expanding the tree as necessary.

The right pane of the window shows statistics for the selected item in the call graph. Click on a method in the call graph and the right pane of the window will show every method that was called from the selected method. You can see how many times each method was called, how much time was spent in each method, how much time was spent in that method and all its contained (child) methods, and the percentages of the total application time. What's more, you can sort on any of these columns by clicking on the column header.

Monitoring Memory

Memory is a critical resource in MIDlets. The toolkit provides a monitor that allows you to scrutinize the memory use of your MIDlet as it runs. To turn on the memory monitor, in KToolbar's menu choose Edit > Preferences. Then click on the Monitoring tab and check Enable Memory Monitor. Click on OK.

Now run the project again. The memory monitor pops up behind the device emulator. It shows a graph of memory use over time. At the bottom of the window is the current count of objects, the number of bytes of memory in use, the number of free bytes, and the total memory.

Memory monitor graph (Click for the full image.)

Your application will run much slower than usual because every object allocation and garbage collection will be monitored.

Click on the Objects tab to see a listing of all the objects your application is using. Each object's type is listed along with the number of live instances, the total number of instances that have been created, the total size in bytes used by the live instances, and the average size used by instances of this type.

The right side of the window shows where instances of this type are created. If you see that a certain type of object is taking up a lot of memory, the right side of the window makes it easy to find out where those objects are being created. The following screen shot shows the memory monitor's view of objects. In this application, 36 MutableImages have been created. On the right side you can see that these images are created in the initializeImages() method of a class named NekoCanvas.

Memory monitor objects (Click for the full image.)

Monitoring Network Use

Convincing a MIDlet to talk to a server isn't always easy. The J2ME Wireless Toolkit 1.0.4 offers a network monitor that can simplify your development considerably. Turn on the network monitor by selecting Edit > Preferences in KToolbar's menu. Then click on the Monitoring tab and check Enable HTTP Monitoring (and Enable HTTPS Monitoring if you wish to monitor secure connections). Click on OK.

Now run your application. Every time a MIDlet makes a network connection, it shows up in the network monitor window.

Netwok monitor (Click for a full size image.)

HTTP requests and responses appear in the left side of the window as little arrows. The direction of the arrow indicates whether the message is passed from client to server or from server to client. Clicking on an arrow brings up a list of headers in the right side of the window. The screen shot shows the header fields for the second HTTP response.

The HTTP request and response bodies are also represented in the left side of the window, contained by the request and response entries. In the screen shot you can see the body for the first HTTP response. Click on the label Body to see the actual data the body contains.

The screen shot shows two HTTP exchanges. The first was successful; the MIDlet requested /slashdot.rdf from the server and received a 200 OK reply. In the second exchange, the server replied 302 Found, indicating that the requested resource is available at a different URL. This detailed reporting is one of the ways the network monitor is very useful; by examining the exact requests and responses you can see whether your MIDlet and the server are behaving as you expect.

Remember, It's Still Just an Emulator

As you enjoy the new features of the J2ME Wireless Toolkit 1.0.4, remember that the profiling and monitoring apply only to the toolkit's emulator. Don't expect the behavior of your application on real devices to duplicate what you've seen in the emulators. The whole idea of method profiling and memory and network monitoring is to give you a solid understanding of how your application performs on one MIDP implementation. It may perform differently in other environments.

Imagine a singer rehearsing for a concert. She practices her performance for her teacher, who suggests improvements. When at last the teacher is satisfied, the singer performs for an audience. The same idea applies to MIDlet development; once you get your MIDlet running smoothly on the toolkit emulators, you're ready to try it on real devices.

Slowing Things Down

One of the tricky parts about writing MIDlets is that the machine on which you run the device emulator is usually much faster and better connected than an actual MIDP device. You may not, therefore, notice processing or network bottlenecks until you test your MIDlet on real devices.

The J2ME Wireless Toolkit 1.0.4 can slow down its emulation speed and simulate a slower network connection, making it easier to find performance problems early in your development cycle.

To slow down the emulator, select Edit > Preferences from KToolbar's menu. Click on the Performance tab. To slow down the execution speed of the emulator, check Enable VM speed emulation and adjust the slider. You can set the emulated network speed with the combo box labeled Enable network throughput emulation at the bottom of the window.

The toolkit includes other features for changing the characteristics of the display. You can specify the type of display, its refresh rate, and a latency for graphics primitives. For more information, consult the user's guide.

Bear in mind that the settings you make here are specific to the toolkit's emulator. Your results will vary on real devices. Still, emulating a slow processor and a slow network will help identify problems in your application before you begin testing on real devices.

Summary

The Wireless Toolkit 1.0.4 offers enhancements to help you create MIDlets that are lean and nimble. The method profiler helps you locate code bottlenecks. The memory monitor shows exactly how memory is used by your application, and the network monitor tracks network data exchanges as they occur. Finally, emulating a slow processor and slow network speed helps you identify usability problems with your MIDlet before you test it on real devices.

This article presents a quick overview of the new features in the J2ME Wireless Toolkit 1.0.4. For a full description, read the user's guide that comes with the Wireless Toolkit ( docs/UserGuide.pdf under the toolkit's installation directory).

About the Author: Jonathan Knudsen [home page] is the author of several books, including Wireless Java (second edition) , The Unofficial Guide to LEGO MINDSTORMS Robots , Learning Java (second edition) , and Java 2D Graphics . Jonathan has written extensively about Java and Lego robots, including articles for JavaWorld, EXE, NZZ Folio, and the O'Reilly Network. Jonathan holds a degree in mechanical engineering from Princeton University.