Core Locationの新機能

(音楽)

どうも (拍手) ようこそ What's New in Core Locationへ Core Locationチームのエンジニア アダム･ドリスコルです iOS 13の Core Locationの改良点を紹介します

デベロッパの望みは アプリケーションで ユーザをハッピーにすることです

皆さんが僕の話を 聞きにきているのは 位置情報サービスが 重要だからでしょう それにはCore Locationが 必要であり―

位置情報取得には ユーザの許可が求められます つまりプロンプトシステムによる 認証により ユーザの選択を促し― APIで処理するのです

本日 お話しするのは iOS 13ではオーソリシステムと そのオプション そしてBeacon Ranging関連の APIの変更点です

“常に許可”の話もする予定です

“使用中のみ許可”の話と

“一時的許可”も 気に入ってもらえるでしょう そして同僚のアンドレアが Beacon Rangingの説明をします

では僕が使ったプロンプトを 見てください

Platforms State of the Unionの 講演でも話しました

オーソリのインタラクションは このプロンプトで始まります

下部にある“許可しない” というオプションを選ぶと アプリケーションは 位置情報にアクセスしません だから十分に注意してください このプロンプトを ユーザに表示するタイミングは ユーザが位置情報にアクセスする 必要性を理解し 承認できる際にしてください

ところで このプロンプトには “常に許可”という オプションはありません 不思議ですか？ アプリケーションによる― プロンプト表示の リクエストを見れば謎が解けます まずはCLLocationManagerが 必要です シンプルなアプリケーションなら インスタンス変数として 設定するのがよいでしょう

“使用中のみ許可”もしくは “常に許可”のどちらかを呼び出します ここではrequestAlwaysAuthorizationを 呼び出すものとします

iOS 12では “使用中のみ”と“常に”という― 両方のオプションが出てきます iOS 13では “常に”のオプションは出ません

しかしCore Locationは リクエストを覚えており ユーザが選択肢の中で 最も前向きな― “使用中のみ”を承認すると―

“使用中のみ許可”が 有効になります 同時に“仮の常に許可”と 呼ばれる状態に入ります どう進むか見てみましょう

上部の青い部分は ユーザが見る画面で 下部の緑の部分は アプリケーション “仮の許可”では この２つは異なります

アプリケーションは “常に許可”を求めると

ユーザは “使用中のみ”を承認しました

設定に進むと “使用中のみ許可”と表示されます しかしCore Locationは “常に許可”と返答しました この場合のアプリケーションに 必要な動作が分かりましたね これで“常に許可”が 必要な機能を使えるのです “使用中のみ許可”の話の際に 詳しく説明します 例えばジオフェンスの セットアップを行ってユーザのために バックグラウンドで 自動ビヘイビアをします

そして Core Locationが監視し―

ユーザがジオフェイスに出入りすると イベントが生成され

LocationManagerDelegateに 届けられます しかしオーソリが仮のものなので Core Locationは ユーザが“常に許可”を望むか 尋ねる時期を待ちます

これがプロンプト表示です “常に許可”を承認するボタンが 下部に見えます アプリケーションは “常に許可”と考え ユーザは“使用中のみ許可”と 考えていました ここでプロンプトは 再度 双方の合意を促すのです

位置情報へのアクセスを ユーザが理解しない時や バックグラウンドで自分の位置情報に アクセスされたくない時は “使用中のみ許可”のままで 留めることができます

アプリケーションと ユーザの意見が一致すれば ユーザは“常に許可”を 承認できます

“仮の許可”の状態は 終了します “常に許可”で終了すれば プロセスを始めたイベントを 受け取りますが “使用中のみ許可”では そうなりません

詳細を解説します

まずアプリケーションが “仮の常に許可”をしている間は Core Locationは イベントを監視しますが “使用中のみ許可”を行ってる時は アプリケーションには報告しません

ユーザが“常に許可”を承認できる プロンプトは後で発生します

そして このプロセスを 開始できるのは一度きりです

しかし この例のように いつも最初に“常に許可”か― “使用中のみ許可”を リクエストできます 位置情報を必要とする機能を 試すことにより ユーザは“常に許可”へ アップグレードするでしょう

