位置情報へのアクセス許可の新機能

位置情報へのアクセス許可の新機能

位置情報へのアクセス許可は新たな世代に移行しつつあります。必要とするユーザー許可を得る際の新しい推奨事項や手法や、新しい診断のシステムを通じて許可が得られない場合に通知を得る方法についてご紹介します。

関連する章
- 0:00 - Introduction
- 1:52 - Authorization goals
- 9:25 - Session lifecycle
- 13:29 - Diagnostic properties
リソース
ダウンロード

ようこそ Core Locationチームのエンジニア Adam Driscollです本日は位置情報へのアクセス許可に関する新機能を紹介しますご存知のように Core Locationは Appleマップなどのアプリがユーザーの位置を検出するための機能です皆さんのアプリでも同様です Core Location APIを使用すれば近隣の面白いイベントをユーザーに知らせたり展示会を案内したりできます去年チームメイトのSirajとNivashが新しい2つのAPIオブジェクトを紹介しました CLLocationUpdateと CLMonitorですどちらもAsyncSequence インターフェイスを提供しておりデバイスの移動時に経度と緯度の最新情報を取得するあるいは指定した空間条件が満たされり満たされなくなったりするたびに状態変更イベントを容易に取得することができます
これらのAPIを使うにはアプリの個々のユーザーから許可を取る必要があります Core Location Authorization API によって実現しますが Swiftでは処理がかなり複雑になる可能性があります今日はこの長いコードをこのように短縮する方法を紹介しますプロセスをより堅牢にする方法を紹介します重要になるのはCLServiceSessionと新システムのDiagnostic Propertiesです 3つのトピックに分けて詳しく説明しますまず CLServiceSessionはアクセス許可の目標つまりアプリの各機能に必要なアクセス許可をアプリの実行中にCore Locationに伝える新しい宣言方法です
次にセッションオブジェクトなのでこれを作成するタイミングやアプリを一時停止または終了した時に何が起きるかについても説明します
最後にまったく新しい Diagnostic Propertiesについて説明しますこれによりアプリはコンテキストに基づいて現在のアクセス許可とその他のあらゆる Core Location APIオブジェクトの機能を完全に把握します
まずは目標です手続き型モデルから宣言型モデルに移行し位置情報へのアクセス許可を扱いますで LocationMonitorSampleアプリを選択するとトグルと上部のオプションの間に位置情報の利用許可がこのように表示されます図にまとめて少し簡素化するとこのようになります
どのアプリもNotDeterminedから始まりますユーザーがそのアプリを承認して次の状態に移行させると次は正確な位置情報またはおおよその位置情報を選択できます
このプロセスを開始するにあたりこれまではCLLocationManagerに加え requestWhenInUseAuthorizationなどのメソッドを使用してアクセス許可を求める必要がありましたこの場合 NotDeterminedから WhenInUseまたはDenialに移行できますこれは明確なリクエスト方法ですがユーザーが通常おおよその位置情報だけを必要とする方法でアプリを使用しておりそのためにその範囲で承認している可能性がありますしかしいずれターンバイターンの詳細な道案内を要求したり明らかに正確な位置情報を必要とする機能を使い始めるかもしれませんそのときに requestTemporaryFullAccuracy (withPurposeKey:)を呼び出して一時的に正確な位置情報を許可するよう促すことができますただし一時的な許可は期限が切れます 00:03:06.902 --> 00:03:10.399 仮にWhenInUse許可が一度しか許可されない設定で
一時的に付与されその後少しだけ機能を離脱し友人とチャットしたとしますその場合はもう一度 requestWhenInUseAuthorizationを呼び出しおそらく requestTemporaryFullAccuracy (withPurposeKey:)も再使用しますこのサンプルでターンバイターン経路を実装しようとすると完全精度のWhenInUse アクセス許可が不可欠になりますそしてこのような許可の目標により図表の各ステップでやるべきことが決まってきます今年登場したCLServiceSessionでは許可の目標を直接表現してそれをタスクに結びつけ駆動させることができますこの例で一部のアプリのユーザーが通常はおおよその位置情報へのアクセスのみ許可する可能性があると言いましたそれは一般的には問題ありませんその選択を考慮して目標を設定しましょう CLServiceSessionをこのように開始して .whenInUseを引数として使います Core Locationは各ユーザーに適切なリクエストを提示してアプリをいずれかの状態にさせますユーザーがナビゲーション機能を使用する時が来たら fullAccuracyPurposeKeyを加えた CLServiceSessionを追加し目標を絞り込みますこれはレイヤー化のようなものでアプリの通常の目標が維持されさらに一時的に完全精度を要求し元のセッションを継続しながら新たなセッションも追加できますともあれこの「Nav」キーは位置情報にアクセスするためのリソースを参照しますこれで Core Locationが一時的な完全精度の許可を必要とした場合でもナビゲーションの目的を説明する文字列が提供され完全精度が必要になった理由が誰でもわかるようになります
ここで少し振り返りましょうまず CLServiceSessionオブジェクトはスクリプトを少し変更できます Core Locationに対してタスクではなく必要なものが知らされますつまりアクセス許可を要求したいタイミングでバックグラウンド化するなどテストが難しい問題についてあれこれと心配する必要がなくなるのですこれは回復可能です CLServiceSessionが維持されているので Core Locationは目標を認識しており次にその目標が達成できそうなタイミングで動作します
したがって CLServiceSessionはプロアクティブに取得するべきです例えば特別な許可が必要になる機能をユーザーが使用する際はアプリが既に完全精度でアクセスしていたとしても CLServiceSessionは維持しますその機能が明示的に完全精度を許可したタイミングを意識してください大抵のユーザーはおおよその位置情報しか使用せずアクセスを拒否することもできたのになぜそうしなかったのでしょうかまたユーザーが特別なアクセス許可を得てまで使おうとする機能とは何でしょうか完全精度のセッションはそのような機能にのみ維持されるべきです最後に CLServiceSessionは文字通り不変で送信可能なオブジェクトですただ通常はニーズの変化を見越して置き換えではなくレイヤー化を行います
もしアプリのコンポーネントがそれぞれ異なる目標の機能を担っておりそれらの機能がときどきレイヤー化または入れ子化されるだけであればそれらのコンポーネントは作成されるサービスセッションを無視してまとめてはなりません必要なものだけを必要なときにだけ個別に作成してくださいレイヤー化された各機能はサービスセッション内で自己完結させ残りはCore Locationに処理させましょう
レイヤー化といえば新登場したCLServiceSessionの構造について説明してきましたが去年紹介した各APIも liveUpdatesやイベントのシーケンスが反復された際のある種のセッションを定義していましたアプリがliveUpdatesを反復しているなら多くの場合おそらく更新を受信しようとしていますよねなのでCore Locationは CLServiceSessionを暗黙化して liveUpdatesまたは Monitor.eventsの反復処理に対応しますこれは非常に便利ですコードを削除するだけでアプリを更新し Core Locationのアクセス許可をサービスセッションで処理できるようになるからですこれで CLLocationUpdateが必要だった去年のサンプルアプリが全面的にアップデートされますこの動作はデフォルトで有効なので暗黙的なサービスセッションでアクセス許可目標が定義可能になります最新のCore Location APIはそれぞれが反復対象の非同期シーケンスを提供し目標となる.whenInUseの状態を反復中に表現しますこれにより先ほど紹介したアクセス許可の処理時に便利だったコードスニペットがさらに便利になります気に入っていただければ幸いですが特に大規模なプロジェクトではアプリを使用するユーザーにアクセス許可を求めるのが望ましくない場合もあるでしょうしかしそのような時でもコードによる更新の反復を停止させるわけにはいきませんもしAPIでアプリに暗黙的にアクセス許可のリクエストを行わせたくなければ暗黙的なセッションの影響を完全に無効化しましょうアプリのInfo.plistで Explicit-Service-Sessionキーを
設定してくださいその後は明示的なセッションを再び取得するだけです暗黙的なオブジェクトではなく実際のCLServiceSession オブジェクトが必要となる主な理由は3つありますまず暗黙的なサービスセッションでは完全精度が不要ですほとんどの場合ユーザーが設定した精度制限を遵守する必要があるからです本当に完全精度が必要な時だけ明示的に切り替えます同様に Core Locationはアプリからの常時アクセス許可を想定していません本当にそのようなアクセス許可が必要な時は必要なタイミングで明示的にCLServiceSessionを実行し目標を.alwaysに設定します今年から Always許可は維持されている間のみ有効でありアプリがフォアグラウンドの時のみ開始できることに注意してください後でセッションのライフサイクルの話題のときに詳しく説明します後に info.plistキーを使うことで特定のタイミングで明示的なサービスセッションを作成できます許可の目標を.noneに設定すれば Core Locationがアプリの代理でユーザーにアクセス許可を要求するタイミングをより詳細に制御できます内部で何度もCore Locationを使用するアプリやユーザーに積極的に位置情報へのアクセスを選択させるアプリにはこれが最も簡単でしょうこれでCLServiceSessionを実行したり liveUpdatesやイベントの反復から取得した暗黙的なセッションを活用できるようになりましたこれらのセッションはユーザー向けの機能を念頭に置いていますつまりアプリのライフサイクル全体で発生するイベントとのやり取りがあります説明しましょう
誰かがアプリを実行しているとします Core Locationに依存する機能を使うタイミングを見てみましょう写真の地理情報のタグ付けなど短時間の機能もあれば長く続く機能もあります例えば MapKitビューを閲覧している時間などですさらに移動時間を調べる作業も同時並行で発生しているかもしれませんこれらの機能のセッション中に CLServiceSessionオブジェクトを作成して維持するのは簡単です機能に実装するコンポーネントにコード内で関連付けて必要に応じてレイヤー化するだけですもちろんデフォルトでこれを行う暗黙的なセッションも実行されます
しかしこれらの機能は必ずしも最初から最後までアプリ内で使われませんエクササイズをトラッキングして記録するような機能の場合数秒も経てばアプリがバックグラウンド状態に移行しユーザーは別のタスクを開始するでしょう例えば別のアプリで音楽を聴きながら運動しワークアウトが終わった時点でエクササイズトラッキングアプリに戻ってきます
機能が概念的に継続し暗黙的なセッションも継続する場合作成された明示的な CLServiceSessionも同じく継続します 3つの理由を説明しますまずこうすることでアプリにアクセス許可の目標を継続的に認識させることができます Core Locationはバックグラウンドではユーザーに対してアプリのアクセス許可の調整を求めませんが必要なものがわかっていれば突然フォアグラウンド状態に戻っても必要に応じて即座にアクセス許可を回復可能です
また Alwaysアクセス許可だけだと LiveUpdatesとCLMonitor.eventsは使用中にのみ結果を取得しますがフォアグラウンド状態で開始されたセッションまたはその他の発効中のセッションが継続的な許可を主張していれば結果を取得できます
最後に上の2つの理由では不十分であったとしても簡単な理由がありますセッションのライフサイクルが機能のスパンと直接結びつき考慮すべき要素が減るのです暗黙的なセッションでもそうなりますとてもお勧めですセッションをバックグラウンドで維持する手法は後でアプリが更新中に一時停止されたときにも便利ですワークアウトのトラッキングをすぐに再開することができます
さらに重要なのはアプリが一時停止中に終了されても機能する点ですどういう場合であれワークアウトはトラッキングしなくてはなりませんそれがアプリに対する要求だからですしかしアプリのプロセスとそれに含まれていたすべての CLServiceSessionオブジェクトや暗黙的なセッションは消えています Core Locationはアプリに提供する情報がなければアプリを継続的に実行させませんアプリに許可されていない更新を生成または提供することもありません例えば .whenInUse許可しかないか LiveActivityまたは CLBackgroundActivitySessionが無効な状態でバックグラウンド化されている場合などですとはいえ他の個々のAPIオブジェクトは引き続きトラッキングされます CLServiceSession liveUpdates その他のシーケンスなどです一時停止や終了が発生してもこれらに基づいて機能しますつまり新たな情報の配信準備が整いアプリのアクセス許可もあればアプリはバックグラウンドで再開または再起動されます
この図でセッションを表している青いバーが実際の処理にかかわらず継続しているのにはこのような理由があります
ただし Core Locationはこれらの明示的または暗黙的なセッションを継続的にトラッキングしませんアプリの再起動後数秒間だけですその起動の起点が Core Location APIであれユーザー操作であれ変わりませんごく短時間ではありますがアプリが機能を再開しない場合もあるのでセッションの状態を漏れなく管理するために重要ですこのようなアプリを記述する際はタスクとなっている機能が処理の起動ロジックにおいてトラッキングおよび認識されるように設定する必要があるほかセッションオブジェクトの再取得や liveUpdatesまたはMonitor.eventsの反復の即時再開もできるようにする必要がありますこうしてオブジェクトは上書きされ Core Locationはアプリが引き続き使用されていることを認識します次はDiagnostic Propertiesです Diagnostic Propertiesはアクセス許可の目標が達成されない理由とタイミングを示します CLServiceSessionは維持するだけで発効しますが各インスタンスは diagnostics AsyncSequenceも公開していますこれはこのコードのように「for try await」で反復処理して状態を確認することができます
ブール値のプロパティもありますこれがDiagnostic Propertyと呼ばれるもので予期せぬ出来事があったタイミングを示していますこの場合はアプリのユーザーが位置情報の共有を拒否したようです .authorizationDenied以外にも .insufficientlyInUseは Core Locationがアプリの代理でアクセス許可を要求できていないことを示します .alwaysAuthorizationDeniedは Alwaysアクセス許可を設定したのに未達成であると示しています .authorizationDeniedGloballyに注目してみましょう位置情報サービスがシステム全体で無効化されるとtrueになります誰かがデバイスをそう設定するとアプリもその設定に従うので .authorizationDeniedもtrueになります Diagnostic Propertiesでは別物として扱われますが関連性はありますもしアプリからのアクセスが明示的に拒否されたタイミングを知りたいだけであれば所要時間の推定をUIから省いて汎用的な項目だけを確認するようにしてください
しかしユーザーの中にはグローバルに移動をするために細かいガイドが必要な人もいるかもしれませんその場合はより詳しいプロパティを確認できますどうなるか見てみましょう再びコードを確認します診断処理ロジックをもう少しニュートラルにすれば流用できるでしょうユーザーがいつそのような決断をしたのか確認したいだけならば注意点が1つありますこのコードが実行された時誰かが既にアプリのアクセスを許可または拒否済みの場合 Core Locationは情報を取得しないので最初の診断は.authorization RequestInProgressが既にfalseの状態で到着しコードがブレークすることがあります悪くないかもしれませんがアプリのアクセス許可は動的に変化しますユーザーが設定を調整したり一時的な許可を利用したりするからですそのためセッションの診断はアプリがそのセッションに対応する機能を提供している間はできるだけ長くリッスンしておいた方が良いでしょう UIが反応できるように @Published varを設定するのもお勧めです
実行中にアプリが位置情報を必要とするタスク内でのセッションと反復まで対応し完了したらキャンセルするという形にすればセッションのライフサイクルは適切になりアプリのユーザーが選択したアクセス許可の下でも UIが適切に反応するようになります Diagnostic Propertiesにより CLServiceSessionの柔軟性は高まりアクセス許可の目標の状態が達成できない場合でも対応可能な方法が示されますそしてご存知のとおり liveUpdatesとCLMonitor.eventsも暗黙的なセッションを提供します Diagnostic Propertiesも各CLLocationUpdateまたは CLMonitor.Eventで使用できます先ほど見たオブジェクトです特にCLLocationUpdateには既にブール値の診断プロパティが .stationaryという名前で含まれていますデバイスが移動を停止して更新が一時停止される前の最後の更新でtrueになります
しかしそれぞれが他のブール値プロパティも含んでいます暗黙的なサービスセッションとしてのロールに起因して発生するかもしれない問題に対応するためですさらに見ていきましょう CLLocationUpdateではさらに2種類将来の更新が到着しない理由の説明ができます .accuracyLimitedはおおよその位置情報が 15分から20分ほどの間隔でしか更新されないことを示し .locationUnavailableは Core Locationが現在位置を取得できていないことを示します CLMonitor.Eventでも条件を満たすイベントが無かったことを精度の制限などの理由から説明できます監視対象の条件の数が多すぎるなどの原因もあります各APIオブジェクトの Diagnostic Propertiesがこれらを組み合わせて活用することでかつてのタイムアウト処理や推測は不要なものとなりました仮にCore Locationが更新やイベントを期待どおりに提供できなかったとしても Diagnostic Propertyを設定することでその理由を知ることができます以上です CLServiceSessionを使うことで必要なアクセス許可を Core Locationに伝えることができます自然に反復するAPIの更新やイベントで許可が自動的に扱われていなければそうしてくださいそして更新イベントサービスセッションが目標を達成できなさそうな場合は常にCore Locationが Diagnostic Propertiesで理由を知らせます必要であればCLLocationUpdateと CLMonitorについて詳しく紹介した去年のセッションをご覧くださいそれではぜひ新機能を試して結果を私たちにお知らせください

