02-25-2010 01:35 PM
I was hoping somebody could clarify some points on push technology. I have a working push system set up with an app and although it is sufficient for my needs right now some things do not seem to be working as advertised.
I am using RIM push and trying to make use of reliable push. I am adding 3 headers (as below) to the push to try to get application level notification and the coverage status of a device.
Problem number one is that I seem to be getting transport level notification (the default). In fact I don't even need the push reliability header at all and I still get the same type of notification with just the notifyurl. Regardless if I have the app installed or not installed, as long as I have coverage the notification my server side app receives is a 200 (success). My understanding of this is my app should only receive a 200 if the listening mobile app is receiving and uses the appropriate code to indicate that it has been received.
Problem number two is that the BES seems to think that my device is always in coverage with regards to how it responds to the x-rim-push-use-coverage header. If I turn off the coverage on my device and leave it off for a short while in the hopes that the BES picks up the change then do a push the notification still comes back with HTTP_X_RIM_DEVICE_STATE=true. My understanding of this is that the push notification should return as soon as the BES can determine that the device is not in coverage (rather than waiting the full 10 minutes in the push queue) with a 400 (unsuccessful push) and HTTP_X_RIM_DEVICE_STATE=false. Further, that the BES should again respond with another notification when the user regains coverage.
Am I misinterpreting the use of this functionality? It is my hope that the application level reliability will allow me to determine if a user has uninstalled the app or otherwise had it bomb and that the device state information will allow me to queue up pushes for users who are not in coverage and then send them once they are.
Thanks in advance,
02-25-2010 04:30 PM
If I'm not mistaken you can only get application-level reliability if the BlackBerry Browser makes at least one HTTP request via the MDS (which will then tell the MDS whether the OS is good enough to support this reliability mode). May be the new push APIs introduced in the 5.0 OS solve this issue somehow...
02-25-2010 09:05 PM
I had read that about using MDS first but I just assumed that my app making a web service call first would be the equivalent of the browser request. I will test again after making sure I use the browser first accessing something inside the intranet. I am pretty sure I saw somewhere that the next BES won't require the first MDS use.
Now if I can just figure out the other question I will be all set.
02-26-2010 08:49 AM
Here's a stale thread where the same issue is described (coverage-based push not working as expected): http://supportforums.blackberry.com/t5/Web-Develop
02-26-2010 12:23 PM
Thanks, don't know how I missed that thread.
Mark's response seems to suggest that the in coverage check works more like a ping to decide if the push should be sent in the first place whereas my reading in the book I have suggests that it is a header of the push itself that will inform the push app that the device is out of coverage and the push failed and then send another notification when the device is back in coverage so the push can be re-initiated.
The final poster seemed to have the same results I did, although the article link is still dead so while confirmation of the behaviour is good that still leaves the question.
02-26-2010 09:35 PM
A little bump.
Someone must be using this functionality. The coverage check seems like valuable stuff but nothing much said of it in the forum except a couple stale threads and the dead link mentioned above as well as conflicting descriptions in different texts.