Contents Previous Next Index

Chapter   2

Developing MIDlet Suites


This chapter describes how you can use the J2ME Wireless Toolkit to create applications. It begins with a description of toolkit projects, then works through the development process.

There are two basic development cycles you are likely to follow in creating MIDlet suite applications. The first is quicker and simpler; you will probably use it in your initial development. The second cycle is longer but allows for more comprehensive and realistic testing.

Toward the end of the chapter you’ll read about how to use the J2ME Wireless Toolkit with advanced development tools like an obfuscator and a debugger. A final section briefly describes how to configure a web server to serve MIDP applications.

2.1 About Projects

In the J2ME Wireless Toolkit, MIDlet suites are organized into projects, where the end result of one project is one MIDlet suite. A project contains all of the files that will be used to build a MIDlet suite, including Java source files, resource files, and the MIDlet descriptor.

The J2ME Wireless Toolkit works on one project at a time. You can create a new project or open an existing project.

In this chapter you will work with a very simple example project. As you read about each step in the development cycles, you can work along in the toolkit.

To create a new project, first start KToolbar. On Windows, choose Start > Programs > J2ME Wireless Toolkit 2.2 > KToolbar.1 You’ll see the KToolbar window.

FIGURE 2  –  The KToolbar window

The KToolbar window

Click on New Project... The toolkit will ask you for the name of the project and the name of the MIDlet class you will write. Fill in the names and click Create Project.

FIGURE 3  –  Creating a new project

Creating a new project

The project options automatically pop up, allowing you to set up the build environment for the project. The default options are fine for this example; just click on OK to dismiss the window. In the KToolbar console, you’ll see some messages telling you exactly where to store the source code and resource files for this project.

FIGURE 4  –  File locations in the console

File locations in the console

2.2 The Simple Development Cycle

The simple development cycle looks like this:

Edit source code > Build > Run

  1. Edit source code. In this step, you create Java source files and resource files that will be used by your application.
  2. Build. The J2ME Wireless Toolkit compiles and preverifies your Java source files.
  3. Run. The compiled Java class files are run on the emulator.

If an error occurs when the toolkit attempts to compile your source files, go back and edit them again. If you find a bug when you are testing your application in the emulator, edit the source files to fix the bug.

Now that you understand the simple development cycle at a high level, the rest of this section illustrates how you can accomplish each step using the J2ME Wireless Toolkit.

2.2.1 Edit Source Code

Editing source code is the only step in which the J2ME Wireless Toolkit is no help at all. You will need to use the text editor of your choice to create and edit source code files.

If you are following along with the example project, create a new Java source file TinyMIDlet.java. It should be saved in the source directory of your project, which will be {toolkit}\apps\Tiny\src\TinyMIDlet.java where {toolkit} is the installation directory of the toolkit. The contents of the file are a very simple MIDlet:

import javax.microedition.lcdui.*; 
import javax.microedition.midlet.MIDlet; 
 
public class TinyMIDlet 
    extends MIDlet 
    implements CommandListener { 
  public void startApp() { 
    Display display = Display.getDisplay(this); 
     
    Form mainForm = new Form("TinyMIDlet"); 
    mainForm.append("Welcome to the world of MIDlets!"); 
     
    Command exitCommand = new Command("Exit", Command.EXIT, 0); 
    mainForm.addCommand(exitCommand); 
    mainForm.setCommandListener(this); 
     
    display.setCurrent(mainForm); 
  } 
   
  public void pauseApp () {} 
   
  public void destroyApp(boolean unconditional) {} 
   
  public void commandAction(Command c, Displayable s) { 
    if (c.getCommandType() == Command.EXIT) 
      notifyDestroyed(); 
  } 
} 

Save the file when you’re finished.

2.2.2 Build

The next step is to build your source code. The toolkit makes this part very easy.

In the KToolbar window, click on the Build button. Assuming you saved your source file in the right place, the toolkit will find it and compile it. Compilation errors are displayed in the KToolbar console. If you have errors, go back and edit the source code to fix them. Once you’ve eliminated your errors, the KToolbar console tells you the project was successfully built.

FIGURE 5  –  Messages about building

Messages about building

Behind the scenes, the J2ME Wireless Toolkit also preverifies the compiled class files. MIDlet class files must be preverified before they can be run on a MIDP device or emulator. The toolkit quietly handles this detail for you; you probably won’t ever realize it’s happening. See the CLDC specification for more information on preverification.

2.2.3 Run

Once the project builds successfully, you are ready to try it out in the emulator. Click on the Run button. The emulator pops up and shows a list of all the MIDlets in your project.

FIGURE 6  –  List of project MIDlets

List of project MIDlets

Choose the MIDlet you want and select Launch. If you’re following along with the TinyMIDlet example, you’ll see the fruit of your labors:

FIGURE 7  –  TinyMIDlet in action

