2

我正在尝试将失败的通知存储在一个db，例如客户端没有互联网访问权限。这将使我能够检查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 + ");

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

问题

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

结论

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

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

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

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

4

1 回答 1

2

enqueued 的返回是预期的 - 请参阅故障排除指南。有关发生的事情的更多见解，请尝试设置 EnableTestSend -

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

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

您也可以使用每消息遥测功能或 REST API - Fiddler+一些文档。

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

而且，作为最后一个，我强烈建议（如果您还没有）查看常见问题解答- 了解不同平台如何处理通知非常重要，以避免在尝试调试已完成的事情时出现这种情况通过设计（例如，也许，如果设备离线，并且有通知，则只会发送最后一个，等等）。

于 2016-04-30T23:00:06.507 回答