我们对iOS推送通知相对较新,而且与Apple一样,我对解决方案的优雅感到印象深刻,但对于该功能行为的一些不透明的“幕后”管理也略有激怒.
我的问题是：成功收到约. 10个单独的静音推送通知,每小时一个,在我们的测试用户最终打开之前,不再向我们的测试应用程序发送.基于此,如果确定应用未被使用,iOS可能会停止提供静默推送通知.这是预期的行为吗？有没有人知道关于Apple使用的启发式的粗略细节？
有兴趣者的测试详情
仅供参考,我们的测试设置如下：
>我们构建了一个简单的通知测试应用程序(使用应用程序为iOS7构建：didReceiveRemoteNotification：fetchCompletionHandler委托方法)
>在测试期间,应用程序在我们的测试iPhone 5的后台保持暂停状态(有时在办公室中使用wifi,有时在伦敦及其周边的3G上).
>我们有一个简单的Ruby脚本使用Grocer gem(这似乎非常好)每小时通过Apple的沙箱APNS网关向应用程序发送静音推送通知.
>当应用程序收到通知时,它会唤醒,写入日志并向我们的后端服务器发出简单请求,该服务器还会记录已发生的事件.
结果：
>一切都与前10个小时完全一致.在此之后,应用程序不再收到通知.
aps = {
badge = 2;
"content-available" = 1;
};
解决方法
几个月前我对我的应用程序的推送功能做了很多测试,我的一些经验在这里：
- Apple Push Notification doesn’t care about if your app is in use or not.
- APNS is not 100% reliable,the most influential factor is network quality(your server to APN server,APN servere to your device).
- I have pushed 10,000 notifications to a iphone4s in 3 minutes,device received more than 95% notifications.So,10 separate silent
push notifications at a rate of one per hour has no pressure.
现在,讨论一下你的问题：
第一：应该意识到通知的第一个接收者是系统,而不是你的应用程序.
如果您的应用程序不在前台,应用程序的应用程序：didReceiveRemoteNotification：fetchCompletionHandler将永远不会被调用,直到您的应用程序再次变为前台.因此,您的“写日志并向我们的后端服务器发出简单请求”操作不适合“记录已发生的事件”.
我认为除非您的应用始终处于前台,否则没有一种“记录所有已发生事件”的好方法.
顺便说一句：当您测试推送时,如果设备没有快速通知通知,您可以更改设备的网络(或关闭然后打开网络),有时,通知将很快到来.
