Thank you for visiting the BlackBerry Support Community Forums.
BlackBerry will be closing the BlackBerry Support Community Forums Device Forums on April 1st (Developers, see below)
BlackBerry remains committed to providing excellent customer support to our customers. We are delighted to direct you to the CrackBerry Forums, a well-established and thorough support channel, for continued BlackBerry support. Please visit http://forums.crackberry.com or http://crackberry.com/ask. You can also continue to visit BlackBerry Support or the BlackBerry Knowledge Base for official support options available for your BlackBerry Smartphone.
"When we launched CrackBerry.com 10 years ago, we set out to make it a fun and useful destination where BlackBerry Smartphone owners could share their excitement and learn to unleash the full potential of their BlackBerry. A decade later, the CrackBerry community is as active and passionate as ever and I know our knowledgeable members and volunteers will be excited to welcome and assist more BlackBerry owners with their questions."
- Kevin Michaluk, Founder, CrackBerry.com
Developers, for more information about the BlackBerry Developer Community please review Join the Conversation on the BlackBerry Developer Community Forums found on Inside BlackBerry.
08-21-2013 05:43 PM
I'm fairly new to Push stuff so this may be covered elsewhere. I didn't find anything by searching the forums.
When sending the push, the PAP <push-message> contains a push-id attribute. This seems to be an arbitrary string that I can specify.
When receiving a push, the PushPayload instance has an id() which is also a string, documented as "Returns the push identifier.". It appears it may be set by the system and unrelated to anything in the push itself, and so far appears to be set to "<APPID>_<some-integer>".
Is there any relationship between these?
What's the purpose of the push-id attribute? I'm doing "open loop" pushes through BIS with the basic Push service (not Push Plus), so my assumption is if I were using Push Plus or sending through BES10 it would be a useful identifier for querying the status of the push.
What's the purpose of the PushPayload id property, and if it's correct that the docs say it returns the "push identifier", then what is the push identifier and is there any connection to the push-id property above?
Thanks for any comments you may have.
Solved! Go to Solution.
08-23-2013 11:42 AM
What you're thinking makes sense however after getting a history lesson on the whole situation I found that this is essentially a bug. Really the push-id value should get passed in and be able to be read from the PushPayload#id field however the Push Server doesn't currently even pass this value down to the client. The push-id is useful today if you push through a BES or have Push Plus for querying the status of a push or canceling a push.
The field you read from PushPayload#id is actually generated automatically on the client if no Push ID is received, which is why it bears no resemblance to....anything useful.
There is a workaround! You can add this header to the push payload section of your server push 'Push-Message-ID', giving your payload a structure like:
I have tested this out and it works well, gives the expected value at the client side.
08-23-2013 03:10 PM
09-01-2013 03:09 PM
I've been slogging along to find out exactly what's crucial, what's redundant, what's optional and what's going to make the whole thing blow up with BIS push and both types of BES10 push. There are lots of different little things... this stuff is pretty brittle.
Wow though.. this one takes the cake:
That header is case-sensitive!!!
If you try to use Push-Message-Id or push-message-id, this feature won't work. Only the exact text "Push-Message-ID" works.
This is a straight bug, I think, since no such header should ever be case-sensitive, but consider this a warning for anyone else trying to use this feature.
09-03-2013 08:31 AM
My guess, the patch to allow this header to be passed through was not extensively tested so it could be added quickly. Once the Push ID of the actual push message (surrounding wrapper of the payload) is able to pass through it should fix this issue as well.
Definitely a facepalm-worthy moment