Core Location Monitorの概要

♪ ♪

みなさん こんにちは Core Location Frameworksチームの エンジニア Nivash Raaja Karukankaatur Murugasamy です Core Location Monitorについての 私の講演にようこそ 新しいCLMonitor APIについてお話 できることをとても嬉しく思います Swiftのわずか数行のコードで シンプルかつ強力な モニタリングロジックを書くことができます モニターを作成し 条件を追加し イベントを待つだけです これです こんにちは CLMonitor！ それでは CLMonitor APIの詳細を 見ていきましょう まず ユーザーの位置情報やビーコンを モニターするためのシンプルで強力な 新しい方法 CLMonitor APIの 概要から説明します それから モニターできる条件の種類と 追加したり削除したりする方法について 説明します 次に モニタリングレコードと そのコンテンツ そしてアプリのライフサイクル中にどう アクセスできるのかを説明します 続いて モニターしている条件のいずれかが イベントに遭遇した場合に アプリで取る必要のある手順を示します 最後に CLMonitorを使用する際に役立つ いくつかの要件と推奨事項で 締めくくります まず モニターとは何か そしてモニターを作るには どうすればよいかを見ていきましょう

CLMonitorは Swiftの トップレベルのアクターで 各CLMonitorインスタンスは モニタリングのゲートウェイとして機能します アクターであるため スレッドやタスクの 同期のオーバーヘッドから 解放されます そのため CLMonitorのコンテンツに アクセスしたり いつでも条件を 追加したり削除したりするには ただ待機する必要があります モニターを作成するには モニターのinitメソッドを 英数字の文字列で呼び出します その名前の先行モニターが存在しない場合 新しいモニターが作成されます そうでなければ 既存のものが開かれます いずれにしても モニターインスタンスが 返されます 指定された名前のインスタンスは 常に1つしか開けないことを注意します モニターされる実体はコンディションと 呼ばれます CLMonitorインスタンスにモニター コンディションを追加し addメソッドを使用して 識別子と関連付けることができます 識別子は英数字の文字列です 例えば この例の"Work"は ユーザーが仕事中であるときに 満たされるコンディションのレコードを 一意に識別します レコードオブジェクトとそのコンテンツは この識別子によってアクセシブルとなり その状態が取り除かれるまで モニターされます 同じ識別子でremoveを呼び出すことで コンディションをモニターから外すことが できます コンディションを削除すると 対応するレコードも削除されます モニターインスタンスの作成方法と コンディションとの関係がわかったところで 利用可能なコンディションのタイプと それを作成してモニターに追加する方法を 見てみましょう iOSでは2種類の条件が サポートされています まずは CircularGeographicConditionです 円形の地理的コンディションは 中心と半径によって定義されます センターは コンディションの 地理的位置を定義します 半径は コンディションが満たされたと みなされる範囲を定義します それ以外の地域は 不満足なコンディションとして報告されます これはiOS 16以前のリリースにおける CLCircularRegionと同様です 中心を定義するには 目的の緯度と経度で CLLocationCoordinate2Dを作成します 次に その中心と目的のある半径で CircularGeographicConditionを作成します iOSでサポートされる他のコンディションは BeaconIdentityConditionです BeaconIdentityConditionは iOS 16や それ以前のリリースで使ったことのある CLBeaconIdentityConstraintや CLBeaconRegionに似ています 異なる場所に複数のサイトを持つ 企業であれば ビーコンを配置することで ユーザーがいずれかのサイトにいるのか 特定のサイトにいるのか あるいは 特定のサイトの特定のセクションに いるのかを アプリで検出することができます

