ere you a little surprised recently that Sun’s J2ME Wireless Toolkit picked up several awards as product of the year in the mobile development tools area? I was. Not that the Wireless Toolkit is a poor tool. But after several years of writing applications in our favorite text editors and then using the Wireless Toolkit to compile, test, debug, etc. our J2ME applications, many J2ME developers were hoping that our J2ME IDEs would catch up to those in the J2EE arena.

Admittedly, there have been improvements. Products and IDEs such as Borland’s Jbuilder/Mobile Studio, IBM’s WebSphere Studio Device Developer, and EclipseME, to name a few, continually provide J2ME developers with more application development power than they have had in years past. Even the Wireless Toolkit has been improved greatly over the years. But here we are in 2005, and most of us are using the same tools used in 2001?a text editor and the J2ME Wireless Toolkit.

What more could we want? Well, to name a few things, I want an IDE that provides:

• A visual, drag and drop, development tool that allows me to put together J2ME application user interfaces similar to the way I build Swing or Web applications.
• An interface to quickly see, change, and experiment with application configuration, defragmentation, obfuscation, localization, and security settings.
• The ability to develop, test, and integrate J2ME applications with server-side applications with which the J2ME applications communicate in a single IDE.
• A means to deploy/upload the applications from the IDE via many different protocols/deployment mechanisms.

For those with a want list like mine, there is good news, or at least hope, on the horizon. Sun’s recently released NetBeans IDE 4.1 and NetBeans Mobility Pack 4.1 is coming pretty close to realizing the dream of a having a full-fledged IDE that even J2EE developers would be proud of and might even use. This article examines the features found in the NetBeans 4.1 Mobility Pack and explores how they can help you produce better J2ME applications in reduced time.

Figure 1. NetBeans IDE 4.1: The NetBeans IDE 4.1 with Mobility Pack 4.1 offers a main window when it first comes up that helps you set up a new project or open an existing sample project to help guide development.

Installation
The NetBeans IDE version 4.1 and the NetBeans Mobility Pack 4.1 require separate downloads and installations. Both are available free, as open source tools from Sun. Install the NetBeans IDE first and then the Mobility Pack. NetBeans has been tested on Windows, Linux, Solaris (x86 and SPARC), and MacOS platforms, but is known to run on other platforms as well. However, J2ME MIDP development is limited to the following platforms:

• Microsoft Windows 2000 Professional SP3
• Microsoft Windows XP Professional SP2
• Red Hat Enterprise Linux 3.0, Fedora Core 1
• Sun Java Desktop System 3.0

You will also need J2SE SDK v. 1.4.2_06 or later or J2SE 5.0_03 or later.

Installation of both products (the IDE and Mobility Pack) is straightforward for most platforms. For the Windows platform, a self-extracting installer is provided. Binary installers are provided for Linux and Solaris. If you have a need to develop server-side applications, you may also want to check out the NetBeans IDE and Sun Java System Application Server Bundle Installation. This will give you NetBeans IDE 4.1 and the App Server Edition 8 all in one shot.

NetBeans 4.1 does not require older versions of NetBeans to be removed. By default, on Windows platforms, the NetBeans IDE 4.1 automatically creates a new user directory when launched (/.netbeans/4.1) which allows past and the new versions to co-exist without issue. You can optionally import projects from Sun Java Studio Mobility as well as from the J2ME Wireless Toolkit (see this article for more information).

Already in Mobility Pack 4.0
Prior to 4.1, the Mobility Pack 4.0 (and NetBeans 4.0 IDE) already offered considerable functionality, which if you have not had a chance to explore yet, you might find the feature set surprising. The initial 4.0 release of the Mobility Pack already offered:

• Integration with Wireless Toolkit 2.2
• API Permissions
• MIDlet Signing
• Certificate Management
• Over-the-air (OTA) emulation
• Push Registry
• Obfuscation
• Support for adding 3rd party emulators
• MIDP localization
• Device defragmentation

