Different ways to make an HTTP or socket connection in BlacBerry

>

Procedure

The BlackBerry Java Development Environment (BlackBerry JDE) application programming interface (API) reference includes five ways to make a Hypertext Transfer Protocol (HTTP) or socket connection.

BlackBerry Enterprise Server using the BlackBerry Mobile Data System (BlackBerry MDS) Connection
BlackBerry Internet Service
Direct Transmission Control Protocol (TCP) stack
Wi-Fi network
Wireless service provider Wireless Application Protocol (WAP) 1.x gateway
Wireless service provider WAP 2.0 gateway

BlackBerry Enterprise Server using the BlackBerry MDS Connection Service

The BlackBerry MDS Services are included in the BlackBerry Enterprise Server software and handle all browser or connection requests and route the requests accordingly. Data flowing between the BlackBerry smartphone and BlackBerry Enterprise Server is encrypted with Advanced Encryption Standard (AES) or Triple Data Encryption Standard (Triple DES). A connection made through BlackBerry MDS provides seamless roaming across wireless service providers that support BlackBerry smartphone service.

By default, all BlackBerry smartphone models, except the BlackBerry 6500 Series and the BlackBerry 7500 Series, use BlackBerry MDS. The following is an example:

(HttpConnection) Connector.open ("http://www.testserver.com");

To make sure that an application uses BlackBerry MDS Services as its connection pathway on all BlackBerry smartphone models, append the deviceside=false parameter to the end of the URL. The following URL is an example:

(HttpConnection)Connector.open ("http://www.testserver.com;"+
"deviceside=false");

BlackBerry Internet Service

Applications are also able to make connections through the BlackBerry Internet Service. This connection route is available to third-party developers and is subject to an application approval process. Data flowing over this connection is not encrypted. Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) or Secure Sockets Layer (SSL) can be used to secure a connection. A BlackBerry Internet Service connection provides seamless roaming across wireless service providers that support BlackBerry smartphone service. Currently, this transport is only available to BlackBerry Alliance Program members, subject to approval. Information about the BlackBerry Alliance Program can be found at the following web site: http://na.blackberry.com/eng/partners/alliance.jsp

Direct TCP stack

For BlackBerry smartphones running BlackBerry Device Software 3.8 and later, a direct TCP stack is included, which allows a direct TCP connection to be opened from the BlackBerry smartphone without using BlackBerry MDS.

For BlackBerry smartphones operating on the iDEN network, including the BlackBerry 6510 smartphone, BlackBerry 7510 smartphone, BlackBerry 7520 smartphone, and BlackBerry 7100i smartphone, a direct TCP connection is used if the deviceside parameter is not present. BlackBerry smartphones not operating on the iDEN network use BlackBerry MDS as the default connection if the deviceside parameter is not specified.

If BlackBerry MDS is not available at the time of connection, the BlackBerry smartphone reverts to direct TCP.

For the BlackBerry smartphone to use direct TCP, the user name and password fields must be completed under Options > TCP or supplied by the application. this article explains how to specify access point name (APN) information in a direct TCP connection.

To override the default behaviour of the default connection on the BlackBerry smartphone, the deviceside parameter must be included within the connection statement. The following is an example:

(StreamConnection)Connector.open("socket://testserver:600;"+
"deviceside=true");

Wi-Fi network

A Wi-Fi enabled BlackBerry smartphone is able to connect over a Wi-Fi network to the BlackBerry Infrastructure. The BlackBerry Infrastructure exists between a BlackBerry smartphone and the BlackBerry Internet Service or BlackBerry Enterprise Server, allowing for connectivity to these components. A BlackBerry smartphone can also be configured to connect directly to a BlackBerry Enterprise Server using a virtual private network (VPN) connection over a Wi-Fi network. What this means is that applications that are making a connection through a BlackBerry Enterprise Server or BlackBerry Internet Service (options 1 and 2 ) can have their connections automatically routed through a Wi-Fi connection without any special logic required in the application. Applications can also make a connection over a Wi-Fi network directly to their destination server, bypassing the BlackBerry Infrastructure, BlackBerry Enterprise Server and BlackBerry Internet Service. To specify that a connection must be made over a Wi-Fi network, the interface=wifi parameter is used. The following is an example:

