Push is a very interesting feature to add to your application. It can dramatically enhance the performance and experience of your application, and therefore the stickiness to the end-user. With all of its uses, there are also many things to take into consideration when adding push: How should the app notify the user when new data is available? What should the app do after the data arrives? How should the push data be stored? What is the easiest way to set up a server so I can easily test out pushing to my client application?
With these questions in mind, I set out to create a few fairly simplistic samples to demonstrate a few potential answers to the above questions.
Sample 1: Simple Push Server Sample
What does it do? This app is written in Cascades, meaning that you effectively have a server-side app capable of sending pushes running right on your BlackBerry 10 device. No need to jump to your computer whenever you want to send a push to your client-side application – simply launch this app and push away!
1) Push a message to a single recipient (specify the device PIN)
2) Retrieve all active and subscribed users (these are all persistently stored via QSettings)
3) Push to all known active subscribed users (pulled from QSettings)
4) Formats the push payload in a specific format that is expected in Sample 2 which includes 3 properties: priority of the push, a title for the message, a body for the message
Sample 2: Simple Push Client Sample
What does it do? This sample is the second half to Sample 1 – it receives push messages, expecting them in the format sent from Sample 1, and handles them differently based on the priority level set. The app also works with the application lifecycle, notifications engine and application cover to provide a fairly comprehensive implementation of push.
1) Receive and display push data
2) Store push data messages (stored via QSettings)
3) Integration with the cover of the application (seen when the application is minimized). The last received push message gets displayed along with a custom header graphic and a timestamp providing details to the user without the app needing to be opened.
4) Integration with the system notifications engine at 3 different levels depending on the priority of push message received:
a. Low: Set the splat on the application icon
b. Medium: Execute a Notification that will alert the user based on the system settings
c. High: Display a NotificationDialog that will contain the details of the push message
5) Work with the application lifecycle when a push arrives to close the application when a push arrives and the user’s attention is not immediately required, and the application is not in use:
a. Low and Medium: Close the application after handling the push message
b. High: Keep the application open; user engagement is expected
Note that best practices state that if the application is launched via a push invocation and does not need to remain open, then it should exit once the message is processed.
Both sample applications can be modified to work with your own push service account by just changing a few variables. Once that is completed, you will have a fully functioning client and server-side push implementation. In the client, the PushManager code handles the push messages received by the device while the CoverManager code handles all updates to the minimized application cover.
Ready to get started? The samples are hosted here: