Uploading an App to the Handset
When I got my first Sprint handset, the LG 5350, I was eager to incorporate it into the testing pipeline. I assumed I would connect it with a USB cable (typical of most handsets), upload the application, and test. Unfortunately, Sprint controls handset access tightly. Like the Microsoft Xbox and Sega Game Cube gaming consoles, no hacking is allowed; only registered developers can gain access to the hardware.
Your only option is to follow Sprint's recommendations and download your application Over The Air (OTA). This simply means that you have to make your application's JAR and JAD files available on a Web server, where you can then "HTTP" your way to the URL where your JAD file resides. The browser will download your application into the Applications folder and test it. Sun Microsystems publishes the high-level OTA Provisioning guidelines on the J2ME portion of its site, and keeping up to date on this process is not only advantageous for development and testing purposes but also may provide you with interesting opportunities for commercial deployment, as you'll learn later.
This OTA procedure can be rather time consuming if the reception in your area is not great, and caching issues with the Sprint gateway can make it confusing and error prone. In the following sections, I share more details about the specific problems you will face and the workarounds I've established in my development processes to deal with these issues.
Trying an App on the Hardware
Place the .jar and .jad files in a place that is accessible via HTTP. For the purposes of this article, I use the fictitious URL: http://webserver/devx/SimpleMidlet.jad. You'll have to make a few configuration changes to the Web server that will serve your JAR and JAD files. This tutorial deals with Apache 1.3 Web server. Consult your particular server's documentation for proper instructions on how to do this.
If you access the Web server containing your JAR and JAD files with your handset, you may find that the JAD file is delivered to the phone as only a text file with its contents displayed as normal text. This indicates that your Web server needs to be configured.
You need to associate specific MIME types to the ".jar" and ".jad" extensions so that the Web server can tell the client which kind of content to expect. In apache, you add the following two lines to the httpd.conf configuration file:
AddType text/vnd.sun.j2me.app-descriptor .jad
AddType application/java-archive .jar
You then restart the server and point your handset to the URL where your .jad file resides. Your particular hardware will vary depending on how its download, confirmation, and installation process works, but most generally tend to follow the high-level process defined by the OTA Provisioning guidelines. On my LG 5350, once the download process is complete, it deposits the MIDlet into the generic Applications directory and prompts me to run the application.
The JAD File
As I mentioned earlier, two files are required for provisioning your application, the JAR and JAD. If you use a tool like KToolBar or Sun ONE to create a MIDlet, you'll notice that the JAD file is automatically created for you and your application's class files are packaged into a JAR along with a file titled manifest.mf. Both the manifest and the JAD files allow you to describe the application by specifying such things as the minimum requirements for running the application, how many MIDlets are part of the MIDlet suite, and any dependencies. Since a JAR file for a MIDlet suite contains information describing itself and might be quite large, the JAD file provides this information without requiring the user to download the entire JAR. This feature potentially saves the user a considerable amount of download time.
The .jad file is a simple text file with an attributes key, a colon, an optional space, and the value for that attribute. It looks like the following:
The optional and user-defined parameters I cover in this section include the following:
MIDlet-DescriptionA description of the MIDlet suite that will be shown to the user
MIDlet-IconAn icon that can be used to represent the MIDlet suite during installation and during use (The icon must be in PNG format.)
MIDlet-Info-URLA URL that contains further information about the suite (Based on your handset, it may be displayed to the user prior to the MIDlet installation.)
MIDlet-Install-NotifyA URL used to report the success or failure of the installation of your MIDlet on the user's hardware
Content-FolderThe name of the folder to which you want the AMS to download your application (If the folder does not exist, it will be created.)
Content-1-HandlerA parameter that tells the AMS to associate your application with a specific URI or MIME type
Many more optional parameters are described in the OTA Recommended Practices document.
You'll see that knowing this file's purpose and formatting will help you overcome some of the bumps you'll run into when provisioning.