03-23-2012 10:42 AM - edited 03-23-2012 10:44 AM
recently I asked the question about how the push registration would be cleaned up on application deletion. And Mark replied to me that with BB Push API, OS would handle the push de-registration which would be better than 4.3 approach which is direct http. Here is my post: http://supportforums.blackberry.com/t5/Java-Develo
When I tested some push demo from RIM couple monthes back, I could not get the application from 5.0 approach to work on my device. However 4.3 approach is working. Here is my post for that as well: http://supportforums.blackberry.com/t5/Java-Develo
Then I took the 4.3 approach which seems more reliable and also thanks to posted simplied BIS push solution (http://supportforums.blackberry.com/t5/BlackBerry-
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.
However from some of the post at the forum, the 5.0 approach is not fully reliable. http://supportforums.blackberry.com/t5/BlackBerry-
So now I am a little hesitating to move to 5.0 approach. I would like to ask people on the forum how your experience with 5.0 push is here. It would be really appreciated.
03-23-2012 10:50 AM
03-23-2012 11:25 AM
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?
03-23-2012 11:31 AM
03-23-2012 11:38 AM
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-
05-25-2012 04:43 AM
We use 5.0 API approach.
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.
05-25-2012 12:09 PM
Thanks for the information. I guess 5.0 approach is reliable then based on your experiment. Not sure why other people saw some issues there. At this point, we will stick to old approach.
05-28-2012 05:42 AM
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...