BlackBerry Application Data Push : How the Application Data Push Process Works

1. Why Push Is Important to BlackBerry Developers

BlackBerry users are familiar with and comfortable knowing that, when they need their data, it is available on their device. With third-party or enterprise applications, mobile users are used to opening an application, entering some information on screen, and clicking a button to make the device connect to one or more servers to retrieve the requested data.

For mobile users who need access to a large amount of data to work with locally (on the device), companies have used the BlackBerry Desktop application programming interface (API) to create the conduit device an application needs to synchronize data to a device connected to the network using the BlackBerry Desktop Manager. To perform a similar synchronization over the air, developers can use the BlackBerry Sync Server SDK to create a connector that synchronizes data with a device application through the Synchronization Service on the BES.

The game-changing feature of the BlackBerry platform is the ability the BES has to push application data to any device application. For a mobile application, instead of having a user open an application and request the data or building the application so it schedules a periodic pull of data (even when new data might not be available) from a server, the application receives its data by having it pushed directly to the application when it becomes available.

Both BlackBerry application types (Browser and Java) can receive data via push.

The ability to push data directly to BlackBerry applications has many dramatic and powerful effects:

• Data can be sent to devices only when there is new data available, rather than requiring that the user check for new data or having the application pull data on a schedule.

• Data can be sent to the device off-hours, on a schedule maintained by the server application or even configured by the user. This allows a server to distribute the load over time and, therefore, eliminates most peak loads on an application server and BES. By sending the data off-hours, there is no disruption of the other tasks the user might be performing on the device.

• Because the data is only sent when there’s new data to send, the device is not connecting to the server repeatedly looking for new data. This reduces the amount of data the device transmits, receives, and processes.

• Because the device does less work (sending less data across the network), a user gets greater life out of a battery charge.

There is no reason that an application can’t also request data on demand when the users want it. In this case, push can populate background information or data that the application knows the mobile user needs. The application can still request additional information when the data it needs is not on the device.

2. How the Application Data Push Process Works

Although each push option works in a slightly different manner, Figure 1 shows the data push process at a high level.

Figure 1. BlackBerry application data push process

To push data to a BlackBerry application, the following steps are performed:

If the mobile user is out of coverage, the data might still be delivered when the device reappears, as long as it is within certain defined time limits.The BlackBerry infrastructure queues requests for a limited amount of time and delivers them when the device returns to coverage. When building a push application, developers must take into account that the device might not be available when the push is sent. The push request can be set up so the push application is notified when the data arrives on the device, and the push application can push the data again if the notification is not received within an expected amount of time.

3. Common Questions About Push

The concept of true application data push is unique to the BlackBerry platform; it’s not a common capability found on mobile devices. When many developers are first exposed to the BlackBerry application data push, some common questions seem to pop up every time:

Where does the push application run?

The push application can run anywhere.

Regardless of whether you’re pushing to internal or external users, the only requirements are that the system running the push application has access to the data it needs to send and that it has the ability to communicate over the network (via HTTP) with the server that is processing the push request (the BES or the RIM Push Infrastructure). The application can run on a desktop computer sitting under a developer’s desk, or it can run on an application server sitting in a corporate data center. The push application can, although it’s not recommended, run on a BlackBerry, Windows Mobile device, or even an iPhone.

For enterprise push applications, the push application also should not be installed on the BES. It sends data to the BES, but it should not be running on the BES or servers hosting any components of the BES or MDS.

What programming languages can I use to write push applications?

Any development language can be used.

Push applications can be written in any computer language, as long as the language supports the technologies required for push. As you’ll see later, the only requirement for a push application is that it is able to communicate with a server via HTTP. There are push applications deployed that are written in PHP, ASP.NET, Python, Java, Visual Basic, C#, and even Delphi.

When should the data be sent to target devices?

Anytime that is appropriate for the target audience.

It’s up to the developer writing the push application to decide when the pushed data should be sent to target devices. Data is typically sent based on a schedule or trigger defined by the business requirements for the application. The data can be sent on schedule; every morning at 7:00 A.M., for example. The data can be sent on a trigger—data can be sent whenever specific changes are made to the data or a specific event occurs.

All that matters is that the developer is careful about how often the data is pushed. Although push typically reduces the amount of data sent to/from a device by removing the need for the application to periodically check for updates, you can still reduce battery performance or increase data plan usage if data is pushed more often than needed. Send the data only when it’s important to send it and try to batch updates to minimize how often data is sent.

If the application is pushing data to a Java application running on the destination device, the push application can just push new or updated data rather than the full data set with every push. The client-side application or application user can be responsible for purging older data.

Can pushed content be customized per destination user or group of users?

Yes. The push application is created based on the needs of the application user. Whether the pushed data is customized for every recipient or the same data is sent to everyone, it is a decision the developer makes when building the push application.

If the information is general and applicable to an entire team (sales promotions, business unit performance against a quota, industry news), send the same data to everyone. If the data being sent is relevant to a single user or group of users, the push application must build a set of data for them and push it before building the data for the next set of users.

4. Pushing to Internal Versus External Users

Internal recipients are BlackBerry users whose device has been activated against a corporate BES. The devices have a BlackBerry Enterprise data plan from their wireless carrier, get corporate email and other PIM data synchronized wirelessly via the BES and have access to internal systems via MDS.

Until recently, data push was only available to internal recipients. RIM recently released products that support pushing data to external recipients (either personal or consumer devices) through Web Signals and the Java Push APIs.

External recipients refer to users whose BlackBerry devices are not under the direct control of the organization pushing the data. They might be BES connected users, but they would be connected to a BES located inside some other corporation’s firewall. The external user definition also covers mobile, BlackBerry-carrying users who might only use their device to access personal email accounts and web browsing through the BlackBerry Internet Service (BIS).