如何知道推送通知的传递状态 [英] How to know Push Notification delivery status
问题描述
我在应用中使用推送通知.一切顺利.
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?
推荐答案
不，推送通知是一劳永逸的.
Apple 不会告诉您以下内容:
Nopes, push notifications are fire-and-forget.
Apple will not tell you the following:
- 不会判断消息是否成功发送
- 不会告诉用户是否已选择退出推送通知
- 还有很多其他的事情，但无论如何......
<小时>
不过
另一方面，当用户选择推送通知时，您的应用可以处理此问题，但在一定程度上:
However
On the other hand, when the user has opted for Push Notifications then your app can handle this but to a certain extent:
基本上，您可以在 -didReceiveRemoteNotification: 和 -didFinishLaunchingWithOptions: 中添加逻辑以联系您的服务器并告诉您的服务器已收到消息.
如果在特定时间段内未收到，则可以重新发送.
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.
但如您所见，这可能会导致向无辜的用户发送相同的推送通知.
从某种意义上说，骚扰他点击你愚蠢的推送通知，这反过来可能会导致他完全关闭你的应用程序的推送通知，但大多数情况下他会删除该应用程序，甚至可能给它一个低评级?
为你服务，我会说.
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 identifier into the payload of the push notification and when your app gets this push notification, it should send this message identifier back 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.
您的服务器可以每小时/每天/任何时间进行检查，并将特定消息重新发送给那些未使用相关消息标识符报告回来的设备令牌.
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.
同样，这意味着您的服务器有时可能需要加班.
Again, this means your server might need to work OT sometimes.
整个方法还有其他问题:
There are other issues with this whole approach:
- 用户收到推送通知但将其关闭而不是使用它打开您的应用
- 您的服务器将假定用户没有看到推送通知，并将再次发送此推送通知
- 用户起初接受推送通知，但后来撤销了此权限
- 用户卸载了应用
- 基本上，曾经用于接收推送通知但不再接收推送通知的设备令牌，很可能是由于您的消息泛滥声誉
- 可能会多次收到相同的推送通知(很烦)
您可以通过在您的应用程序中加入更多逻辑来规避最后 3 种情况，这些逻辑将要发送到服务器的消息 ID 排队并仅在服务器成功响应时将其删除.
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.
所以你看，太多的工作了，服务器端 + 客户端.
此外，在处理大量用户以及稍微降低应用性能时，它会严重降低服务器端的性能.
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.
这篇关于如何知道推送通知的传递状态的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
