Re: OS 10.2.0.424: The app is unable to receive a BES push message once the work space is locked with a password.

sylvainsaintlaurent wrote:Yes, the Push works when the "consumer space" has a password.

It's only when the "work space" has a password that the Push workflow is "blocked" (or broken).

Garett, we can confirm this too. If you remove the workspace password, but add a Device password, then the Push is delivered properly even when the device is password-locked. It's only the locking from a workspace password which inhibits the regular Push. That gives a workaround that may be acceptable in some organizations.

Looking forward to confirmation from BlackBerry, and an ETA for the fix. I hope this will be considered critical enough to make it into the release for 10.2.1.

If switch to headless then you can also have your app listen for the STARTED trigger to register (create a channel) when the app is first installed rather than requiring the user to open the app before pushes can be received.

Re: OS 10.2.0.424: The app is unable to receive a BES push message once the work space is locked with a password.

Are you saying that using headless (I assume _sys_headless_nostop is required, and therefore special signing permissions) will magically bypass the issue, and the pushes will be sent through even when the workspace is locked?

Does the Push have to go to the service, or would it be sufficient to have a "dummy" service which actually did nothing itself, and simply let the UI app carry on as before? If true, this would be a pretty trivial addition to an app.

Am I wrong about headless_nostop being required? I thought that was the only way to hear STARTED, but I just realized you might be able to get that (at startup or just after installation) and the service would be invoked, but allowed to run for only 20s or less as with other non-nostop services. Is that actually how it works?

Re: OS 10.2.0.424: The app is unable to receive a BES push message once the work space is locked with a password.

One reason I'm trying to clarify the headless_nostop question is because apparently that may not work properly under all 10.2 in the wild, which is why they're planning to reject apps in BlackBerry World that ask for that permission prior to 10.2.1.

If we actually do need nostop here, how can we find out what the issue is with it not working on certain releases? (Or can anyone confirm that the 10.2 released on Bell and Rogers will in fact work perfectly well with nostop even now?)

Re: OS 10.2.0.424: The app is unable to receive a BES push message once the work space is locked with a password.

Oh nice. So the issue of Push apps not registering for launch until the user runs them the first time post-installation is effectively gone, provided you restructure the application to use a headless service as the Push recipient (and provided you are willing to have 10.2 as the minimum platform version).

Re: OS 10.2.0.424: The app is unable to receive a BES push message once the work space is locked with a password.

The workaround with the “headless app” is a costly option. I mean, since it’s a new feature, I’ll have to invest in several weeks of testing before releasing a proven solution to my clients. By then, if my market analysis is right, BB will have released the patch.

The workaround with the “headless app” is a costly option. I mean, since it’s a new feature, I’ll have to invest in several weeks of testing before releasing a proven solution to my clients. By then, if my market analysis is right, BB will have released the patch.

SSL

The root cause is still being investigated, so a fix should not be expected anytime soon.

The headless app approach is a bit more complex but provides a much better user experience. I believe you are already engaged with our internal support teams who will be able to help make the code change as painless as possible.