Core Locationは イベントを監視します では どの場合にイベントが届き ドロップされるのでしょうか

“常に許可”の場合は 届けられますが “使用中のみ許可”では 届けられません

ユーザがまだ選んでない時も 届けられません

Core Locationは 拒絶される機会を最小限にするために ユーザが忙しくない時を 待ちます

イベントが生成される間に リクエストを監視すれば それらのイベントは先に 起きたイベントに取って代わります

最終的にCore Locationは 古いイベントをドロップします ユースケースに関係がなく 現在のユーザの視点ではないため 状況理解の 助けにならないからです

このプロセスは 多くのドロップされる イベントを生むでしょう でもユーザを理解するためには 重要なプロセスなのです “常に許可”を得るには 信頼が不可欠です

“常に許可”の可用性と処理は プラットフォームにより変化します

tvOSのサポートは “使用中のみ許可”の時のみで

watchOSが必要なのは “使用中のみ許可”だけです バックグラウンドランタイムへの アクセスに制約があって APIはローンチビヘイビアを 提供してないからです

ウォッチフェイスは常に有効です コンプリケーションに 対応する場合は アプリケーションは “常に許可”を必要としません macOSも同様に “常に許可”をサポートしませんが プロンプティングは自動なので オーソリのリクエストは不要です

つまりMac上の iPadアプリケーションは “使用中のみ許可”と“常に許可” いずれも有効です Mac上で動作するUIKitコードは 最適なリクエストを使用できるのです

以上が“常に許可”についてです “常に許可”の必要性に関しては よく質問が上がります

“使用中のみ許可”の場合を 見てみましょう

既に示唆したので お気づきでしょうが 最初にアプリケーションが “使用中のみ許可”をリクエスト ユーザが承認すると 試用期間と後続プロンプトなしの “使用中のみ許可”を取得

これはユーザが本当に必要とする 新機能を導入する際に “常に許可”を求める機会を 蓄えたのです

では“常に許可”をリクエストするまで 何ができるでしょう？

iOS 12以前は この表が回答を示していました ご覧のように “使用中のみ許可”の時は 位置情報のアップデートを行って Beaconをアレンジできます またバックグラウンドの 使用インジケータを通して―

連続した位置情報の アップデートを受け取れます

しかしバックグラウンドから 直接アップデートは開始できません またバックグラウンドで ローンチする可能性のある― 監視のAPIも使用できません

ここでの一貫した特徴は 何でしょう？ チャートの上部にあるサービスは アプリケーション使用中にのみ 作動します

下部にあるサービスは 使用中ではなくても 位置情報を届けます

iOS 12では これらを使用できませんでした

でも関連情報を届けないモードでも 下部のサービスを実行できるとすれば “使用中のみ許可”に準拠します そして どのサービスが 使用可能かを気にせずに 使用中かどうかについてのみ 考慮できるのです

これがiOS 13の改良点です 緑色のチェックマークは 大幅な位置変更や地域 そして訪問の監視を含む― APIへのアクセスを示します

使用中ならアプリケーションは 大きな位置情報の変化を受け取ります 地域エントリや訪問 そして退出です

iOS 12ではアプリケーションが 地域エントリの監視を行う時は どのオーソリが必要か 考えるのをやめていたでしょう iOS 13では 少し深く考えねばなりません

ユーザは意図を理解し 直接 関わっていますか？

要するにアプリケーションが 使用中であれば “使用中のみ許可”で十分です

アプリケーションが 使用されるのはいつ？

ある時点でアプリケーションは フォアグラウンドに入って

バックグラウンドに入るまで 使用中とみなされます

実際には 数秒の猶予期間があります ユーザがアプリケーションを 離れる直前に 始まるイベントを カバーするためです 非常に短い時間なので 頼りすぎないように

次にフォアグラウンドに入るまで アプリケーションは使用されません

Xcodeでサポートされる バックグラウンドモードリストに 位置情報のアップデートを 加えたら フォアグラウンドに入った後 この状況に移行できます

