J2ME software development for cellular phones

(2002)

Colin Fahey

This document is obsolete!  The information in this document might have been valid and useful in the year 2002, but many things have changed in subsequent years!  This document should now only be regarded as an interesting historical record of the year 2002.  Do not rely on any information or advice in this document.  All technical information in this document is very obsolete. 

Downloading self-created software, self-created images, and self-created telephone alert melodies (i.e., "ring tones"), was relatively rare and difficult in the year 2002.  Sadly, six years later, some cellular phone service providers (including Apple, which provides the exclusive software and "ring tone" portal for the iPhone) still impose restrictions on downloading software, images, and music, because cellular phone service providers enjoyed extremely large financial profits by controlling these types of downloads. 

Fortunately, cellular phones such as those featuring the "Android" software platform, will forever end the ability of companies to create and exploit closed markets for such uses of cellular phones.  Although consumers willingly purchased cellular phone service plans that included very high costs for downloading software, images, and music, this is because of the limited number of cellular phone service options available. 

The economic dynamics that have enabled certain companies to grow to dominate the market should not be interpreted as implicit strong approval by the consumers.  As companies start to dominate, and then make it difficult or impossible for competitors to enter the market, the dominating companies can offer products that combine high positive value (e.g., the ability to communicate from anywhere) with high negative value (e.g., high prices for desirable software, images, and music, all of which would otherwise be freely available; thus, the service adds negative value).  No consumer is forced to purchase a cellular phone, but there is no doubt that the dominant cellular phone service providers have gradually created conditions that can not be considered a "free market".  Therefore, the cellular phone service market has been economically "inefficient" and has been an undue burden on consumers. 

Hopefully, requirements that cellular phone service radio frequencies be available to competing services will restore normal market values to data transfer, such that cellular phone service providers are again reduced to mere carriers of data (i.e., only providing bandwidth) rather than information or entertainment providers! 

The business of transporting data must be separated from the business of selling data, otherwise there will be an incentive for the data transportation business to block competitors from selling data through the same data transportation channel. 

The video game console market suffers from the same problem.  The manufacturers of video game console hardware are in the business of creating devices that can display video games, but those same companies also have exclusive control of the transfer of software to those video game consoles.  Therefore, there is an incentive for the video game console manufacturers to block competitors from selling software for the video game consoles.  If a video game console hardware manufacturer focused on designing and manufacturing hardware that could be sold at a profit (instead of at a significant loss, as with the X-Box and PlayStation and Nintendo video game consoles), then the video game market would thrive, and the quality of the best video games would dramatically improve, and the cost of video games would collapse. 

This section describes how to download development tools that can be used to compile J2ME source code in to class files suitable for mobile devices.  Note that the Sun "J2ME Wireless Toolkit", discussed in a later section of this article, requires downloading the Java SDK described in this section. 

This means you need the conventional Java 2 SDK from Sun.  I downloaded and used version 1.4 via the following link:

Here is what the download page looks like:

Start the installation program.  Install to the default location ( c:\j2sdk1.4.0_03 ) unless you are able to solve path problems that may arise. 

I won't pretend to know what this is, but I simply downloaded it from the Sun web site.

Here is what the CLDC main download web page looks like:

Only 1.0.3 was available at the time I visited.

In order to download this, I needed to register with Sun web site.  I created the following profile:

I downloaded the following file:

I unzipped to the following directory:

I renamed the "cldc-1_0_3-fcs" directory to simply:

I won't pretend to know what this is either, but I simply downloaded it from the Sun web site.

Here's what the MIDP main download web page looks like:

I downloaded the following file:

I unzipped to the following directory:

I renamed the "midp-1_0_3-fcs" directory to simply:

Add the following lines to your AUTOEXEC.BAT file:

Then force these variables to be reloaded by running the batch file:

You can also set up these same variables using the Windows environment variable control panel.

Notice that I chose to specify explicit directory paths to my current version of the Java 2 SDK.  Therefore, if I upgrade, then I must modify the AUTOEXEC.BAT file to specify the new directories. 

Once the settings above take effect, you should be able to run the Java tool programs from the command prompt without specifying the complete path to the tool programs. 

The following command will start the cellular phone device emulator: 

The following image shows the cellular phone device emulator: 

Using any text editor, a person can type in code, such as for this HelloMIDlet.java source code file:

Here is the code in plain text format:

Caution: The following command must be on a single line, but has been expanded to several lines of text only for clarity.

(Current directory: C:\HelloMIDlet)

Note: The "-target 1.1" is necessary to avoid an error in the future "preverify" stage.  Apparently this has something to do with a problem with MIDP 1.0.3 support in JDK 1.4. 

(Current directory: C:\HelloMIDlet)

This generates a new *.class file in a new subdirectory called "output" (by default).

(Current directory: C:\HelloMIDlet)

This starts the phone emulator, indicating that the new "output" directory contains some of the necessary *.class files.

The following image shows the expected result.

A "manifest.mf" file is essential to getting an actual cellular phone to interpret the contents of a *.jar file.  If a proper "manifest.mf" file is not included within the *.jar file, then the cellular phone might successfully download the *.jar file, but might fail to interpret the downloaded file, possibly reporting an error such as "Unsupported Content Type". 

