Deploy Your J2ME Application on a Sprint Phone : Page 3

Web server configuration and caching problems are just two of the obstacles you'll need to overcome when you deploy Java applications on cell phones. This article provides the workarounds and solutions you'll need to overcome these bumps.

by Robert Cadena

Jan 31, 2003

Page 3 of 4

Caching Problems
Since OTA Provisioning requests occur over HTTP on the Sprint network. The Sprint Gateway's caching poses a problem when you try to frequently update your content during testing. When I updated a piece of code in my MIDlet and placed the new JAR into the Web server, I noticed that a new request from the handset for the JAD did not return the updated JAR to the handset. In fact, checking the server logs, I noticed that no new requests had been made for the files.

The solutions I propose are adding extra HTTP headers that tell the Gateway that the file should not be cached and creating a workaround that simply adds a random query string to the URL to trick it into thinking it needs to make a new request for entirely different content.

Using HTTP Headers
There are two ways to specify that certain groups of files or a particular file should not be cached by the gateway:

Specify it in the HTTP header via something like PHP or Perl when outputting a file.
Configure the Web server to mark certain MIME types as non-cacheable.

To mark a file as non-cacheable in PHP, add the following line of code somewhere in the file prior to outputting anything else:


<?
	header("Cache-Control: no-cache");
?>
<html>  </html>

For testing purposes on the development server, I've configured the server to specify that files with the extensions .jar and .jad should never be cached. This allows me to mark a group of files as non-cacheable and frees me from having to use the first method described above, which taints my code. Again, I am using the Apache httpd server. Configuring your server probably will be different, so consult the documentation.

In your httpd.conf file, uncomment the lines of code that look like this:

LoadModule expires_module modules/mod_expires.so . . . AddModule mod_expires.c

This will activate the expiration module. If you haven't added the appropriate MIME types for .jar and .jad file extensions as I specified previously, then do so now. Next, add the following three lines at the end of the file to mark .jar and .jad as non-cacheable:

ExpiresActive On ExpiresByType text/vnd.sun.j2me.app-descriptor "access plus 1 second" ExpiresByType application/java-archive "access plus 1 second"

This tells the proxy or browser that files of type .jar and .jad expire one second after they've been accessed. Don't use this for deployment purposes, however; there are good reasons for the gateway caching.

Adding a Random Query String
If you have absolutely no access to either your server's configuration file or a processing language like PHP or Perl, you can trick the gateway into thinking that a new request you make is for a completely different file. Just append a random query string to the JAR or JAD's URL.

Using my fictitious URL for the SimpleMidlet, the change will look like this:


HTTP://webserver/SimpleMidlet.jad?r=[some random number]

This ensures that the gateway will request the file anew from your server.

This works only if you need to download a new version of the JAD. To download a new version of the JAR, you'll have to modify the MIDlet-Jar-URL using the same scheme as you did for the JAD. The new entry will look something like this:


MIDlet-Jar-URL: HTTP://webserver/SimpleMidlet.jar?r=[some random number]

A word of caution: you might run into trouble with tools like KToolBar if you add too many pre-processing directives to the JAD. Keep them to a minimum.

Download The Code for this Article

« Previous Page 1 234 Next Page »

0 Comments (click to add your comment)

Comment and Contribute