使用中になり 位置情報のアップデートを始めて allowsBackgroundLocationUpdatesを trueにセットします そしてバックグラウンドに入ると 青色のインジケータが現れます アプリケーションはこの期間ずっと バックグラウンドで使用されます

allowsBackgroundLocationUpdatesを ある時点でfalseにします 次にフォアグラウンドを離れると 使用中ではなくなり 通常ビヘイビアに戻ります

ウォッチフェイスの― コンプリケーションは 常に有効です

バックグラウンド動作期間のように これは深緑色だと 覚えておいてください この場合 アプリケーションは 使用中とみなされず オーソリプロンプトを リクエストできません もしコンプリケーションに 対応する場合― アプリケーションのコンテキストから オーソリを求める必要があります

もう１つ注目してほしい ケースがあります このケースはユーザを 取り込む力を提供してくれます ユーザを取り込めれば 関心領域を名付ける― UNLocationNotification Triggerを作れます

ユーザが その領域に入った時に 通知が関連づけられ ユーザに表示されます

この時点でアプリケーションは ユーザの居場所を知らされておらず いつそれが伝えられるかも不明です

しかし この時点で ユーザがアプリケーションを起動し フォアグラウンドに入れば 使用中となります

すべてのCore Location APIサーフェスは― 環境次第では使用可能であり その環境に入るために ローカル通知を使用できます

これはユーザがアプリケーションに 取り込まれたくない時は “常に許可”が必要だということを 意味します

これが他のケースにおいても ユーザの助けになることを願います

“使用中のみ許可”よりも クールな― “一時的許可”という方法もあります このプロンプトの 真ん中のボタンで行います

オーソリステート それからVR プロンプティングシステム間の― 遷移を見てみましょう “一時的許可”が どの部分に当てはまるか分かります

iOS 12ではアプリケーションが フォアグラウンドに入る時には ステートは決定されていません アクセスがないということです 永続ステートを両脇に 高度なオーソリステートをトップに 下部は未定とします 位置情報にアクセス不可なのは 拒否されたのではなく まだ決められていないだけです

未定の状態ではオーソリのプロンプトを リクエストできます 拒否されると 二度とプロンプトできませんが ユーザは“使用中のみ許可”を 承認できます

そして“常に許可”を リクエストして得るか 最初に直接 “常に許可”を求めることもできます これがiOS 12です iOS 13では新たに

一時的ステートを伴う― “仮の常に許可”へのパスを 紹介しました これは“常に許可”と よく似ています しかし“使用中のみ許可”に 戻ることも可能です

“一時的許可”も同様で “使用中のみ許可”とよく似た 動作をする一時的ステートです アプリケーションが使用されなければ すぐに未定状態に戻ります

つまり“使用中のみ許可”が 一時的という点を除けば

“使用中のみ許可”と同様に機能します LocationManagerのDelegateは “使用中のみ許可”に― そして後に 未決定に戻されます

大事なのは それが起きた後に 次に必要な時はアプリケーションが オーソリをリクエストすることです

覚えておいてほしいのは “一時的許可”が 使用中という状態に 密接に結びついていることです また 再びリクエストできるので アプリケーションのフローに より結びついています

では また緑色のチャートを 見てみましょう

これはベーシックなケースですが 第２の区域を 第１の区域に近づけ さらにベーシックにします

アプリケーションが フォアグラウンドで使用中の際に オーソリが必要なインタラクトを ユーザが行えば その時点で オーソリをリクエストします

ユーザが“一時的許可”を 承認すれば アプリケーションは最終的に バックグラウンドに入るまで フォアグラウンド期間の 残りを通して “使用中のみ許可”となります

中間地点でギャップが広がり 使用中でなくなると何が起こるか この場合には― 受け取った“一時的許可”は バックグラウンドに入った時に 失効します

あなたは考えるでしょう オーソリをいつ求めるか フォアグラウンドに入ったら すぐに求めるべきかと

そうではなく 大切なのは 最初にオーソリを要求した理由です ユーザがMAT Viewの アップデートを求めたかもしれない またはメッセージの ジオタグのせいかも