// Iterating liveUpdates to reflect current location
Task {
    let updates = CLLocationUpdate.liveUpdates()
    for try await update in updates {
        if let loc = update.location {
            updateLocationUI(location: loc)
        }
    }
}

// Iterating monitor events to report condition state changes
Task {
    let monitor = await CLMonitor(monitorName)
    await monitor.add(CLMonitor.CircularGeographicCondition(center: applePark, radius: 50),
                      identifier: "ApplePark")
    
    for try await event in await monitor.events {
        updateConditionsUI(for: event.identifier, state: event.state)
    }
}

0:52 - Handle updates with CLLocationManagerDelegate

// Adapting location authorization to Swift with a MainActor singleton
@MainActor class LocationReflector: NSObject, CLLocationManagerDelegate, ObservableObject {
    static let shared = LocationReflector()
    private let manager = CLLocationManager()
    
    override init() {
        super.init()
        manager.delegate = self
    }
    
    func locationManagerDidChangeAuthorization(_ manager: CLLocationManager){
        if (manager.authorizationStatus == .notDetermined) {
            manager.requestWhenInUseAuthorization()
        }
    }
    
    func locationManager(_ manager: CLLocationManager,
                         didUpdateLocations locations:[CLLocation]) {
        // Process locations[0]
    }
    // ...
}

