views:

797

answers:

4

I'm seeing some very strange behaviour from the Apple Push Notification Servers when the recipient iPhone is off. Here is my scenario:

-Send push notification A to Apple. Within a few seconds a push notification popup gets displayed as expected on the iPhone.
-Send blank notification to Apple to cancel previous one (the previous notification is pointless after about 10 seconds, that's why I want to get rid of it). Nothing displayed on the iPhone.
-Turn OFF iPhone completely (not asleep, it is powered down).
-Send push notification B to Apple. Wait 10 seconds.
-Send blank notification to Apple to cancel previous one. Wait 10 seconds.
-Send push notification C to Apple. Wait 10 seconds.
-Send blank notification to Apple to cancel previous one. Wait 30 seconds.
-Turn ON iPhone.
-After about 60 seconds a push notification popup is displayed for notification B on the iPhone.
-Notification C never seems to arrive.

This is very strange! From reading the Apple docs I was expecting only the latest push notification to be sent. I was hoping my blank notification would be sent, I certainly wasn't expecting the oldest unsent push notification to be sent!

The Apple docs say:

Apple Push Notification Service includes a default Quality of Service (QoS) component that performs a store-and-forward function. If APNS attempts to deliver a notification but the device is offline, the QoS stores the notification. It retains only one notification per application on a device: the last notification received from a provider for that application. When the offline device later reconnects, the QoS forwards the stored notification to the device. The QoS retains a notification for a limited period before deleting it.

Has anybody seen this behaviour? Am I just hitting some sort of timing window bug? What should happen?

Updates:
-If I turn the phone off and wait 5 to 15 minutes before sending any push notifications then this problem doesn't occur. In this case when I turn the phone on I don't see any notification popup, although I'm not sure if this is a result of Apple dropping the notification, or their 'queue' working correctly (i.e. holding the newest blank notification instead of the first one with the popup).
-I will investigate further by putting an APNsLogging.mobileconfig onto the iPhone to see what notifications it got.
-Turning wifi off doesn't seem to change the results.
-I have raised a bug report with Apple for this scenario.

+1  A: 

You may want to check for this behavior across both the cellular and WiFi networks. There's a lot of strange behavior when the phone is on WiFi, especially if there are multiple NAT router involved, i.e. in a large corporation where there's a main router and per-floor WiFi routers, or in a home where you have multiple routers used to extend the range. But on cell it's been pretty solid.

Also, the 10-second cancellation delay may be cutting it too close. They don't guarantee timely delivery and I've gotten lags of as much as 3 minutes on the production server after queuing off a push request. You may want to plan for system congestion.

Either way, it sounds like it might be worthy of a bugreporter report.

Ramin
A: 

In apple's document it is said that it can cache the push notification up to 30 days.so u may get push once you switch on your iphone (provided you are having interconnection)

Rahul
Did you read my post, or just the title? Yes I know - in my post I explain that I do get one push notification delivered after turning the phone back on. But it is only the first push in a series of four, my question is whether it should be the most recent push, not the oldest.
Dan J
A: 

How soon was C sent after B? It seems like it may be a bug where there's some kind of timeout server side, and they accidentally keep B if C was sent too soon after...

If you have a good test example (and this seems like a good test) I would file a Radar report on this.

Kendall Helmstetter Gelner
My test had about 10 seconds between each push notification. I plan to retest and vary some of the time intervals to see if I can change the behaviour, then I'll raise a bug with Apple (https://bugreport.apple.com).
Dan J
A: 

For the record, I raised this as bug ID #7349660 with Apple on 29th Oct (https://bugreport.apple.com), then gave them the additional diagnostics they wanted on 30th Oct.

No response from Apple since then, so I am assuming this is probably just low on their priority list, which is fair enough as it is quite a small timing window where the problem can occur (which I didn't realize when I first opened this question).

Dan J