TinyMIDlet in action

2.3 The Full Development Cycle

The second development cycle is slightly more complicated:

Edit source code > Package > Install > Run

  1. Edit source code. This is the same as in the simple cycle.
  2. Package. In this step, the J2ME Wireless Toolkit compiles and preverifies the source files (essentially the same as the Build step from before). Then it bundles the Java class files and resource files into a MIDlet suite JAR file and a MIDlet suite descriptor.
  3. Install. MIDlet suites need to be installed before they can be run. You can install the MIDlet suite into the J2ME Wireless Toolkit emulator or a real device.
  4. Run. As in the simple development cycle, run your application and test for bugs.

In the full development cycle, the first step is identical to the simple development cycle. Editing source code is the same as always. The Build step is now incorporated in packaging.

The full development cycle includes two new steps, packaging and installing. Finally, running an installed application is different in important ways from running an application in the simple development cycle.

2.3.1 Package

The J2ME Wireless Toolkit automates the task of packaging a MIDlet suite. The end result of packaging is two files, a MIDlet descriptor and a MIDlet suite JAR. The descriptor is a small text file that contains information about the MIDlet suite. The JAR contains the class files and resources that make up the MIDlet suite. Devices can use the descriptor to learn about the application before downloading the entire JAR, an important consideration in a memory-lean, bandwidth-starved wireless world.

To ask the toolkit to package your MIDlet suite, choose Project > Package > Create Package from the KToolbar menu. The MIDlet suite descriptor and JAR are generated and placed in the bin directory of your project.

Packaging might involve additional steps. You can use a code obfuscator to shrink the size of the MIDlet suite JAR, a technique that is described later in this chapter. In addition, the J2ME Wireless Toolkit provides tools to allow you to cryptographically sign MIDlet suites. See Chapter 6, “Security and MIDlet Signing,” for more information.

2.3.2 Install

To properly test a MIDlet suite, you should install it into the toolkit’s emulator or a real device. When you press the Run button in KToolbar, the MIDlet suite is not installed into the emulator. Instead, the emulator runs the MIDlet classes directly.

The emulator also has the capability of installing applications into its memory in a process that resembles how applications are transmitted and installed on real devices. To install applications in the J2ME Wireless Toolkit emulator, choose Project > Run via OTA.

The emulator window pops open, but instead of running your MIDlet classes directly, this time the emulator shows the welcome screen of its Application Management Software (AMS). The emulator’s AMS is an example of the type of software that real devices must have to manage MIDlet suites.

FIGURE 8  –  Emulator AMS welcome screen

Emulator AMS welcome screen

Choose Apps to go to the main list of installed applications. Select Install Application and press the select button on the emulator. The emulator prompts you for the URL location of the application you want to install. The URL is already filled in for you.

FIGURE 9  –  URL prompt

URL prompt

Choose Go from the menu to begin the installation. The emulator shows a list of the applications it finds at the URL. Choose the only one and select Install from the menu. The emulator gives you one last chance to confirm your intentions.

FIGURE 10  –  Confirming the installation

Confirming the installation

Choose Install again to finish the installation. You’ll be returned to the emulator’s installed list of applications, which now includes the application you just installed.

FIGURE 11  –  The application menu, again

The application menu, again

Run via OTA is an extremely useful mechanism that makes it easy to install your MIDlet suite on the toolkit emulator. Some features must be tested using this technique, including the push registry and the installation of signed MIDlet suites.

