Xamarin.iOS の拡張ユーザー通知
iOS 10 の新機能であるユーザー通知フレームワークにより、ローカルおよびリモート通知を配信し、処理できるようになります。 このフレームワークを使うと、アプリまたはアプリ拡張機能で場所や時刻などの一連の条件を指定して、ローカル通知の配信をスケジュールできます。
ユーザー通知について
前述したように、新しいユーザー通知フレームワークにより、ローカルおよびリモート通知を配信し、処理できるようになります。 このフレームワークを使うと、アプリまたはアプリ拡張機能で場所や時刻などの一連の条件を指定して、ローカル通知の配信をスケジュールできます。
さらに、アプリまたは拡張機能は、ユーザーの iOS デバイスに配信されるローカルとリモートの通知の両方を受信 (変更も可能) できます。
新しいユーザー通知 UI フレームワークを使用すると、アプリまたはアプリ拡張機能は、ローカル通知とリモート通知がユーザーに表示されたときの両方の外観をカスタマイズできます。
このフレームワークは、アプリがユーザーに通知を配信するための次の方法を提供します。
- ビジュアル アラート - 通知がバナーとして画面の上部からロールダウンします。
- サウンドと振動 - 通知に関連付けることができます。
- アプリ アイコンへのバッジ付与 - アプリのアイコンに、未読メール メッセージの数など、新しいコンテンツが使用可能であることを示すバッジが表示されます。
さらに、ユーザーの現在のコンテキストに応じて、通知を表示するさまざまな方法があります。
- デバイスのロックが解除されている場合、通知はバナーとして画面の上部からロールダウンされます。
- デバイスがロックされている場合は、ユーザーのロック画面に通知が表示されます。
- 通知を見逃したユーザーは、通知センターを開き、利用可能な待機中の通知があればそこで表示できます。
Xamarin.iOS アプリには、送信できる 2 種類のユーザー通知があります。
- ローカル通知 - これらは、ユーザー デバイスにローカルにインストールされたアプリによって送信されます。
- リモート通知 - リモート サーバーから送信されて、ユーザーに表示される、またはアプリのコンテンツのバックグラウンド更新がトリガーされます。
ローカル通知について
iOS アプリが送信できるローカル通知には、次の機能と属性があります。
- ユーザーのデバイス上でローカルなアプリによって送信されます。
- これらは、時間または場所ベースのトリガーを使用するように構成できます。
- アプリはユーザーのデバイスで通知をスケジュールし、トリガー条件が満たされると表示されます。
- ユーザーが通知を操作すると、アプリはコールバックを受け取ります。
ローカル通知の例を次に示します。
- 予定表のアラート
- リマインダー アラート
- 場所に対応するトリガー
詳細については、Apple のローカルおよびリモート通知プログラミング ガイドのドキュメントを参照してください。
リモート通知について
iOS アプリが送信できるリモート通知には、次の機能と属性があります。
- アプリには、通信するサーバー側コンポーネントがあります。
- Apple Push Notification Service (APNs) は、開発者のクラウド ベースのサーバーからユーザーのデバイスにリモート通知のベスト エフォート配信を送信するために使用されます。
- アプリがリモート通知を受信すると、ユーザーに表示されます。
- ユーザーが通知を操作すると、アプリはコールバックを受け取ります。
リモート通知の例を次に示します。
- ニュース アラート
- スポーツ情報のアップデート
- インスタント メッセージングのメッセージ
iOS アプリでは、次の 2 種類のリモート通知を使用できます。
- ユーザー向け - これらはデバイス上でユーザーに表示されます。
- サイレント更新 - バックグラウンドで iOS アプリの内容を更新するメカニズムを提供します。 サイレント更新を受信すると、アプリはリモート サーバーにアクセスして最新のコンテンツをプルダウンできます。
詳細については、Apple のローカルおよびリモート通知プログラミング ガイドのドキュメントを参照してください。
既存の通知 API について
iOS 10 より前の iOS アプリは、UIApplication
を使用して、システムに通知を登録し、その通知をトリガーする方法 (時間または場所によって) をスケジュールしていました。
開発者が既存の通知 API を使用するときに発生する可能性があるいくつかの問題があります。
- ローカル通知またはリモート通知に必要なコールバックが異なっていたため、コードが重複する可能性がありました。
- アプリでは、システムでスケジュールされた後の通知の制御が制限されていました。
- Apple の既存のすべてのプラットフォームで異なるレベルのサポートがありました。
新しいユーザー通知フレームワークについて
iOS 10 では、Apple は新しいユーザー通知フレームワークを導入しました。これは、上記の既存の UIApplication
メソッドに代わるものです。
ユーザー通知フレームワークには、次のものが用意されています。
- 前のメソッドの機能パリティを含む使い慣れた API により、既存のフレームワークからコードを簡単に移植できます。
- より豊富な通知をユーザーに送信できるコンテンツ オプションの拡張セットが含まれています。
- ローカル通知とリモート通知の両方を、同じコードとコールバックで処理できます。
- ユーザーが通知を操作するときにアプリに送信されるコールバックを処理するプロセスを簡略化します。
- 通知を削除または更新する機能など、保留中の通知と配信済み通知の両方の管理を強化しました。
- 通知のアプリ内表示を行う機能を追加します。
- アプリ拡張機能内から通知をスケジュールして処理する機能を追加します。
- 通知自体の新しい拡張ポイントを追加します。
新しいユーザー通知フレームワークは、Apple がサポートする次のような複数のプラットフォームにわたって統合された通知 API を提供します。
- iOS - 通知を管理およびスケジュールするための完全なサポート。
- tvOS - ローカル通知とリモート通知のアプリ アイコンにバッジを付与する機能を追加します。
- watchOS - ユーザーのペアリングされた iOS デバイスから Apple Watch に通知を転送する機能を追加し、ウォッチ アプリがウォッチ自体で直接ローカル通知を行う機能を提供します。
- macOS - 通知の管理およびスケジュールが完全にサポートされます。
詳細については、Apple の UserNotifications フレームワーク リファレンスと UserNotificationsUI のドキュメントを参照してください。
通知配信の準備
iOS アプリがユーザーに通知を送信する前に、アプリをシステムに登録する必要があります。また、通知はユーザーにとっては中断であるため、通知を送信する前にアプリから明示的にアクセス許可を要求する必要があります。
ユーザーがアプリに対して承認できる通知要求には、次の 3 つのレベルがあります。
- バナーが表示されます。
- サウンド アラートが鳴ります。
- アプリ アイコンにバッジが付与されます。
さらに、これらの承認レベルを要求し、ローカル通知とリモート通知の両方に対して設定する必要があります。
次のコードを AppDelegate
の FinishedLaunching
メソッドに追加し、目的の通知の種類 (UNAuthorizationOptions
) を設定することで、アプリが起動するとすぐに通知のアクセス許可を要求する必要があります。
Note
UNUserNotificationCenter
は、iOS 10 以降からのみ使用できます。 そのため、要求を送信する前に macOS のバージョンを確認することをお勧めします。
using UserNotifications;
...
public override bool FinishedLaunching (UIApplication application, NSDictionary launchOptions)
{
// Version check
if (UIDevice.CurrentDevice.CheckSystemVersion (10, 0)) {
// Request notification permissions from the user
UNUserNotificationCenter.Current.RequestAuthorization (UNAuthorizationOptions.Alert, (approved, err) => {
// Handle approval
});
}
return true;
}
この API は統合されており、Mac 10.14 以降でも動作するため、macOS を対象としている場合は、できるだけ早く通知のアクセス許可を確認する必要があります。
using UserNotifications;
...
public override void DidFinishLaunching (NSNotification notification)
{
// Check we're at least v10.14
if (NSProcessInfo.ProcessInfo.IsOperatingSystemAtLeastVersion (new NSOperatingSystemVersion (10, 14, 0))) {
// Request notification permissions from the user
UNUserNotificationCenter.Current.RequestAuthorization (UNAuthorizationOptions.Alert | UNAuthorizationOptions.Badge | UNAuthorizationOptions.Sound, (approved, err) => {
// Handle approval
});
}
}
> [!NOTE]
> With MacOS apps, for the permission dialog to appear, you must sign your macOS app, even if building locally in DEBUG mode. Therefore, **Project->Options->Mac Signing->Sign the application bundle** must be checked.
Additionally, a user can always change the notification privileges for an app at any time using the **Settings** app on the device. The app should check for the user's requested notification privileges before presenting a notification using the following code:
```csharp
// Get current notification settings
UNUserNotificationCenter.Current.GetNotificationSettings ((settings) => {
var alertsAllowed = (settings.AlertSetting == UNNotificationSetting.Enabled);
});
リモート通知環境の構成
iOS 10 を初めて使用する開発者は、開発または運用としてどの環境でプッシュ通知が実行されるかを OS に通知する必要があります。 この情報を入力しないと、iTune App Store に送信されたときにアプリが拒否され、次のような通知が表示される可能性があります。
プッシュ通知の権利がありません - アプリには Apple のプッシュ通知サービス用の API が含まれていますが、アプリの署名に
aps-environment
のエンタイトルメントがありません。
必要なエンタイトルメントを提供するには、次の操作を行います。
リモート通知の登録
アプリがリモート通知を送受信する場合でも、既存の UIApplication
API を使用してトークン登録を行う必要があります。 この登録では、デバイスにライブ ネットワーク接続アクセス APNs が必要です。これにより、アプリに送信される必要なトークンが生成されます。 アプリは、リモート通知に登録するために、このトークンを開発者のサーバー側アプリに転送する必要があります。
次のコードを使用して、必要な登録を初期化します。
UIApplication.SharedApplication.RegisterForRemoteNotifications ();
開発者のサーバー側アプリに送信されるトークンは、リモート通知を送信するときにサーバーから APNs に送信される通知ペイロードの一部として含める必要があります。
トークンは、通知とアプリを結び付けるキーとして機能し、通知を開いたり応答したりするために使用されます。
詳細については、Apple のローカルおよびリモート通知プログラミング ガイドのドキュメントを参照してください。
通知配信
アプリが完全に登録され、必要なアクセス許可がユーザーから要求され、付与されると、アプリが通知を送受信する準備が整います。
通知コンテンツの提供
iOS 10 の新機能として、すべての通知には、通知コンテンツの本文と共に常に表示されるタイトルとサブタイトルの両方が含まれています。 また、通知コンテンツにメディア添付ファイルを追加する新しい機能もあります。
ローカル通知の内容を作成するには、次のコードを使用します。
var content = new UNMutableNotificationContent();
content.Title = "Notification Title";
content.Subtitle = "Notification Subtitle";
content.Body = "This is the message body of the notification.";
content.Badge = 1;
リモート通知の場合、プロセスは次のようになります。
{
"aps":{
"alert":{
"title":"Notification Title",
"subtitle":"Notification Subtitle",
"body":"This is the message body of the notification."
},
"badge":1
}
}
通知送信のスケジュール設定
通知の内容を作成したら、トリガーを設定して通知をユーザーに表示するタイミングをアプリでスケジュールする必要があります。 iOS 10 には、次の 4 種類のトリガーが用意されています。
- プッシュ通知 - リモート通知でのみ使用され、APNs がデバイス上で実行されているアプリに通知パッケージを送信するとトリガーされます。
- 時間間隔 - 今始まって将来のある時点で終了する時間間隔からローカル通知をスケジュールできます。 たとえば、
var trigger = UNTimeIntervalNotificationTrigger.CreateTrigger (5, false);
のように指定します。 - カレンダーの日付 - ローカル通知を特定の日時にスケジュールできます。
- 場所ベース - iOS デバイスが特定の地理的な場所に入るか離れるとき、または Bluetooth ビーコンに近い場所にあるときに、ローカル通知がスケジュールされるようにできます。
ローカル通知の準備ができたら、アプリは UNUserNotificationCenter
オブジェクトの Add
メソッドを呼び出して、ユーザーに表示をスケジュールする必要があります。 リモート通知の場合、サーバー側アプリは通知ペイロードを APNs に送信し、APNs はパケットをユーザーのデバイスに送信します。
すべての部分をまとめると、サンプルのローカル通知は次のようになります。
using UserNotifications;
...
var content = new UNMutableNotificationContent ();
content.Title = "Notification Title";
content.Subtitle = "Notification Subtitle";
content.Body = "This is the message body of the notification.";
content.Badge = 1;
var trigger = UNTimeIntervalNotificationTrigger.CreateTrigger (5, false);
var requestID = "sampleRequest";
var request = UNNotificationRequest.FromIdentifier (requestID, content, trigger);
UNUserNotificationCenter.Current.AddNotificationRequest (request, (err) => {
if (err != null) {
// Do something with error...
}
});
フォアグラウンド アプリ通知の処理
iOS 10 の新機能では、アプリがフォアグラウンドにあり、通知がトリガーされたときに、通知を異なる方法で処理できます。 UNUserNotificationCenterDelegate
を提供して WillPresentNotification
メソッド実装することで、アプリは通知を表示する制御を引き継ぐことができます。 次に例を示します。
using System;
using UserNotifications;
namespace MonkeyNotification
{
public class UserNotificationCenterDelegate : UNUserNotificationCenterDelegate
{
#region Constructors
public UserNotificationCenterDelegate ()
{
}
#endregion
#region Override Methods
public override void WillPresentNotification (UNUserNotificationCenter center, UNNotification notification, Action<UNNotificationPresentationOptions> completionHandler)
{
// Do something with the notification
Console.WriteLine ("Active Notification: {0}", notification);
// Tell system to display the notification anyway or use
// `None` to say we have handled the display locally.
completionHandler (UNNotificationPresentationOptions.Alert);
}
#endregion
}
}
このコードは、UNNotification
の内容をアプリケーション出力に書き出し、通知の標準アラートを表示するようにシステムに要求するだけです。
アプリがフォアグラウンドのときに通知自体を表示し、システムの既定値を使用しない場合は、完了ハンドラーに None
を渡します。 例:
completionHandler (UNNotificationPresentationOptions.None);
このコードを配置した状態で、編集用の AppDelegate.cs
ファイルを開き、FinishedLaunching
メソッドを次のように変更します。
public override bool FinishedLaunching (UIApplication application, NSDictionary launchOptions)
{
// Request notification permissions from the user
UNUserNotificationCenter.Current.RequestAuthorization (UNAuthorizationOptions.Alert, (approved, err) => {
// Handle approval
});
// Watch for notifications while the app is active
UNUserNotificationCenter.Current.Delegate = new UserNotificationCenterDelegate ();
return true;
}
このコードは、アプリがアクティブな状態でフォアグラウンドにある間に通知を処理できるように、現在の UNUserNotificationCenter
に、前述のカスタム UNUserNotificationCenterDelegate
をアタッチしています。
通知管理
iOS 10 の新機能である通知管理では、保留中の通知と配信済み通知の両方にアクセスでき、これらの通知を削除、更新、または昇格する機能が追加されます。
通知管理の重要な部分は要求識別子で、通知が作成され、システムでスケジュールされたときに通知に割り当てられます。 リモート通知の場合、これは HTTP 要求ヘッダーの新しい apps-collapse-id
フィールドを介して割り当てられます。
要求識別子は、アプリが通知管理を実行する通知を選択するために使用されます。
通知の削除
保留中の通知をシステムから削除するには、次のコードを使用します。
var requests = new string [] { "sampleRequest" };
UNUserNotificationCenter.Current.RemovePendingNotificationRequests (requests);
既に配信されている通知を削除するには、次のコードを使用します。
var requests = new string [] { "sampleRequest" };
UNUserNotificationCenter.Current.RemoveDeliveredNotifications (requests);
既存の通知の更新
既存の通知を更新するには、必要なパラメーター (新しいトリガー時刻など) を変更して新しい通知を作成し、変更する必要がある通知と同じ要求識別子を使用してシステムに追加するだけです。 例:
using UserNotifications;
...
// Rebuild notification
var content = new UNMutableNotificationContent ();
content.Title = "Notification Title";
content.Subtitle = "Notification Subtitle";
content.Body = "This is the message body of the notification.";
content.Badge = 1;
// New trigger time
var trigger = UNTimeIntervalNotificationTrigger.CreateTrigger (10, false);
// ID of Notification to be updated
var requestID = "sampleRequest";
var request = UNNotificationRequest.FromIdentifier (requestID, content, trigger);
// Add to system to modify existing Notification
UNUserNotificationCenter.Current.AddNotificationRequest (request, (err) => {
if (err != null) {
// Do something with error...
}
});
既に配信されている通知の場合、既存の通知が更新されて、ホーム画面およびロック画面の一覧の一番上に昇格され、ユーザーが既に読み取っている場合は通知センターで昇格されます。
通知アクションの操作
iOS 10 では、ユーザーに配信される通知は静的ではなく、ユーザーが操作できるいくつかの方法 (組み込みアクションからカスタム アクションまで) を提供します。
iOS アプリが応答できるアクションには、次の 3 種類があります。
- 既定のアクション - これは、ユーザーが通知をタップしてアプリを開き、指定された通知の詳細を表示した場合です。
- カスタム アクション - これらは iOS 8 で追加され、ユーザーがアプリを起動しなくても通知から直接カスタム タスクを実行するための簡単な方法を提供します。 これらは、カスタマイズ可能なタイトルを含むボタンの一覧として、またはテキスト入力フィールドのいずれかとして表示され、バックグラウンド (アプリが要求を満たすのに少し時間がかかることがあります) またはフォアグラウンド (要求を満たすためにフォアグラウンドでアプリが起動された場合) のいずれかで実行できます。 カスタム アクションは、iOS と watchOS の両方で使用できます。
- 無視アクション - ユーザーが特定の通知を閉じると、このアクションがアプリに送信されます。
カスタム アクションの作成
カスタム アクションを作成してシステムに登録するには、次のコードを使用します。
// Create action
var actionID = "reply";
var title = "Reply";
var action = UNNotificationAction.FromIdentifier (actionID, title, UNNotificationActionOptions.None);
// Create category
var categoryID = "message";
var actions = new UNNotificationAction [] { action };
var intentIDs = new string [] { };
var categoryOptions = new UNNotificationCategoryOptions [] { };
var category = UNNotificationCategory.FromIdentifier (categoryID, actions, intentIDs, UNNotificationCategoryOptions.None);
// Register category
var categories = new UNNotificationCategory [] { category };
UNUserNotificationCenter.Current.SetNotificationCategories (new NSSet<UNNotificationCategory>(categories));
新しい UNNotificationAction
を作成すると、ボタンに表示される一意の ID とタイトルが割り当てられます。 既定では、アクションはバックグラウンド アクションとして作成されますが、アクションの動作 (フォアグラウンド アクションに設定するなど) を調整するためのオプションを指定できます。
作成された各アクションは、カテゴリに関連付ける必要があります。 新しい UNNotificationCategory
を作成すると、一意の ID、実行できるアクションの一覧、カテゴリ内のアクションの意図に関する詳細情報を提供する意図 ID の一覧、カテゴリの動作を制御するためのいくつかのオプションが割り当てられます。
最後に、すべてのカテゴリが SetNotificationCategories
メソッドを使用してシステムに登録されます。
カスタム アクションの表示
一連のカスタム アクションとカテゴリが作成され、システムに登録されると、ローカル通知またはリモート通知から表示できます。
リモート通知の場合は、上記で作成したカテゴリのいずれかに一致するリモート通知ペイロードに category
を設定します。 次に例を示します。
{
aps:{
alert:"Hello world!",
category:"message"
}
}
ローカル通知の場合は、UNMutableNotificationContent
オブジェクトの CategoryIdentifier
プロパティを設定します。 次に例を示します。
var content = new UNMutableNotificationContent ();
content.Title = "Notification Title";
content.Subtitle = "Notification Subtitle";
content.Body = "This is the message body of the notification.";
content.Badge = 1;
content.CategoryIdentifier = "message";
...
ここでも、この ID は、上記で作成されたカテゴリのいずれかと一致する必要があります。
無視アクションの処理
前述のように、ユーザーが通知を閉じると、無視アクションをアプリに送信できます。 これは標準のアクションではないため、カテゴリの作成時にオプションを設定する必要があります。 次に例を示します。
var categoryID = "message";
var actions = new UNNotificationAction [] { action };
var intentIDs = new string [] { };
var categoryOptions = new UNNotificationCategoryOptions [] { };
var category = UNNotificationCategory.FromIdentifier (categoryID, actions, intentIDs, UNNotificationCategoryOptions.CustomDismissAction);
アクション応答の処理
ユーザーが上記で作成したカスタム アクションとカテゴリを操作する場合、アプリは要求されたタスクを実行する必要があります。 これを行うには、UNUserNotificationCenterDelegate
を指定し、UserNotificationCenter
メソッドを実装します。 次に例を示します。
using System;
using UserNotifications;
namespace MonkeyNotification
{
public class UserNotificationCenterDelegate : UNUserNotificationCenterDelegate
{
...
#region Override Methods
public override void DidReceiveNotificationResponse (UNUserNotificationCenter center, UNNotificationResponse response, Action completionHandler)
{
// Take action based on Action ID
switch (response.ActionIdentifier) {
case "reply":
// Do something
break;
default:
// Take action based on identifier
if (response.IsDefaultAction) {
// Handle default action...
} else if (response.IsDismissAction) {
// Handle dismiss action
}
break;
}
// Inform caller it has been handled
completionHandler();
}
#endregion
}
}
渡された UNNotificationResponse
クラスには、既定のアクションまたは無視アクションを指定できる ActionIdentifier
プロパティがあります。 カスタム アクションをテストするために response.Notification.Request.Identifier
を使用します。
UserText
プロパティは、ユーザー テキスト入力の値を保持します。 Notification
プロパティは、トリガーと通知コンテンツの要求を含む、元の通知を保持します。 アプリは、トリガーの種類に基づいて、ローカル通知とリモート通知のどちらを使用したかを判断できます。
Note
iOS 12 を使用すると、カスタム通知 UI でランタイムにそのアクション ボタンを変更できます。 詳細については、動的通知アクション ボタンのドキュメントを参照してください。
サービス拡張機能の使用
リモート通知を使用する場合、サービス拡張機能は通知ペイロード内でエンドツーエンドの暗号化を有効にする方法を提供します。 サービス拡張機能は、ユーザーに表示される前に通知の表示コンテンツを拡張または置き換えることを主な目的としてバックグラウンドで実行される非ユーザー インターフェイス拡張機能 (iOS 10 で利用可能) です。
サービス拡張機能は、迅速に実行されることが前提とされており、システムによって実行時間に短い期間が与えられています。 割り当てられた時間内にサービス拡張機能がタスクを完了できなかった場合は、フォールバック メソッドが呼び出されます。 フォールバックが失敗すると、元の通知コンテンツがユーザーに表示されます。
サービス拡張機能の潜在的な用途には、次のようなものがあります。
- リモート通知コンテンツのエンドツーエンドの暗号化を提供します。
- 添付ファイルを追加してリモート通知を強化します。
サービス拡張機能の実装
Xamarin.iOS アプリでサービス拡張機能を実装するには、次の操作を行います。
重要
サービス拡張機能のバンドル識別子は、メイン アプリのバンドル識別子と一致するように、末尾に .appnameserviceextension
を追加する必要があります。 たとえば、メイン アプリに com.xamarin.monkeynotify
のバンドル識別子が含まれている場合、サービス拡張機能のバンドル識別子は com.xamarin.monkeynotify.monkeynotifyserviceextension
にする必要があります。 これは、拡張機能がソリューションに追加されたときに自動的に設定されます。
Notification Service の拡張機能には、必要な機能を提供するために変更する必要があるメイン クラスが 1 つあります。 次に例を示します。
using System;
using Foundation;
using UIKit;
using UserNotifications;
namespace MonkeyChatServiceExtension
{
[Register ("NotificationService")]
public class NotificationService : UNNotificationServiceExtension
{
#region Computed Properties
public Action<UNNotificationContent> ContentHandler { get; set; }
public UNMutableNotificationContent BestAttemptContent { get; set; }
#endregion
#region Constructors
protected NotificationService (IntPtr handle) : base (handle)
{
// Note: this .ctor should not contain any initialization logic.
}
#endregion
#region Override Methods
public override void DidReceiveNotificationRequest (UNNotificationRequest request, Action<UNNotificationContent> contentHandler)
{
ContentHandler = contentHandler;
BestAttemptContent = (UNMutableNotificationContent)request.Content.MutableCopy ();
// Modify the notification content here...
BestAttemptContent.Title = $"{BestAttemptContent.Title}[modified]";
ContentHandler (BestAttemptContent);
}
public override void TimeWillExpire ()
{
// Called just before the extension will be terminated by the system.
// Use this as an opportunity to deliver your "best attempt" at modified content, otherwise the original push payload will be used.
ContentHandler (BestAttemptContent);
}
#endregion
}
}
最初のメソッド DidReceiveNotificationRequest
は、request
オブジェクトを介して通知識別子と通知コンテンツを渡されます。 ユーザーに通知を表示するには、渡された contentHandler
を呼び出す必要があります。
2 番目のメソッド TimeWillExpire
は、サービス拡張機能が要求を処理するための時間が不足しそうになる直前に呼び出されます。 割り当てられた時間内にサービス拡張機能が contentHandler
の呼び出しに失敗した場合、元のコンテンツがユーザーに表示されます。
サービス拡張機能のトリガー
アプリで作成して配信したサービス拡張機能は、デバイスに送信されるリモート通知ペイロードを変更することでトリガーできます。 次に例を示します。
{
aps : {
alert : "New Message Available",
mutable-content: 1
},
encrypted-content : "#theencryptedcontent"
}
新しい mutable-content
キーは、リモート通知コンテンツを更新するためにサービス拡張機能を起動する必要があることを指定します。 encrypted-content
キーは、サービス拡張機能がユーザーに提示する前に復号化できる暗号化されたデータを保持します。
次のサービス拡張機能の例を見てみましょう。
using UserNotification;
namespace myApp {
public class NotificationService : UNNotificationServiceExtension {
public override void DidReceiveNotificationRequest(UNNotificationRequest request, contentHandler) {
// Decrypt payload
var decryptedBody = Decrypt(Request.Content.UserInfo["encrypted-content"]);
// Modify Notification body
var newContent = new UNMutableNotificationContent();
newContent.Body = decryptedBody;
// Present to user
contentHandler(newContent);
}
public override void TimeWillExpire() {
// Handle out-of-time fallback event
...
}
}
}
このコードは、encrypted-content
キーから暗号化されたコンテンツを復号化し、新しい UNMutableNotificationContent
を作成し、Body
プロパティを復号化されたコンテンツに設定し、ユーザーに通知を表示するために contentHandler
を使用します。
まとめ
この記事では、ユーザー通知が iOS 10 によって強化されたすべての方法について説明しました。 新しいユーザー通知フレームワークと、Xamarin.iOS アプリまたはアプリ拡張機能でそれの使用方法を示しました。