2. Tools

BUILDING MIDP applications is surprisingly easy. This chapter describes several development alternatives and explains some of the magic that these tools provide.

2.1. Sun Java Wireless Toolkit for CLDC: A Toaster Oven

The Sun Java Wireless Toolkit for CLDC, which used to be the J2ME Wireless Toolkit, is simple and powerful. If you already understand the Java programming language and are comfortable with a text editor, the toolkit is a great place to learn about MIDP.

The Sun Java Wireless Toolkit for CLDC includes three main components:

• KToolbar allows you to manage and build projects.

• The emulator is a simulated mobile phone. It enables you to test applications without having to use a real device.

• A collection of utilities and tools provides support for many MIDlet features and optional packages.

The Sun Java Wireless Toolkit for CLDC is similar to a toaster oven because it has a simple interface and a surprising amount of ability.

The toolkit keeps pace with the rapidly evolving Java ME landscape. The toolkit and its emulator support the Mobile Service Architecture (MSA) specification, providing a highly capable development environment well ahead of actual devices.

But how, you might be wondering, can the emulator send SMS messages? How can it support the Location API? What about Bluetooth? One of the wonders of the toolkit emulator is that it simulates any environment it cannot directly support. Network connections, of course, can be supported using network connections of the underlying desktop computer. For Short Message Service (SMS) and Multimedia Message Service (MMS), the toolkit provides a simulation environment such that different instances of the emulator can exchange messages. A messaging console utility can also exchange messages with running emulators (see Figure 2.1). Other utilities include settings to determine the emulator’s simulated location (to support the Location API), a simulated Bluetooth environment, simulated smart card slots that connect with desktop smart card emulators, and more.

Figure 2.1. Sun Java Wireless Toolkit emulator

The Sun Java Wireless Toolkit also provides tools to monitor running applications. These include a memory monitor that shows every object and its size, a network monitor that displays all network traffic in or out of the emulator, and a method profiler that shows how much time your application spends in each of its methods.

For comprehensive information on the features and capabilities of the Sun Java Wireless Toolkit, read through the Users Guide in the documentation.

As of this writing, the current version is 2.5.1. The toolkit is freely available here:

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

Before installing the toolkit, you will need the Java 2 Platform, Standard Edition Development Kit (JDK), version 1.5.0 or later, and Apple’s QuickTime Player. Both are freely available.

2.2. NetBeans Mobility Pack: A Gourmet Kitchen

If you really like the muscle of an integrated development environment (IDE), the NetBeans Mobility Pack delivers a professional and powerful development experience.

NetBeans is an open-source IDE for the Java programming language. The Mobility Pack adds components to NetBeans that are necessary for MIDP development. It incorporates the Sun Java Wireless Toolkit emulator and utilities. Like a gourmet kitchen, NetBeans Mobility Pack allows you to create anything that the toolkit can create, but you get a much wider and more powerful selection of tools, like melon ballers and mini whisks.

You can download NetBeans Mobility Pack here:

http://www.netbeans.org/products/mobility/

One jazzy feature in NetBeans Mobility Pack is a visual editor with which you can create screens and screen flows for your application (see Figure 2.2). In addition, NetBeans offers the usual IDE features, such as a source code editor with lots of bells and whistles, refactoring tools, a debugger, access to version control systems, and much more.

Figure 2.2. Visually editing screen flow in NetBeans Mobility Pack

2.3. Eclipse, Too

If you’ve fallen in love with Eclipse, you can use EclipseME to create MIDlet suites. EclipseME handles some details of connecting device emulators to the Eclipse development environment. It’s available here:

http://eclipseme.org/

2.4. Inside a MIDlet Suite

Both the Sun Java Wireless Toolkit and NetBeans Mobility Pack handle the details of building and packaging MIDlet suites. If you use one of these tools, you won’t generally need to understand how things work under the hood. However, you should at least understand the basic structure of a MIDlet suite, and it’s a good idea to understand how the suite is built.

The MIDlet suite itself is a Java Archive (JAR) file. It contains the classes that make up the application as well as any supporting resource files, such as images and sounds (see Figure 2.3). The JAR file manifest contains attributes that fully describe the MIDlet suite. You can read the MIDP specification to find out the names and appropriate values for the attributes, but most of the time it’s easier to let your build tool worry about manifest attributes.

Figure 2.3. Example MIDlet suite JAR file structure

A separate file, the MIDlet descriptor (or JAD file), is a small text file that describes the contents of a MIDlet suite (see Figure 2.4). It contains many of the same attributes as the MIDlet suite descriptor. The purpose of the descriptor is to allow a device to download and examine the descriptor before making a decision to download the whole MIDlet suite. The descriptor shows the size of the MIDlet suite, its required APIs, and other information that is useful to a device and a user in deciding whether or not to download and install a MIDlet suite.

Figure 2.4. Example MIDlet suite descriptor

2.5. Building a MIDlet Suite

Your build tool can create a MIDlet suite JAR file in three steps:

1. Compile the Java programming language source files to produce class files. This is accomplished using the javac compiler. A special flag, -bootclasspath, tells the compiler that the classes will run in a MIDP/CLDC environment rather than a desktop Java platform.
2. Preverify the compiled Java classes. In the desktop Java platform, every class loaded into the virtual machine is verified to confirm it is correctly formed and won’t do anything bad, like writing in memory it doesn’t own. In a MIDP/CLDC environment, to save space, the bytecode verifier is less sophisticated. Preverifying prepares class files for the less sophisticated bytecode verifier.
3. Package preverified class files and resource files into a JAR file. Include the correct MIDlet suite attributes in the JAR file manifest.

2.6. The Command Line: A Campfire

Developers choose tools based on their experience and personalities. Some developers prefer the gritty power of the command line and a tool like Ant (http://ant.apache.org/). At a command line, you can accomplish the steps described in the previous section as follows:

1. If you have the Sun Java Wireless Toolkit installed in WTK25, then you can compile a source file called YaYaMIDlet.java as follows. (With a newer version of javac, you might need to specify -target 1.2 to produce the right version of bytecode.)

   

2. With the Sun Java Wireless Toolkit, you can preverify the class file from the last step like this:

   

3. Packaging is done using the jar tool, which is part of the desktop Java platform development kit. You can create a MIDlet suite JAR from the class in the previous example like this, assuming the MIDlet suite attributes are in a plain text file called extra.mf:

   

4. Custom Ant tasks for building MIDP applications are freely available, and in fact, NetBeans uses its own set of custom Ant tasks to build applications. Here are two other possibilities:

   http://antenna.sourceforge.net/

   http://www.j2mepolish.org/

2.7. Preprocessors

One of the challenges of writing MIDlet applications is the wide variety of MIDP devices upon which your application will run. Different screen sizes, capabilities, and implementation bugs mean that it’s difficult to make one set of source code that runs flawlessly on all devices.

A common answer to this challenge is to create a variety of application bundles targeted at a variety of devices or device types. You might, for example, build one bundle for Nokia Series 40 devices and another for certain types of Motorola devices.

In many cases, this is simply an issue for bundling your application. You might want to bundle art image files of different sizes depending on the target device screen size, for example. In addition, you can bundle different application properties to communicate device-specific values to your application.

In some cases, however, you might find yourself wanting to write code for specific devices. In this case, you need something like a C preprocessor, something that enables conditional compilation.

One example of this approach is J2ME Polish, created by Robert Virkus.

http://j2mepolish.org/

J2ME Polish provides a preprocessor, a database of device capabilities, and conditional resource bundling. It is based around the open-source build tool Ant.

Another possibility is Dennis Sosnoski’s JEnable:

http://www.sosnoski.com/opensrc/jenable/

2.8. Obfuscators

An obfuscator optimizes a set of class files. Originally, the purpose of an obfusctor was to make it harder to reconstruct source code from class files (decompiling), but obfuscators are also great at removing unused code and reducing the overall size of a MIDlet suite.

An obfuscator is crucial in applications that use third-party APIs. Without an obfuscator, the classes from the third-party API are bundled with your own application classes. Your MIDlet suite JAR file’s size is increased directly by the size of the third-party API.

When you apply an obfuscator to your MIDlet suite JAR file, the obfuscator analyzes the class files, finds out exactly which classes and methods you are using, and discards everything else. In addition, it renames classes, member variables, and methods from human-readable names to much smaller machine-generated names.

Obfuscators have some limitations. In particular, they might throw out classes that are only accessed using Class.forName(). However, this usage is unusual in MIDP applications. Also, an obfuscator doesn’t play nicely with a debugger. Leave the obfuscator out of the build while you are developing and debugging. Use the obfuscator when you are packaging a finished application.

ProGuard is an excellent obfuscator and is also free:

http://proguard.sourceforge.net/

2.9. Emulators

An emulator is a simulated device that runs on a desktop computer. Emulators are extremely helpful because they enable you to write source code, build, and run on one desktop computer.

Once you get your application running smoothly on an emulator, you should test it on a range of emulators. After that, you can start testing on real devices.

Emulators vary widely in their capabilities and accuracy. The Sun Java Wireless Toolkit emulator supports a zillion APIs, but it does not represent any real device. It’s excellent for most of your development work.

Device manufacturers offer emulators that mimic the screen sizes, controls, and behavior of real devices. Most emulators can be integrated with the Sun Wireless Java Toolkit and NetBeans Mobility Pack. Table 2.1 presents some starting points.

Table 2.1. Where to Download Emulators

2.10. Device Testing

Someday you will need to test your application on real devices, on real networks. This is a slow and humbling experience. Although you might have made your application run flawlessly on desktop emulators, real devices have the usual assortment of unexpected behavior.

Some devices also allow for on-device debugging, with debugging information carried over a serial cable connected to your development computer. If you expect to target a specific device or a small number of devices, and those devices support it, on-device debugging could be a useful tool in developing your application.

2.11. Summary

MIDP development tools are readily available, and you can’t beat the price. These tools know how to assemble MIDlet suites, allowing you to concentrate on writing source code. If you really want to, you can create MIDlet suites using a command line and some kind of automation, usually Ant. Device emulators are available to help in testing your application on a desktop computer. While budgeting your project, don’t forget to include time and money for testing on real devices and real networks.