第２の試用期間で ユーザが再び求めたら オーソリをリクエストしてください 位置情報の継続的な使用を ユーザが求めない場合は フォアグラウンドに入ってすぐ 再度リクエストしないこと

ところで― ユーザの実行をトラッキング中に バックグラウンドでの 制限時間を超えた後も

位置情報へのアクセス続行を ユーザが求める場合があるでしょう この場合 実行を開始し オーソリをリクエストして “一時的許可”を受け取ると 位置情報のアップデートを開始します バックグラウンドに入った時は 青色のインジケータが現れて “一時的許可”は中断されず アプリケーションは 使用中のままとなります

フォアグラウンドで再開する際は 実行を終了し allowsBackgroundLocationUpdatesを 再びfalseにします

フォアグラウンドに入り次第 オーソリをリクエストする― 確実なユースケースがあります ユーザがアプリケーションと 直接やり取りしている時にだけ “常に許可”を期待する場合です フォアグラウンドに入った時は オーソリをリクエストするが allowsBackgroundLocationUpdatesを 設定しないこと そうすればオーソリは失効して バックグラウンドに入ります

そしてまたフォアグラウンドに来れば 繰り返しです

ユーザの要望を自問し もし彼らが本当に求めているのであれば いずれは より永続的な “使用中のみ許可”を得るでしょうが ユーザが承認を確信するまでは 問いかけましょう

“使用中のみ許可”は新たに 地域監視などにも対応しました

そして“一時的許可”は 臨機応変に処理できます ではBeacon Ranging APIの 改良について 同僚のアンドレア･グッゾに 説明をお願いします アンドレア (拍手) やあ 皆さん アンドレア･グッゾです Core Locationチームで ソフトウェアエンジニアをしています Beacon Rangingについて 説明します iOS 13でのAPIの改良点や Beacon Rangingの使用法― すばらしい 位置情報エクスペリエンスを ユーザに提供する方法などです

まずはBeacon Rangingの おさらいから 地域監視のAPI拡張として iOS 7で紹介しました

ユーザに位置情報の 新次元とも言えるべき― エクスペリエンスを 提供するのです

これは地域監視APIの一部です Rangingを起動するためには 地域監視を使用します リソースを浪費しないためにも Beaconの位置を把握しましょう

地域監視は導入なので “常に許可”を必要としました iOS 13では “使用中のみ許可”において使えます

Beacon Rangingは 地域監視の拡張として紹介しました Beaconの存在として定義された 区域を表すために CL区域対象物を CL Beacon区域に広げました そしてBeaconを検知する UUID メジャー値とマイナー値を インクルードしました

iOS 12以前のバージョンでは このデータタイプを― Beacon Ranging APIにパスします

１つのBeaconを検知するタプルに 焦点を絞りましょう これは複数でなく１つの 大きなBeaconとして現れます タプルの要素で区域を 定義する場合― 実際にはタプルとマッチする Beaconを用います Beacon Regionでは マイナー値とメジャー値を除外できます これはワイルドカードの 使用に相当します マイナー値を除外すると 区域は 同じUUIDとメジャー値を共有する Beaconにより定義されます 同様にメジャー値を除外すると 異なるメジャー値 マイナー値と 同じUUIDを持つ― Beaconをインクルードする 区域となりました CLBeaconIdentityConstraintを iOS 13で導入したのは― タプルの意味を示すためです それは 関与するBeaconや 領域を定義するものなのです

Beacon Regionの作成時 このデータタイプが使えます この後 Beacon Ranging APIに アクセスするために 必要なデータタイプの 実例をご紹介します

では実際に 機能するか見てみましょう

美術館訪問に使われる アプリケーションを― 作っていると想像してください 名称を入力したり カタログを見たりすることなく 目の前にある作品の詳細を 来館者に提供するのです

そのために美術館に Beaconをインストールします すべてのBeaconには 同じUUIDを使います 各展示室にはメジャー値― 特定の作品には マイナー値を設定します これで展示室内に来館者が いるかどうかを特定できます 来館者がカフェにいる間は Rangingの必要はありません 来館者が展示室にいる時に Beacon Rangingをしたいからです この時点で 来館者に一番近い作品を特定し 詳細を提供します