If you want to test your MIDlet suite on a real device, you’ll need to install it first. How this happens depends heavily on the device you are using. There are two likely possibilities:

  • You can deploy the application on a web server, then transmit the application from server to device using the Over the Air (OTA) protocol described in the MIDP 2.0 specification. This is most likely the same mechanism that users will encounter when they go to purchase or install your application.
  • You might be able to transfer the MIDlet suite to the device using a Bluetooth, infrared, or serial connection. This is quite a bit simpler than running a web server, and although it won’t give you any insights into the process of installing your application on the device via OTA, it allows you to see how your application performs on the device.
  • 2.3.3 Run

    Once the application is installed, running it is simple. Just choose the application from the list and choose Launch from the menu.

    FIGURE 12  –  Launching the installed application

    Launching the installed application

    Running an application on a real device depends heavily on the device itself. Consult your device documentation for information.

    2.4 Using an Obfuscator

    An obfuscator is a tool that reduces the size of class files. MIDlet suites need to be compact, both to minimize download times and to comply with sometimes stringent limits on JAR size imposed by manufacturers or carriers. Using an obfuscator is one way (not the only way) that you can keep your MIDlet suite JAR small.

    You can use an obfuscator in the packaging step of the development cycle. Although the J2ME Wireless Toolkit doesn’t come with an obfuscator, it is already configured to use the ProGuard obfuscator. All you need to do is download ProGuard and put it in a place where the toolkit can find it.

    ProGuard is published under the terms of the GNU General Public License (GPL). If you are comfortable with the terms of the license, you can download and use ProGuard free of charge.

    Installing ProGuard in the J2ME Wireless Toolkit is straightforward:

    1. Go to the ProGuard web site, http://proguard.sourceforge.net/.
    2. Download the latest version.
    3. Uncompress the proguard.jar file from the lib directory of the ProGuard installation to the bin directory of your J2ME Wireless Toolkit installation.

    Once ProGuard is installed, you can use it by choosing Project > Package > Create Obfuscated Package.

    In some cases you will need to provide a script file that controls how the obfuscator works. If you are loading classes using Class.forName(), for example, you need to tell ProGuard to leave the class names unchanged.

    Create a script file using a text editor, then save it under the project’s main directory. Consult the ProGuard documentation for information on script files. Next you need to tell the toolkit how to find this file. To do this, edit {toolkit}\wtklib\{platform}\ktools.properties, where {platform} is the name of your underlying platform (most likely Windows or Linux). Add a line as follows:

    obfuscate.script.name: scriptfile  
    

    Replace “scriptfile” with the name you used for the script file. You will need to quit and restart KToolbar for the change to take effect.

    The J2ME Wireless Toolkit also includes support for RetroGuard. If you want to use RetroGuard, you’ll need to download it separately and change the toolkit’s configuration.

    1. Go to the RetroGuard web site, http://www.retrologic.com/retroguard-main.html.
    2. Download the latest version.
    3. Extract the retroguard.jar file from downloaded zip file to the bin directory of your J2ME Wireless Toolkit installation.
    4. Edit {toolkit}\wtklib\{platform}\ktools.properties so that it uses the RetroGuard obfuscator plug-in:
    obfuscator.runner.class.name: com.sun.kvem.ktools.RunRetro 
    obfuscator.runner.classpath: wtklib\\ktools.zip 
    

    Retroguard will be used when you create an obfuscated package.

    To switch back to ProGuard, edit the obfuscator lines in the ktools.properties file as follows:

    obfuscator.runner.class.name: com.sun.kvem.ktools.RunPro 
    obfuscator.runner.classpath: wtklib\\ktools.zip 
    

    If you want to use a different obfuscator, you’ll have to implement an obfusctor plug-in yourself. See the J2ME Wireless Toolkit Basic Customization Guide for an example of how to implement an obfuscator plug-in.

    2.5 Using a Debugger

    A variation on running your application is running it with a debugger. A debugger allows you to monitor the running application more closely, set breakpoints, and examine variables.

    You will need to supply your own debugger. You can use the jdb debugger from J2SE™ or another debugger of your choice.

    Begin by choosing Project > Debug from the KToolbar menu. Enter the TCP/IP port number that the debugger will use to connect to the emulator. Click on Debug. The emulator begins running and waits for a connection from a debugger.

    Start up your debugger and attach it to the port you specified. Make sure to set the remote debugger to run in remote mode and to use TCP/IP. For more information, consult the debugger’s documentation.

    Information about using jdb with the J2ME Wireless Toolkit is here:

    Debugging MIDlets

    http://developers.sun.com/techtopics/mobility/midp/questions/jdb/

    2.6 Deploying Applications on a Web Server

    The MIDP 2.0 specification includes the Over The Air User Initiated Provisioning Specification, which describes how MIDlet suites can be transferred over-the-air (OTA) to a device. You can test this type of scenario using the J2ME Wireless Toolkit emulator.

    To deploy a packaged MIDP application remotely on a Web server:

    1. Change the JAD file’s MIDlet-Jar-URL property to the URL of the JAR file. The URL should be an absolute path. For example:
    2. MIDlet-Jar-URL: http://your.server.com/midlets/example.jar 
      
    3. Ensure that the Web server uses the correct MIME types for JAD and JAR files:
    1. For MIDlet suite descriptors, map the .jad extension to the text/vnd.sun.j2me.app-descriptor MIME type.
    2. For MIDlet suite JARs, map the .jar extension to the application/java-archive MIME type.

    The details of how to configure a Web server depend on the specific software used.

    The emulator implements the device behavior during OTA provisioning. You can use the emulator to test and demonstrate the full provisioning process of MIDlet suites from a server to the device. All you need to do is launch the emulator’s AMS. (You may already be familiar with the AMS if you have used KToolbar’s Run via OTA option.

    To launch the emulator’s AMS, you have two options:

    {toolkit}\bin\emulator -Xjam

    Now follow the AMS prompts to install your application. This process is very similar to the Run via OTA option described earlier in this chapter, except you will need to enter the URL of your own server to install your application.

    1Depending on how Windows is configured, you might need to choose Start > All Programs instead of Start > Programs.

     


    Contents Previous Next Index J2ME Wireless Toolkit User's Guide
    J2ME Wireless Toolkit 2.2