Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Java Development

Reply
Trusted Contributor
pli
Posts: 174
Registered: ‎09-04-2011
My Device: Bold
My Carrier: at&t

Is BB Push API (5.0 approach) reliable?

[ Edited ]

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.

 

 

Please use plain text.
Developer
simon_hain
Posts: 15,806
Registered: ‎07-29-2008
My Device: Z10 LE
My Carrier: O2 Germany

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
Please use plain text.
Trusted Contributor
pli
Posts: 174
Registered: ‎09-04-2011
My Device: Bold
My Carrier: at&t

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?

Please use plain text.
Developer
simon_hain
Posts: 15,806
Registered: ‎07-29-2008
My Device: Z10 LE
My Carrier: O2 Germany

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 :smileyhappy:
----------------------------------------------------------
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
Please use plain text.
Trusted Contributor
pli
Posts: 174
Registered: ‎09-04-2011
My Device: Bold
My Carrier: at&t

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

Please use plain text.
Trusted Contributor
pli
Posts: 174
Registered: ‎09-04-2011
My Device: Bold
My Carrier: at&t

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

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

Please use plain text.
New Contributor
emiliogl
Posts: 2
Registered: ‎05-25-2012
My Device: 9105
My Carrier: Movistar

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

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!

 

Please use plain text.
Trusted Contributor
pli
Posts: 174
Registered: ‎09-04-2011
My Device: Bold
My Carrier: at&t

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

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.

Please use plain text.
New Contributor
emiliogl
Posts: 2
Registered: ‎05-25-2012
My Device: 9105
My Carrier: Movistar

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

 

Regards!

 

 

Please use plain text.