次の方法で共有

直接通知の概要

  • [アーティクル]

直接通知は、短い汎用のプッシュ通知です。 説明のみを目的としており、UI コンポーネントは含まれません。 他のプッシュ通知と同様に、Windows プッシュ通知サービス (WNS) 機能は、クラウド サービスからアプリに直接通知を配信します。

生の通知は、さまざまな目的で使用できます。たとえば、ユーザーがアプリに対するアクセス許可を付与した場合に、アプリがバックグラウンド タスクを実行するようにトリガーするなどです。 WNS を使用してアプリと通信することで、永続的なソケット接続の作成、HTTP GET メッセージの送信、およびその他のサービス間接続の処理オーバーヘッドを回避できます。

重要

生の通知を理解するには、「 Windows プッシュ通知サービス (WNS) の概要で説明されている概念を理解しておくことをお勧めします。

 

トースト、タイル、バッジのプッシュ通知と同様に、未加工の通知は、割り当てられたチャネル Uniform Resource Identifier (URI) 経由でアプリのクラウド サービスから WNS にプッシュされます。 WNS は、そのチャネルに関連付けられているデバイスとユーザー アカウントに通知を配信します。 他のプッシュ通知とは異なり、未加工の通知には指定された形式がありません。 ペイロードの内容は完全にアプリで定義されます。

生の通知の恩恵を受ける可能性があるアプリの図として、理論上のドキュメント コラボレーション アプリを見てみましょう。 同じドキュメントを同時に編集している 2 人のユーザーを検討してください。 共有ドキュメントをホストするクラウド サービスは、生の通知を使用して、他のユーザーが変更を行ったときに各ユーザーに通知できます。 生の通知には必ずしもドキュメントへの変更が含まれているわけではありませんが、代わりに、各ユーザーのアプリのコピーが中央の場所に接続し、使用可能な変更を同期するように通知します。 生の通知を使用することで、アプリとそのクラウド サービスは、ドキュメントが開いている間、永続的な接続を維持するオーバーヘッドを節約できます。

生の通知のしくみ

すべての未加工通知はプッシュ通知です。 そのため、プッシュ通知の送受信に必要な設定は、未加工の通知にも適用されます。

  • 生の通知を送信するには、有効な WNS チャネルが必要です。 プッシュ通知チャネルの取得の詳細については、「 通知チャネルを要求、作成、保存する方法を参照してください。
  • アプリのマニフェストに Internet 機能を含める必要があります。 Microsoft Visual Studio マニフェスト エディターでは、このオプションは Capabilities タブの下に Internet (Client)として表示されます。 詳しくは、「Capabilities」をご覧ください。

通知の本文は、アプリで定義された形式です。 クライアントは、アプリでのみ理解する必要がある null で終わる文字列 (HSTRING) としてデータを受け取ります。

クライアントがオフラインの場合、 X-WNS-Cache-Policy ヘッダーが通知に含まれている場合にのみ、生通知が WNS によってキャッシュされます。 ただし、デバイスがオンラインに戻ると、1 つの直接通知のみがキャッシュされ、配信されます。

クライアントに対して実行できる生通知のパスは 3 つだけです。これらは、通知配信イベントを通じて実行中のアプリに配信されるか、バックグラウンド タスクに送信されるか、削除されます。 そのため、クライアントがオフラインで、WNS が未加工の通知を配信しようとすると、通知は削除されます。

生の通知の作成

生の通知の送信は、タイル、トースト、バッジのプッシュ通知を送信するのと似ていますが、次のような違いがあります。

  • HTTP Content-Type ヘッダーは"application/octet-stream" に設定する必要があります。
  • HTTP X-WNS-Type ヘッダーは "wns/raw" に設定する必要があります。
  • 通知本文には、サイズが 5 KB 未満の文字列ペイロードを含めることができますが、空の文字列にすることはできません。

未加工の通知は、アプリがアクションを実行するようにトリガーする短いメッセージとして使用することを目的としています。たとえば、サービスに直接連絡して大量のデータを同期したり、通知コンテンツに基づいてローカル状態を変更したりします。 WNS プッシュ通知を配信することは保証されないため、クライアントがオフラインのときなど、生の通知がクライアントに届かない可能性をアプリとクラウド サービスが考慮する必要があります。

プッシュ通知の送信の詳細については、「 Quickstart: プッシュ通知の送信」を参照してください。

未加工の通知の受信

アプリで直接通知を受信するには、次の 2 つの方法があります。

アプリでは、両方のメカニズムを使用して生の通知を受信できます。 生通知によってトリガーされる通知配信イベント ハンドラーとバックグラウンド タスクの両方がアプリに実装されている場合、通知配信イベントはアプリの実行中に優先されます。

  • アプリが実行されている場合、通知配信イベントはバックグラウンド タスクよりも優先され、アプリは通知を処理する最初の機会を持ちます。
  • 通知配信イベント ハンドラーは、イベントの PushNotificationReceivedEventArgs.Cancel プロパティを true に設定することで、ハンドラーが終了した後に未加工の通知をバックグラウンド タスクに渡さないことを指定できます。 Cancel プロパティが false に設定されているか、または設定されていない場合 (既定値は false)、通知配信イベント ハンドラーが処理を完了した後、未加工の通知によってバックグラウンド タスクがトリガーされます。

通知配信イベント

アプリでは、通知配信イベント (PushNotificationReceived) を使用して、アプリの使用中に直接通知を受信できます。 クラウド サービスが未加工の通知を送信すると、実行中のアプリはチャネル URI で通知配信イベントを処理することで、それを受信できます。

