apns http2 api在卸载app后没有返回状态410

时间:2016-09-02 10:50:56

标签: ios apple-push-notifications http2 apns-php

我使用带有http2协议的apns来发送推送,我使用的代码类似于这篇文章: https://stackoverflow.com/a/34831873/1546652

当我的应用程序正确安装时,apns http2 api在发送消息时工作正常,我的响应是这样的风格: {"响应":""" httpcode":200}

问题在于,当我卸载应用程序并向无效registrationId发送推送时,我没有收到状态410,也没有收到响应"原因:未注册"仍然收到状态为200的真实回复。

如何在apns http2中取消应用程序时收到410状态和对应响应?

3 个答案:

答案 0 :(得分:3)

This technical note可能会有所帮助,基本上是

iOS将保持每个APNS环境(生产/沙盒)的一个套接字连接,当您从iOS删除应用程序时,如果它是给定环境的最后一个应用程序,它也会杀死该套接字连接,这会导致删除事件删除了最后一个应用程序。

这通常发生在开发应用程序中。

解决方案是在设备上安装虚拟应用程序,该设备注册APN并使用开发者身份进行签名,现在当您在开发期间从设备中删除真实应用程序时,它将保持与APNS的连接打开,从而导致应用程序删除向APNS报道。

此外,在我的测试中,我在APNS响应中反映应用删除之前经历了大约30-60分钟的延迟。

答案 1 :(得分:1)

这是我在APNS产品服务中的 410 状态经验;删除设备上的分发应用程序后,我可以得到410次响应,但是随后,在花费大量时间测试 APNS Http / 2 API之后,我注意到,即使返回2到3天后,它也会返回属于已删除应用程序的先前设备令牌的始终成功响应(http 200 )。

添加apns日志配置文件后,我发现了这两行登录设备:

APSCourier: Received message for recently removed topic ‘com.xxx.xxx.xxx’
APSCourier: Sending acknowledgement message

我认为,这是关于在设备上接收已删除主题的通知并将其确认消息从设备发送到后端APNS的异步流程。 APNS不会以某种方式对这些确认采取任何措施。

考虑到APNS行为的当前状态,使用新的APNS通知服务将其作为卸载跟踪过程的一部分目前不是正确的方法

您可以代替APNS执行后台任务来对服务器执行ping操作,以使您检测到卸载状态。

并希望分享来自苹果开发者论坛的一些链接,讨论 parallel 主题:

APNs token still valid after app uninstalled

Older APNs device tokens do reach the device

Old APNs tokens not invalidating?

How do APNS HTTP/2 and APNS HTTP/1.1 Work together?

When does APNS report an uninstall?

答案 2 :(得分:0)

您还应该尝试使用旧的反馈服务,但该服务仍然有效。

NWPusher是一种快速检查方法。