ios 如何知道推送通知的传递状态

How to know Push Notification delivery status

提问by MaxEcho

I am using push notification in an app. Everything is going fine.

我在应用程序中使用推送通知。一切都很顺利。

Sometimes message sent from server but in app side it does not receive.

有时消息从服务器发送，但在应用程序端它没有收到。

In this situation I have to know which message is missing to deliver(app did not receive).

在这种情况下，我必须知道缺少哪条消息要传递（应用程序没有收到）。

Is there any way to know from server side which message is received by app and which are not?

有什么办法可以从服务器端知道应用程序收到哪些消息，哪些没有？

回答by staticVoidMan

Nopes, push notifications are fire-and-forget.

不，推送通知是一劳永逸的。

Apple will not tell you the following:

Apple 不会告诉您以下内容：

1. Will not tell whether the message was sent successfully or not
2. Will not tell if the user has opted out of Push Notifications
3. Many other things but anyways...

1. 不会告诉消息是否发送成功
2. 不会告诉用户是否已选择退出推送通知
3. 许多其他事情，但无论如何......

---

---

However

然而

On the other hand, when the user has opted for Push Notifications then your app can handle this but to a certain extent:

另一方面，当用户选择推送通知时，您的应用程序可以处理此问题，但在一定程度上：

Basically, you could add logic in the -didReceiveRemoteNotification:and -didFinishLaunchingWithOptions:to contact your server and tell your server that the message was received.
If it wasn't received within a particular time slot then you can resend it.

基本上，您可以在-didReceiveRemoteNotification:和 中添加逻辑-didFinishLaunchingWithOptions:以联系您的服务器并告诉您的服务器已收到消息。
如果在特定时间段内未收到，则可以重新发送。

But as you see, this could lead to a possible scenario of flooding an innocent user with the same push notifications.
In a sense, harassing him to tap your stupid push notification, which in turn may lead him to switch off push notifications for your app entirely but mostly he would delete the app and maybe even give it a low rating?
Serves you right, I'll say.

但如您所见，这可能会导致向无辜用户发送相同推送通知的情况。
从某种意义上说，骚扰他点击你愚蠢的推送通知，这反过来可能会导致他完全关闭你的应用程序的推送通知，但大多数情况下他会删除该应用程序，甚至可能给它一个低评级？
为你服务，我会说。

Anyways, if you go ahead with this, you would need to implement an identification pattern where you insert a unique message identifierinto the payload of the push notification and when your app gets this push notification, it should send this message identifierback to the server.
Your server should then log that a particular device token returned a message identifier, which means it received that particular push notification.

无论如何，如果你继续这样做，你需要实现一个识别模式，你将一个唯一的message identifier插入到推送通知的有效负载中，当你的应用程序收到这个推送通知时，它应该将它发送message identifier回服务器。
然后，您的服务器应记录特定设备令牌返回 a message identifier，这意味着它收到了该特定推送通知。

Your server can check on a hourly/daily/whateverly basis and resend a particular message to those device tokens that have not reported back with the relative message identifier.

您的服务器可以每小时/每天/任何时间进行检查，并将特定消息重新发送到那些尚未向相关message identifier.

Again, this means your server might need to work OT sometimes.

同样，这意味着您的服务器有时可能需要加班。

---

---

There are other issues with this whole approach:

整个方法还有其他问题：

1. User received push notification but dismisses it rather than opening your app with it
   • Your server will assume the user did not see the push notification and will send this push notification again
2. Ghost device tokens
   • User accepted push notifications at first but later revoked this privilege
   • User uninstalled the app
   • Basically, device tokens that once use to receive push notification but no longer do, most probably due to your message flooding reputation
3. User received push notification but taps it at a later time
   • might get same push notification multiple times (very irritating)
4. User received push notification but taps it when there is no internet connectivity
5. User received push notification but your server is down, possibly fried \m/

1. 用户收到推送通知但将其关闭而不是打开您的应用程序
   • 您的服务器将假定用户没有看到推送通知，并将再次发送此推送通知
2. 幽灵设备令牌
   • 用户起初接受推送通知，但后来撤销了此权限
   • 用户卸载了应用
   • 基本上，曾经用于接收推送通知但不再接收推送通知的设备令牌，很可能是由于您的消息泛滥声誉
