In a previous blog post – Push and BlackBerry Dynamics – Stephen Leonard explained the various options you can use to push data to a BlackBerry Dynamics (BD) app. If you aren’t sure which technology to use to send your push, read through that article first. This blog post will explain some of the nuances of receiving push messages in a BD application, regardless of which push technology you use.
Receiving a Push Message
When a non-BlackBerry Dynamics application receives a push, the operating system notifies the application and delivers the payload for the application to process. The same scenario also applies to BD applications when they are running. But recall when a user starts a BD application, they need to unlock the application using a password (or other method). Unlocking the application allows the encrypted application container to be utilized. So, what happens when a push arrives and the container is locked?
Receiving a Push Message in a Locked Container
If a push message arrives while the container is locked, the application is unable to be started by the OS and will be unable to act on the push message until the user unlocks the container. This means the user must perform an action to unlock the container – such as entering their password – before the application can act on the push message. For many applications, this delay may not impact the user experience. The application can process the push message when the user unlocks it and display the data to the user. But what about applications that use push to receive timely updates that need to be processed immediately? These applications may require the BlackBerry UEM administrator to select the “No Password” policy for the app.
Receiving a Push Message with the “No Password” Policy
Version 3.2 of the BlackBerry Dynamics SDK introduced a new feature called No Password Policy. This removes the requirement that the user set a password or other mechanism such as fingerprint scan to unlock an application. The No Password Policy can be assigned on a per application basis, so one application installed by a user may have this policy while another application on the same user’s device does not. Since no user action is required to start the application, the OS can start the app, allowing the app to process the push message when it arrives. In this scenario, the application will behave like non BD applications that receive push messages.
Account for Both Scenarios
The user experience of your BlackBerry Dynamics application should take both scenarios into account. You may recommend administrators that deploy your applications use the No Password Policy. However, some may choose not to, so you’ll need to be ready to handle the scenario where your application cannot process the push message as soon as it arrives.