複数の拠点のオフィスで利用できる Appleのカフェテリアを 簡単な例として 考えてみましょう 関連アプリで位置情報に基づいた動作を 可能にするために ビーコンをどう効果的に展開できるかを 見てみましょう さらに 様々な状況下で BeaconIdentityConditionを 使い分けることで アプリがどのようにビーコンを モニターできるかを説明します ビーコンを定義するものを簡単に 見てみましょう UUID文字列 メジャー番号 マイナー番号が 含まれます BeaconIdentityConditionを使えば UUID メジャー マイナーの 3つすべてを指定することで 特定のビーコンをモニターできます また UUIDとメジャーだけ あるいは UUIDだけを指定して ビーコングループから 任意の1つのビーコンを ワイルドカード検索することもできます マイナーまたはメジャーとマイナーを 未指定のままにしておくと それらのプロパティに任意の値を持つ ビーコンがマッチする可能性があります この例でどのように使えるか見てみましょう これらのカフェテリアにすべてが同じ UUIDを持つビーコンを配置できます そして アプリでは このUUIDをモニターする BeaconIdentityConditionを 作成することができます そして ユーザーがこれらのビーコンの いずれかに近づくと コンディションが満たされます そうでない場合は不満足と判断されます コードでは UUIDだけを指定した initメソッドを呼び出すことで これを行うことができます 必要な場所にビーコンを配置したので ユーザーが特定のサイトの いずれかにいるかどうかを検出することに 興味があるかもしれません 今回はユーザーがApple Parkサイトにいるか どうかをモニターする方法を見てみましょう これを実現するために 各サイトに 配置されたビーコンは 一意のメジャー番号を共有しなければ なりません そして アプリで そのメジャーと 全体のUUIDを持つ BeaconIdentityConditionを モニターできます コンディションの状態は ビーコンが UUIDとメジャー値の両方に一致する サイトにデバイスがあるときのみ 満たされたと判断されます 他のサイトでは不満足なままでしょう コードでは UUIDとメジャーだけを指定した initメソッドを呼び出すことで BeaconIdentityConditionを作成できます

これで すべてのサイトまたは特定の サイトをモニターする方法がわかりました しかし 特定のサイト内の特定の セクションをモニターすることもできます これは 各サイト内の異なる場所 例えば料理ステーションに 対応するマイナー値を持つビーコンを 配置することで実現できます アプリでは UUIDとメジャー値とともに 特定のマイナー値の BeaconIdentityConditionを モニターできます このようなコンディションは 全体的なUUIDとメジャーだけでなく そのマイナーを持つビーコンが 検出されたときにのみ満たされます コード上では UUID メジャー マイナーを渡して BeaconIdentityConditionを 作成することになります BeaconIdentityConditionを作成するときは 必要なinitメソッドを使用します さて様々なタイプや特性のコンディションを 作成する方法がわかったところで モニタリングのためにコンディションを 追加する方法を見てみましょう

CLMonitorインスタンスにidentifierと 呼ばれる英数字の文字列を指定して addメソッドを呼び出すことで モニタリングコンディションを追加できます コンディションは識別子に関連付けられます 与えられた識別子ですでにモニター されているコンディションがある場合 それは渡された新しいコンディションに 置き換えられます コンディションを追加すると Core Locationによって決定されるまで 初期状態は不明となります コンディションを追加する前に そのコンディションの現状を把握している インスタンスもあるでしょう このような場合 モニタリングの追加時に 状態を渡すことで デフォルトの初期状態を上書きできます この例では アプリはあなたがApple Parkの 敷地内にいないと推測し そのため条件が満たされないことを 見込むと仮定しましょう 呼び出しに"assuming: .unsatisfied"を 加えることができます そして 状態をunsatisfiedに設定して モニタリングを開始します でも 心配無用です もし あなたが想定している状態が 間違っていたとしても Core Locationは それが確定すれば 正しい状態を教えてくれます コンディションをモニターから外すには コンディションが追加されたときに 渡された識別子でremoveメソッドを 呼び出します これで コンディションとは何か どのようなタイプがサポートされているか モニタリングからコンディションを追加 または削除する方法がわかったと思います レコードのコンテンツと モニター内の 1つのレコードまたはすべてのレコードを いつでも検査できるようにする方法を 詳しく見てみましょう 先ほどのスライドを思い出し モニタリングのコンディションを追加すると Core Locationはレコードを作成し そのレコードにコンディションを追加します レコードはコンディションに加えイベントと 呼ばれる別のオブジェクトが含まれます

