UltraLiteJ BlackBerry Connectivity
Recently, I struggled with a nasty device operating system bug which caused me to delve deeply into the various connectivity paths available to application developers using UltraLiteJ on BlackBerry devices. Although I knew most of the details already, I realized that this knowledge may not be universal, and since I don’t hate my users (quite the contrary), I figured I would post a summary of the options, and save you some time interpreting the Research In Motion (RIM) white papers.
To those of you who want the final word on this topic, download http://na.blackberry.com/eng/developers/resources/Network_Transports_tutorial.pdf from RIM.
So here goes…
UltraLiteJ on a BlackBerry device can communicate to a MobiLink Synchronization Server through many different paths. RIM really only considers two (BES and BIS) to be first class options while the others are last resort.
- The BES path. This is the preferred route. It applies only to devices that are paired with a BlackBerry Enterprise Server (BES) and requires the BES to have MDS service enabled. With this networking option, connectivity gets proxied through the MDS server attached to the BES. This option is carrier independent (works when roaming). The bonus of this path is that if the device detects a Wi-Fi route to the BES, it will use Wi-Fi instead of the cellular network and whether it uses the cell network or Wi-Fi, all communication between the device and the BES are encrypted.For UltraLiteJ users, you can ensure you are using the BES path by using:
mySyncParms.getStreamParms().setURLSuffix( “;deviceside=false” );
If you are using a relay server, your URL suffix might look like this:
- The BIS path. This is the next best thing. When the device is not paired with the BES, devices can communicate through the BlackBerry Internet Service (BIS – which is essentially a MDS/BES hosted by RIM on the carrier’s behalf). Like the BES path, this path works when roaming and will route through Wi-Fi if it is available. Unlike the BES path, communication is not encrypted (use HTTPS to secure the synchronization stream to the MobiLink server) and if you need to access servers behind a corporate firewall, you need to add a hole in your firewall, use some tunneling technology from a public server to the firewalled server, or use the Sybase relay server (easiest option). This network path requires you to be a RIM Partner and requires you to apply for permission to use it for each application.
- The Direct TCP path. This option uses a publicly available IP gateway accessed from the cellular network. It may require you to specify gateway information in one of the device option screens. It will not attempt to route through Wi-Fi and communication is not encrypted (again use HTTPS to secure if needed). UltraLiteJ user should add “;deviceside=true” to the URL suffix:
mySyncParms.getStreamParms().setURLSuffix( “;deviceside=true” );
- The Direct Wi-Fi path. RIM literature usually considers this as part of the Direct TCP path. To force Wi-Fi use instead of the cellular network, add “;interface=wifi” to the URL. UltraLiteJ user should add “;deviceside=true” to the URL suffix:
mySyncParms.getStreamParms().setURLSuffix( “;deviceside=true;interface=wifi” );
- The WAP 2.0 path. Devices with OS 4.2.0 or greater can connect through a cellular carrier’s WAP 2.0 gateway. Applications must look up the Service Book record, if any, for the WAP 2.0 gateway to retrieve the Connection UID (sample code is provided in the RIM White Paper under the section Wireless service provider WAP 2.0 gateway) and then set the UltraLiteJ URL suffix appropriately:
mySyncParms.getStreamParms().setURLSuffix( “;ConnectionUID=” + uid );
I’m not sure how portable this is – that is, if roaming will the service books get updated to find the new gateway? Exercise left to the reader
- The WAP 1.x path. This is the least preferred path according to RIM and should only be used in third world countries and old devices. An application developer would need to look up the APN information for each carrier they intend to use, then create the appropriate URL suffix. You could borrow some code (RIM won’t mind, they even recommend that you use it) from RIM’s Network Diagnostic Tool to use the service books to try to identify what carrier you are on but the gateway parameters would still have to be hardcoded in the application for each supported carrier. Below is a string for Rogers (for others search for WAP Gateway APN” or see http://www.blackberryfaq.com/index.php/Carrier_specific_APN/TCP_settings):
A complete list of WAP 1.x parameters is available in the RIM White Paper.
Be explicit! If using BES, add the “;deviceside=false” string to the URL suffix. If use Direct TCP, use the “;deviceside=true”. The default behaviour (yes I’m Canadian so I spell it with a “u”) is different whether you are on an IDENT network or not. Always better to be clear what you want (if just for the security aspect).
Make your life simple! Use BES or BIS – you can join at the base level for free and then apply for permission to use BIS transport. If you need help, contact Tom Slee – he will put you in contact with the right person at RIM and he would love to know how you are using UltraLiteJ so we can make it better.
This last point (let us know what you are doing) will probably be a subject of a separate post