BlackBerry Development : Pushing to a Java Application,The Enterprise Push Process

1. Pushing to a Java Application

Data can be pushed to BlackBerry client applications written in Java. The major difference is that, instead of pushing an HTML page, the application pushes data in whatever format the destination application supports. The application can push HTML or XML data to the client application, but extra markup information would be delivered that likely wouldn’t be used in a Java application. Another difference is that, when pushing to a Java application, most of the push parameters used to support Browser Push are not used.

On the client side of this push option is a custom Java application that must be created and deployed to receive the pushed content. This application, the push listener or receiver, must perform the following functions:

• Register as a startup application on the BlackBerry so it will be ready to receive pushed content without the user’s intervention. This ensures the data is as accurate as possible because the application always listens for data while the device is on.

• Open a new thread for processing the data sent by the push application.

• Store the data locally (so it can be viewed by the mobile user).

• Render the data in a way easily processed by the user of the application.

You can have the user execute the program when needed, but that eliminates much of the benefit you get from push and requires coordination between the mobile user and the push process. If the push receiver isn’t running when the pushed data arrives, it will not be processed by the application.

Each push listener listens on a particular port on the destination device. Pushed content is targeted at a particular client application on the destination device through the port number the application is listening on. When the push request is sent to the server for the device, the push application includes the port number with the request so the device knows where to deliver the data once it arrives.

Use this push option if you want to send data to a device application and have the ability to work with the data even when the device is outside of network coverage (a wireless dead zone or on an airplane). Because the listener application has the ability to store the data locally and manipulate it any way it wants, this option provides more flexibility and potential for a better user experience.

For an example for how this could be used, imagine a sales representative who frequently enters areas where network coverage is not available. A backend push application might be used to push sales data, customer order information, special promotions, or even inventory numbers to a rich client running on the device. The sales rep can review information, take orders, inform the customer of delivery estimates—all without having network coverage. The sales rep can even take orders when there’s no network coverage; she can have inventory information on the device (albeit a bit dated) and any orders can be queued up, delivered, and validated later when the device goes back into coverage.

2. The Enterprise Push Process

The push process begins with an application running on a desktop or server somewhere. The application can be written in any development language that supports HTTP. The application can do its push any time it wants: randomly, on a schedule or on a trigger. Both the BES and MDS will be involved in getting the push content delivered to the device.

To push data to BlackBerry devices, the BlackBerry environment must be running BES for Exchange 3.5 or higher or BES for Domino version 2.2 or higher.

Additionally, the MDS Connection Service must be installed and enabled in the environment.

Figure 1 illustrates the push process, which consists of the following steps:

Figure 1. Enterprise push process

The destination device can be identified through the email address or PIN associated with the device. If PIN is used, there will need to be some way to keep the PIN list updated when users change devices. Because users frequently upgrade their devices, the most reliable way to identify users is via their email address.

If a push recipient is not within wireless coverage and, therefore, not able to receive the pushed data, MDS only holds onto the push request for a limited amount of time before discarding the request. When you build your push application, take advantage of the push feature X-RIM-PUSH-NOTIFYURL that allows your application to receive a notification when the pushed data arrives on the device. If the data is important, push the data again if you don’t receive confirmation that the data was delivered successfully.

A former colleague once said, “I’d recommend developers assume the data won’t get there so they are ready to handle situations where a device is out of coverage (battery dead, user on a flight, etc.).” There’s just no guarantee the data will be delivered to the device.

The pushed content can get to a device in different ways. In most cases, the pushed content is delivered to the device with the initial push request but, in other cases, it can be retrieved later. Table 1 summarizes the available options.

When sending a Browser Channel or a Browser Message, the push application can either include the web page in the push request or it can send the URL to the content and it will be retrieved when the channel or message is opened. In either case, the page must be stored on a web server before being pushed so it will be available if it is ever needed.

To push the page or content with the request, merely append the content to the end of the push request. To have the content retrieved later, the push application should leave the push request empty and include the URL pointing to the stored page in the Content-Location HTTP header.

For Cache Push and pushes to a custom Java listener application, the pushed content must be included with the request.