Overview

 

The first thing you should do is read the SUN guide entitled “Do-It-Yourself MIDP on Mac OS X” found at http://developers.sun.com/techtopics/mobility/midp/articles/osx/.

Starting from a clean installation of OS X, you need to:

-Install Ant (for making your life easier - note that you need to compile, verify, and package your application before it can be deployed on the phone).

-Install mpowerplayer for emulation purposes (http://mpowerplayer.com/products-sdk.php).

-Use your favorite editor for creating and editing source code files.  I use JEdit (http://www.jedit.org/), but any editor (even TextEdit) will do!

 

Installing the software

 

Installing Ant simply involves copying it to a directory, and changing your $PATH environment variable to point to the /ant/bin directory.  You do this, so that you can type “ant” at the prompt.  For example, I copied the ant distribution to the /Development/ant directory on my Mac.  I then included in my .bash_profile file (in my home directory) the line “export PATH=/Development/ant/bin:$PATH”.

Start a new instance of Terminal, type “ant” and you should get a message like “Buildfile: build.xml does not exist”.  This is actually good, because it means that ant is working.  Note that ant works by looking for a file called “build.xml” in the current directory.  For each of your projects you need to create such a file, which is basically a makefile.

 

To install mpowerplayer, just download the distribution SDK, and unzip it into a directory.  I unziped it into the /Development/mpp directory.  You are now ready to compile your first MIDlet.  Go to the mpp directory, and cd into the Tutorial directory.  Type ant, and watch your first MIDlet being compiled, verified and packaged.  In the same directory you will find an index.html file, which describes the sample MIDlet, the ant build process, and other interesting bits.  Also, the src directory contains the source code for your first MIDlet, and the bin directory contains the jar and jad files.  The jar file is the MIDlet itself, while the jad file is a small text file that contains extra information abou the MIDlet (such as author, version, etc.).

 

Developing for Symbian

 

Now that you are up and running in developing MIDlets on your Mac, you are ready to develop for the Symbian platform.  Symbian has built-in support for MIDlets, so essentially you just have to copy the application to your phone, and run it.  Here are some interesting issues that we came across when developing for Symbian (using the setup we have described so far).

 

Activating components

 

If you switch back and forth between forms, you will notice that the component that was active when you left the form is the active one when the form is shown again.  For example, assume you have a form for entering information about specific people (Name, phone, address, age).  Assuming a user enters this data and presses OK, the last active component on the screen is going to be, in this case, the age field.  The next time you display the form to, say, add a new contact, the information that was entered there is still going to appear.  You can iterate through all the components on the form and clear them, so that the user is presented with a clear form.  However, the active component is still going to be age.  To get over this problem, you can use the setCurrentItem method.  The call to activate the first component on a form called myForm would look something like:  Display.getDisplay(this).setCurrentItem(myForm.get(0));

 

Hint:  The setCurrentItem, according to the J2ME specification is supposed to activate the form on which the item is, and activate the item.  However, the mpowerplayer implemenation does not support this fully, and only activates the component without showing the form (thus appearing as if nothing happens).  To get over this problem with the emulator, you can issue an additional call to the  setCurrent method.  Issue this call after the setCurrentItem call, because otherwise once the form appears it will show a switch from the previous active field to the new active field.  To sum up, the calls should look like:

Display.getDisplay(this).setCurrentItem(myForm.get(0));

Display.getDisplay(this).setCurrent(myForm);

 

Getting the menus right

 

You will also want to make sure that your application displays the menus you want it to, depending on which screen or form is currently viewable.  Beware of the fact that the J2ME implementation displays menu items (commands) that you have not specified.  Specifically, it displays an Exit command on every single screen of your application (effectively allowing users to terminate the application from every single screen). This has the effect that one command may be immediately accessible (assuming your phone has two activation keys - since there is always the exit command).  Also, in cases where you have added an exit command yourself, the application is effectively going to display two exit possibilities: one called ‘Close’, and the other one called whatever it is you have named it (e.g. ‘Exit’).

 

There are other instances when the system will dynamically add its own commands to your menus.  Specifically, you can define a TextField to be of type any, phonenumber, email, etc.  In the case of phonenumber, the system will automatically switch the keypad to numeric entry, but will also provide an option in the menu “Add from Contacts”, which essentially allows you to select a contact from the addressbook and paste that number into the TextEdit.  The same is true with email TextFields.

 

Stability issues

 

Even when developing very simple GUI applications (of the Hello-world type) it becomes obvious that the J2ME support in the Symbian environment is not quite mature.  In many instances clicking on your application icon will result in absolutely nothing.  In such cases, the only effective remedy I know of is to restart the phone.   Interestingly enough, during one of these incidents, I tried to install a new version of my application.  I was issued with a error message that “the application is currently running”, although it does not appear on the list of processes displayed when the menu button is kept pressed for 2 seconds or so.  I have reason to believe that these lockups happen when the phone is left idle with the application running for a period of 5 minutes or so, but I have not reached a conclusion yet.

 

String sorting

 

Beware that when sorting strings, empty strings such as “” are sorted before actual text using String.compareTo().  This may cause some confusion about your sorting algorithm if you are sorting, for instance, an array of string, and then presenting it to the display.