However as I said at first post, I am also worried about the push registration from device would be piled up at BB Push server if our application is deleted and user doesn't give us chance to do push deregiration before reboot or no network that time.

Re: Is BB Push API (5.0 approach) reliable?

we use the old implementation, but not due to any specific reason or test result, just because we have a sample implementation ready to copy/paste.

----------------------------------------------------------feel free to press the like button on the right side to thank the user that helped you.please mark posts as solved if you found a solution.@SimonHain on twitter

Re: Is BB Push API (5.0 approach) reliable?

thanks, Simon. Then for the push de-registration on application deletion, is there concern for you that push registration for some devices might still exist at the push server and it might pile up? Or do you have code at the push initiator side to clean up the push registration in some way?

Re: Is BB Push API (5.0 approach) reliable?

no, we have never handled the server-side ourselves so far. i guess you could clean up if a certain number of pushes don't read the destination (if you use reliability).or you just ignore it

----------------------------------------------------------feel free to press the like button on the right side to thank the user that helped you.please mark posts as solved if you found a solution.@SimonHain on twitter

Re: Is BB Push API (5.0 approach) reliable?

got it. I guess we are ignoring it right now :-). Unfortunately we are not using push plus right now. For push essential, I don't think that we would know whether push is able to reach the destination or not.

The reason why we don't choose push plus is that the notify url for push would have to pre-set for one particular push app ID and we don't have a good way to share the same push app ID accross our different env. (production, staging, QA, dev) and we don't want to have a new push eval app ID every time there is new dev or QA env to be spinned up. here my post for this as well in case that you are interested in our issues: http://supportforums.blackberry.com/t5/BlackBerry-Push-Development/Different-BlackBerry-Push-AppID-r...

Re: Is BB Push API (5.0 approach) reliable?

In dev & test environment (Essentials) , we send custom aknowledge messages back to our content provider server each couple of minutes, with push messages ID's received it than timespan to check them in server.

If not aknowledge received after several configured retries, we drop that device registration on content provider.

For production (Plus service), we switch to reliability BUT still keep our aknowledge system for safeguard porpouses, with a connection back delay of 1 hour aprx.

Re: Is BB Push API (5.0 approach) reliable?

Well it depends upon application type. Perhaps you could assume drop of some messages in chat application, but not in a LOB application, so... design for best performance (push) and prepare for fail (fallback pull sync) is the best approach for us, wathever API level o services we use...