(StreamConnection)Connector.open("socket://testserver:600;"+
"interface=wifi");

Wireless service provider WAP 1.x gateway

The connection string uses WAP parameters, which are hosted by a wireless network provider. Not all wireless service providers support connections through their WAP gateway. Contact the wireless network service to find out if support exists and to obtain a listing of their WAP gateway parameters.

The following is an HTTP connection over a WAP gateway:

(HttpConnection)Connector.open("http://wap.google.com;"+
"WAPGatewayIP=127.0.0.1;WAPGatewayAPN=carrier.com.gprs")

The WAPGatewayIP and WAPGatewayAPN values are required parameters. Each parameter specified must be separated by a semicolon. The following is a table of supported WAP parameters:

Parameter	Description
WapGatewayIP	IP address of the gateway.
WapGatewayAPN	APN for General Packet Radio Service (GPRS) networks only. For testing purposes, you can use rim.net.gprs
WapGatewayPort	Gateway port value. If port 9203 is specified, Wireless Transport Layer Security (WTLS) is used unless WapEnableWTLS=false is specified.
WapSourceIP	IP address of the source.
WapSourcePort	Source port value.
TunnelAuthUsername	User name for APN session, when Password Authentication Protocol (PAP) or Challenge Handshake Application Protocol (CHAP) authentication is used.
TunnelAuthPassword	Password for APN session, when PAP or CHAP authentication is used.
WapEnableWTLS	Explicitly turns on or turns off WTLS. If this parameter is not specified, WTLS is used by default for connections to port 9203.

Wireless service provider WAP 2.0 gateway

BlackBerry Device Software 4.2.0 and later includes the ability to connect through a WAP 2.0 gateway. This is done by locating the service record on the BlackBerry for the WAP 2.0 gateway and using its UID when making the connection. The following code sample demonstrates how this can be done.

 

ServiceBook sb = ServiceBook.getSB();
ServiceRecord[] records = sb.findRecordsByCid("WPTCP"); 
String uid = null; 
for(int i=0; i < records.length; i++) 
{
    //Search through all service records to find the 
    //valid non-Wi-Fi and non-MMS 
    //WAP 2.0 Gateway Service Record.
    if (records[i].isValid() && !records[i].isDisabled()) {
        if (records[i].getUid() != null && 

                 records[i].getUid().length() != 0) {
            if ((records[i].getUid().toLowerCase().indexOf("wifi")==-1) 

&& (records[i].getUid().toLowerCase().indexOf("mms")==-1)) {
                    uid = records[i].getUid(); 
                    break;
            }
        } 
    }
} 
if (uid != null) {
    //open a WAP 2 connection
    Connector.open(_url + ";ConnectionUID=" + uid);
} else {
    //Consider another transport or alternative action.
}

Mobile thick clients vs thin clients

For many application developers, the fastest, easiest way to introduce a mobile solution was to "chop down" an existing Web-based application. Users that had a device with a browser could then access the applications. However, because the resulting applications were not designed for the navigation capabilities of a mobile device or the smaller bandwidth, the user experience suffered. These problems can be solved by using a thick client instead of a thin client.

With a thin client, there is nothing running on the device except the presentation. All the content is on the host. The data, along with the rules to display it, are sent down and rendered on the local machine. Everything is done on the server; every request requires going back to the host. With a thick client, however, the presentation engine is on the local machine, which does the work.

The need for thick clients is driven by the complexity of the information and the presentation demanded by
mobile users. Mobile users, too, want robust applications and a good user experience. Years ago with the
PC, users went to a Web site and got straight HTML. PC users said, "That's not good enough." Then came
dynamic HTML, Java applets, Flash, and great plug-ins.

It depends on

• what application you want to build
• which audience you want to target
• Operating cost
• Billing and revenue models

Thin clients are good for:

