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と、その他の関連データが別のテーブルに保存されます。

通知を受信したクライアントのイベントは、通知が受信されたことを示すメッセージをサーバーに送信します。その後、エントリはテーブルから削除されます。

クライアントが受信しない通知は、 を通じてbackground task検出されます。これは、起動するたびにbackground task、たとえば 6 時間ごとに行わbackground taskれ、欠落しているすべての通知が取得されます。これにより、background task関連する通知を作成できるようになり、ユーザーは通知を見逃すことはありません。

4

1 に答える 1

2

enqueued が返されることが予想されます -トラブルシューティング ガイダンスを参照してください。何が起こったのかについての詳細な洞察については、EnableTestSend を設定してみてください -

「result.Stateは、プッシュに何が起こったのかについての洞察なしに、実行の最後に単にエンキューされたと述べます。これで、EnableTestSendブール値を使用できます」（c）ドキュメンテーション

ただし、EnableTestSend が有効になっている場合は、いくつかの制限があることに注意してください (同じページで説明されているため、古い情報による将来の問題を回避するために、ここにコピーして貼り付けることはしません)。

Per Message Telemetry 機能または REST API も使用できます - Fiddler+一部のドキュメント。

そして、フォローアップの質問として、役立つと思われる SO i seen に関するいくつかの議論がありました: firstとsecond .

最後に、 FAQを確認することを強くお勧めします (まだ行っていない場合)。完了したものをデバッグしようとする状況を回避するために、さまざまなプラットフォームが通知をどのように処理するかを知ることが重要です。設計による（たとえば、デバイスがオフラインで通知がある場合、最後の通知のみが配信されるなど）。

于 2016-04-30T23:00:06.507 に答える