Java Development

[pli]

Hi, expert,

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-Development/Clean-up-push-registration-with-Blackberry-P...  

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-Development/IOCancelledException-Send-receive-was-cancel... and it seems that other people got the same issue as I did.

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-Push-Development/Simplified-BIS-Push-client-sample... (many thanks to Simon,MSohm, mahrensm, LWalker).

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-Push-Development/Push-message-don-t-arrive-after-d... 4.3 appraoch makes me feel better since I have the full control and it works great so far at our testing.

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.

[simon_hain]

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.

[pli]

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?

[simon_hain]

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

[pli]

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...

[pli]

could any one who is using 5.0 approach comment as well? Or really 4.3 approach is used at majority of cases?

[emiliogl]

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.

Regards!

[pli]

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.

[emiliogl]

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...

Regards!