ローカル通知の管理をアプリ内で柔軟に行いたいときに活用できるのが UNUserNotificationCenter.current().getPendingNotificationRequests
です。
これは通知をスケジュールした後、どの通知がまだ保留状態にあるのかを確認・取得できるAPI。
特定の通知のキャンセルや状態確認、リスト表示などに役立ちます。
この記事では getPendingNotificationRequests
の基本的な意味や使い方、主要な引数、活用シーン、注意点までをわかりやすく丁寧に解説します。
getPendingNotificationRequestsとは?
getPendingNotificationRequests(completionHandler:)
は、UserNotifications フレームワーク に含まれる UNUserNotificationCenter クラス のインスタンスメソッド です。
ユーザー通知センター (UNUserNotificationCenter
) にある現在保留中のローカル通知リクエスト一覧を非同期的に取得してくれます。
このメソッドを使うことで、アプリがスケジュールした通知(トリガーを待っている状態)の一覧を取得し、確認・表示・削除などの処理を行うことができます。
通知がすでに発火されたものは含まれず、まだ発火前の保留状態の通知のみが対象となります。
具体例:保留中の通知を取得・表示する
以下は、保留中の通知リクエストを取得してコンソールに出力するサンプルコードです。
1 2 3 4 5 6 7 8 9 10 11 |
import UserNotifications UNUserNotificationCenter.current().getPendingNotificationRequests { requests in for request in requests { print("通知ID: \(request.identifier)") print("タイトル: \(request.content.title)") print("本文: \(request.content.body)") print("トリガー: \(String(describing: request.trigger))") } } |
このコードでは、各通知の identifier
(通知識別子)、content
(通知本文)、および trigger
(トリガー条件)を順に出力しています。
これを使えば、保留中の通知が何件あるのか、どんな内容かをアプリ内で動的に取得して処理できます。
主要な引数とその意味
getPendingNotificationRequests
は非同期APIで、クロージャ内で取得結果が渡されます。
指定するのは completionHandler
のみです。
引数名 | 型 | 説明 |
---|---|---|
completionHandler | ([UNNotificationRequest]) -> Void |
保留中の通知リクエストを受け取る非同期クロージャ |
受け取る配列の要素 UNNotificationRequest
は、スケジュールされた1つ1つの通知の情報(ID、コンテンツ、トリガーなど)を表します。
getPendingNotificationRequestsの活用シーン
getPendingNotificationRequests
は以下のような場面で活躍します。
- 現在スケジュールされている通知を一覧表示したいとき
- 通知のキャンセル対象を判断したいとき(特定IDのみ削除など)
- デバッグ用途で現在の通知状況を確認したいとき
- 通知の重複スケジュールを防止したいとき(同一内容の通知が複数回セットされていないか確認)
- 設定済みの通知をアプリ内で可視化したいとき(設定画面など)
このように、通知機能が動的な管理を必要とするアプリでは非常に便利なAPIです。
getPendingNotificationRequests を使うときの注意点
getPendingNotificationRequests
は便利なメソッドですが、実際にアプリで利用する際にはいくつか注意しておくべき点があります。
これらを理解しておくことで、想定外の動作を避け、通知管理を安全に実装できます。
1. 非同期処理である
このメソッドは 非同期的に通知リストを返す 仕組みになっています。
呼び出した直後には結果が得られず、クロージャ内で結果を受け取ります。
そのため、UI の更新や状態管理は必ず メインスレッドに戻して 行う必要があります。
1 2 3 4 5 6 |
UNUserNotificationCenter.current().getPendingNotificationRequests { requests in DispatchQueue.main.async { self.notifications = requests // UI更新は必ずメインスレッドで } } |
2. 通知許可が前提
ユーザーが通知を拒否している場合、通知はそもそもスケジュールされません。
その状態で getPendingNotificationRequests
を呼んでも 結果は空配列 になります。
利用前に getNotificationSettings()
で許可状況をチェックするのが実践的です。
3. 取得できるのは「保留中の通知」のみ
取得できるのは まだ発火していない通知 に限られます。
すでに通知センターに表示された通知や、履歴として残っているものは取得できません。
「今後送られる予定の通知を確認・管理するためのAPI」として使うのが正しい使い方です。
4. 通知数の上限に注意
iOSでは 最大64件 までしかローカル通知をスケジュールできません。
これを超えると古い通知から自動的に削除される仕様です。
大量の通知を扱うアプリでは、定期的に getPendingNotificationRequests
を呼んで通知を整理し、不要なものを削除する仕組みを取り入れると安全です。
まとめ
今回は UNUserNotificationCenter.current().getPendingNotificationRequests
について詳しく紹介しました。
- このメソッドは、現在保留中のローカル通知リクエストを非同期で取得するためのAPI
- 非同期クロージャ内で
[UNNotificationRequest]
を受け取り、各通知の詳細にアクセス可能 - 保留中の通知一覧の取得、キャンセル対象の判断、通知の重複管理などに活用できる
- 非同期である点や通知許可の状態などに注意して使う必要がある
ローカル通知をより柔軟に管理したい時、保留中の通知の状態を把握・制御したい時に、非常に強力なツールとなります。
通知の設計・制御に getPendingNotificationRequests
を積極的に取り入れて、より良いユーザー体験を提供しましょう。