登録管理

  • [アーティクル]

このトピックでは、プッシュ通知を受け取るために Notification Hubs にデバイスを登録する方法について説明します。 このトピックでは、大まかなレベルでの登録について説明した後、デバイスを登録するための 2 つの主要なパターンについて説明します。デバイスから通知ハブに直接登録し、アプリケーション バックエンドを介して登録します。

デバイスの登録とは

登録は Notification Hubs のサブエンティティであり、デバイスの PNS ハンドル (Platform Notification Service ハンドルのこと、たとえば ChannelURI、デバイス トークン、GCM registrationId) をタグおよび場合によってはテンプレートと関連付けます。 タグは、通知を正しいデバイス ハンドル セットにルーティングするために使用されます。 詳細については、「 ルーティングとタグ式」を参照してください。 テンプレートは、登録ごとの変換を実装するために使用されます。 詳細については、「 テンプレート」を参照してください。

登録は一時的なものであることに注意することが重要です。 含まれる PNS ハンドルと同様に、登録は期限が切れます。 Notification Hubs での登録の有効期限は、最大 90 日間まで設定できます。 この制限は、登録を定期的に更新する必要があること、また重要な情報の唯一のストアであってはならないことを意味します。 この自動的な有効期限切れにより、モバイル アプリケーションをアンインストールするときのクリーンアップも簡略化されます。

登録には、各デバイス/チャネルの最新の PNS ハンドルが含まれる必要があります。 PNS ハンドルはデバイス上のクライアント アプリでのみ取得できるため、登録を管理する方法の 1 つはクライアント アプリ上で直接行うことです。 一方で、タグに関連するセキュリティの考慮事項およびビジネス ロジックに関しては、アプリ バックエンドで登録を管理する必要があります。 次のセクションでは、これら 2 つの方法について説明します。

デバイスからの登録の管理

クライアント アプリから登録を管理するときは、バックエンドは通知の送信のみを行います。 クライアント アプリは、PNS ハンドルを最新の状態に維持し、タグに登録します。 このパターンについて次の図で説明します。

Registration Management

デバイスは、まず PNS から PNS ハンドルを取得してから、通知ハブに直接登録します。 登録に成功すると、アプリ バックエンドからその登録に対して通知を送信できるようになります。 通知の送信方法の詳細については、 ルーティングとタグ式に関するページを参照してください。

この場合、デバイスから通知ハブにアクセスする際にリッスン権限のみを使用します。 詳細については、セキュリティに関するページをご覧ください。

次のコードは、Notification Hubs API リファレンスを使用してデバイスを登録します。

await hub.RegisterNativeAsync(channelUri, tags);

[hub registerNativeWithDeviceToken:deviceToken tags:nil completion:^(NSError* error) {
    if (error != nil) {
        NSLog(@"Error registering for notifications: %@", error);
    }
}];

hub.register(regid, tags);

これらのメソッドで、呼び出すデバイスの登録を作成または更新します。 つまり、ハンドルまたはタグを更新するには、登録全体を上書きする必要があります。 登録は一時的なものであることを思い出してください。したがって常に、特定のデバイスが必要とする最新のタグを信頼できるストア (デバイスまたはアプリ バックエンドのローカル ストレージ) に保持する必要があります。 登録を更新する方法の詳細な例については、 ニュース速報 チュートリアルを参照してください。

REST API を使用してデバイスから登録することもできます。 詳細については、「 Notification Hubs REST インターフェイスを使用する方法」を参照してください。

次のシナリオのチュートリアルでは、クライアントからの登録手順が説明されています。

テンプレート

テンプレートを使用する場合、各登録は個々のテンプレートを表します。 つまり、デバイスが 2 つのテンプレートを使用する場合は、各テンプレートを固有の PNS ハンドルとタグ セットで個別に登録する必要があります。

ネイティブ登録 (つまり、テンプレートを使用しない) の場合は、テンプレートの登録メソッドは既存の登録を作成または更新します。 異なるテンプレートを対象にするには、登録時にテンプレート名を指定します。 同じデバイスで複数のテンプレートを使用する場合は、異なる名前を指定します。

重要

テンプレートを使用するときは、前のセクションで示したようなデバイスの登録は必要ありません。 その登録は、ネイティブ通知 (プラットフォーム固有の形式で送信される通知) を送信する場合にのみ使用されます。

次のコードは、Notification Hubs API リファレンスを使用してデバイスを登録します。

await hub.RegisterTemplateAsync(channelUri, template, templateName, tags);

[hub registerTemplateWithDeviceToken:deviceToken name:templateName jsonBodyTemplate: template expiryTemplate:nil tags:nil completion:^(NSError* error) {
    if (error != nil) {
        NSLog(@"Error registering for notifications: %@", error);
    }
}];

hub.registerTemplate(regId, templateName, template, tags);