1:07 - CLServiceSession simplifies

// CLServiceSession in action

Task {
    let session = CLServiceSession(authorization: .whenInUse)

    for try await update in CLLocationUpdate.liveUpdates {
        // Process update.location or update.authorizationDenied
    }
}

7:15 - Implicit service sessions

// CLServiceSession in action

Task {
    let session = CLServiceSession(authorization: .whenInUse)

    for try await update in CLLocationUpdate.liveUpdates {
        // Process update.location or update.authorizationDenied
    }
}

7:34 - Implicit service sessions

Task {
    for try await update in CLLocationUpdate.liveUpdates {
        // Process update.location or update.authorizationDenied
    }
}

13:37 - Diagnostics – Following the progress of location authorization

// Following the progress of location authorization with CLServiceSession
let mySession = CLServiceSession(authorization:.whenInUse)

for try await diagnostic in mySession.diagnostics {
    if (diagnostic.authorizationDenied) {
        // Ok, let’s let them pick a location instead?
    }
}

15:00 - Diagnostics – Following the progress of location authorization

// Following the progress of location authorization with CLServiceSession
let mySession = CLServiceSession(authorization:.whenInUse)

for try await diagnostic in mySession.diagnostics {
    if (!diagnostic.authorizationRequestInProgress) {
        // They’ve decided (maybe already).  We can move on!
        break
    }
}

15:25 - Diagnostics – Following the progress of location authorization

// Following the progress of location authorization with CLServiceSession
let mySession = CLServiceSession(authorization:.whenInUse)

for try await diagnostic in mySession.diagnostics {
    if (!diagnostic.authorizationRequestInProgress) {
       reactToChanges(authorized:!diagnostic.authorizationDenied)
    }
}

15:46 - Diagnostics – Following the progress of location authorization

// Following the progress of location authorization with CLServiceSession
Task {
    let mySession = CLServiceSession(authorization:.whenInUse)

    for try await diagnostic in mySession.diagnostics {
        if (!diagnostic.authorizationRequestInProgress) {
            reactToChanges(authorized:!diagnostic.authorizationDenied)
        }
    }
}

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

関連する章

リソース