アプリが実行されておらず、 バックグラウンド タスク) を使用していない場合、そのアプリに送信された未加工の通知は、受信時に WNS によって削除されます。 クラウド サービスのリソースを無駄にしないようにするには、アプリがアクティブかどうかを追跡するロジックをサービスに実装することを検討する必要があります。 この情報には 2 つのソースがあります。アプリは、通知の受信を開始する準備ができていることをサービスに明示的に通知でき、WNS はサービスを停止するタイミングを伝えることができます。

  • アプリはクラウド サービスに通知します: アプリはそのサービスに連絡して、アプリがフォアグラウンドで実行されていることを通知できます。 この方法の欠点は、アプリがサービスに頻繁に接続する可能性があることです。 ただし、アプリが受信生通知を受信する準備ができたときに、サービスが常に認識するという利点があります。 もう 1 つの利点は、アプリがサービスに接続すると、サービスはブロードキャストではなく、そのアプリの特定のインスタンスに生の通知を送信することを認識することです。

  • クラウド サービスは WNS 応答メッセージに応答します : アプリ サービスは、 X-WNS-NotificationStatus および WNS から返された X-WNS-DeviceConnectionStatus 情報を使用して、アプリへの生通知の送信を停止するタイミングを決定できます。 サービスが HTTP POST としてチャネルに通知を送信すると、応答で次のいずれかのメッセージを受信できます。

    • X-WNS-NotificationStatus: dropped: これは、通知がクライアントによって受信されなかったことを示します。 ドロップ応答は、アプリがユーザーのデバイスのフォアグラウンドに存在しなくなったことが原因であることが安全な前提です。
    • X-WNS-DeviceConnectionStatus: disconnected または X-WNS-DeviceConnectionStatus: tempconnected: これは、Windows クライアントが WNS に接続しなくなったことを示します。 WNS からこのメッセージを受信するには、通知の HTTP POST で X-WNS-RequestForStatus ヘッダーを設定して要求する必要があります。

    アプリのクラウド サービスでは、これらのステータス メッセージの情報を使用して、生の通知による通信試行を停止できます。 アプリがフォアグラウンドに切り替えたときに、アプリから接続されると、サービスは生の通知の送信を再開できます。

    X-WNS-NotificationStatus に依存して、通知がクライアントに正常に配信されたかどうかを判断しないでください。

    詳細については、「 Push 通知サービスの要求ヘッダーと応答ヘッダー」を参照してください。

生の通知によってトリガーされるバックグラウンド タスク

重要

未加工の通知のバックグラウンド タスクを使用する前に、アプリに BackgroundExecutionManager.RequestAccessAsync 経由でバックグラウンド アクセスを許可する必要があります。

 

バックグラウンド タスクは、 PushNotificationTrigger に登録する必要があります。 登録されていない場合、未加工の通知を受信してもタスクは実行されません。

未加工の通知によってトリガーされるバックグラウンド タスクを使用すると、アプリが実行されていない場合でも (ただし、アプリの実行がトリガーされる場合もあります)、アプリのクラウド サービスがアプリに接続できるようになります。 これは、アプリが継続的な接続を維持する必要なしに発生します。 未加工の通知は、バックグラウンド タスクをトリガーできる唯一の通知の種類です。 ただし、トースト、タイル、バッジのプッシュ通知ではバックグラウンド タスクをトリガーできませんが、生の通知によってトリガーされるバックグラウンド タスクは、タイルを更新し、ローカル API 呼び出しを通じてトースト通知を呼び出すことができます。

未加工の通知によってトリガーされるバックグラウンド タスクの動作を示す図として、電子書籍を読むのに使用されるアプリを考えてみましょう。 まず、ユーザーがオンラインで、場合によっては別のデバイスで書籍を購入します。 これに対して、アプリのクラウド サービスは、書籍が購入され、アプリがダウンロードする必要があることを示すペイロードを使用して、各ユーザーのデバイスに生の通知を送信できます。 その後、アプリはアプリのクラウド サービスに直接アクセスして新しい書籍のバックグラウンド ダウンロードを開始します。これにより、後でユーザーがアプリを起動すると、ブックは既に存在し、読み取り可能になります。

未加工の通知を使用してバックグラウンド タスクをトリガーするには、アプリで次の手順を実行する必要があります。

  1. BackgroundExecutionManager.RequestAccessAsync を使用して、バックグラウンドでタスクを実行するためのアクセス許可を要求します (ユーザーはいつでも取り消すことができます)。
  2. バックグラウンド タスクを実装します。 詳細については、「 バックグラウンド タスクでアプリをサポートする」を参照してください。

その後、アプリに対して直接通知が受信されるたびに、 PushNotificationTrigger に応答してバックグラウンド タスクが呼び出されます。 バックグラウンド タスクは、生の通知のアプリ固有のペイロードを解釈し、それに対して動作します。

アプリごとに、一度に実行できるバックグラウンド タスクは 1 つだけです。 バックグラウンド タスクが既に実行されているアプリに対してバックグラウンド タスクがトリガーされた場合は、新しいバックグラウンド タスクを実行する前に最初のバックグラウンド タスクを完了する必要があります。

その他のリソース

詳細については、Windows 8.1 の Raw 通知のサンプル と、Windows 8.1 の Push と定期的な通知のサンプル をダウンロードし、Windows 10 アプリでソース コードを再利用します。