HTTP Issues

Whether you're invoking web services or just scraping data from existing web pages, HTTP is the protocol you typically use for network communication. Here are some issues with HTTP communication on the BlackBerry platform.

J2ME HTTP Refresher

The BlackBerry platform is a J2ME platform, so the J2SE classes you would normally use for doing HTTP connections — HttpURLConnection and the like — are not available. The Generic Connection Framework (GCF) defined by the CLDC is what you use to open HTTP connections.

To make an HTTP connection, simply call the Connector.open method with a standard HTTP URL, as in this example:

import java.io.*;
import javax.microedition.io.*;

String url = "http://www.ericgiguere.com/index.html";
HttpConnection conn = null;
InputStream in = null;

try {
    conn = (HttpConnection) Connector.open( url );
    
    int rc = conn.getResponseCode();
    
    if( rc == HttpConnection.HTTP_OK ){
        in = conn.openInputStream();
        
        // process the page data here
    }
}
catch( IOException e ){
    // handle errors
}
finally {
    if( in != null ){
        try { in.close(); } catch( IOException e ){}
    }
    
    if( conn != null ){
        try { conn.close(); } catch( IOException e ){}
    }
}

The GCF is really quite simple to use. For more details, see my tech tip Making HTTP Connections with MIDP.

Avoid the Event Thread

Whatever you do, don't call Connector.open on the event thread. The programmer's guide mentions this, but it's easily missed. The symptom? On a real device, your application will hang for no apparent reason, even though it runs fine in the device simulator.

Each application has a single thread that is marked as the event thread, the thread that all user interface events are funneled to for processing. A call to Connector.open with an HTTP URL causes the system to block the calling thread and to ask the user to confirm that the application has permission to make the HTTP call. The confirmation is done via the event thread. If you block the event thread, the application hangs waiting for the event thread to unblock in order to display the message. Oops!

The easiest way around this is to always call Connector.open on a new thread. You'll be needing a different thread to read the data returned by the HTTP call anyhow, so just put all the connection stuff in a separate thread. It just complicates your life a bit because you have more state to maintain across threads.

Blackberry Enterprise Server Limitations

By default, the BlackBerry Enterprise Server (BES) limits the response size of a single HTTP response to 128K. If you try to fetch anything bigger your application will receive a 413 (Request Entity Too Large) response code. To get around this you must use the BES management console to change the value of the Maximum number of kilobytes per connection field to a higher value, up to 1024K.

Note that this limit also applies to the MDS simulator, so you'll need to change the simulator's settings as well. Edit the mds\config\rimpublic.property file in your JDE installation directory and change the value of the IPPP.connection.MaxNumberOfKBytesToSend property to match the BES setting and then restart the simulator.

Using a WAP Gateway

On an unpaired device (a device that is not associated with a BlackBerry Enterprise Server) your HTTP calls are made using the carrier's WAP gateway. To use the WAP gateway you must suffix carrier-specific gateway information to the HTTP URLs. For example, here's what you use on the Rogers network in Canada:

http://path;WapGatewayIP=208.200.67.150;
WapGatewayPort=9201;WapGatewayAPN=blackberry.net

You can also use this syntax on a paired device to force connections to go through a WAP gateway, but normally there's no need since the BES is an HTTP proxy.