The list was extensive and the additions in the 4.1 release provide strong indication that Sun is making a serious run at providing J2ME developers, especially those with limited budgets or committed to open source tools, with the next generation of IDE that goes well beyond that of the Wireless Toolkit. I encourage you to look at the guides and tutorials referenced in this article for more information about these features. Also, you will find the NetBeans IDE Help extremely useful and detailed in helping describe and instruct on the features of NetBeans and Mobility Pack development.

Figure 2. Visual Designer Tabs: The Mobility Pack 4.1 MIDlet Visual Designer allows you to switch between the Screen and Flow Designers for visual GUI and MIDlet work flow development and the actual source code.

Features of NetBeans Mobility Pack 4.1
For a dot release, Mobility Pack 4.1 contains a significant number of new features. Interestingly, the feature that has?and will continue?to grab most of the community’s attention (the Visual Mobile Designer) will probably still leave many developers wanting. In fact, I would submit that the major features of this release are all good first steps, but will need to be enhanced to give us the IDE we long for.

Visual Mobile Designer
The most anticipated enhancement with NetBeans Mobility Pack 4.1 is the Visual Designer. With Mobility Pack 4.1, Sun has taken an initial stab at providing a drag-and-drop user interface development tool for visually/graphically developing javax.microedition.lcdui Alerts, Forms, Lists, and Text Boxes and designing a MIDlet’s work flow. The tool, called MIDP Visual Designer (MVD), has three tabs (see Figure 2) that allow you to switch between MIDlet source code, the Screen Designer for GUI development, and the Flow Designer for modeling how a MIDlet creates views and what command actions force them to display.

The Screen Designer allows you to drag and drop commands and items from a palette on to the various javax.microedition.lcdui.Screen elements that are associated with a MIDlet. Like visual editors associated with Web or Swing application development, you can then edit properties associated with the screen as well as the components (see Figure 3).

Figure 3. Screen Design: The Screen Designer allows you to pick commands and GUI items from the palette (left of the screen) to the screen designer and then set the properties to anything on the screen with the properties editor on the right side of the IDE.

The Screen Designer is a step in the right direction, but many of you will soon see that this first release tool has many shortcomings. First of all, the tool is only valid for new development projects and does not offer reverse engineering. If you inspect the generated MIDlet source code created using the Screen Designer, there is a read-only section in it (as shown in the example code snip below) which old MIDlets obviously will not have. As the generated code comment suggests, modifying this code section will invalidate your ability to use the visual editors:

// --- This section is auto-generated by NetBeans IDE. Do not modify or you may lose your changes.//    /**     * This method initializes UI of the application.     */    private void initialize() {// For adding user code into this block, select "Design" item in the inspector and invoke property editor on Action property in Properties window.        javax.microedition.lcdui.Display.getDisplay(this).setCurrent(get_entryForm());    }

In fact, when you go to create a new MIDlet, you are asked whether you wish to create a “Visual” MIDlet or to create a MIDlet without use of the MVD (see Figure 4). Only “Visual” MIDlets can be worked on in the MVD.

Figure 4. Visual vs. Non-Visual MIDlet Creation: When creating a new MIDlet, you will have to specifically request to use the new MIDlet Visual Designer or not. The MVD can only be used with new NetBeans 4.1 projects.

The second shortcoming of the MVD is that all the visual components are embedded within the MIDlet class. Therefore, the MVD does not easily support the creation of independent (and reusable) forms, lists, alerts, etc. that can be shared by many MIDlets. Finally, the MVD does not support the visual development of Canvas-based user interfaces. Based on recent on-line chat sessions with the NetBean developers, the development team hopes to rectify some of these shortcomings in future releases of the Mobility Pack (the Transcript of the June 2 Chat on NetBeans Mobility Pack was still to be posted at the time of this writing?check this page under “Chats” for updates).

The Flow Designer offers a feature I have not seen in any J2ME IDE to date. The Flow Designer allows you to define the screens and actions that take users from one screen to the other in a visual manner (see Figure 5). For those developers working on applications with a complex user interface that allows users to move back and forth among screens with many commands, this tool can help you keep track of the user options and system reactions in your MIDlet. Again, the visual tool, in its current implementation, may limit the manner in which you implement your system (connecting almost everything through the MIDlet code), but it can help make sure you implement all the menu options that your users see.