The following is an example of a simple "manifest.mf" file.

Here is the "manifest.mf" file as plain text: 

Notice that the CLDC and MIDP versions are specified in this file.  Be very cautious and conservative when editing the various fields in this file.  If you get "File Corrupt" errors, then try eliminating all fields that are not shown in this example.  Also, put the fields in the order in which they appear in the example.  Also, shorten each field value as much as you can, and keep the characters limited to simple letters, digits, periods, and dashes.  Some cellular phone services, and cellular phones, can tolerate more variation of field ordering and field contents. 

The following command creates a *.jar file.  The *.jar file will contain the specified manifest.mf file, and will contain the *.class files found in the specified directory.

Current directory: C:\HelloMIDlet

Complex hypothetical example of creating a *.jar file

Suppose an icon image file (e.g., "icon.png") is to appear in a *.jar file as "/icon.png".  (Note: Program icons do not appear on the Motorola T720 cellular phone, but do appear on other cellular phone types, and do appear in the MIDP emulator.) 

Suppose there is a directory named "images" with image files (*.png format).  Suppose this directory, and all of the images contained in the directory, should be accessible to the Java program by the relative directory /images (such that an image "a.png" would be accessible using the path "/images/a.png"). 

Suppose all of the *.class files produced by the preverify command are contained in a directory named "verified".  For example, the verified version of the main class, "MyApp.class", would be in the "verified" folder, along with the other classes of the program.  All of these classes are to be accessible in the root directory of the *.jar file. 

The following command will create a *.jar file that achieves the various goals specified in the previous paragraphs.  Caution: the command has been expanded to several lines of text here only for clarity.  When entering the command at a command prompt, the command must not contain line breaks; otherwise the command interpreter will interpret the entered text as multiple independent commands. 

The final part of the command is difficult to understand.  It has the following meaning:  "Change the current working directory to .\verified, and then put all *.class files found in the relative directory '.' (namely all *.class files in the current working directory) in to the *.jar file."  Because the directory had been changed before specifying the path of the classes to put in the *.jar file, the local path will not appear in the relative path when the files are placed in to the *.jar file. 

For example, suppose the verified classes are in the following directory: 

C:\MyApp\verified 

Suppose there are class files such as the following: 

C:\MyApp\verified\w.class 

Then specifying "-C .\verified ." in the command to create the *.jar file, starting from a current directory of "C:\MyApp", will result in "w.class" being put in the root directory of the *.jar file. </e>

Warning: When the "-C" option is specified, it changes the current working directory at that point of processing the overall sequence of command parameters to the jar command.  Therefore, the jar command might complain that it cannot find other files mentioned in command parameters beyond the "-C" option.  If this happens, simply move the "-C .\verified ." to be the final parameters of the overall command. 

The following shows verbose output of the jar command. 

A *.jad file is necessary so that the cellular phone can describe a computer program to a person before the person decides to download the program.  The *.jad file also provides some indirection from the *.jar itself. 

Here is the example hi.jad file in plain text format:

There are programs which can generate the *.jad file, which makes it easier to update the "MIDlet-Jar-Size:" field each time the *.jar file is changed (and its size changes).  If you search the Internet you will find useful J2ME programs. 

If the size field doesn't specify the exact byte total of the *.jar file, then the following error might appear after a successful download to a cellular phone: "Download Failed" (download failed). 

For the Motorola T720 cellular phone, the following error message might be used to inidcate invalid fields in the *.jad file, or possibly invalid fields in the generated MANIFEST.MF file within the *.jar file: "Failed: File Corrupt" (failed: file corrupt). 

The following executes the class found in the *.jar file, described by the *.jad file. 

(Current directory: C:\HelloMIDlet)

Much of what I presented here can be found on many other Internet sites.  However, I corrected some errors found on other Internet sites, and added missing details, and presented the complete experience of someone trying to do this stuff.  Here are very informative links that helped me get started: 

http://wireless.java.sun.com/midp/articles/getstart
http://wireless.java.sun.com/midp/articles/setup

The simple program presented in the previous section of this document only has a single source code file, and the program does nearly nothing and thus is not a good example of cellular phone programming. 

My friend Sam Robertson wrote an interesting J2ME program that teaches a person to play the card game "Blackjack" (also called "21").  A player is presented with a "dealer card", and the player's pair of cards, and the player must decide what to do: "stay", "hit", "double-down", or "split". 

This program has six source code files.  The program responds to user input, and does simple drawing and text updates. 

Click on the following link to get the source code, and the *.jad file, "manifest.mf" file, and a batch file, all in one convenient ZIP file.

Extract to an arbitrary directory, but if you extract to "c:\" under Windows, the following example discussion will be even closer to your actual situation.

File: "manifest.mf":

The following batch file is rough, but it serves as an illustration of how you might get started with writing your own batch file to build your J2ME program.  This example batch file does the following:

Here is the same file ("build_sbj.bat") in plain text format:

Here is the result of running the "build_sbj.bat" batch file at the command line:

Note that the warning messages for the "rmdir" and "del" operations simply indicate that there is nothing to remove. 

You can see the new directories (i.e., "classes" and "verified") and the new *.jar file that resulted from running the batch file:

To deploy the sbj.jar file, we need to create and edit the sbj.jad file to have the correct *.jar size in the appropriate field:

File: sbj.jad

A person might need to add the complete URL to the *.jar file when the *.jad file is put on an Internet site -- but I discovered (by an experiment) that I was able to avoid mentioning the full URL (i.e., I only specified the *.jar file name by itself).  However, putting in the complete URL, but I wanted to let you know what I observed.

Having multiple source files in your project is common, and in this section we gave a crude illustration of building multiple classes, followed by packaging and execution. 

Please see the following section regarding using Sun Wireless Toolkit, which makes building applications much easier. 

Sun offers a convenient development environment for building and packaging J2ME programs: "Java 2 Platform Micro Edition (J2ME) Wireless Toolkit (version 1.0.4_01)". 

(Caution: You need to download the Java 2 SDK 1.4 as described in an earlier section to use this toolkit. Do this now if you don't already have this version of the Java 2 SDK.) 

Go to the following Internet site to download the toolkit: 

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

Download the "1.0.4_01 English" version.  Here is what the download page looks like: 

This will download the following file: "j2me_wireless_toolkit-1_0_4_01-bin-win.exe" 

Execute this program to install on your system.

After the toolkit is installed, you can launch it from the "Start" (start) menu system:

You can also access MIDP-1.0 documentation via the "Documentation" item in this Start (start) menu.

Disregard the "MIDlet-Jar-Size" field (with value "100" bytes) for now.  We will eventually cause the correct value to get set. 

Click on the only row in the table ("MIDlet-1") to highlight and select it.  Then click the "Edit" button. 

Do the following: 

(1) Project --> Clean : Removes all *.class files;
(2) Build : Builds all *.class files and preverifies;
(3) Project --> Package --> Create Package : Produces *.jar and *.jad

When you do these three steps, the resulting *.jar and *.jad are immediately ready for execution in the local emulator, or for immediate deployment on your Internet site for others to download "Over The Air" (OTA).  The *.jar size field in the *.jad file will be correct.  Don't forget to do step (3) every single time you rebuild! 

Now you can test by hitting the "Run" (run) button. 

Just copy the *.jar and *.jad files from the specified locations (reported by the toolbar's console window during a build of the project), such as:

(From the console window:)

Put these files directly on to your Internet site without modification, and it should work.  Here is what I saw on my cellular phone after downloading this compiled application "over the air" (OTA)

If you have an Apache Internet web server, you need to create a file named ".htaccess" within your web site root directory.  The ".htaccess" file enables you to override Apache configuration, such as adding or overriding file MIME types.  You must add the specify the MIME types corresponding to *.jar files and *.jad files, as shown in the following text file: 

Here is my simple .htaccess file as plain text:

Apparently, creating or modifying this file results in an immediate change of Apache server behavior.  I guess the Apache server checks the modification date and time of the ".htaccess" file upon each new incoming transaction, and the server reloads that file if the modification date and time has changed. 

If you have a different kind of Internet web server, you must determine how to specify MIME types, and you must ensure that *.jar files and *.jad files are assigned the appropriate MIME types. 

You will know if the MIME types have not been set up if the cellular phone refuses to download your *.jad file and reports the following error: 

"406: Not Acceptable" 

The Motorola T720 J2ME cellular phone with AT&T service is able to download a *.jad file directly, by typing the URL of the *.jad file in to the cellular phone.  This is likely to work for other J2ME cellular phones with other cellular phone service providers. 

However, it might be more convenient for people to download the *.jad file by selecting a link within an HTML document or within a WML document.  (Note: WML is now obsolete. Most cellular phones can now interpret HTML.) 

The following images show the exact sequence of actions I did to download and execute the MIDlet developed and deployed as described in the previous sections above.  These images are photographs of the screen of my cellular phone. 

(1) Main screen: When you open the phone, you see the main screen. Press the center button to go to the main menu. 
(2) Main Menu: Move to the item "WebAccess". 
(3) WebAccess: Move to the item "Go To URL". 
(4) Enter URL: Type in the URL of a *.jad file (or of an HTML document, or of a WML document). 
(5) Details; This information was parsed from the *.jad file. Press DOWNLD to download the *.jar file. 
(6) Download Complete; Wait for this message to disappear; 
(7) Installing; Wait for this message to disappear; 
(8) xxxx bytes transferred; Wait for this message to disappear; 
(9) Installed; Wait for this message to disappear; 


When the WebAccess menu appears again, after the program has been installed, simply exit each menu to return to the main screen. 

(1) Main screen: When you open the phone, you see the main screen. Select the "Games & Apps" option via the main menu, or press the downward cursor on the main screen. 
(2) Java Powered: Wait for this screen to disappear. 
(3) Games & Apps: Select the item with the name of your program! 
(4) Yay! Successful execution of your program! 

The program appearance on the cellular phone is very similar to the appearance within the emulator.

The following errors messages are only relevant to the Motorola T720 (GSM/J2ME) cellular phone. 

Cause #1

Any file (HTML, JAD, JAR, MID, GIF) over 1644 bytes will cause this error for certain Internet web hosts and servers.  Here is a brief list of hosts and servers: 

The problem is due to a flaw in the Motorola T720 GSM/J2ME firmware, which causes downloading files in fragments to fail.

The only apparent solution is to switch Internet web hosts or server type.  Other cellular phone types do not have this problem. 

Cause #2

The "MIDlet-Jar-Size:" field of a *.jad file does not indicate the exact byte total of the corresponding *.jar file.

Cause #1

The *.jar file uses API functions which are not available on the specific cellular phone. 

For example, MIDP 2.0 functions are not available on the Motorola T720 GSM/J2ME cellular phone (which only has MIDP 1.0 functions).  A program might execute within an emulator, but might not execute on the cellular phone. 

The solution is to search for MIDP 2.0 functions in the source code and replace them with MIDP 1.0 functions, or eliminate the features which require the MIDP 2.0 functions. 

Cause #2

The "manifest.mf" file used to create the *.jar file (via the "jar" utility) contains errors. 

Make sure the "manifest.mf" file has the following versions of CLDC and MIDP: 

The entire "manifest.mf" file should look almost exactly like the following: 

Each line of text in the "manifest.mf" file, including the final line of the file, should end with a "carraige return" (CR; 13; 0x0d) character followed by a "line feed" (LF; 10; 0x0a) character. 

The only fields of the "manifest.mf" file in your own version of the file that should differ from the example shown here are the first three fields listed in the example.  The final three fields should be an exact match with the example, and the final two characters of the file should be the "carriage return" and "line feed" after the final field. 

Here are possible problems in your version of the "manifest.mf" file: 

Perhaps some of the cases listed above do not actually cause problems for many cellular phones, but eliminating all of the cases listed above might enable the download to succeed.  After the download is successful, you can experiment with variations of the "manifest.mf" file to discover what other things you can do without causing download errors.  When the "manifest.mf" file is modified, it is important to verify that downloading the program continues to work for all target cellular phones and cellular phone service providers.  Some phones and services are less flexible than others. 

When a "manifest.mf" file is added to a *.jar file via the jar program, the jar program creates a new version of the manifest file within the *.jar file.  The generated version of the manifest file within the *.jar file is named "MANIFEST.MF".  The jar program might add fields to this file that do not exist in the "manifest.mf" file provided by the programmer.  Do not extract a "MANIFEST.MF" file from a *.jar file, unless you are prepared to eliminate some fields and make the remaining fields look exactly like the example "manifest.mf" file shown above. 

Cause #1

The cellular phone cannot accept the MIME type reported by the remote server for a specific file. 

For example, JPG image files are not supported by the Motorola T720 and will cause this error.

This error can also occur if the MIME type for a supported file type (e.g., GIF, MID, JAD, JAR) is not reported correctly by the server.  A person must be very careful to report the exact MIME type for the supported file types. 

Cause #2

The file cache on the cellular phone itself needs to be cleared (e.g., Browser Settings -> Clear Cache). 

If you recently added MIME types to a remote server, and then attempted to download a file that had previously failed to install due to an incorrect or missing MIME type, then the file cache on the cellular phone might be an obstacle to downloading the file again with the proper MIME type. 

It is also possible that the remote file was modified and that the cached version is defective and is preventing the repaired file version from being downloaded as a replacement. 

Clearing the browser cache on the cellular phone should ensure that a subsequent download benefits from the latest server configuration (e.g., new MIME settings) and remote file updates. 

Cause #3

[From Motorola documentation: http://developers.motorola.com/developers//wireless/global/emea/other/UCT.html]

Cause #1

You have a Verizon phone! 

Verizon does not allow its customers to download images (GIF), ring tones (MIDI), or programs, from arbitrary Internet web servers.  One must either use their "Get It Now" service, or use a USB cable and the "Get Around 'Get It Now' (GAGIN)" software. 

Solution: Simply wait for competition in the "free market" to eliminate "closed platforms".  The whole technology might be obsolete by the time this succeeds, but this is what happens when companies are guided by greed alone. 

Cause #2

The error message indicates that the MIME type associated with the file extension (e.g., .gif, .mid, .jar) of the file being downloaded has not been specified by the Internet web server.

If you have an Apache Internet web server, for example, then you must modify an ".htaccess" file, adding the following lines:

Cause #1

The server hosting the file being downloaded did not specify the MIME type for that file (e.g., GIF, MID, JAR).  Thus, the cellular phone assumes that the file is plain text.  Also, the cellular phone might have a limit on the size (in bytes) of text files which is smaller than the limit on the size (in bytes) of binary files (e.g., GIF, MID, JAR).  Therefore, a binary file interpreted as a text file is likely to exceed the maximum allowed size of a text file, and will thus cause the error. 

If you have an Apache Internet web server, for example, then you must alter an ".htaccess" file, adding the following lines:

Cause #2

Apparently this error can also occur even if the remote server has the proper MIME types established.  I have not yet determined when this error occurs instead of the "Download Failed" for this situation. 

Evidently, the Motorola T720 GSM/J2ME cellular phone cannot process an aspect of the HTTP 1.1 specification which allows for files to be broken in to fragments, requiring multiple "GET" requests. 

When using the Motorola T720 GSM/J2ME cellular phone to download files from certain Internet web server types, any file (e.g., HTML, JAD, JAR, MID, GIF) larger than 1644 bytes will cause this error.  Here is a brief list of Internet web hosting providers and whether or not the Internet web hosting provider causes a problem for the Motorola T720 GSM/J2ME cellular phone:

The problem is due to the firmware in the Motorola T720 GSM/J2ME cellular phone, which affects its ability to download files in fragments. 

The only apparent solution, when downloading to the Motorola T720 GSM/J2ME cellular phone, is to avoid certain Internet web hosting server types.  Most other cellular phone types do not have this problem, and so this problem might now be safely ignored. 

Cause #1

This error has nothing to do with the Internet server that is hosting the requested file. 

If you get this error, I suggest that you do the following things: 

I received the "Connection unsuccessful. Try again later." error message for several days after I first purchased a cellular phone.  Then, by random chance, I removed the battery.  When I put the battery back in to the cellular phone, I immediately had access to the Internet. 

I received this error several times during the subsequent six months, and the procedure above has restored access to the Internet each time.  I did not determine which step of the procedure might be the most important, but I believe that simply removing the battery and putting the battery back in to the cellular phone might be sufficient. 

In my opinion, this error message is too vague.  Why was the attempt to connect unsuccessful?  Was the cellular phone service network too busy?  Was the cellular phone service's "Gateway" server not functioning?  Is my cellular phone not receiving or transmitting enough radio signal strength?  When would be a good time to attempt the download again?  Ten seconds from now?  An hour from now?  A week from now?  The error message would be more helpful if it were more specific about the cause of the problem and if it were more specific about a possible solution. 

Cause #2

If you did a "Master Reset", or if you have never been able to access the Internet, then inspect the network settings on the cellular phone.  For an example of network settings (for the Motorola T720 GSM/J2ME cellular phone, for AT&T service in the Los Angeles, California area), see the section specified by the following link: 

AT&T cellular phone configuration settings (for the network)

You can create or acquire a MIDI sound file (*.mid) from any source.  I found the theme music to the television show "Knight Rider" (1982-1986) in MIDI format (e.g., "knightrider.mid") by a simple search of the Internet. 

The following image gives you some idea of how a MIDI file appears in a MIDI editor.  It is not necessary to have a MIDI editor to get music on to your phone.  You can get an existing MIDI file (*.mid) from any source.  However, you can also use a MIDI editor of your choice to create your own original polyphonic music. 

If you have an Apache Internet web server, for example, then you must alter an ".htaccess" file, adding the following lines: 

The ".htaccess" file will specify or override the MIME types indicated by the server for files of various types (typically indicated by the file extensions, such as .MID, .GIF, .JAR). 

If you have already added other MIME types for other file types, your complete ".htaccess" file might resemble the following text:

Apparently, creating or modifying this file results in an immediate change of Apache server behavior.  I guess the Apache server checks the modification date and time of the ".htaccess" file upon each new incoming transaction, and the server reloads that file if the modification date and time has changed. 

If you have a different kind of Internet web server, you must determine how to specify MIME types, and you must ensure that *.jar files and *.jad files are assigned the appropriate MIME types. 

You will know if the MIME types have not been set up if the cellular phone refuses to download your *.jad file and reports the following error: 

"406: Not Acceptable" 

I copied a MIDI file named "kr.mid" to the root directory of my Internet web server.  You can use software such as "Filezilla" to make the FTP transfer simple and convenient. 

For the Motorola T720 GSM/J2ME cellular phone, downloading a MIDI file begins with the "WebAccess" menu.  Selecting "Go To URL", followed by typing the URL of the MIDI file, starts the download.  For example, I typed in the following URL:

If the download is successful, and if you are using a Motorola T720 cellular phone, you will be given the option of storing the file on your cellular phone.  When you decide to store the file, you are given the option of simply storing in your set of ring tones or instead setting the file to be the current ring tone (which also, as a side effect, stores in your set of ring tones). 

The following images summarize the process of downloading and playing MIDI files for the Motorola T720 GSM/J2ME cellular phone.  Other J2ME enabled cellular phones, with other cellular phone service providers, are likely to have a similar download procedure.  If your cellular phone service provider is Verizon, then you are out of luck; none of this will work, and you should go and buy an "Android" phone to help destroy the "closed phone" market! 

(1) Main screen: Press the appropriate button to show the main menu. 
(2) Main Menu: Go to the "WebAccess" item. 
(3) WebAccess: Go to the "Go to URL" item. 
(4) Enter URL: Type in the URL of a MIDI file (*.mid) on an Internet web site. 
(5) Connecting: Wait for the download to begin. (If you received the "406: Not Acceptable" error message, then the Internet web server did not assign an appropriate MIME type for MIDI files (*.mid)).) 
(6) Downloading: Wait for the downloading to finish. 
(7) Download Complete: Wait for this screen to disappear. 
(8) MIDI Playback: The MIDI file starts playing immediately. Press the menu button to go to the Tone Menu, and continue to step (9), or press the "STORE" button and go to step (12). 
(9) Tone Menu: You have the option of playing... 
(10) Tone Menu: You have the option of getting details. 
(11) Details: Here we see the size in bytes. 
(12) Store Options: From step (8) we can hit the "STORE" button to get to this menu.  You have the option of storing to the phone's collection of tunes.  Hit "SELECT" to store. 
(13) Stored: The MIDI tune has been stored. 
(14) Total Bytes Transferred: This is simply a notification of the number of bytes downloaded, so that you aren't surprised by your upcoming cellular phone service bill! 

You can play the stored MIDI files at any time on your cellular phone, and you can use any MIDI file as your ring sound.

(1) Main screen: Press the appropriate button to go to the main menu. 
(2) Main Menu: Go to "Media Center". 
(3) Media Center: Go to "My Tones". 
(4) My Tones: Highlighted tone starts playing immediately.  You can change the name with the "EDIT" option.  Hitting the menu button gives you other options. 

Go through the following menu screens:

(1) Main screen 
(2) Main Menu 
(3) Ring Styles : Press "SELECT" 
(4) [Silent, Soft, Loud] Detail : Press "CHANGE" 
(5) Calls: [current ring style/tune] : Press "CHANGE" 


Scroll though list of ring styles (silent, vibration styles, permanent ring tunes, etc), and at the bottom you will see your downloaded tunes.  Simply press the "SELECT" button to make your new ring tune active! 

The following steps can be used to create a 120 * 160 GIF image file (*.gif) suitable for displaying on the Motorola T720 GSM/J2ME cellular phone, either as a background image for the main screen, or as an image in the image gallery. 

(1) Open any image file with Microsoft Paint or Adobe Photoshop or any other suitable image editing software; 
(2) Scale or crop the image to 120 pixels wide and 160 pixels high (i.e., a 120 * 160 pixel image); 
(3) Save the file in a GIF image format (*.gif); (Within Adobe Photoshop the way to do this is: File -> Export -> Gif89a) 

The image file must be in the GIF image file format so that the Motorola T720 cellular phone is able to decode and display the image.  If the image dimensions are exactly 120 * 160, then the image will fit perfectly on the screen of the Motorola T720 cellular phone; otherwise the image will have blank borders on two sides. 

Note: I successfully downloaded and displayed a *.gif image file which was 118 * 120 pixels, which is smaller than the screen size of 120 * 160.  I think the remaining part of the screen is filled with a color selected from the border of the image.  Perhaps the pixel color of the pixel in the upper left of the image is used as the color for the empty borders surrounding two sides of the image. 

The Motorola T720 cellular phone can display 4096 colors, which I think is encoded as 12-bit RGB (4-4-4).  Therefore, I think images with small color gradients that span large areas should be avoided, because the borders of these gradients will be very obvious and distracting to a person looking at the image.  Also, the GIF format itself is limited to only 256 different colors, so a person needs to be aware of this limitation, too.  In any case, it is always best to simply look at an image on the cellular phone to know whether or not the image is suitable for the cellular phone. 

I copied a GIF file named "si.mid" to the root directory of my Internet web server.  You can use software such as "Filezilla" to make the FTP transfer simple and convenient. 

For the Motorola T720 GSM/J2ME cellular phone, downloading a GIF image file begins with the "WebAccess" menu.  Selecting "Go To URL", followed by typing the URL of the GIF file, starts the download.  For example, I typed in the following URL:

If the download is successful, and if you are using a Motorola T720 cellular phone, you will be given the option of storing the file on your cellular phone.  When you decide to store the file, you are given the option of simply storing in your set of images or instead setting the file to be the current background (i.e., "wallpaper"). 

The following images summarize the process of downloading GIF image files for the Motorola T720 GSM/J2ME cellular phone.  Other J2ME enabled cellular phones, with other cellular phone service providers, are likely to have a similar download procedure.  If your cellular phone service provider is Verizon, then you are out of luck; none of this will work, and you should go and buy an "Android" phone to help destroy the "closed phone" market! 

(1) WebAccess: Go to the "Go to URL" item. 
(2) Enter URL: Type in the URL of a GIF image file (*.gif) on an Internet web site. 
(3) Connecting: Wait for the download to begin. (If you received the "406: Not Acceptable" error message, then the Internet web server did not assign an appropriate MIME type for GIF image files (*.gif)).) 
(4) Preview of downloaded image, with option to "STORE" (store) the image in the memory of the cellular phone; 
(5) Store Options: The GIF image can simply be stored, or it can be used to replace the current "wallpaper" (background of the main screen), or it can be used as a "screen saver" (i.e., an image which will appear when the cellular phone buttons have not been pressed for a specified amount of time). 
(6) Changed: Wallpaper [image name]: This is simply a notification that the "wallpaper" image has been changed. 
(7) The appearance of the the main screen of the cellular phone after the "wallpaper" (i.e., background) image has been changed.  The "Space Invaders" have conquered my cellular phone! 

To download an animated GIF image to use as a "screen saver" image on your cellular phone, simply follow the instructions in the previous section of this document for preparing and downloading an image. 

If the GIF image is an animating GIF, then the "screen saver" will show this animation. 

Simply set the image as the "screen saver" image after the image has been downloaded. 

The following animated GIF image can be used as an animated "screen saver" image on the Motorola T720 GSM/J2ME cellular phone. 

Sadly, the Motorola T720 cellular phone does not animate the "wallpaper" image.  It would have been very awesome to open the cellular phone and see an animating background on the main screen!  :^( 

You will only see an animated GIF appear on the Motorola T720 cellular phone when the phone enters "screen saver" mode, which might require 30 seconds or more to start.  (You can set this delay in one of the menus.)  The screen illumination is likely to turn off before the screen saver appears.  The "screen saver" does not appear during an active phone call.  Therefore, considering all of these facts, the "screen saver" feature of the Motorola T720 cellular phone is rather lame. 

This section of this document is unlikely to be useful to anyone, because this section describes settings for a very specific cellular phone (Motorola T720 GSM/J2ME) for a very specific cellular phone service provider (AT&T) for a very specific region (Southern California).  However, I include this information for historical interest. 

Also, there is a DNS setting for Java programs:

(1) Doing a "master reset" will set the WAP Port numbers to "9201", so these must be changed to "9203". 

(2) The secondary WAP IP and Port is set to the same IP and port as the primary WAP settings.  I was able to use "mMode" (i.e., go to any URL) with a totally blank secondary WAP setting, but I had "Line Type 1: Modem" at that time.  I don't know if setting it to "ISDN" makes it more likely that the secondary WAP settings will be used. 

(3) A "master reset" makes the "Timeout:" field "15 minutes".  Change the value to "2 minutes". 

(4) The "Name:", "Homepage:", and "GPRS APN:" fields all involve typing in letters and symbols manually. 

(5) The fields which are shown empty in the example above are really intended to not have any text entered.  The blanks are not accidental. 

Motorola has a software development kit SDK that includes an emulator capable of emulating many Motorola phones, including the T720.  You can get this SDK for free, and you do not need CodeWarrior to use the phone emulator included with the SDK, despite all the mention of CodeWarrior on the Motorola web site.  Also, in general I think you can get by without CodeWarrior or Motorola SDK even if you are doing professional development for the T720.

You must register with Motorola to even learn about their J2ME SDK, let alone download it. 

http://kb.motorola.metrowerks.com/motorola/developmentTools.do

There are some functions for playing "Compact MIDI" and even "*.wav" files.  Install and read the documentation to learn more details. 

Here's a comment I received in an e-mail:

Here's a quote from Motorola's web site regarding their SDK:

A friend of mine apparently had no problem downloading and using this toolkit -- which apparently gives you everything you need (JDK, MIDP, CLDC) and extra tools to make the JAD, etc.  I haven't tried it myself.  Here are other comments on this toolkit: 

Quote from a Slashdot posting: 

Quote from a Slashdot posting:

From a Nokia site:

From an e-mail message I received:

Here are some cool 7650 links:

There are two dominant software platforms for mobile devices: J2ME and BREW.  Many cellular phone carriers have decided to offer phones with J2ME support: AT&T, T-Mobile, and Sprint.  One major carrier has decided to only offer phones with BREW support: Verizon. 

A mobile device that supports J2ME can execute J2ME programs but cannot execute BREW programs.  A mobile device that supports BREW can execute BREW programs, but cannot execute J2ME programs. 

Manufacturers of mobile devices often offer several versions based on different wireless broadcast standards.  For example, Motorola offers two versions of the T720: GSM and CDMA.  Coincidentally, the GSM version of the T720 supports J2ME programs, and the CDMA version of the T720 supports BREW applications.  Thus, although wireless broadcast standards are not technically related to phone operating systems, circumstances in the marketplace have led to this accidental correlation. 

Here is a summary of what cellular phone service providers allow customers to do: 

AT&T offers the best customer and developer access to the cellular phone devices and to multimedia files on the Internet.  Evidently, AT&T has decided to focus on the business of transporting bytes through their networks, rather than attempting to be in the business of selling multimedia content. 

Verizon is the most oppressive cellular phone service provider of them all.  Their "Get It Now!" business model, which involves artificially restricting customer use of their own cellular phone devices to protect the business of selling multimedia content, has inspired many frustrated customers to terminate their contracts with Verizon or find ways to bypass the "Get It Now!" portal.  Just as movie theaters and sports arenas can charge extremely high prices for food because customers cannot easily access alternative sources of food in those circumstances (i.e., there is a lack of access to competition), Verizon can charge extremely high prices for access to multimedia files and software programs because customers cannot easily access alternative sources for multimedia files and software programs. 

BREW is "Binary Runtime Environment for Wireless", a proprietary software platform developed by QUALCOMM.  To learn more about BREW, visit the following Internet site: 

http://www.qualcomm.com/brew

The SDK can be downloaded from Qualcomm.  In 2002, the SDK could be used to build software using Microsoft Visual C++ 6.0, and the programs could be transferred to a cellular phone without a "test signature". 

All phones with Verizon contracts use BREW.  All software, images, and music must be transferred through Verizon's "Get It Now!" portal, and usually involves paying fees beyond the network bandwidth costs. 

J2ME is "Java 2 Platform, Micro Edition", a "highly optimized" Java runtime environment.  To learn more about J2ME, visit the following Internet site: 

http://java.sun.com/j2me

You might have already done some Java programming.  J2ME includes many of the Java classes used for desktop computer programs.  Obviously, any Java classes which are pure Java code, and do not depend on any hardware or operating system functions, can be compiled to execute within the context of any Java virtual machine. 

A person can create threads, sockets, graphics canvases, etc, very easily.  A person only needs to download a *.JAR file (and possibly a *.JAD file) to install an application on a cellular phone. 

Downloading the Java SDK is free.  The documentation for Java is thorough.  Millions of people have developed code for Java.  There are numerous Internet forums discussing various aspects of Java programming. 

In mere minutes of searching the Internet, I found hundreds of interesting software programs, and images, and sound effects, all for the Motorola T720 GSM/J2ME cellular phone -- and all files cost nothing to download. 

I am very excited by being able to take full advantage of the multimedia aspects of my property (i.e., my cellular phone) without having to pay my cellular phone service provider for anything more than the use of their cellular phone network. 

I have created software for both J2ME and BREW platforms, and, in my opinion, I think both technologies have their advantages and disadvantages, and both are quite capable of being used to create sophisticated programs very easily. 

However, a business that is interested in creating and selling software for cellular phones should start by considering a single question: "If I develop software, will I be allowed to sell it?" 

If a business develops software for the J2ME platform, then most cellular phone service providers allow customers to go to any Internet site and download any J2ME software, without imposing any cost beyond the cost of transferring bytes through the cellular phone network.  Thus, a software development business is certain to be able to have access to potential customers, and can make their own arrangements for collecting money from customers for any software purchases. 

If a business develops software for the BREW platform, then Verizon decides whether or not the software will be available for sale to customers.  Furthermore, Verizon will extract a large percentage of the selling price of the software for the privilege of being allowed to sell software through their exclusive portal. 

Here is my BREW and Verizon horror story: 

I had a unique idea for a software program for cellular phones at a time when cellular phones were starting to be able to execute BREW and J2ME programs.  I was very excited because I believed that I could create and publish a unique program for these platforms long before any competitors would be ready to create a similar product.  I was convinced that I might finally do something in my life that would make me wealthy.  So, I quit my job and started work on a BREW version of my software idea.  After six months of hard work, and no income, I was finished with my BREW program!  I was ready to submit it to Qualcomm for testing. 

That's when I made a horrifying discovery: Even if my program passed the quality assurance testing, Verizon would have to approve of the sale of my software -- and Verizon could disapprove of my software for any reason (beyond the obvious reasons of being offensive or in competition with some other aspect of Verizon's business).  I simply didn't imagine this possibility.  Everything I read about BREW development implied that the challenge was to pass quality assurance testing.  Nothing I read mentioned any need to have the software approved by cellular phone service providers.  I would not have been surprised to learn that cellular phone service providers might choose to not sell offensive or malicious programs, but such considerations seemed so unimportant for my particular project that I did not think about the more general concept that cellular phone service providers might choose to not sell ordinary software programs! 

One of my friends, who had already sold several video game programs through Verizon, asked a Verizon representative if Verizon would approve my software for sale on their network...  The Verizon representative said: "no", because there were a few other software programs in that broad genre already.  My software was a vocabulary tutor (with special consideration for the SAT and GRE standardized tests), but the Verizon representative said that the word game genre was already "crowded", despite the fact that there were fewer than 10 word-related programs total in the "Get It Now!" portal, and the other programs were very different (e.g., crossword puzzles, "Scrabble", "Boggle", etc).  My program was a technological achievement: It stored the definitions of 5000 vocabulary words, along with synonyms and antonyms, and word meaning groups (so that quiz questions would be challenging), in a program that was less than 1 MB.  My program would have been unique on the market for many months, and potentially for a couple of years. 

I was angry, depressed, and financially broke.  Six months of work was wasted, all because Verizon only wanted software that was certain to sell thousands of copies in their sales portal, and the Verizon representative didn't think my software had a high sales potential. 

Here is the most important lesson I learned from this bitter experience:  Check every part of a business plan before starting work.  (Ideally, every part of the business plan could be tested repeatedly, by actual execution of the various critical procedures, before and during the effort to create the product.) 

I should have checked whether or not there would be any likely obstacle to selling my software before I started to develop the software.  I would have discovered that Verizon could choose to not allow me to sell my software. 

I learned a second lesson:  Avoid situations in which other people have the ability to determine whether or not you have access to customers!