ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

The Realities of Deploying Wireless J2ME Solutions Over Unreliable Networks

by Mike Wilson
03/27/2002

The major players in the handheld market have put their weight behind Java (Nokia, Ericsson, Motorola), the 2.5-3.0G networks are coming online, and you've been sweating over a MIDlet for the past few weeks, rearing to get it up and running on the latest device.

It should work -- after all, it works well on your desktop emulator connecting to your back-end service. Two weeks before launch you get a MIDP device and are hit by some real-world wireless realities:

  • The device's processor is a lot slower than your workstation.
  • The data request/response, in real life, is much slower than on the fixed-wire LAN prototype.
  • The application is too large to fit on the device, although it was fine for the emulator.
  • The battery drain caused by network communication when using your MIDlet is excessive.
  • The wireless network keeps disconnecting your device; this is a "normal" occurence under wireless conditions.
  • The bandwidth fluctuation is very high, causing your request/response-driven MIDlet to be intermittently non-responsive.

You have no control over the 17MHz processor on the device. You can optimize your code and load it on the device, but what can you do about the network? The one thing you have not possibly taken into account -- a fundamental requirement of applications operating in a wireless environment -- is to have an optimized reliable communication model over unreliable network conditions.

This is clearly an analysis and design flaw. The Internet is fast and reliable, in comparison to a wireless environment. GPRS network operators say they will achieve as little as 9-20 Kbs (speeds similar to the Mobitex PALM VII Network in the U.S.), even using all eight channels for data. Add to that the complexity of shadows and ad hoc disconnects, and obviously you have a totally different set of challenges to overcome. WAP was a good idea that worked well in emulator mode, but when used away from the desktop on a wireless device, the user experience was sub-optimal, to say the least.

Inflated market expectations of WAP -- expectations of having the full capabilities of the Internet on wireless devices -- fell well short of reality, impeding market adoption rates. Unfortunately, J2ME is on track to take the same path.

J2ME HTTP

A large majority of MIDlets work under the client/server, request/response model over HTTP, relying on back-end services to do all of the heavy lifting. This leaves the MIDlet thin and simple, a requirement mandated by the limitations of the device and network. Programmers can take for granted that HTTP will be available on MIDP devices, since it is part of the related specification. We will first take a look at a simple example using this technology.

Wireless Java

Related Reading

Wireless Java
Help for New J2ME Developers
By Qusay Mahmoud

Client J2ME Using HTTP

In the following example we use a MIDlet POSTing to a servlet over HTTP, running under a Tomcat server. Note: You need to remember to set the MIME types as in Example 1 below, and then to handle the request/response model.

Example 1. Setting the MIME Type for, and POSTing within, a MIDlet

 1 // Callback for making the HTTP connection.
 2 public void prepareRequest( String originalURL, HttpConnection conn ) throws IOException{
 3   
 4   conn.setRequestMethod(HttpConnection.POST );
 5   conn.setRequestProperty("User-Agent", "Profile/MIDP-1.0 Configuration/CLDC-1.0" );
 6   conn.setRequestProperty("Content-Language", "en-US" );
 7   conn.setRequestProperty("Accept", "application/octet-stream" );
 8   conn.setRequestProperty("Connection", "close" );
 9   conn.setRequestProperty("Content-Length", Integer.toString( data.length ) );
10   OutputStream os = conn.openOutputStream();
11   os.write( data );
12   os.close();
13  }
14 
15  ...........................
16  //HTTP Connection
17  try {
18    conn = HttpConnectionHelper.connect( url, this );
19    display("Connecting to the server..." );
20    int rc = conn.getResponseCode();
21    if( rc == HttpConnection.HTTP_OK ){
22      StringBuffer text = new StringBuffer();
23   ...........
24  } catch( IOException e ){ }
25 

Example 2. Servlet  processing

    1 public class SampleServer extends HttpServlet { 
    2 
    3 public void doPost( HttpServletRequest request, HttpServletResponse response ) 
             throws IOException,   ServletException { 
    4 
    5  // Get the input stream and read the data... 
    6  ServletInputStream in = request.getInputStream(); 
    7  DataInputStream    din =  new DataInputStream( in ); 
    8  String text = din.readUTF(); 
    9  din.close(); 
   10 
   11  // Do something with the data. In this case make the string upper case and split it into tokens. 
   12 
   13  text = text.toUpperCase(); 
   14  StringTokenizer tok = new StringTokenizer(text ); 
   15 ........ 
   16 }

Pages: 1, 2

Next Pagearrow