意外と落とし穴が多い
そう思っていた時期が私にもありました。
LIFFはLINEネイティブアプリ内で開くWebViewという性質上、通常のWebアプリケーションよりは落とし穴が多いです。
特に大きな落とし穴として、ユーザーがiOS端末上のLIFFから要求された位置情報の取得を連続で拒否すると、再び許可する方法がなくなるというものがあります。
そのあたりも含めて、LIFFでの位置情報の扱いについてウォークスルーしていきましょう。
ユーザーが拒否／許可を指定できる箇所
- LINEアプリ自体がOS設定レベルで位置情報を取得する要求に対しての許可
- LIFFブラウザで開かれたWebアプリがGeolocation APIで位置情報を取得する要求に対しての許可
- LINEプラットフォームによる位置情報収集に対しての許可
- LINE Beaconに対しての許可
そのうち、LIFF（Webアプリ）が位置情報を取得するには、1番と2番の許可が必須となります。
1. とにもかくにもLINEアプリに対するOSレベルの許可が必要
OSレベルの位置情報要求ダイアログ
OSレベルの設定のため、iOSかAndroidかで若干異なりますが、基本的にはLINEアプリの位置情報の許可をオンにする必要があります。
Androidの場合は、端末ごとに設定の項目名等が異なるため、適宜読み替える必要があります。
アプリ単位の設定からたどり着く方法
- iOS：[設定] > [アプリ] > [LINE] > [位置情報]
- Android: [設定] > [アプリ] > [LINE] > [許可] > [位置情報]
位置情報セクションからたどり着く方法
- iOS：[設定] > [プライバシーとセキュリティ] > [位置情報サービス] > [LINE]
- Android: [設定] > [位置情報] > [アプリへの位置情報の利用許可] > [LINE]
許可スコープと取得精度
LIFFで位置情報を利用するには、上記の位置情報設定で「しない」以外の選択肢を選ぶ必要があります。
また、特定施設への往訪などをトリガーにした機能を設ける場合、「正確な位置情報」が許可されていないと数キロレベルの誤差が出るため、位置情報があっても使い物にならないというケースが多いでしょう。
【対処】導線にトーク画面での位置情報のメッセージ送信を活用する
上述の通り、わりと設定の項目位置が深いので、スマホに不慣れなユーザーがすんなり設定を変更するのが難しい場合もあります。
当該の設定項目に一気に遷移させるために、トーク画面での位置情報メッセージ送信機能を活用できます。
「位置情報へのアクセスを許可する」で一気に遷移する
基本的にLIFFをユーザーに利用させる場合、公式ラインのリッチメニューからの起動が多いので、以下の2通りの手段が選べます。
- Messaging APIでクイックリプライに位置情報アクションを設定する
- liff.sendMessagesで擬似的な位置情報アクションを発生させる
Messaging APIでクイックリプライに位置情報アクションを設定する
chat_message.writeの権限さえあれば、トーク画面に説明文とともに位置情報アクションを使えばええやんけ〜！
と思いきや、位置情報アクションはクイックリプライでなければ設定できません。
そのため、正攻法としてはMessaging APIでユーザーに対して説明文＋クイックリプライでの位置情報アクション送信をするのがよいでしょう。
この方法は、Messaging APIによる課金対象ののメッセージとなってしまいますが、メッセージを受信した通知がユーザーに届きますし、クイックリプライというスマートな方法でユーザーに当該機能へのアクセスを促せる利点があります。
liff.sendMessagesで擬似的な位置情報アクションを発生させる
一方で、LINE公式アカウントとのトーク画面経由で開かれたLIFFであれば、liff.sendMessagesでも擬似的に位置情報アクションを発生させることができます。
LINE URLスキームの位置情報を送るを用います。
URIアクションに https://line.me/R/nv/location/ を指定すればOKです。
2. Geolocation APIレベルでの位置情報の取得許可
Geolocation APIレベルの要求ダイアログ
OSレベルでの位置情報の許可が取れている場合、LIFFブラウザ上のWebアプリはGeolocation APIによる位置情報取得のダイアログを表示します。
その際、OSレベルの許可スコープで「次回または共有時に確認」を設定していると、OSレベルの要求ダイアログが都度開くため、連続で似たようなダイアログが表示されることになる点に留意が必要です。
2回連続での拒否で復元不能に
iOSのWebViewでは、Geolocation APIの位置情報取得要求に対して、ユーザーが2回連続で同じ選択肢を選ぶと、以降はその選択肢が既定値となり、要求に対してダイアログが表示されなくなります。
また、通常SafariであればOSの設定画面からアプリ別の設定項目に飛べるため、ブラウザ内部の許可情報をリセットすることが一応可能ですが、LIFFブラウザはLINEアプリ内のWebViewであるため、iOSの設定画面からはLIFFブラウザの許可情報をリセットすることができません。
そのため、誤ってユーザーが「許可しない」を2回連続で選択してしまうと、以降は同じドメインに対してLIFFブラウザ上で位置情報を取得することができなくなります。
根本対処は存在しない前提での次善策
この問題に対する根本的な対処は存在しませんが、可能な限り防ぐ手段を講じることはできます。
- 事前確認ダイアログの実装
- ドメイン変更
事前確認ダイアログの実装
ユーザーに位置情報の取得を行う前に、事前に位置情報の取得を行うことを説明するダイアログを表示します。
位置情報を提供することに嫌悪感のあるユーザーが勢いで「許可しない」を選択し、あとから許可不能になることを防ぐため、実際に要求をおこなう前にキャンセルできるようにしておくのがよいでしょう。
あくまで対症療法ですが、慎重なユーザーがとりあえず操作を進めてみて「位置情報が必要そうなら使わなくていいや」と思った段階で安全に引き返せるようにしておけば、かなりのケースを防げると思います。
というのも、指定施設への往訪をトリガーにした機能など、そもそも位置情報がなければ成り立たない機能をわざわざ使おうとするユーザーであれば、許可を選択する可能性は高いからです。
ドメイン変更
これは反則気味の手段ですが、LIFFのドメインを変更することで、再び位置情報の取得を行えます。
なぜなら、WebView上の許可情報はドメイン単位で管理されているためです。
したがって、再審査を避けるのに本番URLを固定した上で、当該処理のみを一定時間ごとに変更される別ドメインに切り出すなどの工夫も一応は考えられます。
ドメインに関して公式のミニアプリポリシーには以下のような記載があります。
以下の場合において一時的にユーザーを外部のウェブサイトやネイティブアプリに誘導することを許可します。
（中略）
・トランザクションや認証を行う
・決済を別のネイティブアプリで行う
（中略）
・プライバシーポリシーや利用規約、企業の公式サイトに遷移する
・店舗の地図を地図アプリで開く
こと認証済みミニアプリに関しては同一のLIFF IDであっても、本番のエンドポイントURLから別のサブドメインにランダムでリダイレクトさせるような構成は「外部のウェブサイトへの誘導」に該当しそうです。
外部のウェブサイトへの誘導とは、LINEミニアプリのエンドポイントURLのドメイン名とは異なるドメイン名のサイトを、LIFFブラウザまたは外部ブラウザで開くことを指します。
Androidでの挙動
Androidでは、さらに挙動が変わります。
iOSのように2回連続で拒否した場合に許可ダイアログが表示されなくなることはないため、その点は安心です。
ただし、AndroidのWebViewでは、Geolocation APIの位置情報取得要求に対して、ドメイン単位ではなくLIFF ID単位で許可情報が管理されていそうです（あくまで挙動からの推察です）。
さらにAndroidでは、LIFFブラウザ上で外部サイトに遷移した場合に、遷移先では位置情報が根本的に利用できなくなっていそうです（iOSではその制約は現時点ではないように見えます）。
またこれは端末の問題かもしれませんが、Androidのほうが位置情報の取得に時間がかかることが多い印象があります。
Geolocation APIからの取得要求に対して、通常のブラウザとは異なる認可挙動をしているように見えるので、その影響でしょうか。
3. LINEプラットフォームによる位置情報収集
OSではなくLINEアプリ内の設定項目になります。
[設定]＞[プライバシー管理]＞[情報の提供]＞[位置情報の取得を許可]
オンにした場合、LINEアプリの画面が表示されている際に、当社はご利用の端末の位置情報と移動速度を取得することがあります
詳しくは下記ページをご参照ください。
4. LINE Beacon
こちらもLIFFでの位置情報取得には影響しませんが、位置情報を取り扱う機能としてLINE Beaconというものが存在するので触れておきます。
LINE Beaconによる施設往訪確認
対象施設にLINE Beacon端末を設置しておけば、そのBluetooth範囲にユーザーが入ったことを検知できます。
そのため、Geolocation API以外の手段として特定の施設への往訪をトリガーにした機能を実装することが可能です。
利用のハードルは少し高い
まず、LINE Beaconを利用するには、自分で電子工作するか、5000円以上するビーコン端末を購入する必要があります。
さらに、ユーザーは[設定]＞[プライバシー管理]＞[情報の提供]＞[LINE Beacon]をONにしている必要もあります。
この設定はデフォルトでOFFです。使ってもらうにはユーザー誘導が必須です。
そのため、利用のハードルは高いですが、往訪条件を設けたい場合、確実にBluetooth範囲にいることが確認できるでしょう。
端末の登録とイベントの受信
一部の法人アカウントを除き、利用できるのは対象エリアにユーザーが入ったことを示す"enter"イベントのみです。
enterというイベント名称から、ユーザーがすでにエリア内にいる状態であとから端末のBeacon設定をONにした場合にどうなるのか不安になりますが、ONにしたタイミングでenterイベントが発火することを私の手元のBeacon端末で確認したので、その点は問題なさそうでした。
他にも、LINE Beacon端末は1台の端末を1つのLINE公式アカウントにしか紐づけられないという制約もあるので注意が必要です。逆に当たり前かもしれませんが、複数のLINE Beacon端末を1つのLINE公式アカウントに紐づけることは可能です。
また、一度紐づけた端末をあとから解除して別のLINE公式アカウントに紐づけることはできるため、開発検証用に1台の端末を使いまわすことは可能です。
まとめ
LIFFでの位置情報取得は、一見シンプルな実装に見えますが、LIFFブラウザ特有の制約により慎重な設計が必要です。
位置情報に関する内容はある程度は網羅的に含めたつもりなので、ぜひユーザーフレンドリーなアプリを作成する際の参考にしてください！
Discussion