• Displaying regularly changing information eg. news.
• Casual one-off browsing, where the user is unlikely to ever need to come back and benefit from having any sort of state remembered, and not being able to access any content is not a serious problem (due to lack of signal, etc).
• Very changeable data with simple display requirements that change unpredictably over time, with minimal data entry requirements.
• Situations where reliable network connections are guaranteed – either fast connections, or very small nuggets of content that can be found very quickly.

Thick clients are good for:

• Repeated user experiences – local secure caching can reduce data entry, always a significant pain point on mobile.
• Intelligent data delivery can reduce costly data overheads whilst providing faster responses for the user for known types of data set.
• High interactivity and improved user experiences with many potential data visualisation models and on-client validation (minimising round trip requirements to the server, which cost money and time).
• Improved branding around content, which only ever has to be downloaded once rather than at the start of ever session – handsets rarely dedicate persistent storage to browser caches so ever visit to a branded site reloads many Kbs of images, CSS etc.
• Real security, guaranteed – there are known issues with Wap security which can even affect Wap2 browsers running through legacy APNs.
• Offline access – content can be stored locally to browse even when there is no signal (eg. Tube maps), data entry can be performed when required and then submitted to a server asynchronously etc.
• Data roaming can be incredibly expensive so for content like travel guides designed to be read abroad, or interactive services for which Java can choose to use SMS instead of GPRS, there are big cost savings to be had.
• Precise optimal rendering of certain types of content, for example barcodes (used for ticketing etc) which would be useless if the handset decided to rescale them badly as can happen when displaying MMS messages or images in browsers.

First is the ability to do local processing and local data storage. With a thin client, modifying one item could require making several trips back to the host. And, because the bandwidth in the wireless world is so small, bringing pages down is a long, arduous task. A thick client, however, enables mobile users to work offline with the local data that is brought down; everything is done locally.

The advantage of a thick client's local processing ability can be seen when a user makes a mistake while entering data. With a thin client, the user would be prompted again, requiring another trip. With a thick client, you could use an "if" statement to determine if the information is correct before sending it to the host, which saves time.

How To - Use the preprocessor in BlackBerry JDE

RIM Application Program Compiler (RAPC) supports a few basic preprocessor directives. The directives can be used to take advantage of features available in later BlackBerry smartphones and builds without fragmenting into multiple code lines, or to make it easy to remove debug output for final versions.

The following directives are supported:

Enable the preprocessor
//#preprocess

If, else, end if block:
//#ifdef
…
//#else
…
//#endif

If is defined, then the code between #ifdef and else is executed; otherwise, #else to #endif is executed. The else section is not mandatory.

If not, else, end if block:
//#ifndef
…
//#else
…
//#endif

#ifndef is the opposite of #ifdef. If is not defined, the code is executed.

When using the BlackBerry JDE Plug-in for Eclipse or BlackBerry JDE 4.7 and later, you can set preprocessor defines in the Project Properties window, on the Compile tab as shown in the following image:

If the Preprocessor defines box is not present in Eclipse®, update the BlackBerry JDE Plug-in for Eclipse to the latest available version. If you have not configured Eclipse to use the BlackBerry JDE Plug-in for Eclipse update site, this can be accomplished by following the steps found at http://na.blackberry.com/eng/developers/javaappdev/javaeclipseplug.jsp.

To use the preprocessor in BlackBerry JDE prior to version 4.7, you must manually add it to the Java® development project (JDP) file. To do this, complete the following steps:

Open the JDP file with an editor.
Go to the line that starts with Options.
At the end of the line, add -define ;;…; as in the following example:
Options=-quiet -define=FOO;PREPROCESSOR
The -define statement is simply an argument passed to the RAPC. Therefore, you can use it with your own command line build scripts. This functionality has been present since RAPC version 4.0.
If you use the preprocessor, make sure at least one definition is defined, typically PREPROCESSOR, or it will not engage.

Check out AppJam: Only Apps >> Mobile Applications >> Demo of Mobile Apps >> Mobile Application Showcase event >> AppStores

Check out AppJam: Only Apps >> Mobile Applications >> Demo of Mobile Apps >> Mobile Application Showcase event >> AppStores