アプリケーションの使用中に すべての処理は行われます

美術館のガイドとなる このアプリケーションを 来館者が既に インストールしている場合― 美術館へ到着した際に リマインドするべく ローカル通知を用いて 知らせることにより アプリケーションを 起動する選択肢を示します

この図が表しているのは 使用中のアプリケーションの ステートです Beaconの定義領域を監視 そしてイベントの出入りに対応し Ranging中はBeaconの Proximityを受け取ります

初期のステートに注目しましょう Beaconの定義領域は どのように定義されるのでしょう すべての展示室に Beaconをインストールします すべてのBeaconには同じUUID― 展示室にメジャー値 特定の作品にマイナー値を設定 来館者がいつ展示室に入るのかを 特定するため Beacon領域の作成時は メジャー値とマイナー値は省き UUIDだけを提供します コードを見てみましょう

最初に“使用中のみ許可”を取得

UUIDだけを供給することで CLBeaconIdentityConstraintを 作ります

そして新しいAPIで Beacon区域を作ることで― 監視を開始できます

この時点で来館者が 展示室内にいるか特定できるので ステートの変化に 対応するだけでいいのです 来館者が展示室に入ったら Rangingを開始して

展示室を出たらRangingを停止

デリゲートメソッドによって これを達成できて―

ステートに基づき対応できるのです 室内ならRangingを開始して 室外なら停止します BeaconIdentityConstraintを 提供して 区域を通して 回収できることを紹介しました 初期のステートを把握するため 最初に監視を開始した時― デリゲートメソッドが 呼び出されます 展示室内で来館者が アプリケーションを開始すると ステートを含む デリゲートが呼び出されます

これが展示室の出入りへの 対応方法です では展示室内での 作品の特定方法を見てみましょう

来館者の目の前にある 作品の情報を提供し 来館者の動きに合わせ 最も近い作品を特定するためには

デリゲートメソッドを 定義すれば十分です ステータスアップデートに応じて 定期的に呼び出されるため Proximityで分類されたリストを 受け取ることができ 一番近いBeaconを 特定し対応できます

アプリケーション使用中の 動作について紹介しました では来館者がアプリケーションを ダウンロード済みの場合― 美術館到着時に 利用を促す方法です アプリケーションのローンチを 認識させるためには 位置情報によって作動する― ローカル通知を使用します

美術館の地理的座標を 提供することで 実際の地理的な地域を 作る必要があります

到着時についてのみ 言明しましたが 出発時にも対応したい場合 通知を設定することもできます

ローカル通知の設定には UserNotificationsのAPIを使います

これで以上です Beacon Rangingについて おさらいをしました iOS 13での Ranging APIの改良点 そして すばらしい 位置情報エクスペリエンスを― 提供する方法を紹介しました 最後の要約のために アダムに戻ってもらいます (拍手)

ありがとう 我々が考えるべき ３つの事柄とは？

１つ目は位置情報のオーソリが 一新した点です プライバシーが 厳重に守られていることにより アプリケーションへの ユーザの信頼度が 向上することを願っています

２つ目は動作テストの必要性です “一時的許可”の承認のみで 行ってください きちんと動作しますか？ ユーザエクスペリエンスを 向上する方法は？ ユーザの心構えができる前に 永続的オーソリの承認を 促さないためには？

３つ目は 位置情報関連エクスペリエンスの― 向上に役立つRangingです 新しいRanging APIの試用に 最適なサンプルが Toolkitにあります とてもシンプルです

ご質問があれば 今週はラボが２つあります １つ目の開催予定は 本日の11～13時で― ２つ目は 明日の13～15時です “一時的許可”について話すのは Keynoteと― Platforms State of the Union そして この講演で３度目です 次は 本日２時からの Designing for Privacyです その他には マッピング関連の講演もあります Core Locationとあわせて お聞きください ではWWDC19を楽しんでください ラボで会えるのを楽しみにしています (拍手)