Push Notification Performance

2 posts, 0 answers
  1. Kelly
    Kelly avatar
    73 posts
    Member since:
    Apr 2011

    Posted 07 Apr 2014 Link to this post


    I have some general questions about iOS pushes, please.  I'm receiving maybe 4 in 10 pushes I send, and I'm trying to figure out how to troubleshoot why.

    1) What does the Devices column in the Push page of the TBS Data Browser reflect?  Using the same Filter (UserId) for a valid user, some of the Devices column values are 1, and some are 0.  The value doesn't seem to correlate with whether I actually received the push.  If I try the "Add new notification based on this" feature for an item whose Devices value is 0, the "Devices in this segment" value always says 1, so I know the device is valid even when the Devices column says 0.

    2) I know pushes are not guaranteed.  I know TBS is handing off the push to Apple immediately, so any lag or disappearance is on Apple. So I have to ask.  Are pushes really THIS unreliable? I'd love to hear that I've set up something incorrectly - but if I had, I don't think I'd receive ANY pushes.  Please set my expectations set as to how well this should work.

    3) Obviously, a supplemental strategy of polling for new data is in order. Is there a rule of thumb for how often an application that expects to have thousands of users (billions eventually :>)  should poll the rest api and be considered a good citizen? I certainly don't want my app to be considered a pig.

    4) Do the push providers know when a notification has been delivered? If so, could it be that when a later notification has been successfully delivered, earlier notifications that have previously failed are considered delivered too?  If that's not how it works, then how could I get push #10 when pushes 5 through 9 never arrive? Is that why they recommend only using pushes to poke the application to retrieve new data, rather than to deliver real data?  I only ask because I see that the Android pushes use a "collapse_key" field to roll up similar notifications and save bandwidth.

    5) Every time my application is invoked, I log in the user, then call enableNotifications, then getRegistration.  If the user is registered, I use updateRegistration, otherwise I call the register function.  Does that sound correct?  The doc is full of warnings about the token sometimes changing. Could it change out from under a user who stays logged in for a long period?

    Thank you,

  2. Anton Dobrev
    Anton Dobrev avatar
    607 posts

    Posted 09 Apr 2014 Link to this post

    Hi Kelly,

    Straight to your questions:

    1. The "Devices" column of the grid takes a while to aggregate and reflects the count of devices the push notification was sent to.

    2. It is right that pushes are sometimes referred to as "best effort". However,  the push notification services could be relied on, in terms to know that messages created through Backend Services will be sent immediately to the corresponding server. Each disruption in Backend Services is shown at the status page. In regard to Apple-specific notifications, the Apple Push Notification servers await the response from the device for its availability, before continuing to process the queue of incoming messages. The following doc is considered to be the general guideline for troubleshooting push notifications for Apple devices. Along with the already effective enhancement in our push infrastructure, we are working on more developer-friendly experience for troubleshooting push notifications in the context of Backend Services.

    3. We are eager to contemplate the great accomplishments of our customers, so the only limitations imposed to them in the Backend Services realm are these deriving from their subscription plan. Of course, in regard to the end users of the apps, instrumented with the Telerik Platform services, their bandwidth and calls to the server should be spared as much as possible, with elaborated client-side management of the operations for retrieving and syncing of the data.

    4. The push servers know when the notification is delivered in a indirect way as they await the response of the device's state. iOS devices will receive only the last notification sent to them when they become available. In Android devices this is specified by the collapse_key key (for the lack of more accurate word).

    5. The described workflow is the appropriate one. In regard to the push token, the push service providers always warn that the push token may suddenly change.

    Please, let us know if this information is helpful for you.

    Anton Dobrev
    Everlive is now Telerik Backend Services, and is part of the Telerik Platform.
Back to Top