This article will show you how to use NetBeans 4.1 and the Mobility Pack to write a Java Mobile Edition application quickly and easily. It will demonstrate the simple GUI creation and storage facilities available to a mobile application developer, but will not delve into the online connection capabilities at this point (I will instead save that for the future).
The application I will demonstrate will be a simple vehicle mileage calculator and tracker, allowing you to use a mobile phone or other Java-enabled device to track your average fuel consumption and cost per mile. It is deliberately kept simple and I will note any simplifying assumptions made as the application is presented. It is, of course, entirely up to you if you want to extend this code into something more detailed and useful.
The toolset used for this demonstration is NetBeans 4.1 with the Mobility Pack, both of which are freely available for download from http://www.netbeans.org.
The full project source for this article is available for download from this link.
Getting Started
Before you can start building the application, you will need to get NetBeans 4.1 and the Mobility Pack if you don't already have them.
Both the NetBeans IDE and the Mobility Pack can be downloaded from http://www.netbeans.info/downloads/download.php?type=4.1.
Optionally, enter your e-mail address or uncheck the checkboxes, and click Next to get to the download area.
Be sure to read the Installation Instructions and Mobility Pack release notes using the links on the download page.
Create a New Project
- New Project->Mobile->Mobile Application
- Project Name: MileageCalculator
- Set the project location to where you want it on the disk.
- Uncheck the "Create Hello MIDlet" option.
- Click Next.
- For this application, choose Default Color Phone, CLDC-1.0, and MIDP-1.0 options.
- Click Finish.
Create the Visual MIDlet
The core of our application will be a visual MIDlet, which can be thought of as a visual JavaBean for a phone. In fact, this is selling it short—the MIDlet encompasses multiple forms and other GUI views, navigation information between these GUI parts, lifecycle methods for the application, as well as the usual event handlers, methods, and properties.
To create your MIDlet, do the following:
- Expand the MileageCalculator node in the Projects pane (if it is not already expanded).
- Right-click on the <default package> node and select New->Visual Midlet.
- Set the MIDlet name to MileageMidlet, and the MIDP Class Name to the same.
- Ignore the MIDlet Icon unless you have a really nice icon to use already (creating icons is beyond the scope of this article).
- For the package, type in something that makes sense. For example, I will use com.crispybits.j2me.demo.mileage.
- Choose MIDP Version to be MIDP-1.0.
- Click Finish.
You should now find yourself looking at the flow designer. There should be an icon that looks like a phone, with a Start Point and an Exit Point. This is one view of the MIDlet; there are two more selectable by buttons at the top of the main pane: Screen Design and Source. Click the Source button to see what is already in the MIDlet at present.
You should see a default constructor (empty) and three lifecycle methods: startApp(), pauseApp(), and DestroyApp(). I will come back to these later.
Creating the GUI
The first part of your application building will be the GUI. There will be three screens in your application. The "main" screen will be the summary page—where you can see the current mileage, MPG, and cost information summarized. There will also be menu options from this screen to the two others you need—an initial setup screen (to enter the vehicle's mileage when you first start using the calculator) and a screen to enter new details when you fill up.
The Summary Page
The summary page will simply give you a run down of the current details for your vehicle, including the current recorded mileage, the current MPG, and the cost per mile since you started keeping records.
Note: the "cost per mile" is simply what the gas is costing.If you want to track maintenance and other items, this application could easily be augmented to do so.
To create the summary page:
- Select the MileageMidlet and switch to the Flow Design view in the main pane.
- In the inspector pane (top right), right-click on the Screens node and select Add Form.
- A new form will appear in the Design view; drag it to the right of the phone icon.
- Right-click on the new form, and select Rename, call it SummaryForm.
- From the red dot next to Start Point on the phone, drag a line out to the red dot on the SummaryForm. This will make the SummaryForm be displayed as the starting form when you run the application.
- Double-click on the SummaryForm to go to the Screen Design for that form.
So far, so good (and nice and easy). You should now see an empty screen ready to take new widgets from the pallette (to the left of the empty form). Before you start adding components, I will take the chance to talk about GUI design in Java ME, and how it compares with desktop applications.
If you have designed a full swing GUI, you will notice some differences when using Java ME to create screens. The most obvious is that there are fewer components. Not so obvious, however, is that (at least for what we are doing) you cannot control the layout of the components as much as you might be used to in swing. The concept of different layout managers does not exist in this GUI builder, nor does it make sense if you stop and think about it.
When designing for a mobile device, you are likely to be dealing with any number of different screen sizes and configurations. Generally speaking, a Java ME application will use all of the screen, not a window within that screen, so that means that the application could be displayed at any resolution from fairly small (say 100x100 pixels for the sake of argument) up to much higher resolutions.
When you think about this, it makes sense that trying to control layout would be very hard. In fact, the device will largely control the layout based on what makes sense to it. I will put down the components you want in the order you want (using a simple flow layout for you Swing folks out there), and leave it to the device to figure out the display details.
Although it may feel a bit strange at first, this model of development is actually quite liberating after you get used to it, and you can certainly slap some GUIs together pretty fast. They might not win any beauty prizes, but they will be functional and they will work on any device (although if you pack a lot onto one screen, you might find yourself scrolling around a lot when running on lower-resolution devices).
The "device handles it" philosophy is carried over even further for the action items (like the menu). You will define the menu actions you want, and the device will figure out how to present them to the user. The likelihood is that the options will be attached as a menu on one of the device's "soft buttons," but it really is down to the device on which the application is running.
Note: If you have a particular device in mind (let's say your phone) and know the resolution, you can right-click on the screen in the Screen Designer, select "Set Screen Size," and then set it to the desired resolution. Although this won't guarantee what it will look like on your device, it will give you a better idea of how much information you can fit on the screen.
Managing the Modern Network
Business Service Management: Generate Revenue Through IT 
Evaluating Software as a Service for Your Business
Storage Networking: Configuration and Planning
Is Your Disaster Recovery Plan Good Enough? 
IE 7
Firefox 2.0
