开发者

Weird Apple Push Notification behaviour when the receiving iPhone is turned off

开发者 https://www.devze.com 2022-12-09 13:01 出处:网络
I\'m seeing some very strange behaviour from the Apple Push Notification Servers when the recipient iPhone is off.Here is my scenario:

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开发者_如何学C 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.


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.


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


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)


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.

0

精彩评论

暂无评论...
验证码 换一张
取 消