3. 用户收到推送通知但稍后点击它
   • 可能会多次收到相同的推送通知（非常烦人）
4. 用户收到推送通知，但在没有互联网连接时点击它
5. 用户收到推送通知，但您的服务器已关闭，可能炸了 \m/

You can circumvent the last 3 scenarios by having even more logic in your app that queues the message id's that are to be sent to the server and removes it only when the server responds successfully.

您可以通过在您的应用程序中添加更多逻辑来规避最后 3 种情况，这些逻辑将要发送到服务器的消息 ID 排队并仅在服务器成功响应时将其删除。

So you see, too much work, server-side + client-side.
Plus it's a massive performance degrader on the server-side when dealing with a good volume of users as well as lowering the performance of your app by a wee bit.

所以你看，太多的工作，服务器端 + 客户端。
此外，在处理大量用户以及稍微降低应用程序性能时，它会严重降低服务器端的性能。

回答by meda

The Feedback Service

反馈服务

The Apple Push Notification Service includes a feedback service to give you information about failed push notifications. When a push notification cannot be delivered because the intended app does not exist on the device, the feedback service adds that device's token to its list. Push notifications that expire before being delivered are not considered a failed delivery and don't impact the feedback service. By using this information to stop sending push notifications that will fail to be delivered, you reduce unnecessary message overhead and improve overall system performance.

Query the feedback service daily to get the list of device tokens. Use the timestamp to verify that the device tokens haven't been reregistered since the feedback entry was generated. For each device that has not been reregistered, stop sending notifications. APNs monitors providers for their diligence in checking the feedback service and refraining from sending push notifications to nonexistent applications on devices.

Apple 推送通知服务包括一项反馈服务，可为您提供有关失败推送通知的信息。当由于设备上不存在预期的应用程序而无法传递推送通知时，反馈服务会将该设备的令牌添加到其列表中。在传递之前过期的推送通知不被视为传递失败，并且不会影响反馈服务。通过使用此信息停止发送无法传递的推送通知，您可以减少不必要的消息开销并提高整体系统性能。

每天查询反馈服务以获取设备令牌列表。使用时间戳来验证自反馈条目生成以来设备令牌尚未重新注册。对于尚未重新注册的每个设备，停止发送通知。APNs 监控提供商在检查反馈服务方面的勤奋，并避免向设备上不存在的应用程序发送推送通知。

回答by Sr.iOSDev

1.If you are asking about notifications not delivered on a device which has application installed on the device and just because of notification getting expired before it is delivered or something else, notifications are not delivererd.

1.如果您询问未在设备上安装了应用程序的设备上传递的通知，并且只是因为通知在传递之前已过期或其他原因，则通知不会传递。

Then the answer is

那么答案是

Nope.

不。

It does not provide support where in you can check if the Notifications is expired and not delivered on a valid device:

它不提供支持，您可以在其中检查通知是否已过期且未在有效设备上传送：

any option to know if apple app get the push notification?

任何知道苹果应用程序是否收到推送通知的选项？

Refer to Moshe's answer in above link. I am including his answer here so that it is useful to everyone in future even in case the link becomes dead.

请参阅上面链接中 Moshe 的回答。我在这里包括了他的回答，以便将来即使链接失效也对每个人都有用。

The short answer, you can't, since APNS is one way. However, since an app can execute arbitrary code upon receipt of a notification, you can use this to say, send an http request to your own server when the notification is recieved.

简短的回答，你不能，因为 APNS 是一种方式。但是，由于应用程序可以在收到通知后执行任意代码，因此您可以使用它来表示，在收到通知时向您自己的服务器发送 http 请求。

2.If you asking of the notifications not delivered as user has uninstalled the application then you can refer to meda'sanswer in this post.

2.如果您询问由于用户已卸载应用程序而未发送的通知，那么您可以参考本文中meda的回答。

Hope this helps you and let me know if you have any queries regarding my explanation.

希望这对您有所帮助，如果您对我的解释有任何疑问，请告诉我。

回答by manishsharma93

You can get the the delivery report of Push notification, Not from server but from your app, using "Service Extension" and modifying little bit in your Push json. Checkout this linkfor detailed explanation.

您可以使用“服务扩展”并在您的 Push json 中稍微修改一下，而不是从服务器而是从您的应用程序获取推送通知的交付报告。查看此链接以获取详细说明。