このイベントは 満足 不満足 または不明かどうかに関わらず コンディションの現在の 観測された状態を表す状態と コンディションがその状態に遭遇した 日時を含みます なぜイベントに別のコンディションの インスタンスがあるか不思議かもしれません これをリファインメントと呼びます 何に使うのでしょうか？ BeaconIdentityConditionから 思い出すことができれば アプリはUUIDだけ またはUUIDとメジャー もしくはUUIDとメジャー マイナーと併せて モニターすることができます メジャーとマイナーのワイルドカードが 指定されたコンディションが満たされた場合 そのイベントはリファインメントが 適用された状態で配信されます そのリファインメントコンディションは UUIDだけでなく 観測されたビーコンのメジャーとマイナーの 情報も伝えます そして 条件が満たされなくなると リファインメントはリセットされ ゼロになります 条件が追加されたときに渡された 識別子によって 一意にアドレス指定された各レコードを持つ レコードの複数のインスタンスが 存在することができます コンディションをlastEventsと 識別子に関連付けた モニターのレコードはすべて あなたのアプリに保存されます これにより いつでも最後に観測された コンディションとそれに対応する状態を 問い合わせることができます コードを見てみましょう あるコンディションに関連づけられた レコードを検索するには その識別子でrecordメソッドを 呼び出します 渡された識別子でモニターされている コンディションがない場合は ゼロが返されます 次に conditionプロパティに アクセスすることで 基礎となるモニターコンディションを 取得できます そして lastEventプロパティにアクセス することで そのコンディションで アプリに配信されたlastEventを 取得できます そしてイベントから 直近に観測された状態 日付 リファインメントを取得できます これで1つのレコードを取り出す方法が わかりました すべてのモニタリング記録はどうやって 入手するのでしょうか？ すべての識別子を追跡する必要が ありますか？ その必要はありません あなたのモニター上のidentifiers プロパティにリストを保持します 各レコードとそのコンテンツを取得するのに 簡単に反復処理できます レコードのコンテンツにアクセスする方法が わかったところで 変更が発生したときにイベントを 消費する方法を見てみましょう イベントを受け取るコードは タスクでラップされた 単純なループを使って実装できます Core Locationは lastEventで 報告された状態と 異なるモニターコンディションの状態を 観測すると モニターのイベント非同期シーケンス プロパティを通じて 新しいイベントを配信し 待機ループを再開します 配信されたイベントオブジェクトは 新しい状態と 影響を受けた状態の識別子をもたらします あるいは 新しいイベントを処理する間に 識別子を使ってレコードと そのコンディションのlastEventを 取得できます その情報をもとに 今起きていることの 背景を探ることができます これです！ シンプルなグリータープログラムが 完成しました CLMonitorがどう機能するか分かったので ベストな使い方を アドバイスします まず 3つの重要な要件から始めましょう まず 異なるコンディションの処理を 分離するために 異なる名前で複数のモニターを持つことが できますが 与えられた名前に対して 一度に1つだけインスタンス化する必要が あります CLMonitorはモニターしている コンディションの状態を維持するため 同じ名前で別のものを初期化しようとすると 望ましくない動作になる可能性があります 2番目に イベントは予測不可能に到着する 可能性があるため 常にモニターのイベントシーケンスで Task待ちをしているのがベストです イベントは それを処理したあとにのみ あるレコードのlastEventになります そのため イベントを待っていない間に コンディションの状態が変化した場合 イベントを待つまでモニターに新しい状態が 反映されません 最後に アプリが終了している場合 いずれかのモニターコンディションが イベントに遭遇すると Core Locationは ユーザー位置情報の受信が 許可されている限り アプリをバックグラウンドで起動します つまり アプリがモニターしている状態に 興味を持ち続けるのであれば アプリが起動するたびにモニターと イベント待ちを再実行する必要があります これを行う一つの方法は didFinishLaunchingWithOptionsアプリの デリゲートコールバックを リッスンすることです

新しいAPIは起動動作をもたらすので アプリからのみCLMonitorを使用することを 強く推奨します ウィジェットやプラグインで使用すると 代わりにアプリが起動し 一度に1つの名前の1つのモニターしか 存在しないようにするのが複雑になります 最後に 先に述べたことですが CLMonitorがモニターしている コンディションの状態の変化を 観測したときに コンディションと その状態が持続し イベントが生成されます そのため これらの状態を独自のテーブルで 管理して到着するイベントと 不同期になるよりも CLMonitorが 表現している状態を見ることを 強く推奨します とはいえ SwiftUIの視覚化のような いくつかのアプリケーションでは 別個の表現を保持する必要があるかも しれません それをする必要がある場合 SwiftUIのためにその表現を予約し 予想されるイベントについて推論するために それを使用しないでください これがCLMonitorです！ 新しいAPIにはとても期待しています ぜひ試してみてください！ これにより モニター体験が向上することを 願っています ぜひご意見をお聞かせください また CLMonitorの動作を示す サンプルアプリも用意しています このビデオのリソースセクションで 入手できます ダウンロードして試してみてください 最後に 同僚のSirajによる位置情報の 最新情報のセッションを確認してください ご視聴ありがとうございました！