各登録呼び出しでは、PNS ハンドルとオプションのタグ セットに加えて、通知本文のテンプレートとテンプレートの名前も提供することに注意してください。 さらに、各プラットフォームはテンプレートの一部である追加のプロパティを持つこともできます。 Windows ストア (WNS を使用) および Windows Phone 8 (MPNS を使用) の場合は、追加のヘッダー セットをテンプレートの一部にすることができます。 APNs の場合、expiry プロパティを定数またはテンプレート式に設定することができます。

これらのテンプレート フィールドを変更する方法については、「 API リファレンス 」または 「Notification Hubs REST API」を参照してください。

Windows ストア アプリのセカンダリ タイル

Windows ストア クライアント アプリケーションの場合、セカンダリ タイルに通知を送信する処理は、プライマリ タイルに送信する場合と同じです。 ネイティブ登録とテンプレート登録の両方がサポートされます。 唯一の違いは、セカンダリ タイルは ChannelUri が異なり、クライアント アプリ上の SDK が透過的に処理することです。

大まかなレベルでは、前のセクションで提供されているすべての情報は、ディクショナリ プロパティ Microsoft.WindowsAzure.Messaging.NotificationHub.SecondaryTiles で公開されているオブジェクトで対応するメソッドを呼び出すことによって、セカンダリ タイルと連携します。 次に例を示します。

await hub.SecondaryTiles["myTileId"].RegisterNativeAsync(new string[] {"Yankees"});
await hub.SecondaryTiles["myTileId"].RegisterTemplateAsync(buildToastTemplate(), "toastTemplate", new string[] {"RedSox"});

SecondaryTiles ディクショナリは、Windows Microsoft Store アプリで SecondaryTiles オブジェクトを作成するために使用されるのと同じ TileId を使用します。

プライマリ タイルの ChannelUri と同様に、セカンダリ タイルの ChannelUris は常に変化する可能性があります。 更新される Notification Hubs でクライアント アプリの登録を維持するには、デバイスはセカンダリ タイルの現在の ChannelUri で更新する必要があります。

注意

アプリがアクティブでないときは、セカンダリ タイルを削除できます。 対応する登録で通知は発生せず、Notification Hubs によって自動的に削除されます。

デバイスからの登録の欠点

デバイスからの登録は最も簡単な方法ですが、いくつかの欠点があります。

1 つ目の欠点は、クライアント アプリがアクティブな場合にのみ、クライアント アプリからタグを更新できることです。 たとえば、スポーツ チームに関するタグを登録する 2 つのデバイスがある場合、1 番目のデバイスが追加タグ (たとえば Seahawks) を登録したとき、2 番目のデバイスは、そのデバイスのアプリが再度実行されるまで Seahawks についての通知を受け取りません。 さらに一般的には、タグが複数のデバイスの影響を受ける場合、バックエンドからのタグ管理が推奨される選択肢です。

クライアント アプリから登録を管理する場合の 2 つ目の欠点は、アプリはハッキングされる可能性があるので、セクション「タグレベルのセキュリティ」で説明されているように、特定のタグへの登録をセキュリティで保護するために追加の対応が必要になることです。

アプリ バックエンドからの登録の管理

バックエンドから登録を管理するには、追加のコードを作成する必要があります。 デバイスのアプリは、アプリが開始されるたびに (タグとテンプレートと共に) 更新された PNS ハンドルをバックエンドに提供する必要があり、バックエンドはService Busでこのハンドルを更新する必要があります。 この設計について次の図で説明します。

Registration Management

バックエンドから登録を管理する利点は、デバイス上の対応するアプリが非アクティブのときでも登録に対するタグを変更できること、および登録にタグを追加する前にクライアント アプリを認証できることです。

アプリ バックエンドから、登録に対して基本の CRUDS 操作を実行できます。 次に例を示します。

var hub = NotificationHubClient.CreateClientFromConnectionString("{connectionString}", "hubName");
            
// create a registration description object of the correct type, e.g.
var reg = new WindowsRegistrationDescription(channelUri, tags);

// Create
await hub.CreateRegistrationAsync(reg);

// Get by id
var r = await hub.GetRegistrationAsync<RegistrationDescription>("id");

// update
r.Tags.Add("myTag");

// update on hub
await hub.UpdateRegistrationAsync(r);

// delete
await hub.DeleteRegistrationAsync(r);

ノードまたは REST API を使用することもできます。

重要

バックエンドは、登録の更新が複数ある場合のコンカレンシーに対応する必要があります。 Service Bus は、登録管理向けにオプティミスティック コンカレンシーを提供しています。 HTTP レベルでは、これは登録管理操作で ETag を使用することにより実装されます。 この機能は、Microsoft SDK から透過的に使用されます。コンカレンシーの理由で更新が拒否された場合は、例外がスローされます。 このような例外に対応し、必要に応じて更新を再試行する処理は、アプリ バックエンドの役割です。

その他のリソース

次のシナリオのチュートリアルでは、アプリ バックエンドからの登録手順が説明されています。