この記事は Frank van Diggelen による Android Developers Blog の記事 "Improving urban GPS accuracy for your app" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android では、デベロッパーの皆さんがユーザーにとって、便利なアプリをできる限り簡単に作成できるようにしたいと考えています。そのため、Fused Location Provider API（FLP）などの API では、位置情報を最大限に活用できるようにすることを目指しています。しかし、密集した都市部では、通りの反対側や誤った区画を指すなど、その位置情報の精度が低いというご指摘をこれまで多くの方からいただいておりました。
ライドシェアやナビゲーションなど、特によく利用されている位置情報アプリでは、この点が非常に重要になります。たとえば、街でユーザーがライドシェアをリクエストしても、GPS エラーのためアプリが簡単に位置を特定できない場合があります。
誤って通りの反対側を指してしまうエラーが起こる主な原因は、都市では GPS シグナルが反射しやすいためです。この大きな GPS 問題の解決に役立てるため、私たちは新しいプロジェクトを立ち上げました。そのソリューションは、3D マッピングを活用して補正を行うという方法です。これには、建物の 3D モデル、未加工の GPS 測定データ、機械学習を組み合わせる必要があるため、Google のような企業の規模でしか実現できません。
12 月の Pixel Feature Drop では、Pixel 5 と Pixel 4a5G に 3D マッピングを活用した GPS 補正が追加されます。Pixel で使われている Qualcomm® Snapdragon™ 5G Mobile Platform にフィードバックを提供するシステム API により、都市部（ビルの谷間、いわゆる「アーバン キャニオン」）での精度が大幅に向上します。
この写真から、3D マッピングを活用した補正を行わない場合、GPS の結果が不安定になって通りの反対側（または誤った区画）を指す頻度が高くなることがわかります。一方、3D マッピングを活用した補正を行うと、位置は何倍も正確になります。
都市部では GPS が構造的に誤った場所を指す点が今までの問題でした。その問題は、すべての GPS システムが衛星からの見通し線に基づいて位置を特定しているために引き起こされています。しかし大都市では、直接の信号は建物によって妨害されるため、ほぼすべての信号が障害物に反射した後に届くことになります。
GPS チップは信号が見通し線上にあることを仮定しているので、信号が余分な経路を通過してきた分だけ、計算に誤差が生じます。最も一般的な副作用は、位置が通りの反対側に表示されることですが、特に多くの高層ビルが建っている大都市では、誤った区画に表示されることもあります。
この問題は、10 年以上にわたって解決が試みられてきました。しかし、Android に 3D マッピングを活用した補正が搭載されるまでは、大規模な解決策は存在しませんでした。
Google Play サービスの 3D マッピングを活用した補正モジュールには、Google が保持している世界中の 3,850 以上の都市の 3D 建造物モデルのタイルが含まれています。現在、Google Play サービスの 3D マッピングを活用した補正は、歩行者による利用のみをサポートしています。歩きながらデバイスの GPS を使うと、Android の Activity Recognition API が今歩行していることを認識します。さらに、3,850 以上の都市のいずれかにいる場合、その都市の 3D モデルのタイルがダウンロードされ、スマートフォンにキャッシュされます。キャッシュのサイズは約 20 MB で、写真 6 枚程度の大きさです。
このモジュールでは、3D マッピングを活用した補正アルゴリズムが難問を解決します。つまり、GPS の位置が正しくない場合、どうすれば信号を妨害したり反射したりしている建物を知ることができるかという、卵が先か鶏が先かわからないような問題です。この問題は、3D マッピングを活用した補正によって解決され、FLP には一連の補正済みの位置が渡されます。システム API はこの情報を GPS チップに渡し、チップがそれ以降の GPS 精度を改善できるようにします。
12 月の Pixel Feature Drop では、Pixel 5 と Pixel 4a(5G) を対象に、3D マッピングを活用した補正のバージョン 2 をリリースします。これにより、通りの反対側を指すという現象の発生率が約 75% 減少します。Android 8 以降を使っているその他の Android スマートフォンでは、FLP にバージョン 1 が実装されており、通りの反対側を指すという現象の発生率が約 50% 減少します。2021 年初頭には、Android エコシステム全体（Android 8 以降）でバージョン 2 を利用できるようになる予定です。
Android の 3D マッピングを活用した補正は、米国の Global Positioning System（GPS）に加え、その他の Global Navigation Satellite System（GNSS）の信号にも対応しています。具体的には、GLONASS、Galileo、BeiDou、QZSS の信号です。
GPS チップ パートナーは、それぞれのテクノロジーにおけるこの作業の重要性について、次のように述べています。
「ユーザーは、モバイル スマートフォンの位置情報やナビゲーション機能の精度に依存しています。位置情報テクノロジーは、お気に入りのレストランを見つけたり、タイミングよくライドシェア サービスを利用したりする際に非常に重要ですQualcomm Technologies は、Google の 3D マッピングを活用した補正を組み込んだ最新のQualcomm® Location Suite テクノロジーによるユーザー エクスペリエンスの改善で、主導的な役割を果たしています。今回の Google との共同作業は、歩道レベルの精度の位置情報実現に向けた重要なマイルストーンです」
―― Qualcomm Technologies, Inc. プロダクト管理担当副社長、Francesco Grilli 氏
「Broadcom は、BCM47765 二周波 GNSS チップのナビゲーション エンジンに Google の 3D マッピングを活用した補正を組み込みました。二周波の L1 および L5 信号と 3D マッピングを活用した補正を組み合わせることで、アーバン キャニオンでこれまでにない精度を実現できます。L5 と Google の補正を組み合わせれば、都市部での GNSS の活用に革命を起こすことができます」
――Broadcom Inc. エンジニアリング担当シニア ディレクター、Charles Abraham 氏
「Google の 3D マッピングを活用した補正によって、スマートフォン ユーザーが都市環境で歩行しているときの個人の位置情報の精度が大きく進展しました。MediaTek Dimensity 5G ファミリーは、3D マッピングを活用した補正に対応しています。これにより、高精度デュアルバンド GNSS や業界トップレベルのデッドレコニング パフォーマンスに加えて、最高精度のグローバル位置情報を 5G スマートフォン ユーザーに提供できます」
―― MediaTek
Android 8 以降を実行しているスマートフォンでは、3,850 以上の都市で GPS をオンにして歩行しているときに、Android の 3D マッピングを活用した補正が自動的に作動します。デベロッパーがこの改善を活用する最適な方法は、FLP を使って位置情報を取得することです。GPS チップによるさらに高度な 3D マッピングを活用した補正は、現在のところ、Pixel 5 と Pixel 4a 5G で利用できます。また、今後数週間のうちに、Android エコシステム全体（Android 8 以降）に対してロールアウトされる予定です。今後、運転中などの他のモードもサポートする予定です。
Android の 3D マッピングを活用した補正は、以下を含む 3,850 以上の都市で利用できます。
Google Earth 3D モデルの拡張とともに、3D マッピングを活用した補正の範囲も広がります。
Google マップにもアップデートが行われます。これにより、一部の都市で、歩道、横断歩道、安全地帯などの歩行者向けの街区レベルの情報の精度が向上します。2021 年には、Google Maps Platform を使っているアプリにもこのアップデートが提供されます。3D マッピングを活用した補正による位置情報の精度向上と合わせて、皆さんのようなデベロッパーが、世界中で Android を使っている 20 億人の歩行者のユースケースのサポートを向上させてくださることを期待しています。
私たちは 3D マッピングを活用した補正の他にも、位置情報の精度と利便性を向上させる努力を懸命に続けています。Fused Location Provider API（FLP）の最新の改善項目は、以下のとおりです。
getCurrentLocation
FusedLocationProviderClient
Qualcomm および Snapdragon は、Qualcomm Incorporated の商標または登録商標です。Qualcomm Snapdragon および Qualcomm Location Suite は、Qualcomm Technologies, Inc. および/またはその子会社の製品です。
2020 年は、予想もつかない事態が続く中で、困難な状況をポジティブに変える取り組みに多くのデベロッパーの皆さまが精力を傾けてこられました。世界保健機関（WHO）と世界中のゲーム関連事業者が提唱した #PlayApartTogether （離れていっしょに遊ぼう）キャンペーンを日本でも立ち上げ推進した、株式会社ミラティブと株式会社ミクシィの取り組みもその 1 つです。
Google Play では Play ストアに特集ページを設け、賛同デベロッパーのゲームを掲載しました。詳細をまとめた動画をご覧ください。
Posted by Tamao Imura - Developer Marketing Manager, Platforms and Ecosystems
この記事は Vesna Doknic による Google Play Developers - Medium の記事 "Churn: acting before it’s too late" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
アプリのユーザーは、3 つの基本的なグループに分けることができます。それは、エンゲージメントがない（獲得戦略によって新たに引き寄せられたグループ）、エンゲージメントが増加中（利用維持戦略によって利用が促進されたグループ）、エンゲージメントが減少中（離脱阻止戦略によってつなぎ留められているグループ）の 3 つです。これらはすべて異なる戦略が関わっているので、獲得、維持、離脱阻止をまったく別の領域として考えることは理にかなっています。しかし、離脱との闘いは軽視されることが多く、獲得の増加や、エンゲージメントの高いユーザーの維持率を上げることで、相殺できたりするものと見なされがちです。
前回の記事（英語）では、どうすればデベロッパーが効果的な維持戦略を策定できるかについて説明しました。これは、エンゲージメントの高いユーザーを維持する可能性を高めることを狙った戦略です（さらに細かく掘り下げたレポート全文をご覧ください）。しかし、戦略やアプリがどれほど素晴らしいものであっても、いくらかのユーザーは離脱してしまうものです。
ユーザーの離脱は、目先の収益以上の損失を会社にもたらします。例えば、早い段階でユーザーが離脱すれば、そのユーザーの獲得コストは完全に無駄であったということになります。また、離脱したユーザーを再定着させることは可能ですが、それには新しいユーザーを獲得するよりも費用も時間もかかる可能性が高いです。
ユーザーを再定着させるには、そもそもユーザーの離脱を引き起こした問題を直接的に克服しなければなりません。そのコストを考えると、ユーザーを再定着させるよりも、最初からユーザーが離脱しないようにあらかじめ手を打っておくほうがはるかに効果的です。
それでは、どうすれば手遅れになる前に行動できるのでしょうか。
離脱を防ぐということは、離脱が起こる前に対処するということです。すなわち、警告システムを作り、離脱の兆候を特定して早い段階で行動するのです。ユーザーは一夜にして離れるわけではありません。離脱する前には、アプリの使い方が変わり始めます。そしてそれは、計測して特定することが可能です。この危険信号を特定するには、以下の様なデータを確認し、離脱するユーザーがどのような行動をとっているのかを調べます。
Quickbooks は、詳細なモデリングによって最近離脱したユーザーの行動を分析し、高い離脱率と相関性のある行動に注目した「ユーザー リスク プロフィール」を作っています。
これは 200～300 種類のアプリ内行動をまとめたもので、機能を使用しない、休眠の日数、重要指標を達成できない、などが含まれています。詳しい方法について知りたい方は、こちらの記事（英語）をご覧ください。
Quickbooks は、このような「点検」を行うことで、即座に介入して独自の方法で望ましい行動を促し、離脱のリスクを軽減できるようにしています。
離脱を予測できるようになったら、離脱する可能性が高いユーザーを特定してアプリに呼び戻すことを試みます。そのためには、ユーザーにアプリの価値を再認識してもらわなければなりません。既に使っている機能についてのリマインダーを表示したり、近くリリースされる機能に期待してもらったりすることも効果的です。
これを行う方法の 1 つは、ユーザーがアプリを使って既に実現したことを思い出してもらうことです。Yazio は、ユーザーの進捗を目に見える形で継続的に追跡し、離脱を防ぐ方策として、頻繁にお祝いの言葉を贈っています。進行状況バーと祝福の画面を使ってユーザーのモチベーションを上げ、目標の達成を促します。
可能な限りコンテンツをパーソナライズし、ユーザーに自分が大事にされていると感じてもらえるようにするのも効果的です。Mobills は、使用率が低下したユーザーに対し、そのユーザーに合わせたメッセージを送り、ギフトを提供したり応援するようにしています。
Lifesum も、ユーザーに合わせたメッセージを送っています。ただし、ユーザーが見落としている可能性があるものを強調します。つまり、重要な機能のリマインダーを重視し、ユーザーの使用率を維持できるように、あまり知られていない機能についてお知らせしています。
アプリで定期購入を導入している場合、その更新期間には常にリスクがつきまといます。ここで最も重要なことは、適切なタイミングで適切な兆候に基づいて行動することです。そのためには、定期購入期間が終了する数週間前または数か月前、まさに離脱を示す行動が起きているときに、その行動を特定する必要があります。兆候は思ったよりも早く見つかるかもしれません。
続いて、キャンセル以外の選択肢を確実に示して、そのことをユーザーにはっきりと伝えます。ユーザーは、より手頃な価格、または広告をベースにしたオプションが存在することを知らないかもしれません。ユーザーにキャンセルの理由を与えないようにしましょう。
オファーを行うときは、価値の見せ方を工夫してみましょう。定期購入の更新をユーザーに促すのは、難しいものです。どんなメッセージがユーザーの共感を得るかを判断するために、異なるメッセージを試してみてもよいかもしれません。コストやメリット、オプションを明確に提示すれば、ユーザーは選択肢を与えられたように感じて選びやすくなる可能性があります。また、実世界の同等なものとコストを比べれば、視野を広げて価値を見直してもらえるかもしれません。Yazio は、定期購入の月間コストが 1 日 1 杯のコーヒーや他のダイエット製品よりも安いことをアピールしています。
また、常に言えることですが、パーソナライズしたメッセージを送れば、ユーザーは自分が大事にされていると感じます。Quickbooks は、定期購入のキャンセル フローの途中で、ユーザーがアプリで実現したこと（1,000 マイルを移動したなど）や、費用を払ったにもかかわらずまだ使っていなかった機能を提示しています。
上記のステップを通して、注目すべきユーザー グループとそれらのグループの障壁を表す、離脱につながるさまざまな行動パターンを発見できるかもしれません。もちろん、一部のグループでは、離脱は避けられない可能性もあります。アプリが提供するサービスの価値を誤解したユーザーや、単にそのアプリでは事足りなくなったユーザーがそういったグループに当てはまるでしょう。そういったケースもあるので、再定着に向けたさまざまな努力をしているにもかかわらず活動のレベルが低いままであるユーザー グループではなく、価値をもたらしてくれるグループに注目するようにしましょう。完全に離脱をなくすことは不可能であることを忘れないでください。
この記事が、離脱を最低限に抑える戦略の立案にお役に立つことを願っています。ここでご紹介した戦略は、「どっちつかず」のユーザーを定着させるために役立ち、獲得戦略や維持戦略とともに、アプリを継続的に成長させるために欠かせないものです。 この内容についてもっと知りたい方は、以下の関連情報をご覧ください。
この記事は、SameSite Cookie 属性変更シリーズの一部です。
SameSite
スキームフル Same-Site は、「サイト」の定義を、「登録可能ドメイン」のみから、「スキーム＋登録可能ドメイン」に変えるものです。詳細や例は、「同一サイト」と「同一オリジン」を理解するをご覧ください。
重要な用語: つまり、http://website.example のような安全でない HTTP バージョンのサイトと、https://website.example のような安全な HTTPS バージョンのサイトが、お互いにクロスサイトと見なされるということです。
うれしいのは、すべてのウェブサイトを既に HTTPS にアップグレードしている場合、何も心配することはない点です。その場合、何も変わることはありません。
まだウェブサイトを完全に HTTPS にアップグレードしていない場合は、この作業の優先度を上げる必要があります。ただし、サイトにアクセスするユーザーが HTTP と HTTPS を行き来している場合は、一般的なシナリオとその SameSite Cookie の動作について、以下をお読みください。
警告: 長期的に計画されているのは、サードパーティ Cookie のサポートを完全に廃止し、プライバシーを保護できる手法に置き換えることです。Cookie に SameSite=None; Secure を設定してスキームをまたいで送信できるようにする方法は、完全な HTTPS への移行に向けた一時的なソリューションとしてのみ検討してください。
SameSite=None; Secure
以下の変更を有効化すると、Chrome と Firefox でテストできます。
chrome://flags/#schemeful-same-site
about:config
network.cookie.sameSite.schemeful
true
Cookie のデフォルトを SameSite=Lax に変更した主な理由の 1 つに、クロスサイト リクエスト フォージェリ（CSRF）に対する保護がありました。しかし、安全でない HTTP トラフィックが存在する場合、ネットワーク攻撃者が Cookie を改ざんし、それを使って安全な HTTPS バージョンのサイトに侵入するチャンスが残ることになります。スキーム間にクロスサイト境界を追加することで、このような攻撃に対する保護を強化できます。
SameSite=Lax
重要な用語: 以下の例では、すべての URL で site.example などの同じ登録可能ドメインを使用していますが、http://site.example と https://site.example のようにスキームが異なっています。これを、お互いにクロススキームであるといいます。
これまで、クロススキームなウェブサイト間のナビゲーション（たとえば、http://site.example から https://site.example へのリンク）では、SameSite=Strict Cookie の送信が許可されていました。今後、これはクロスサイト ナビゲーションとして扱われます。つまり、SameSite=Strict Cookie はブロックされます。
SameSite=Strict
SameSite=None;Secure
警告: すべての主要ブラウザは、スクリプトや iframe などのアクティブな Mixed Contents をブロックします。さらに、Chrome や Firefox などのブラウザでは、パッシブな Mixed Contents のアップグレードやブロックに向けた作業が進んでいます。
ここで行う変更は、完全な HTTPS へのアップグレードを進める間の一時的な修正としてのみ検討してください。
サブリソースの例として、イメージ、iframe、XHR や Fetch によるネットワーク リクエストなどがあげられます。
これまで、ページでクロススキーム サブリソースを読み込んだ場合、SameSite=Strict または SameSite=Lax の Cookie の送信や設定が許可されていました。今後、これは他のサードパーティまたはクロスサイトのサブリソースと同じように扱われます。つまり、SameSite=Strict や SameSite=Lax の Cookie はすべてブロックされます。
加えて、ブラウザが安全なページで安全でないスキームからのリソースの読み込みを許可したとしても、サードパーティまたはクロスサイト Cookie には Secure が必須なので、リクエストの Cookie はすべてブロックされます。
Secure
これまでは、クロススキーム バージョンのウェブサイト間で POST を行った場合、SameSite=Lax または SameSite=Strict が設定された Cookie の送信は許可されていました。今後、これはクロスサイト POST として扱われ、SameSite=None Cookie のみ送信できるようになります。このシナリオは、デフォルトで安全でないバージョンを表示し、ログインまたはチェックアウト用のフォームを送信する際にユーザーを安全なバージョンにアップグレードするサイトで使われている可能性があります。
SameSite=None
サブリソースと同じく、リクエストが安全な HTTPS などのコンテキストから安全でない HTTP などのコンテキストに向かう場合、サードパーティまたはクロスサイトの Cookie には Secure が必要になるので、リクエストの Cookie はすべてブロックされます。
警告: ここでの最適なソリューションは、フォームのページと送信先ページの両方で HTTPS などの安全な接続を使うことです。この点は、ユーザーがフォームに機密性の高い情報を入力する場合に特に重要になります。
Chrome と Firefox では、デベロッパー ツールやメッセージを利用できます。
Chrome 86 以降では、DevTools の [Issue] タブにスキームフル Same-Site の問題が表示されます。サイトで以下の問題が表示される可能性があります。
ナビゲーションに関する問題:
サブリソースの読み込みに関する問題:
詳しい内容は、スキームフル Same-Site のテストとデバッグに関するヒントにも掲載されています。
Firefox 79 以降で about:config から network.cookie.sameSite.schemeful を true に設定すると、スキームフル Same-Site の問題に関するメッセージがコンソールに表示されます。サイトで以下の内容が表示される可能性があります。
cookie_name
http://site.example/
一部のリンクやサブリソースが安全でない URL を指している可能性があります。
この問題を修正する方法の 1 つは、HTTP Strict-Transport-Security（HSTS）と includeSubDomain ディレクティブを使うことです。HSTS と includeSubDomain を使うと、ページに安全でないリンクが意図せずに含まれる場合でも、ブラウザが自動的に安全なバージョンを使ってくれます。
includeSubDomain
サイトを完全に HTTPS にアップグレードしてユーザーを保護することを強くおすすめしますが、ご自身でアップグレードできない場合は、ホスティング プロバイダに相談してアップグレードのオプションを提供できるかを確認してください。セルフホストの場合は、Let's Encrypt が証明書をインストールして設定するためのさまざまなツールを提供しています。また、HTTPS 接続を提供できる CDN やその他のプロキシを経由してサイトにアクセスするように移行することも検討できます。
それでも難しい場合は、影響を受ける Cookie の SameSite 保護の緩和を試します。
Lax
Strict
None
SameSite 属性のない Cookie は、SameSite=Lax を指定した場合と同じように扱われ、それと同じクロススキーム動作が適用されます。なお、安全でない手法も一時的に例外として許可されています。詳しくは、SameSite FAQ の Chromium における Lax＋POST 対処法をご覧ください。
ページと同じ安全性が確保されている場合、WebSocket 接続は今後も同一サイトと見なされます。
同一サイト:
https://
wss://
http://
ws://
クロスサイト:
この記事は Chet Haase による Android Developers - Medium の記事 "Now in Android #30" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android 開発の最新ニュースやトピックをご紹介する Now in Android。今回は App Bundle、マテリアル デザイン コンポーネント、新しいターゲット API 要件、新しい Fragment とフローのドキュメント、最近公開されたブログ記事・動画・関連ドキュメント、ポッドキャスト エピソードなどをご紹介します。
最先端の Android 開発に関する新しい技術コンテンツを扱う連載 MAD Skills シリーズが続いています。
App Bundle のミニシリーズは、Google Developer Expert の Angelica Oliveira からのヒント、続いて私（質問役）と Ben Weiss、Wojtek Kaliciński、 Iurii Makhno（回答役）によるリアルタイム Q&A とアーカイブで終了しました。App Bundle の全エピソード（動画と記事）は、まとめのブログ記事（英語）からリンクしています。
続いて MAD Skills は、マテリアル デザイン コンポーネント（MDC）についての新しいミニシリーズに入りました。マテリアル デザイン コンポーネントは、マテリアル デザイン ガイドラインを使ってアプリの構築を簡単にするライブラリです。
初回は Nick Butcher が、Android デベロッパーにマテリアル デザイン コンポーネントの使用を推奨する理由を説明しています。この動画には、テーマのサポート、組み込みの画面遷移、デフォルトのマテリアル スタイルのコンポーネントなど、MDC が提供するさまざまな機能の概要が含まれています。このコンテンツは、以前にブログ記事（英語）も掲載しています。
次に、Nick Rout がマテリアル テーマについてのエピソードを投稿しました。MaterialThemeBuilder サンプル プロジェクトについて説明しつつ、マテリアル テーマの使い方とカスタマイズの方法を紹介しています。
この動画に加えて、色、書体、形状について取り上げた記事（英語）もそれぞれご覧ください。
12 月第一週にかけて、Chris Banes が 3 つ目のエピソードを投稿しました。Android 10 の Force Dark 機能と MDC の DayNight テーマの両方を使い、MDC でダークテーマを作成する方法について説明しています。また、Chris はこのコンテンツをブログ記事形式（英語）でも公開しました。
引き続き、ほかにも MDC 関連のコンテンツを公開する予定です。さらに、日本時間 12 月 11 日午前 3 時から、もう一度リアルタイム Q&A （英語）を行います。詳細は MDC プレイリストをご覧ください。
連載中の MAD コンテンツは、YouTube の MAD Skills プレイリスト、Medium のブログ記事（英語）、またはすべてのリンクが掲載されているランディング ページからご覧ください。
2021 年後半には、ターゲット API（新規アプリとアプリのアップデート）と App Bundle の両方の要件が追加されます。Hoi Lam が、これについて詳しく説明したブログ記事（日本語）を投稿しました。簡潔にまとめると、次のようになります。
2021 年 8 月:
2021 年 11 月:
Fragment は、UI デベロッパーに重要なアーキテクチャ要素を提供し、アプリの UI の小さな塊を自己完結的な形で管理できるようにします。Fragment と Navigation を組み合わせている方も、単独で Fragment を使っている方も、アプリで最も効果的に Fragment を使う方法を確認することをおすすめします。ツールや API の使い方を理解するために、最新の綿密なドキュメントを公開することが重要であると考えています。サポートが終了した API の利用は避けるべきですが、関連ドキュメントでは、正しい方向性を示したり、ベスト プラクティスを説明しています。
そこで、Fragment のドキュメントを大きく改訂し、ライフサイクル、状態、テストなど、Fragment のさまざまな側面について説明している最新のガイドを公開しました。こちらから、最新のドキュメントをご確認ください。
AndroidX で Fragment の修正や拡張を行っている Ian Lake が、Twitter のフィードで今回のドキュメントの変更に触れています。
Kotlin のフローについての新しいドキュメントも公開しました。ここには、フローの基本的な使用方法から、新しい StateFlow および SharedFlow API のテスト方法まで、あらゆる情報が掲載されています。また、フローの使用についての動画も忘れずにご覧ください。
StateFlow
SharedFlow
先週私は、アプリの起動時のパフォーマンスに関するいくつかの処理を自動化する方法について、ブログ記事（英語）を投稿しました。私は、起動時のパフォーマンス全般に注目しており、何度も繰り返して連続実行する際に、起動時間を求める処理を自動化する妥当な方法を見つけたいと考えてきました。同じように起動時のパフォーマンス テストに興味がある方のために、私が利用したアプローチを公開しています。
Manuel Vivo は、Dagger から Hilt への移行というブログ記事（英語）で、「その価値はあるのか？」という疑問を投げかけています。このブログ記事では、移行を検討すべきいくつかの重要な理由に触れています。たとえば、API のテスト、整合性、AndroidX 拡張機能との統合などです。
Hilt を使い始めるデベロッパーの皆さんに役立ててもらうため、Filip Stanis がKotlin による Hilt 実践ガイド（英語）を投稿しました。依存性注入や Dagger を使ったことがない方でも大丈夫です。まったく初めてという方も、ぜひお読みください。
タイトルからは、この記事が Kotlin デベロッパー向けのように思えるかもしれませんが、これは記事のコード スニペットに Kotlin を使っているからです。記事で紹介している一般的なアプローチやテクニックは、Java プログラミング言語を使っているデベロッパーにも当てはまります。
Manuel Vivo が Kotlin Vocabulary シリーズに新しい動画を投稿しました。Kotlin フローを使ってデータのストリームを発行する方法について説明しています。これは、以前公開した動画、コルーチンの ABC が元になっているので、先にそちらを見てからフローを学ぶのもよいでしょう。
David Winer が Kotlin Synthetics と View Binding についてのブログ記事を投稿しました。この 2 つはどちらも、厄介な findViewById() 呼び出しをコードから無くすためのメカニズムです。このブログ記事では、Kotlin プラグインの今後のバージョンで Synthetics のサポートが終了することをお伝えしています。また、今後も推奨とサポートが継続される @Parcelize エクステンションについても触れています。
findViewById()
@Parcelize
最近の Android リリースでは、ユーザーデータの保護、データアクセスへのコントロール、透過性向上に関して、多くの変更が行われています。特に重視されている領域が位置情報です。ユーザーは、アプリの位置情報へのアクセスを望まない場合や、そのアクセスを非常に注意深く制御したい場合があるからです。
そのため、Google Play ポリシーにより、バックグラウンドでの実行中に位置情報にアクセスするアプリでは、（Play Store から）アクセス許可をリクエストする操作が必須になります。このブログ記事では、そのリクエスト方法について詳しく説明しています。
今回は以上です。次回も Android デベロッパーの世界の最新アップデートをお届けします。お楽しみに。