Figure 5. Flow Designer: The Flow Designer allows you to see the relationship between MIDlet, screens, and the actions that take you to each.

In general, the MVD is a good first start to a set of visual editing tools that will make J2ME development user interfaces and application flow much easier. Coding GUI components by hand is a tiresome and error prone activity that will be greatly improved by MVD, especially when you can reverse engineer your current applications and build reusable GUI components like Forms.

Last month, I wrote an article about turning your J2ME devices into Web service clients. If you download and run the Web service included with that article, I have rewritten the accompanying J2ME client as a “Visual” MIDlet. Download the code associated with this current article and you will find three zip files in the download. Extract the contents of the GetQuote.zip into your NetBeans Projects folder (C:Documents and Settings by default on Windows XP systems). After doing so, you should be able to open the project called GetQuote in the NetBeans IDE. If you open the GetQuoteMIDlet, you can view the GetQuoteMIDlet with the Screen and Flow Editors. Again, because the MVD requires all the visual components to be embedded within the MIDlet, the formerly separate EntryForm and PolicyList classes are now embedded into the GetQuote MIDlet class. If you get the Web service running from the last article, you can run the updated Visual MIDlet client against that Web service with no changes to the server-side.

Server-side Integration (Wireless Connection Wizard)
The second big feature added to the 4.1 version of the Mobility Pack is the Wireless Connection Wizard. This tool helps generate wireless MIDlet clients of enterprise services. The Wizard automatically generates the MIDlet and client-side classes and a Servlet which delegates the client requests to the appropriate enterprise service(s). Again as another first generation tool, the Wireless Connection Wizard offers a great deal of promise. I was able to generate and modify a MIDlet that connected to a simple Servlet in minutes using this tool.

Figure 6. The Wireless Connection Wizard: To open the Wireless Connection Wizard, select MIDP under Categories and Wireless Connection Wizard in the File Type in the New File dialog box.

To see this new feature, use the NetBeans 4.1 IDE to create a Web or Enterprise Application. Select File?> New Project. . . and then select Web under “Categories” and “Web Application” under “Projects” in the proceeding New Project dialog box.

Now, in the project, create a Servlet or other enterprise service using the NetBeans tools. I used the New Servlet tool. In my project, I created a Servlet to accompany my Web service of the last article. This Servlet responds with the Average Insurance Rate for any given city passed to the Servlet as a parameter. The code for my Web Application Project is available in the download associated with this article. Find the CityRates.zip in the download and extract the contents of this zip file into your NetBeans Projects folder (C:Documents and Settings by default on Windows XP systems). After doing so, you should be able to open the project called CityRates and the project should contain the InsuranceAvg servlet.

The Wireless Connection Wizard can automatically create a MIDlet to access any enterprise service as long as the class and methods adhere to the following conditions:

• The class (in my case, the Servlet) containing the methods must have public access.
• The service containing the methods must contain a public constructor that takes no parameters.
• The method accessed (or “exported” method as it is typically referred to) in the service must have public access.
• The method’s parameter types and return types must be supported. Supported parameter types and return types are: boolean, boolean[],byte, byte[], short, short[], char, char[], int, int[], long, long[], java.lang.String, and java.lang.String[].

Figure 7. Identify the Web Application Projec: Specify the Web application containing the enterprise service that you want to create a MIDlet to access and specify what to call the delegate Servlet that will be created to act as the intermediary between the MIDlet client and the enterprise service.

Figure 8. Identify the Exported Services: Select from the available public “services” or methods those with which you want the MIDP client to communicate.

In the case of the InsuranceAvg servlet, a single “exported” method was added to the servlet called getAverageInsuranceRate(String city) as shown in the listing below. For the purposes of this demonstration, the average city insurance rate is artifically calculated by generating a random number between 0 and 4 and multiplying 100:

public String getAverageInsuranceRate(String city){        if (city!= null) {            return city + " average Gold Insurance rate		 is: $" + new java.util.Random().nextInt(4) * 100;        } else {            return "No city specified.";        }    }

