Azure NotificationHub - 检测失败的通知

Question

我正在尝试将失败的通知存储在 db 中，例如客户端无法访问 Internet。这将使我能够从 backgroundService 检查是否缺少通知，然后从 backgroundService 创建它。

因此，我的Azure App Service Mobile 上有以下内容：

var notStat = await hub.SendWindowsNativeNotificationAsync(wnsToast, tag);
telemetry.TrackTrace("failure : " + notStat.Failure + " | Results : " + notStat.Results + " | State : " + notStat.State + " | Success : " + notStat.Success + " | trackingID : " + notStat.TrackingId + ");

代码 sn-p 是为了测试来自客户端的影响，但无论我做什么，生成的日志都只是消息是enqueued。

问题

那么如何检测失败的通知呢？

结论

总结对已接受答案的讨论：

发送通知后，NotificationId 和其他相关数据将存储在单独的表中。

收到通知的客户端上的事件随后将向服务器发送一条消息，说明已收到通知。然后从表中删除该条目。

客户端未收到的通知将通过background task 找到。这将是每次background task 触发时，例如每 6 小时，background task 将检索所有丢失的通知。这使background task 能够创建相关通知，并且用户不会错过任何通知。

Answer 1

enqueued 的返回是预期的 - 请参阅troubleshooting guidance。有关发生的事情的更多见解，请尝试设置 EnableTestSend -

“result.State 将在执行结束时简单地声明 Enqueued，而无需了解您的推送发生了什么。现在您可以使用 EnableTestSend 布尔值” (c) documentation

但请注意，启用 EnableTestSend 时，存在一些限制（在同一页面上进行了描述，因此不会在此处复制粘贴，以避免将来出现过时信息的问题）。

您也可以使用每消息遥测功能或 REST API - Fiddler+some documentation。

并且，作为后续问题，我看到一些关于 SO 的讨论可能对您有所帮助：first 和 second。

最后，我强烈建议（如果您还没有）查看FAQ - 了解不同平台如何处理通知非常重要，以避免在您尝试调试通过设计完成的某些事情（例如，可能，如果设备处于离线状态，并且有通知，则只会传递最后一个，等等）。