With the service (i.e. the Servlet) in place, the Wireless Connection Wizard can now be used to generate a MIDlet client. Create another project, this time a Mobile Application, in the NetBeans IDE. As the Wizard will generate the MIDlet for you, you do not need to create the HelloMIDlet as suggested in the New Project dialog box. In fact, just create an empty Mobile Application and the Wizard will do the rest in a moment.

After you have created the project, right click on the project and request a New?>File/Folder… from the corresponding menu.

Figure 9. Specify the MIDlet and Associated Client Code: The last step before the Wizard generates the necessary code is to specify the client side class name and indicate which parts should be generated.

From the ensuing dialog box, request a MIDP Wireless Connection Wizard as shown in Figure 6. The Wireless Connection Wizard will then guide you through the creation of your MIDP enterprise service client.

The Wireless Connection Wizard will identify the Web applications already in your NetBeans environment or you can request to open a project that is not already available. You must name the Servlet the Wizard will create that delegates the MIDP client requests to the enterprise services and place it in an appropriate package in your Web application project (see Figure 7).

Figure 10. The MIDlet in Communication with the Enterprise Service: The Get Average City Insurance MIDlet running and communicating with the City Rates enterprise service.

After identifying the Web application with the service to which you want to connect, you must select the services to “export” (see Figure 8). Again, the exported enterprise services or methods must be public and have parameters of supported types.

The last step in the Wireless Connection Wizard is to name and generate the client application (see Figure 9). The Wireless Connection Wizard generates all the client code, stub methods, and a sample MIDlet (Visual MIDlet?of course) based on the specifications you provide in this last step. When finished, the Wizard generates code to put in both the MIDP application and Web application projects. The MIDP project gets the client code, stub and MIDlet while the Web application project is provided the delegate servlet and supporting classes.

Using the Wireless Connection Wizard, I created a new client side project called GetAverageRate that contains the AvgCityRateClientMVD MIDlet. After the Wizard generated the MIDlet, the only work left for me was to use the Visual Designer to pretty-up the labels and display. The GetAverageRate project is located in the GetAverageRate.zip file in the download. If you extract the contents of this zip file into your NetBeans Projects folder (C:Documents and Settings by default on Windows XP systems) you will have both ends of the MIDP client and Web application enterprise service example shown through this section of this article. When you have the resulting client running against the service, your MIDP client should look something like what is shown in the screens of Figure 10.

Deployment Options
Lastly, Mobility Pack 4.1 offers the means to deploy your project MIDlet Suite(s) to a server file system or device directly. Deployment has always been a little painful in J2ME development,for many reasons?proprietary vendor mechanisms, protocols, security, etc. While this new IDE feature will not solve all ills, it does offer the possibility that deploying a J2ME application may soon be more like deploying an enterprise application.

Figure 11. The Deploying Option IS Selected: Deploying a project’s MIDlet suite can now be accomplished from inside the IDE. Four methods of deployment are available. The method displayed here is FTP.

Access the MIDP Suite Deployment feature by right clicking on the MIDP project and selecting “Properties” from the menu options. On the Properties dialog window, select the “Deploying” Category as shown in Figure 11. The deployment configuration dialog box allows you to pick the deployment method, destination, and required deployment information/settings such as authentication information.

Today, there are four deployment method options available through the Project Properties dialog. J2ME developers can deploy their J2ME MIDP suites using SCP, WebDAV, FTP, or a straight file copy.

Wrap Up
As you can see, the new NetBeans IDE and Mobility Pack 4.1 have a lot to offer. The last couple of releases have really improved on the J2ME developer’s ability to write, debug, and deploy MIDP apps. Is my laundry list of needs and wants for a J2ME IDE completely satisfied with this latest release of NetBeans and the Mobility Pack? Not yet, but it’s are getting closer. The visual editing feature, in particular, has a ways to go. However, even the folks at Sun have indicated they realize this is a first step. But the future looks much brighter. I am almost ready to remove that text editor from my desktop.