この記事は Todd Kerpelman(Developer Advocate) による The Firebase Blog の記事 "Why is my Cloud Firestore query slow?" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Cloud Firestore のパフォーマンスについては、「ベースのデータセットではなく結果セットのサイズに比例して高速化する」、「低速のクエリを作成するのは実質的に不可能だ」など、その素晴らしさを評価する声がよく聞かれます。そしてほとんどの場合、それは事実です。アプリでは莫大な数のレコードが格納されたデータセットに対するクエリを実行し、ユーザーが画面から親指を離すよりも早く結果を取得できます。

とは言え、デベロッパーからは「特定の状況では Cloud Firestore の動作が遅く感じられ、クエリの結果を取得するのに予想よりも時間がかかる」という意見を聞くこともあります。それはなぜでしょうか。今回は、Cloud Firestore の動作が遅くなったように見える場合に考えられる原因と、その対処方法をご紹介します。

理由その 1: データが多すぎる

クエリが遅くなったと感じる場合に第一に考えられる原因としてクエリ自体は非常に高速に実行されているのですが、クエリが完了した後にすべてのデータをデバイスに転送する必要があり、実際にはその処理に時間がかかっているのです。

たとえば、組織内の全営業担当者を対象にしたクエリを実行するとしましょう。このクエリは非常に高速に実行されます。しかし、その結果セットが 2,000 人の従業員のドキュメントで構成されていて、各ドキュメントに 75 KB のデータが含まれていたらどうでしょう。デバイスでは 150 MB のデータをダウンロードする必要があり、それが完了するまで結果は確認できません。

パフォーマンスを改善するには

この問題を解決するには、必要なデータ以外は転送しないようにするとよいでしょう。簡単なのは、クエリに制限を追加する方法です。従業員リストの結果のうち、ユーザーが必要なのは先頭のごく一部だけだと思われる場合は、クエリの最後に limit(25) を追加すれば、最初の方のデータのみダウンロードされ、その他のレコードはユーザーがリクエストした場合に限りダウンロードされるようにすることができます。これについてはこちらの動画で詳しく説明していますので、ぜひご覧ください。



一方、営業担当者 2,000 人全員のデータをクエリで取得する必要があると考える場合は、別の方法があります。最初のクエリで取得したいデータのみを含むドキュメントをこれらのレコードから分離し、その他の詳細なデータを含むドキュメントは個別のコレクションまたはサブコレクションにまとめるのです。後者のドキュメントは最初の取得時には転送されませんが、ユーザーの必要に応じて後からリクエストできます。



ドキュメントのサイズを小さくすると他にもメリットがあります。たとえば、クエリにリアルタイム リスナーを設定して、ドキュメントが更新されるとそのドキュメントがデバイスに送信されるようにしたい場合です。ドキュメントのサイズを小さくしておけば、リスナーで変更が発生するたびに転送されるデータの量も少なくなります。

理由その 2: オフライン キャッシュが大きすぎる

Cloud Firestore のオフライン キャッシュはとても優れた機能です。オフラインの永続性を有効にすると、ユーザーがトンネル内に入ったときや飛行機に 9 時間乗っている間でも、アプリはオンラインと「同じように機能」します。つまり、オンライン中に読み取ったドキュメントをオフラインでも利用でき、オフライン中に書き込んだデータは、アプリがオンラインに戻るまでローカルでキューに追加されます。さらに、クライアントの SDK ではこのオフライン キャッシュを利用して、大量のデータがダウンロードされないようにすることができるため、ドキュメントの書き込みなどのアクションを高速化できます。ただし Cloud Firestore は「オフライン優先」のデータベースとして設計されているわけではないので、今のところローカルでの大量のデータの処理には向いていません。

Cloud Firestore はクラウド内で、すべてのコレクションの全ドキュメントとそのフィールドをもれなくインデックスに登録しますが、（現時点では）オフライン キャッシュ用にこうしたインデックスを作成することはありません。つまり、オフライン キャッシュ内のドキュメントにクエリを実行する場合、Cloud Firestore ではクエリ対象のコレクションについて、ローカルに保存されているすべてのドキュメントを展開してからクエリと照合する必要があります。

別の言い方をすれば、バックエンドでのクエリは結果セットのサイズに応じて遅くなりますが、ローカルのオフライン キャッシュ内でのクエリは、クエリ対象のコレクションに含まれるデータのサイズに応じて遅くなります。

ところで、ローカルでのクエリが実際にどの程度遅くなるかは、状況によって異なります。ここで話題にしているのはローカル、つまりネットワークに接続していない状態でのオペレーションですが、これはネットワーク呼び出しを行うよりも速い可能性が（しかもかなりの確率で）あります。ただし、1 つのコレクションに含まれる大量のデータを分類しなければならない場合、あるいは単に動作が遅いデバイスを使用している場合、大きなオフライン キャッシュに対するローカル オペレーションは著しく遅くなる可能性もあります。

パフォーマンスを改善するには

最初に、前のセクションで説明したおすすめの方法を試してみてください。つまり、ユーザーが必要とするデータのみを取得できるようクエリに制限を追加し、不要な細かいデータはサブコレクションに移動することを検討します。また、以前の投稿の最後に取り上げた「複数のサブコレクションと単独の最上位コレクション」のどちらを使うべきかという観点で考えた場合、このケースでは「複数のサブコレクション」を採用した方がよいでしょう。そうすれば、キャッシュの検索対象が、こうした小さめのコレクションに含まれるデータのみとなるからです。

2 番目の方法は、必要以上のデータをキャッシュに詰め込まないようにすることです。私は、デベロッパーがキャッシュを意図的にこのように使用するケースをいくつか見たことがあります。アプリの最初の起動時に膨大な数のドキュメントにクエリを実行し、その後のすべてのデータベース リクエストにローカル キャッシュを強制的に参照させるというものです。通常、データベース コストを削減したり、以降の呼び出しを高速化したりする目的で用いられますが、実際にはメリットよりデメリットの方が大きい場合がほとんどです。

3 番目の方法は、オフライン キャッシュのサイズを小さくすることです。モバイル デバイスのキャッシュのサイズはデフォルトで 100 MB に設定されていますが、状況によっては（特に、大規模な 1 つのコレクションにほとんどのデータが格納されている場合は）、このサイズではデータが多すぎてデバイスで処理できない可能性があります。このサイズは、Firebase の設定で cacheSizeBytes の値を変更することで調整できます。特定のクライアントに対してサイズを調整するとよいでしょう。

4 番目に、永続性を完全に無効にして、何か変化があるか確認してみてください。この方法は通常はおすすめしません。前に述べたように、オフライン キャッシュは非常に優れた機能だからです。それでも、クエリが遅くなったように感じて、その理由がわからない場合は、永続性を無効にしてアプリを再実行することでキャッシュが問題の原因かどうかを判断できるでしょう。

理由その 3: ジグザグマージ結合に問題がある

「ジグザグマージ結合」という名前を私が個人的に気に入っていることはさておき、このアルゴリズムは複合インデックスに依存せずに複数のインデックスからの結果を統合できる点で非常に便利です。基本的には、ドキュメント ID 順に並べ替えた 2 つ（またはそれ以上）のインデックス間を行き来して一致を見つける仕組みになっています。

しかし、ジグザグマージ結合にも 1 つ弱点があります。どちらの結果セットもサイズが大きいにもかかわらず両者の共通部分が少ないと、パフォーマンスの問題が発生する場合があるのです。一例として、カウンター サービスも提供している高級レストランを検索するクエリを考えてみましょう。

restaurants.where('price', '==', '$$$$').where('orderAtCounter', '==', 'true')

両方ともかなり大きいグループですが、共通部分はおそらくほとんどありません。この場合、ジグザグマージ結合では、必要な結果を取得するために多くの検索を行う必要があります。

クエリのほとんどが高速に実行されているのに、特定のクエリを複数のフィールドに対して一度に実行している最中に遅くなる場合は、この状況に陥っている可能性があります。

パフォーマンスを改善するには

複数のフィールドにわたるクエリがが遅くなる場合、それらのフィールドに対する複合インデックスを作成することでパフォーマンスを改善できます。バックエンドでは、その後のすべてのクエリで、ジグザグマージ結合ではなくこの複合インデックスを使用するようになります。つまり、クエリは結果セットのサイズに比例して高速になるということです。

理由その 4: Realtime Database に慣れてしまっている

Cloud Firestore は、クエリ機能、信頼性、スケーラビリティの点で Firebase Realtime Database を上回ります。ただし北米で利用する場合は、一般に Realtime Database の方が低レイテンシです。通常はそれほど大きな差はなく、チャットアプリなどでは違いに気付くことはおそらくないでしょう。しかし、データベースの超高速応答に依存するアプリ（たとえばリアルタイム描画アプリやマルチプレーヤー型ゲームなど）の場合は、Realtime Database の方が「まさにリアルタイム」だと感じられるかもしれません。

パフォーマンスを改善するには

Realtime Database の低レイテンシが求められるプロジェクトを進めている（かつ、大部分のユーザーが北米にいると予想される）場合、もし Cloud Firestore の特有の機能が必要ないのであれば、そのプロジェクトの該当箇所には Realtime Database を使用するとよいでしょう。ただしその前に、以前のブログ投稿や公式ドキュメントを確認して、2 つのデータベースそれぞれのメリットとデメリットを十分に理解しておくことをおすすめします。

理由その 5: 物理的な制約がある

ほぼ完ぺきな状況であっても、利用している Cloud Firestore インスタンスがオクラホマでホストされていて、ユーザーがニューデリーにいる場合、「光の速度」の関係で少なくとも 80 ミリ秒のレイテンシが発生します。そして現実的に、どのネットワーク呼び出しでも 242 ミリ秒前後のラウンドトリップ時間がかかります。そのため、Cloud Firestore がどれほど高速に応答しても、その応答が Cloud Firestore とデバイス間を移動する時間がどうしてもかかってしまうのです。

パフォーマンスを改善するには

まず、単回のフェッチの代わりにリアルタイム リスナーを使用することをおすすめします。クライアントの SDK 内でリアルタイム リスナーを使用すると、非常に優れた多くのレイテンシ補正機能が提供されるためです。たとえば Cloud Firestore は、ネットワーク呼び出しが戻るのを待っている間、キャッシュされたデータをリスナーに提示するため、ユーザーに結果を表示する時間がより高速になります。また、データベースへの書き込みはすぐにローカル キャッシュに適用されます。つまり、デバイスがサーバーによる確認を待っている間に、これらの変更が即座に反映されることがわかるでしょう。

次に、ユーザーの大半が所在する場所でデータをホストするようにします。最初にデータベース インスタンスを初期化する際に Cloud Firestore のロケーションを選択できるので、アプリに最適なロケーションはどこか、コスト面だけでなくパフォーマンス面も含めて十分に検討しましょう。

3 番目の方法としては、量子エンタングルメントに基づいた信頼性の高い安価なグローバル通信ネットワークを実装することが挙げられます。これにより、光の速度の問題を回避できるためです。この対応が済めば、おそらくライセンス料の支払いを終わらせることができ、そもそもどんなアプリを作っていたかも忘れてしまうかもしれません。

最後に

今後、Cloud Firestore のクエリが遅く感じる場面に遭遇したときは、上記の内容に目を通していずれかの状況に当てはまるかどうかを確認してください。なお、アプリのパフォーマンスを確認するには、実際の使用環境でのパフォーマンスを測定するのが一番です。この目的に最適なサービスとして、Firebase Performance Monitoring があります。

Performance Monitoring をアプリに統合して、クエリの実際のパフォーマンスを確認できるようカスタム トレースを 1～2 つ設定してみることをおすすめします。

Reviewed by Sophia Hu - Data Management Specialist, Google Cloud

この記事は Chrome セキュリティ チーム、Chris Thompson による Google Online Security Blog の記事 "Chrome UI for Deprecating Legacy TLS Versions" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

昨年 10 月、Chrome 81 で TLS 1.0 と 1.1 のサポートを削除する計画についてお知らせしました。この投稿では、削除の前段階として穏やかな警告 UI を導入すること、Chrome 81 で TLS 1.0 と 1.1 をブロックすることになる UI についてお知らせします。サイト管理者は、ただちに TLS 1.2 以降を有効にし、ここで紹介する UI が表示されないようにしてください。
以前の TLS の使用は減少していますが、現在もページ読み込みの 0.5% 以上で非推奨のバージョンが使われています。最終的なサポートの削除に向けた移行を容易にし、古い設定が動作しなくなったときにユーザーを驚かせることがないように、Chrome は 2 段階でサポートの終了に対応します。まず、非推奨のバージョンを使っているサイトに対して、新しいセキュリティ インジケーターを表示します。次に、ページ全面に警告を表示してサイトへの接続をブロックします。


削除前の警告
2020 年 1 月 13 日より、Chrome 79 以降で、TLS 1.0 または 1.1 を使用しているサイトに「Not Secure」インジケーターを表示し、ユーザーに古い設定であることを警告します。

サイトで TLS 1.0 または 1.1 を使っている場合、Chrome はセキュリティ インジケーターをダウングレードし、ページ情報に詳細な警告メッセージを表示します。この変更では、ユーザーがページにアクセスする操作がブロックされることはありませんが、接続のセキュリティがダウングレードされていることが警告されます。
なお、Chrome の DevTools には既に警告が表示されるようになっています。非推奨のバージョンの TLS を使っていることをサイトオーナーに警告するためです。


削除後の UI
2020 年 3 月に Stable チャンネルにリリースされる予定の Chrome 81 以降では、TLS 1.0 または 1.1 を使っているサイトにアクセスしようとすると、ページ全体を覆うインタースティシャル警告が表示されて接続がブロックされます。

サイト管理者は、ただちに TLS 1.2 以降を有効にしてください。サーバー ソフトウェアによっては（Apache や nginx など）、構成の変更やソフトウェアのアップデートが必要になる場合があります。さらに、すべてのサイトで TLS 設定を再確認することをお勧めします。最初のお知らせの際に、最新の TLS の基準について概要を説明しています。

企業向けリリースで SSLVersionMin ポリシーを “tls1.2” に設定すると、TLS 1.0 と 1.1 の最終的な削除について事前に確認することができます。この設定を行うと、クライアントが TLS 1.0 および 1.1 プロトコルで接続できなくなります。対応に時間がかかる企業は、このポリシーを使って TLS 1.0 や TLS 1.1 を有効化し直し、警告 UI を無効化することができます。ただし、この操作を行えるのは、2021 年 1 月までに限られます。

Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Chrome プロダクト マネージャー、Kenji Baheux による Chromium Blog の記事 "Experimenting with same-provider DNS-over-HTTPS upgrade" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


 ウェブを安全に使えるようにするという長年にわたる私たちの取り組みの一環として、Chrome 78 で DNS-over-HTTPS（DoH）実装を検証するための実験を行います。名前からもわかるとおり、この考え方は、HTTPS によって確保されるセキュリティとプライバシー上の重要な利点を DNS にもたらします。DNS は、指定されたウェブサイトをホスティングしているサーバーをブラウザが判断する仕組みです。たとえば、パブリック WiFi に接続しても、DoH を使っていれば、他の WiFi ユーザーが皆さんの見ているサイトを知ることはできなくなります。また、なりすましやフィッシング攻撃も防ぐことができます。この実験は、既に DoH をサポートしている DNS プロバイダと連携して実施します。実験の目的は、現在の DNS サービスを DoH バージョンにアップグレードすることで、ユーザー間のセキュリティやプライバシーを改善することにあります。このアプローチでは、使用する DNS サービスは変わらず、プロトコルだけが変わります。そのため、既存の子ども向けの保護を含め、現在の DNS プロバイダが行っているコンテンツ制御の有効性は変わりません。

さらに具体的に説明します。Chrome 78 で行う実験では、ユーザーの現在の DNS プロバイダが DoH 対応プロバイダのリストに掲載されているかどうかを確認し、そのプロバイダが提供する同等の DoH サービスにアップグレードします。DNS プロバイダがリストに掲載されていない場合、Chrome は現在の動作を継続します。リストに掲載されるプロバイダは、プライバシーとセキュリティに対する強い姿勢、DoH サービスに向けた準備の完了、実験の参加への同意という条件を満たすプロバイダから選択されました。実験の目的は、Chrome の実装を検証し、パフォーマンスへの影響を評価することです。 

この実験は、サポートされているすべてのプラットフォーム（Linux と iOS を除く）で、一部の Chrome ユーザーを対象に行われます。Android 9 以上で、ユーザーが Private DNS 設定で DNS-over-TLS プロバイダを指定している場合、Chrome は関連付けられている DoH プロバイダを使い、エラー時にはシステムの Private DNS にフォールバックする場合があります。

DNS プロバイダの現状を維持し、プロバイダの同等な DoH サービスへのアップグレードのみを行うので、同じユーザー エクスペリエンスが維持されます。たとえば、DNS プロバイダが提供する不正なソフトウェアからの保護やペアレンタル コントロール機能は引き続き動作します。DoH が失敗した場合、Chrome はプロバイダの通常の DNS サービスを使います。Chrome 78 の chrome://flags/#dns-over-https でフラグを無効にして、実験をオプトアウトすることも可能です。


ほとんどのマネージド Chrome リリースは、実験の対象外になります。企業や教育機関の管理者の方は、今後のリリースノートを読んで DoH ポリシーについての詳細をご確認ください。このポリシーは、Chrome Enterprise ブログでも公開する予定です。

DNS には 35 年の歴史があり、さまざまな関係者が利用して多様なユースケースを実現しています。特に、ISP が提供する家族向けの安全なコンテンツ フィルタリングにおいて、DNS が重要な役割を果たせることは承知しています。そのため、重要なステークホルダー（ISP や DNS プロバイダ、オンラインの安全性を専門とする組織など）を巻き込んで手順についての議論を行いつつ、家族向けフィルターなどの現在利用されているユーザー向け機能を尊重した段階的なアプローチをとります。また、Chrome の機能とパフォーマンスの改善への協力に同意したユーザーから送られるパフォーマンスや信頼性に関する統計、ユーザーによるフィードバックも考慮します。

この実験は、ユーザーのプライバシー、セキュリティ、安全性を改善するために、協力して歩まなければならない長い道のりのつつましい第一歩です。DoH が実環境でどのように動作するか、確認するのが待ち遠しくてたまりません。皆さんからのフィードバックもお待ちしています！

Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Leo Postovoit による The AMP Blog の記事 "Powerful impact: Why we AMPized the Australian pop culture site – GOAT" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


NOVA Entertainment はオーストラリアでも特に有名なメディア ブランドで、過去 19 年間にわたってラジオ、メディア、ローカル コンテンツに携わってきました。その NOVA がポップカルチャーやニュース、エンターテイメント向けのモバイル ファースト プラットフォームとして構築したのが GOAT です。

GOAT は、プログレッシブを重視した WordPress ビルドの開発によって恩恵を受けた最初の NOVA のサイトです。GOAT の編集者たちの目標の 1 つは、アクセスしやすく便利で高速なフォーマットによってコンテンツを届けることです。パフォーマンスとユーザビリティは最優先事項です。ここでは、GOAT の技術革新において AMP と PWA がどのようなインパクトをもたらしたのかについて説明します。

課題
GOAT ウェブサイトには、パフォーマンスとユーザビリティに関する問題が発生していました。ユーザー エクスペリエンスを改善して多くの端末との互換性を向上させるための最優先事項は、サイトのパフォーマンスを向上させることでした。サイトがコンテンツやアセットをレンダリングする際に遅延が生じ、ユーザーやオンサイト体験、共有体験の妨げになっていました。これは驚くべきことではありません。サイトへのエンゲージメントのレベルにパフォーマンスがどれほど重要かは、複数の調査結果が一貫して示しています。
今年東京で開催された技術カンファレンスの講演の冒頭で、Google 社員の Jeany Halliman は、Google がメディアサイトの訪問者を対象に「サイトを見る際に一番嫌なこと」を尋ねた調査について触れました。

「広告業界出身の私は、いつも（訪問者が嫌うのは）広告だと思っていました。しかし、ユーザーの大半は、遅いウェブサイトと答えたのです」 – Jeany Halliman

この回答と、ページのスピードが直帰率に与える影響を細かく観測した結果には、明らかに相関性があります。しかし、過大な広告戦略が注目され、多くのメディアサイトがそれに対する「反動」を受けていることを考えれば、多くの方にとって、スピードがページの広告よりも上位に来ていることは驚きだったはずです。

チャンス
NOVA は、WordPress エンジニアリング エコシステムのリーダー的存在であり、Google と連携して公式の AMP Plugin for WordPress のメンテナンスを行っている XWP に連絡しました。XWP は、Rolling Stone、News Corp Australia、Rogers などの大手パブリッシャーや、Cloudinary、Google、BigCommerce、Automattic などの技術パートナー向けに美しく複雑なソリューションを開発していることで知られ、ウェブを進化させることを重視して仕事に取り組んでいます。

NOVA のステークホルダーが示した主要な目標は、パフォーマンス、拡張性、ユーザビリティでした。そのため、XWP にとっては、向かうべき道がプログレッシブ AMP によるアプローチであることは明白でした。

一方で、AMP ファースト戦略に移行するにあたって最も重要な目的は明らかでした。ユーザーが繰り返し利用し、喜んで共有してくれる高速な体験を作成するには、CI/CD、自動テスト、高可用性ホスティングを含む開発のベスト プラクティスを駆使して確実に拡張性や安定性を実現することも重要です。GOAT サイトは、コードの品質が高く、最新の WordPress の実装に関する留意点を踏まえて構築されているので、早いだけでなく、長く使えるものとして作られています。

解決策
AMP やその他のパフォーマンス改善策に精通している XWP は、NOVA が GOAT サイトで達成したい目標を実現するため、さまざまな実装を検討しました。最も適していたのは、1 つのコードベースで開発を効率化できる AMP ファースト戦略でした。

そこからさらに一歩進めた GOAT は、PWA 機能プラグイン（これも XWP と Google が連携して開発しています）のすばらしい事例とも言えるでしょう。このプラグインは、Service Worker を活用してオフライン モードや通知などの追加機能を提供します。また、この定義済みソリューションでは、AMP と PWA のメリットを今までになく簡単に組み合わせることができる amp-install-serviceworker コンポーネントが活用されています。

現在含まれている PWA 機能の範囲は限定的ですが、長期的な目標として、PC やモバイル端末へのインストール機能、さらに充実したオフライン モードやプリフェッチ ページ、ネイティブのプッシュ通知などを追加したいと考えています。これらの機能は、ウェブのあちこちに見られる強力な PWA と同様のものです。

広告の組み込み 
広告の読み込みが適切に設定されていない場合、ページのパフォーマンスが低下する原因となる可能性があります。GOAT のようなメディア重視のサイトでは、特にその傾向が顕著です。AMP を使うということは、XWP が GOAT の広告スタックを実装する際に、AMP 標準に準拠したアプローチを採用しなければならないということです。  完全に AMP 対応されていない広告プロバイダを利用するために多少の妥協は必要になりましたが、結果的には、広告収入を頼りにするメディアサイトとしてかなり高いパフォーマンスを実現しました。これは 2 つの長所を兼ね備えています。すなわち、優れたユーザー エクスペリエンスを実現でき、広告の読み込みも次善の方法で最適化されているので、パフォーマンスの低下につながることはありません。

結果 
ここまで説明してきたように、GOAT は NOVA のサイトで初めて統合編集ワークフローとパフォーマンスを重視したテーマビルドを実稼働させたものです。これは PWA サイトであると同時に、すべてのテンプレートがネイティブ AMP として構築されています。パフォーマンス面での成果は明らかです。

• 複数のプロパティの編集操作を統合しています。
• モバイルの Google Pagespeed Insights スコアは 7 から 77 に上昇しました。
• WebPageTest 3G テスト: 実装前 / 実装後。ポイント: レンダリング開始時間（Start Render）が 1.5 秒短縮されました。操作が可能になるまでの時間は、43 秒からわずか 10 秒になりました。
• Lighthouse テスト: 実装前 / 実装後。最初のコンテンツ描画（First Contentful Paint）が 5.8 秒から 2.5 秒になりました（3.3 秒短縮）。パフォーマンス スコアは 7 から 65 に上昇しました。最初の CPU アイドル時間（First CPU Idle）は 16.2 秒から 5.9 秒に短縮されました。
• GTmetrix: 実装前 / 実装後。PageSpeed スコアは D（63%）から B（82%）に上昇しました。

AMP の活用を始める
GOAT サイトの AMP ファースト戦略で達成した結果をもとに、AMP を活用して現在のビジネスの課題を解決する方法について、さらに学習することをお勧めします。

• AMP の詳細については、amp.dev にあるプロジェクトのホームページをご覧ください。  
• 自分のサイトの互換性を評価し、AMP によってパフォーマンスとユーザー エクスペリエンスの恩恵を得られるかを確認してみたい方は、AMPized.com（WordPress サイトで AMP のメリットを実現する XWP のサービス）をご覧ください。

執筆者: XWP ストラテジスト、Leo Postovoit

Reviewed by Chiko Shimizu - Developer Relations Team

この記事は Naina Raisinghani による The AMP Blog の記事 "amp-script: AMP ❤️ JS" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

今年の AMP Conf では、<amp-script> のデベロッパー プレビューを紹介しました。本日は、<amp-script> の一般公開についてお知らせします。カスタム JavaScript は、AMP コンポーネントによって別の Worker スレッドで実行されます。そのため、超高速な AMP ページはそのままに、カスタム JavaScript を追加できるようになります。
<amp-script> を使うと、既存の AMP コンポーネントでは実現できなかったユースケースに対応できます。また、AMP ページと非 AMP ページでコードを共有することもできます。JavaScript フレームワークを使うことも可能です。次にあげるのは、<amp-script> チームが構築してきたいくつかのサンプルです。

• Vue を使った Todo MVC
• パスワード チェッカー
• D3.js を使ったニュース記事のデータ視覚化
• 次のセクションに移動する前に検証が必要になる複数ページフォーム（下のイメージ）

上の例を見て興味を持った方は、<amp-script> を試してみてください。なお、AMP のパフォーマンスを保証するために、いくつか制約がある点に注意が必要です。

• コンテンツのジャンプ: 通常の <amp-script> では、意図しないコンテンツのジャンプを回避するため、ユーザーのジェスチャーが発生しないとページのコンテンツを変更することはできません。 
• ページ読み込み: <amp-script> はユーザーの操作なしにページのコンテンツを変更することはできないので、ページの読み込み時にコンテンツを変更することもできません。
• スクリプトのサイズ: 1 つの <amp-script> で使うスクリプトは、150 kB 以下である必要があります。なお、お気に入りの JS フレームワークを使うことはできますが、150 K の制限内に収まっている必要があります。
• API のサポート: Web Worker ですべての API がサポートされているとは限りません。WorkerDOM には、許可されている API のリストが掲載されています。また、いくつかの DOM のメソッドやプロパティはまだ実装されていません。リスト全体は、WorkerDOM の互換性で公開されています。追加してほしい API がある方は、問題として送信してください、

<amp-script> は、React、Preact、Angular、Vue.js、jQuery、D3.js など、皆さんが既に利用しているかもしれないフレームワークに対応しています。

この点は、AMP を使っているデベロッパーから寄せられた最も重要な要望でした。AMP Project は、スピードという AMP の価値提案を維持しつつ、この要望に対処できたことをうれしく思っています。<amp-script> の動作の詳細については、こちらをご覧ください。また、このガイドに従って <amp-script> を試してみてください。このすばらしい手法を使うと、これまでは不可能だったたくさんのユースケースを実現できるようになります。

<amp-script> の使用に関する問題や機能リクエストがありましたら、遠慮なくお知らせください。


投稿者: Naina Raisinghani（Google AMP Project、プロダクト マネージャー）


Reviewed by Chiko Shimizu - Developer Relations Team

この記事は Allen Huang and Rohan Shah (Product Managers on Android UI) による Android Developers Blog の記事 "Gesture Navigation: A Backstory" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Android Q の最大の変更点の 1 つが、新しくなったジェスチャー ナビゲーションです。新しいシステム ナビゲーション モードでは、画面の左端または右端から内側にスワイプすると前の画面に戻ることができ、画面の下部から上にスワイプするとホーム画面に戻ることができます。また、画面の下隅から斜めにスワイプするとデバイス アシスタントが起動します。

システム ナビゲーションをジェスチャー モデルに移行したことで、ナビゲーション ボタンを非表示にしてアプリの画面領域を拡げ、より臨場感あふれるエクスペリエンスを実現できるようになりました。

今回は、ナビゲーション デザインの過程でどのような課題に直面し、難しい選択を迫られたときどのような理由で決断したかなど、新しいシステム ナビゲーションにまつわる裏話を披露します。ジェスチャーのデザインに関して少々マニアックな部分にまで踏み込みますが、デベロッパー並びに OEM パートナーの皆様とユーザーの利便性のバランスをどう取るかについて、Google がいかに頭を悩ませたかをご理解いただけたらと思っています。アプリをこれらの変更に対応させる方法については、Medium の記事シリーズ「エッジ ツー エッジへの対応」で詳しく解説しておりますのでぜひご覧ください。

ジェスチャーに移行した理由

アプリ デベロッパーやパートナーの皆様にとっての Android の魅力の 1 つは、スマートフォンでまったく新しい革新的な手法を試すことができる点ではないでしょうか。

モバイル デバイスのジェスチャー機能は 2009 年には登場していましたが、ジェスチャー ナビゲーションのパターンが急激に増えたのはここ 3 年ほどのことです。

この流れをリードしたのが、たとえば Fluid NG や XDA のような、独創的なアイデアに挑戦してきた革新的な Android パートナーや Android アプリです。

Google が調査したところ、ジェスチャーはユーザーにとってさまざまなメリットがあることがわかりました。

1. ジェスチャーは、スマートフォンを操作する方法としてよりスピーディーで、自然で、人間工学的に優れている
2. ジェスチャーはより意図的である（ソフトウェア ボタンは、スマートフォンを手に取るとき偶然タップしてしまうことがある）
3. ジェスチャーを採用することで、アプリ コンテンツに上書き表示するシステム ナビゲーションを最小限に抑えることができ、より臨場感あふれるエクスペリエンスを実現できる（大画面化と狭額縁化が進む中、「ホーム」ボタン、「戻る」ボタン、ナビゲーション バーなどを画面に表示する必要がない）

しかし、良いことばかりではありません。ジェスチャー モードにはさまざまな問題もあります。

1. ジェスチャーは、すべてのユーザーが快適に利用できるとは限らない
2. ジェスチャーは、習得がより難しく、ある程度の調整も必要になる
3. ジェスチャーは、アプリのナビゲーション パターンと競合する可能性がある

しかし、何よりも私たちが問題だと感じたのは、Android スマートフォンでもブランドや機種が違えばジェスチャーが異なるという「断片化」が生じており、特に Android デベロッパーの皆様がこの点に大きな懸念を抱かれていることでした。
そこで Google では、ここ 1 年ほどかけて Samsung、Xiaomi、HMD Global、OPPO、OnePlus、LG、Motorola などのパートナーと協力し、将来的にジェスチャー ナビゲーションを標準化していくことを決めました。一貫性のあるユーザー エクスペリエンスとデベロッパー エクスペリエンスを提供するため、Android Q 以降の新しいデバイスでは、Q のジェスチャーをデフォルトのジェスチャー ナビゲーションにします。
ただし、すべてのユーザーがジャスチャーを快適に利用できるとは限りません。ジェスチャーのような細かな動きが得意でない方々のために、すべての Android デバイスで引き続き 3 ボタン ナビゲーションをオプション機能として提供することにしています。

今回これらのジェスチャーを採用した理由

Google ではまず徹底的な調査を行いました。ユーザーはどういう形でスマートフォンを握っているか、指が届く範囲はどのあたりか、最もよく使うのはスマートフォンのどの部分か、などです。これらの調査結果をもとに、ジェスチャー モデルのプロトタイプを数多く作成し、望ましさ、使用速度、人間工学性などさまざまな側面にわたってテストを実施しました。最終的なデザインは、ユーザーがすぐに習得できるか、ユーザーが短期間で慣れるか、ユーザーがどう感じたかなどを基準に決定しました。
「戻る」ボタンは、Android の初期から引き継がれている特徴的なナビゲーション要素です。どのような操作方法が「正解か」という議論はあるものの、「戻る」ボタンのおかげで多くのユーザーが Android を、操作しやすい、習得しやすいと感じてくれたようです。実際のところ、「戻る」ボタンは非常によく利用されており、使用回数は「ホーム」ボタンより 50% も多くなっています。今回のデザインにあたっては、この「戻る」ボタンを人間工学性と信頼性に優れ直感的に行えるジェスチャーにすることを目標の 1 つとし、使用頻度がそれほど高くないナビゲーション（ドロワー、「最近」など）よりも優先することにしました。
また、最も重要な 2 つのジェスチャー（「戻る」と「ホーム」）は、下に示した到達範囲の図に基づいて、親指が最も快適に届く領域で操作できるようにデザインしました。


スマートフォン画面のヒートマップを見ると、ユーザーが片手でスマートフォンを持った状態で快適に行えるジェスチャーがわかります。
ジェスチャー モデルのプロトタイプを数多く作成したことはすでに述べましたが、これらを試してもらい、ユーザーの評価とジェスチャー操作にかかった時間を比較しました。以下は、最終的な Q モデルと他のナビゲーション モードを比較したテスト結果のグラフです。

各ナビゲーション モードの人間工学性と片手操作性についてのユーザー評価の比較（値が大きいほど良い）

各ナビゲーション モードでの「戻る」と「ホーム」の操作にかかった平均時間の比較（値が小さいほど良い）

各ナビゲーション モードでの「最近」操作にかかった平均時間の比較（値が小さいほど良い）

「ホーム」と「戻る」の操作にかかった平均時間は、Q モデルが他のどのモデルよりも短く、ボタンを使った操作よりも速いことがわかります。一方、「最近」の操作は他のモデルに比べ少し時間がかかっていますが、これは「最近」の使用頻度が「ホーム」の半分程度であるため優先度を下げたことによるものです。
定性的に見ると、ユーザーは Q モデルの片手操作性を高く評価していますが、人間工学性の面では依然としてボタンのほうが評価が高くなっています。

アプリドロワーとその他のアプリスワイプ

最終的には、操作性と使用頻度のバランスを考慮し、サイドスワイプを「戻る」ジェスチャーとして採用しました。しかし、特にジェスチャーがアプリに及ぼす影響を考えると、難しい決断を強いられる場面もありました。

たとえば、Google アプリによって異なりますが、アプリ ナビゲーション ドロワーをスワイプ操作で開いているユーザーは 3～7% 存在します（残りのユーザーは 3 本線のメニューをタップして開いています）。このドロワーのスワイプ ジェスチャーが「戻る」ジェスチャーに置き換えられたため、一部のユーザーは 3 本線のメニューを使った操作に慣れる必要があります。非常に難しい決断でしたが、「戻る」操作の使用頻度の高さを考慮し、ユーザーにとって最も便利になるように最適化したつもりです。

ユーザーの行動を変えずにすむよう、ドロワー ジェスチャーと「戻る」ジェスチャーをうまく識別できる方法がないか試行錯誤しました。しかし、どの方法を採用した場合でも、前の画面に戻ろうとしたユーザーが誤ってドロワーを引き出してしまうことがあり、「戻る」ジェスチャーの信頼性に疑念が生じてしまうと判断しました。

ドロワーに限らず、ジェスチャーは人々にとって大きな変更であり、慣れるまでに平均で 1～3 日かかりました。特に、カルーセルを左右にスワイプするのが苦手だったユーザーは、「戻る」ジェスチャーに慣れるのにも苦労したようです。

定性的な調査の結果によると、1～3 日で新しい操作に慣れたユーザーは、2 つのジェスチャーをしっかり区別し、スムーズに操作できるようになりました。3 ボタン ナビゲーションに戻すオプションも残されていますが、大部分のユーザーが戻したくないと回答しました。

他の調査では、ユーザーが新しいシステム ナビゲーションに切り替える際には、それに慣れるための明確な調整段階があることもわかりました。Q モデルの場合、最初の 1～3 日は「戻る」ジェスチャーの使用回数は少ないのですが、その後は 3 ボタン システムや Android P ナビゲーションと同じぐらいの頻度で利用されるようになりました。

デベロッパーの皆様にご対応いただきたいこと

Google としては、このようなジェスチャー ナビゲーションによって、Android でのユーザー エクスペリエンスの標準化を進めていきたいと考えています。今回採用したジェスチャー モデルはほとんどのユーザーにとって最適なものと考えていますが、これらが既存のアプリのジェスチャーと競合する場合は、デベロッパーの皆様にアプリの操作方法を調整していただく必要がございます。皆様のご負担を少しでも軽減できるよう、十分な情報提供を心掛けてまいります。

新しいジェスチャー ナビゲーションへの対応は、次に示す 3 つステップで進めることができます。

1. エッジ ツー エッジに対応します。これにより、アプリのコンテンツを画面いっぱいに表示できるようになります。
2. システム ユーザー インターフェース（ナビゲーション バーなど）との視覚的な重なりを処理します。
3. システム ジェスチャーとの競合を解消します。

これらのステップについては、Medium の記事シリーズ「エッジ ツー エッジへの対応」で詳しく解説しています。シリーズ最後の記事では、これまでに多く見られたいくつかのシナリオを紹介し、アプリをエッジ ツー エッジ対応にするための最適な方法を提案します。
新しいジェスチャー ナビゲーションについて、ご意見、ご感想などございましたらぜひお寄せください。Android Q のジェスチャー ナビゲーションはもちろん、Android の日々の改善に役立てさせていただきます。

Posted by Yuichi Araki - Developer Relations Team

Google Cloud は、インターネットサービス業界で活躍するインフラエンジニア、サーバーアプリケーションエンジニア、テクニカルリーダーの皆様に向けて、"Google Cloud INSIDE Digital" を開催します。

業界をリードする方々や、深い専門知識をもつ Google 社員をスピーカーに迎え、注目インターネットサービスの開発の裏側や、Google Cloud Platform（GCP） を中心としたテクノロジーアップデートをお届けします。この Google Cloud INSIDE Digital をきっかけに、新しいサービスやプロダクトが生まれるような会へ、参加者の皆様と共に育てて行きたいと考えています。

今回のテーマは「ここでしか聞けない AI 、機械学習サービスの活用例」。様々なアプリケーション、サービスに AI が搭載されると言われる時代において、他企業の取り組みが気になる方も多いのではないでしょうか。今回は、GCP の AI、機械学習サービスの最新動向と、先進的な企業における AI 、機械学習の活用例についてご紹介します。

この記事は Eric Steinlauf による Google Developers Blog の記事 "The Speed Benefit of AMP Prerendering" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
 投稿者: Google ソフトウェア エンジニア、Eric Steinlauf


本日は、プリレンダリングが読み込み時間に与えるメリットについて、最新の分析を紹介したいと思います。AMP は、ページ読み込み時間を短縮するために設計されました。また、Google 検索は、ページ読み込み時間を短縮する特に重要な方法の 1 つとして、リンクがクリックされる前にプライバシーを保護しつつ AMP ドキュメントのプリレンダリングを行っています。

First Viewport Ready

AMP フレームワークは、すべてのページ コンテンツのレイアウトと、すべてのリソースの読み込みステータスを把握できるように設計されています。そのため、すべての「ファースト ビュー」コンテンツが読み込まれたタイミングがわかります。また、ドキュメントがプリレンダリングされたり、表示されたりしたタイミングもわかります。つまり、AMP フレームワークは、クリックしてからファースト ビューのコンテンツが表示されるまでの時間を計算できます。AMP は、First Viewport Ready（FVR、最初のビューポートの準備完了）というカスタム指標を使ってページ読み込みのスピードを測定します。この指標の定義は、「ユーザーがクリックしてから、ファースト ビューの広告以外のリソースが load イベントを発行するまでの時間（プリレンダリングも考慮されます）」です。AMP ドキュメント全体がプリレンダリングされていれば、この指標は 0 になります。クリックされた時点でドキュメントのプリレンダリングが完了していない場合や、まったくプリレンダリングが行われていない場合、この指標は 0 よりも大きくなります。
Google 検索には、プリレンダリングされる AMP ドキュメントも、プリレンダリングされない AMP ドキュメントもあります。そのため、プリレンダリングが FVR に与える影響を確認することができます。下のグラフは、プリレンダリングが行われる場合と行われない場合の FVR をパーセンタイルで示しています。AMP フレームワークがドキュメントの表示前にプリレンダリングを正常に完了した場合、FVR は 0 になります。

First Contentful Paint

First Contentful Paint（FCP、最初のコンテンツの描画）は、ブラウザが測定するページ読み込みスピード指標です。この指標は、AMP ドキュメントだけでなく、すべてのドキュメントで利用できます。FCP は、DOM のコンテンツの一部が初めてレンダリングされたタイミングを指します。FCP が高いということは、明らかにページが遅いことを意味します。ただし、FCP が低くても、必ずしもページの読み込みが早いとは限りません。最初に表示されるコンテンツが重要とは限らないからです。これは便利な指標ですが、AMP はどのコンテンツが表示されているかを把握しているので、コンテンツの表示タイミングを理解したい場合、FVR を使う方がよいでしょう。
FCP はプリレンダリングを考慮しないので、AMP はプリレンダリングを踏まえた派生指標として、クリック前の時間を引いた Prerender-adjusted First Contentful Paint（PFCP、プリレンダリング調整済みの最初のコンテンツの描画）を計算します。プリレンダリングが行われない場合、PFCP = FCP となります。FCP もプリレンダリングによって低下しますが、違いは FVR ほど劇的ではありません。

プリレンダリングが行われる場合の PFCP の中央値は、プリレンダリングが行われる場合の FVR の中央値よりも高くなっています。これは驚きかもしれません。これが起こるのは、クリック後にブラウザが画面にコンテンツを描画しなければならないためです。PFCP にはこの時間が含まれますが、FVR には含まれません。

まとめ

AMP ドキュメントのプリレンダリングを行うと、ページの読み込み時間を大幅に短縮できます。プリレンダリングを行うと、ユーザーが早く見たいコンテンツを早く表示できます。ページ読み込み時間はさまざまな方法で測定できますが、この点は測定方法によらず一貫しています。このスピードアップには、プライバシーを保護したプリレンダリングが必要です。現在のところ、これを行えるのは AMP だけです。今後は、Signed Exchanges などの新しいウェブ プラットフォーム機能によって、非 AMP ドキュメントでもプライバシーを保護した即時読み込みが実現できるようになるでしょう。

Reviewed by Chiko Shimizu - Developer Relations Team

この記事は Chris Banes (Developer Programs Engineer) による Medium Blog の記事 "Gesture Navigation: Handling visual overlaps" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。



今回は、ジェスチャー ナビゲーションに関する連載の第 2 回です。他の回を見逃した方は、こちらからご覧になれます。

ジェスチャー ナビゲーション: エッジ ツー エッジへの対応

本連載の第 1 回では、アプリを「エッジ ツー エッジ」に対応させる方法をご紹介しました。ただしこの方法では、アプリのビューの一部がシステムバーの背後に隠れてしまい、ユーザーから見えなくなる場合があります。そこでこの投稿では、インセットを使用して、こうしたビューをシステムバーから離す方法を説明します。
この投稿では、「システム UI」と呼ばれる要素についても取り上げます。これは、システムが提供する画面上の UI の総称で、たとえばナビゲーション バーやステータスバー、通知パネルなどが該当します。

インセット

「インセット」と聞いて思わず尻込みした Android デベロッパーは、おそらく Android Lollipop の頃、ステータスバーの背後に描写しようとした経験があるのではないでしょうか。たとえば、このトピックに関するだいぶ前の StackOverflow の質問は、驚くほど多くの閲覧数を集めています 😲。
インセットは、画面のどの部分がシステム UI（ナビゲーション バーやステータスバーなど）と交差するかを表します。交差とは、単にコンテンツの上に表示されることを意味する場合もありますが、システム ジェスチャーに関係することもあります。インセットを使用することで、たとえば特定のビューを端から離すなどのようにして、重なり合いを避けることができます。
Android では、インセットは WindowInsets クラス（AndroidX では WindowInsetsCompat）で表されます。Android Q には、アプリのレイアウト時に考慮すべき 5 種類のインセットがあります。どのインセットを使用するかは状況に応じて異なります。それぞれのタイプについて詳しく見ていきましょう。

システム ウィンドウ インセット

メソッド: getSystemWindowInsets()
システム ウィンドウ インセットは、現在最もよく使用されているインセットです。API 1 以降、さまざまな形式で存在するこのインセットは、システム UI が（Z 軸上で）アプリの上に表示されるときは常にビュー階層にディスパッチされます。代表的な例はステータスバーとナビゲーション バーですが、画面キーボード（IME）もこれに該当します。
アプリでシステム ウィンドウ インセットを使用する例を見てみましょう。ここで設定している FloatingActionButton（FAB）は、画面の下隅に 16 dp の余白（ガイドラインの仕様どおり）をとって配置されます。（ソースはこちら）

エッジ ツー エッジ対応に変換する前の Google I/O アプリの FAB

前回の投稿のステップ 1 と 2 を完了すると、ビューは下図のようにナビゲーション バー背後にまで広がって配置されるようになります。

全画面配置をリクエストした後の Google I/O アプリの FAB

このように、カンファレンスのスケジュール リストがナビゲーション バーの背後にまで拡張された状態は、ユーザーの没入感を高めるのに効果的です ✔️。リストとグリッドの処理方法については、後日別の投稿で説明します。

ところで、この例を改めて見てみると、FAB の一部が隠れてしまっているため、ユーザーがビューを操作（タップ）できない可能性があります。この種の視覚的な重なりは解消しなければなりません 🚫。上の図のように、デバイスがボタン ナビゲーション モードに設定されているときはバーが高くなるため、対応が必要なことはより明らかです。ジェスチャー ナビゲーション モードで動的な色調整が行われる場合は特に問題ありませんが、半透明スクリムに切り替わる可能性が常にあることを覚えておく必要があります。半透明スクリムになると、操作できなくなる場合があるためです。

この機会にすべてのナビゲーション モードでアプリをテストしておくことをおすすめします。

では、視覚的な重なりはどのように処理すればよいのでしょう。そこで出番となるのがシステム ウィンドウ インセットです。このインセットはビュー階層上のどの位置にシステムバーが配置されるかを表すので、その値を使用して、システムバーからビューを遠ざけることができます。

上の例では、FAB が下端と右端の近くに配置されています。そこで、systemWindowInsets.bottom および systemWindowInsets.right の値を大きくしてビューの下端と右端の余白を広くすることで、ナビゲーション バーから離すことができます。
この設定を適用すると、次のようになります。

これを正確に実装する方法については、この投稿の後半で詳しく説明します。

つまり、システム ウィンドウ インセットは、クリック可能なビューがシステムバーと重なって隠れてしまわないよう、そのビューを移動またはパディングする場合に活用できます。

タップ可能要素インセット

メソッド: getTappableElementInsets()
次に紹介するのは、Android Q で新たに追加されたタップ可能要素インセットです。前述のシステム ウィンドウ インセットとよく似ていますが、こちらはナビゲーション バーの表示の変化に対応します。
実は、「タップ可能要素インセット」は無視して、代わりに「システム ウィンドウ インセット」を使用する方が便利です。次の「ジェスチャー インセット」にスキップしてかまいませんが、詳しく知りたい方は引き続きお読みください。🕵️

タップ可能要素インセットでは、クリック可能（タップ可能）なビューに適用される最小限のインセットを定義します。ここでの最小限とは、このインセットの値ではシステムバーと重なる部分が引き続き存在する場合があることを意味します。この点で、システムバーとの重なりを常に回避するシステム ウィンドウ インセットとは異なります。
FloatingActionButton の例を使って、2 つのインセットの値の違いを確認しましょう。

ピンク = ナビゲーション バーの領域。緑 = 下の余白に各インセットを指定した FAB の領域。

なお、ナビゲーション バーのサイズは変化するので、上の表の値はハードコードせず、インセットを使用してください。

「タップ可能要素インセット」と「システム ウィンドウ インセット」は、デバイスがボタン ナビゲーションに設定されているときは同様に機能することがわかります。違いが現れるのは、デバイスがジェスチャー ナビゲーションに設定され、かつ色調整が有効になっているときです。この状態ではナビゲーション バーは透明です。つまり、タップ可能なビューは理論上ナビゲーション バー内に配置可能であることから、下端の値が 0 になっています。

ただし、インセットではビューの配置場所を考慮しないため、タップ可能要素インセットを使用すると理論的に次のような結果になる可能性もあります。



これでは、ビューがナビゲーション バーに近過ぎて、ユーザーにとって紛らわしくなり適切とは言えません。

実際のところ、タップ可能要素インセットを使用できる状況でも、代わりに「システム ウィンドウ インセット」を使用した方がよい場合がほとんどです。

ジェスチャー インセット

メソッド: getSystemGestureInsets() および getMandatorySystemGestureInsets()
次に紹介するシステム ジェスチャー インセットも、Android Q で新たにプラットフォームに追加されたインセットです。ご存じのとおり、Android Q では新しいジェスチャー ナビゲーション モードが導入され、ユーザーは次の 2 種類のタッチ ジェスチャーでデバイスを操作できるようになりました。

1. 画面の右端または左端から横にスワイプすると、「戻る」機能がトリガーされます。
2. 画面の下端から上にスワイプすると、ホーム画面または最近使ったアプリを表示できます。

Android Q のジェスチャー ナビゲーションのデモ

システム ジェスチャー インセットは、システム ジェスチャーがアプリのタッチ操作より優先されるウィンドウの領域を表します。ところで、先ほど紹介した方法は 2 つありました。これは、システム ジェスチャー インセットが実際に 2 種類あるためです。すなわち、すべてのジェスチャー領域を含むインセットと、そのサブセットである必須システム ジェスチャー インセットです。

システム ジェスチャー インセット

1 番目のシステム ジェスチャー インセットについて説明します。このインセットには、システム ジェスチャーがアプリのタッチ操作より優先される画面上の領域全体が含まれます。Android Q では下の図のように、下のインセット（ホーム表示ジェスチャー用）と左右のインセット（戻るジェスチャー用）が設定された状態になります。

          0
   +--------------+
   |              |
   |  システム    |
40 | ジェスチャー |  40
   | インセット   |
   |              |
   +--------------+

          60

では、デベロッパーがシステム ジェスチャー インセットを使用するのはどのような場合でしょうか。このインセットはシステム ジェスチャーが優先される場所を表します。つまり、このインセットを使えば、スワイプ操作が必要なビューの位置をあらかじめ決めておくことができます。
システム ジェスチャー インセットの使用が適している例としては、下部のシート、スワイプ操作を使用するゲーム、カルーセル（ViewPager）などが挙げられます。一般に、このインセットは、スワイプ可能なビューを端から離れた位置に移動またはパディングする場合に使用します。

必須システム ジェスチャー インセット

必須システム ジェスチャー インセットはシステム ジェスチャー インセットのサブセットで、アプリによって除外できない（つまり「必須」の）領域のみが含まれます。詳しくは次回のブログ投稿（ジェスチャーの競合への対処方法の回）で説明しますが、ここではまず、アプリで画面の特定の部分からシステム ジェスチャーを排除できるということを覚えておいてください。

必須システム ジェスチャー インセットは、システム ジェスチャーが必須であり常に優先される画面の領域を表します。現在 Android Q で必須の領域は、画面下部のホーム表示用ジェスチャー領域のみです。ユーザーがいつでもアプリを終了できるようにするため、必須の領域となっています。
Android Q デバイスのジェスチャー インセットの一例を挙げるとすると、次の図のようになります。

          0                              0
   +--------------+               +--------------+
   |              |               |    必須      |
   |  システム    |               |  システム    |
40 | ジェスチャー | 40          0 | ジェスチャー | 0
   | インセット   |               |  インセット  |
   |              |               |              |
   +--------------+               +--------------+
          60                             60

システム ジェスチャー インセットでは左右と下部にインセットが設定されていますが、必須システム ジェスチャー インセットの方は、ホーム表示ジェスチャー用の下部のインセットしかありません。ジェスチャー領域の除外については、次回のブログ投稿で詳しく取り上げます。

固定インセット

メソッド: getStableInsets()
最後にご紹介するのは、固定インセットです。ジェスチャー ナビゲーションと特に関連はありませんが、Android で利用できるインセットの一種ですので簡単に説明しておきます。

固定インセットはシステム ウィンドウ インセットと関係がありますが、システム UI が実際に表示される場所ではなく、表示される「可能性がある」場所を表します。固定インセットは主に、システム UI の表示のオンとオフを切り替え可能なモード（たとえば、ゲーム、フォトビューア、動画プレーヤーなどでよく使われるリーンバック モードや没入モードなど）に設定されているときに使用されます。

インセットの処理

ここまでで、各インセットについて理解を深めていただけたことと思います。次は、これらのインセットを実際にアプリで使用する方法を見ていきましょう。

WindowInsets にアクセスする際は、主に setOnApplyWindowInsetsListener メソッドを使用します。次に示すのは、ビューがナビゲーション バーの背後に表示されないようパディングを追加する例です。（ソースはこちら）

ここでは、ビューの下部のパディングを、システム ウィンドウ インセットの下部の値に設定しています（具体的な数値は指定していません）。

注: ViewGroup でこれを行う場合は、必要に応じて android:clipToPadding="false" に設定してください。デフォルトでは、すべてのビューでパディング内の描画がクリップされるためです。この属性は RecyclerView でよく使用されます。詳しくは、今後別の投稿で取り上げたいと思います。

なお、リスナー関数には冪等性が必要です。リスナーが同じインセットで複数回呼び出される場合、結果は毎回同じでなければなりません。次に示すのは、冪等性がない関数の例です。（ソースはこちら）

🙅 リスナーが呼び出されるたびにビューのパディングを追加（+=）してはいけません。ウィンドウ インセットのパスはいつでも、またビュー階層の存続中には複数回、発生する可能性があります。

Jetpack

インセットに関する注意点として、最小 SDK バージョンにかかわらず、Jetpack の WindowInsetsCompat を常に使用することをおすすめします。WindowInsets API は長年にわたって改良を重ね、拡張されています。この compat バージョンを使うことで、すべての API レベルで一貫した API と動作を実現できます。

Android Q で利用可能な新しい種類のインセットに対し、この compat メソッドは、すべての API レベルのホストデバイスに適した値を提供します。AndroidX の新しい API を使用するには、androidx.core:core:1.2.0-xxx（現在のアルファ版）以降にアップデートしてください。最新バージョンについてはこちらで確認できます。

さらに先へ

上記でご紹介したのは WindowInsets[Compat] API を使用する最も簡単な方法ですが、コードが非常に冗長で反復的になる可能性もあります。今年前半に私が投稿したブログ記事では、バインディング アダプターを使用して、ウィンドウ インセットの処理を大幅に簡素化する方法をいくつかご紹介しました。詳しくはこちらをご覧ください。

WindowInsets — リスナーからレイアウトまで

この連載の次回の投稿では、アプリのジェスチャーがシステム ジェスチャーと競合した場合の対処方法について見ていきます。
Posted by Yuichi Araki - Developer Relations Team

多くの企業が、ユーザーが探したい場所を正確にすばやく見つけるのに役立つ Google Maps Platform のオートコンプリート（入力補完）機能を活用しています。一方で、似たような検索結果が複数得られた場合に、その精度をさらに高めるために何かできるのではないかという要望も耳にします。今回は、ユーザーが探している場所をより簡単に選択し、迅速な意思決定を行えるよう、そして効率の良い方法で日々の用事を済ませられるように改良した新しいオートコンプリート機能をご紹介します。

追加のプレイスタイプ

ユーザーが関心を持っている場所を似通ったものの中から明確に区別できるように、既存のオートコンプリートを拡張して、該当するすべてのプレイスタイプを返すようにしました。新しいオートコンプリート機能は、レストラン、医療サービス、礼拝所、金融機関など、追加のプレイスタイプを返すことができます。これらの追加のプレイスタイプを使用することで、たとえば、公園、ショップ、介護施設、その他のビジネス用にそれぞれカスタムアイコンを定義して、検索結果を視覚的にわかりやすくできます（注:次の図は、東京で、タイプが”施設”で、”na”から始まる場所の検索を行った時の表示例です。左側（Example 1）が以前の表示で、結果一覧のアイコンはすべて同じ表示です。右側（Example 1a）が追加のプレイスタイプを利用した場合で、タイプごとに異なるアイコンを表示することができます）。

より多くのコントロールをカスタマイズ

追加のプレイスタイプを使用することで、ユーザーにとって最も関連性の高い結果のみを提示可能となります。実際にこれを実現するためには、オートコンプリートの戻り値で返される追加のプレースタイプを使用することで、アプリまたはサイトの要件に合致した、適切な条件で結果を抽出・結合できるでしょう。

たとえば、旅行サイトの場合、検索結果のホテルの周辺にあるレストランやショッピングの場所の結果のみを返すように選択できます。不動産サイトの場合、物件の周辺にある学校、公園、食料品店のみを表示するように選択できます。

直線距離

似通った場所を区別できるようにして、すばやく迷わずに適切な場所を選択したいという要望も耳にします。たとえば、ユーザーがサンフランシスコのダウンタウンを訪れていてコーヒーショップを探しているとします。検索の結果、同じ名前のカフェが 5 か所、検索エリア内にあるということは起こりえることです。そのエリアについて詳しくなければ、ユーザーが名前と住所だけでカフェを選ぶのは難しいでしょう。

そこで、より良いユーザーエクスペリエンスを提供できるよう、ユーザーが選択した場所から検索結果までの直線距離を提供する新しいオートコンプリートフィールドを設けました。直線距離を提供することで、ユーザーは同じ名前を持つ複数の場所をより適切に区別し、探している場所を正確にすばやく見つけることができます。たとえば、ユーザーがサイトで「Joe's Coffee Shop」と入力して複数の「Joe's Coffee Shop」カフェがリストアップされたときに、それぞれのカフェがユーザーの現在地からどれだけ離れているかを示すことができるのです。こうして、検索結果にある各カフェの違いをより簡単に認識し、適切なものを選択できます（注:次の図は、サンフランシスコで、”osh”から始まる施設を検索する例です。 左側（Example 2）が以前の表示です。直線距離の表示は無く、同じ名前を有する複数の場所を区別しにくいことがわかります。右側（Example 2a）は直線距離を追加した表示であり、左側よりも場所の区別がしやすい表示となっています。）

現在、この直線距離フィールドは Places API でウェブサービスとして利用できます。 Android、iOS、JavaScript の Places SDK への追加作業は現在開発を進めています。


ユーザーにとって有益であり、旅行、不動産、ライドシェアリング、配送など、多くの業界で優れたエクスペリエンスを構築できるよう、今回新たに開発したオートコンプリート機能についてご紹介致しました。ぜひ試していただき、 Issue Tracker に課題やフィードバックなどご報告ください。また、@GMapsPlatform にツイートして皆さんの開発の様子をお聞かせください。我々は、開発者の皆さんが Google Maps Platform で素晴らしいものを開発されるお手伝いをするために日々努力しています。今回ご紹介した新機能を使って何を構築されるのか、楽しみにしています。



Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やご意見はページ右上の「お問い合わせ」より承っています。


Posted by 丸山 智康 (Tomoyasu Maruyama) - Google Maps テクニカルアカウントマネージャ

Google マップのエンジニアリングチームをリードする Travis McPhail は 今年の Google I/O において、Google Maps Platform 上で高いパフォーマンスと拡張性を持ったアプリを構築するため　Maps JavaScript API 上での deck.gl のサポートを発表しました。それ以降、世界中のデベロッパーのみなさんに、deck.gl がウェブ地図にもたらす可能性についてお伝えしてきました。みなさんからの熱狂的な反応をうれしく思っています。deck.gl とは何か、まったく初耳という方へ、この記事では、deck.gl の概要をお話します。

deck.gl とは？

vis.gl のフレームワーク スイートの一部である deck.gl は、各種の高性能で美しいデータ視覚化をウェブ環境にもたらすことができるオープンソースのフレームワークです。このフレームワークを使ってどのようなことができるのか、deck.gl 関連文書から抜粋します。

• 大量のデータセットの取扱いと効率の良い更新
• インタラクティブなイベントハンドリング（大量のデータセットから1点を抽出するピッキングなど）
• 地図の投影法、背景地図との重畳
• 実証済みで十分にテストされた各種サンプルデータ
• 新たなレイヤーの作成や既存レイヤーのカスタマイズが容易

なぜ deck.gl なのか？

データ視覚化において多くのウェブ開発者が直面する課題の一つが、極めて大量のデータセットを、効率良く取り扱わなければならないということです。開発者からは、もはや何百ではなく、数万、数十万、数百万点ものデータポイントの展開を図らなければならないという声も上がっています。

シングルスレッドのイベントループ モデルである JavaScript は、大量データの取り扱いや 3D 画像の描画といった、重いコンピュータ処理にはあまり適していません。この弱点を克服するため、deck.gl は非同期でユーザーのコンピュータの GPU にアクセスを可能にする WebGL ライブラリを使います。すなわち、大量のデータを処理する負担を、ブラウザから、この種の作業により適しているハードウェア内部に移行させるわけです。その結果、数百万ものデータポイントを迅速に処理し、とても美しいデータ可視化を実現できるのです。

deck.gl はどのように機能するのでしょうか？

deck.gl は、Maps JavaScript API が提供する OverlayView を利用し、地図上にレイヤーとして重ねて、データを視覚化します。ユーザーが地図を左右上下に動かしたりズームさせる時でも、deck.gl の視覚化レイヤーは、ユーザーが日頃使い慣れているグーグルマップでのユーザー体験と同じような、背景地図と完全に同調した動きが可能です。



deck.gl のレイヤーを使ったアプローチによって、複合的効果を得るために、地図の上に複数の視覚化した情報のレイヤーを追加することも可能です。それを実行した例が以下の図です。それぞれ独立した 2 つのデータセットを散布図レイヤーとして重ね合わせることで、一枚の主題図を作成しました。

この記事は Chromium Blog の記事 "Chrome 78 Beta: a new Houdini API, native file system access and more" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome Beta チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2019 年 10 月 7 日の時点で Chrome 78 はベータ版です。

CSS のプロパティと値

CSS Properties and Values API Level 1 により、CSS 変数はさらに力を発揮するようになります。変数を完全なカスタム プロパティとして登録できるので、特定の型であることを常に保証できます。また、デフォルト値を設定したり、アニメーションさせたりすることも可能です。

例として次のイメージをご覧ください。



ここでは、CSS のカスタム プロパティを使って色を変化させています。この変化は新しい API を使わなければ実現できないだけでなく、型安全でもあります。詳細およびこのイメージを生成するために使ったコードについては、Houdini の新しい API を使ったスマートなカスタム プロパティをご覧ください。

ネイティブ ファイル システム

オリジン トライアル中の新しい Native File System API を使うと、ユーザーのローカル端末にあるファイルを操作できます。これにより、IDE、写真や動画のエディタ、テキスト エディタなどの強力なウェブアプリを構築できるようになります。ユーザーがアクセス権を与えると、ウェブアプリはこの API を使ってユーザーの端末にあるファイルやフォルダを直接読み取ったり保存したりできるようになります。この処理は、すべてプラットフォーム独自のファイルを開くまたはファイルを保存するダイアログ ボックスを通して行われます。下のイメージは、Mac でファイルを開くダイアログ ボックスを使っているウェブページを示しています。



詳細を知りたい方、サンプルコードやテキスト エディターのデモアプリを見たい方は、Native File System API: 簡単にローカル ファイルにアクセスするをご覧ください。

登録に関する情報や、本リリースの他のオリジン トライアルのリストについては、オリジン トライアルのセクションをご覧ください。

オリジン トライアル

このバージョンの Chrome には、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。上記の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録したい方は、オリジン トライアル ダッシュボードをご覧ください。オリジン トライアル自体の詳細を知りたい方は、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。

SMS Receiver API

ウェブサイトでは、SMS メッセージでワンタイム パスワードを送り、それをフォームに手入力（またはコピーして貼り付け）してもらうことで電話番号を検証することがあります。ネイティブ プラットフォームはプログラムから SMS メッセージにアクセスする API を提供しているので、ユーザーはフォームを手で操作する必要はありません。
SMS Receiver API を使うと、ユーザーの電話に配信された SMS メッセージで明示的にオリジンに宛てられたものに対し、（特別なフォーマット規約を通して）ウェブサイトからのアクセスが可能になります。

今回のリリースに追加されたその他の機能

INPUT/TEXTAREA プレースホルダのデフォルト スタイルに不透明度を適用

::placeholder のデフォルト スタイルを #757575 から rgba(0, 0, 0, 0.54) に変更します。

ページのアンロード時にポップアップを許可しない

window.open() メソッドを使ってアンロード時に新しいページを開くことができなくなります。ポップアップ ブロッカーは既にこれを禁止していますが、ポップアップ ブロッカーが有効になっているかどうかにかかわらず、禁止されるようになります。現在のところ、企業は AllowPopupsDuringPageUnload ポリシーフラグを使ってアンロード中のポップアップを許可することができます。このフラグは、Chrome 82 で削除される予定です。

バイト単位の更新チェックをすべての Service Worker の importScripts() リソースに拡大

importScripts() でインポートされる Service Worker スクリプトでバイト単位のチェックが有効になります。現在、Service Worker が更新されるのは、Service Worker のメイン スクリプトが変更された場合のみです。この動作は最新の仕様に準拠していません。また、デベロッパーは、インポートしたスクリプトの URL にハッシュを追加するなどの回避策を使う必要があります。

Web Socket の高速化

PC で Chrome 78 の WebSocket オブジェクトを使う場合、ArrayBuffer オブジェクトのダウンロード速度が向上します。私たちのテストでは、以下のように改善されています。結果はネットワークのスピードやハードウェアに依存するので、環境によって異なる場合があります。

• Linux: 7.5 倍高速
• Windows: 4.1 倍高速
• Mac: 7.8 倍高速

マスク可能アイコン

Chrome 78 では、マスク可能アイコンのサポートが追加されます。ウェブ デベロッパーは、マスキングされる前のアイコンを指定して icon オブジェクトに "purpose": "maskable" を追加できるようになります。マスク可能アイコンには、108dp のアイコンを使うことを推奨します。詳細については、CSS Tricks の マスク可能アイコン: PWA で Android のアダプティブ アイコンを使うをご覧ください。

オートフィルされる支払い手段に対する hasEnrolledInstrument() の制限を強化

有効期限内のカードと請求先住所を要求することにより、取引の際の認証を改善します。これにより、オートフィル データの質が向上し、PaymentRequest.hasEnrolledInstrument() が true を返す確率が高くなります。また、オートフィル データを使って取引を行う際のユーザー エクスペリエンスが改善されます。

PaymentResponse.prototype.retry()

支払いの応答データに問題がある場合（配送先住所が私書箱である場合など）、PaymentResponse インスタンスの retry() メソッドを使ってユーザーに支払いのやり直しを求めることができるようになります。

不透明度のパーセント表記

不透明度関係のプロパティで値のパーセント表記が可能になります。具体的には、opacity、stop-opacity、fill-opacity、stroke-opacity、shape-image-threshold が対象になります。たとえば、opacity: 50% は opacity: 0.5 と同じ意味になります。これにより、整合性と仕様への準拠性が向上します。rgba() 関数は、rgba(0, 255, 0, 50%) などの alpha 値のパーセント表記に既に対応しています。

PaymentRequest.onshippingaddresschange イベントでの住所の間引き

ShippingAddressChange イベントから販売者のウェブサイトに共有する配送先住所の詳しい情報を間引きます。PaymentRequest.onshippingaddresschange は送料や税金などを踏まえて支払金額を調整できるよう、ユーザーが選択した配送先住所を販売者に渡します。この時点で、ユーザーは取引を完全に確定させてはいないため、販売者に返す情報はできる限り少なくすべきです。これにより、配送先住所から recipient、organization、addressLine、phoneNumber が削除されます。通常、これらの情報は送料や税金の計算には不要です。

シーク

seekto アクションにメディア セッション アクション ハンドラが追加されます。アクション ハンドラは、一時停止や再生などの共通メディア関数に明示的に結びつけられているイベントです。seekto アクション ハンドラは、再生時間を特定の時間に移動させる場合に呼び出されます。

User Timing L3

既存の User Timing API を拡張し、2 つの新しいユースケースに対応します。

• デベロッパーは、performance.measure() および performance.mark() にカスタム タイムスタンプを渡せるようになります。これにより、任意のタイムスタンプ間の計測を行うことができます。
• デベロッパーは、performance.mark() および performance.measure() で任意のメタデータを報告できるようになります。これにより、標準化された API で分析用の高度なデータを提供できます。

サポートの終了と機能の削除

ページを離れる際の同期 XHR を許可しない

ユーザーがページを移動するまたは閉じることによってページを離れる際に、同期 XHR が許可されなくなります。これは、以下のイベントに適用されます。

• beforeunload
• unload
• pagehide
• visibilitychange

ページがアンロードされるタイミングで確実にサーバーにデータを送信するには、sendBeacon() または Fetch keep-alive を使うことを推奨します。

現在のところ、企業ユーザーは AllowSyncXHRInPageDismissal ポリシーフラグを使ってページ アンロード時の同期 XHR リクエストを許可できます。デベロッパーは、オリジン トライアル フラグ allow-sync-xhr-in-page-dismissal を使って同じことができます。これは暫定的な「オプトアウト」方法です。このフラグは Chrome 82 で削除される予定です。

XSS Auditor

XSS Auditor は Chrome から削除されました。XSS Auditor を使うと、サイト間で情報がリークされる可能性があります。また、Auditor をバイパスする仕組みもよく知られています。

Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Google Developers Blog の記事 "From Code to Community: Why developers call DevFest home" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


1. DevFest のことはどこで知り、どうして参加しようと思ったのですか？

2018 年でコインブラに住んで 3 年目になっていましたが、ソフトウェア デベロッパーとして働いている職場以外の友人はいませんでした。私の熱意を理解してくれる人に会いたいと思っていたので、今までとは違うことをしようと決意しました。そして、どうすれば知見を持った開発者とつながることができるのかと考え、ソーシャル メディアを使い始めました。やがて、フィードに DevFest が表示されました。そのとき突然、このすばらしいイベントがコインブラで行われ、業界のリーダーたちが集まり、セッションが行われ、とてもクリエイティブな体験できることを知りました。コミュニティへの参加をこれほど楽しみに思ったことはありません。すぐにチケットを手に入れました。

2. 初めての DevFest はどんな場所でしたか？

いったいどうしてこんなに変わってしまったのでしょうか。DevFest は、私の個性を進化させてくれたのだと実感しています。今は、コミュニティの一部でありたいと思っています。これまでの人生にはなかった感覚です。

「かなり内気で人付き合いが苦手な性格だった私が『ここは自分の居場所だ、わが家なんだ』と感じたので、驚きました」

3. DevFest 2018 の中で、今年も体験したいと思っていることは何ですか？
さまざまなブースです。DevFest Coimbra には、いろいろな会社の人と話せるブースがあります。家のすぐそばに成長できるチャンスがこんなにもあることがわかり、興奮します。私の場合、ポルトガルが急速に拡大していること、そして有能な人と話すために非常に多くの会社が DevFest にやってくるのを見るのが楽しいですね。このような関係を作っておけば、自分にふさわしいチャンスを見つけようとするとき、違った結果になるはずです。


4. まもなく DevFest 2019 が開催されます。一番楽しみにしていることは何ですか？
新しい参加者を刺激することです。最近運営スタッフになったので、新しい参加者の方にも、私が初めて DevFest の会場に入ったときのように感じてもらえることを楽しみにしています。同僚の GDG リードと一緒に、みんなで心を込めて参加者をお迎えするための活動を行う中で、そのように感じています。


5. DevFest 2019 に参加する皆さんへのアドバイスをお願いします。
ぜひ声をかけてください。それだけでどんなことが起こるでしょうか。きっと驚くと思います。DevFest は、ただの講演やワークショップではありません。大事なのは人なのです。このコミュニティでは、外向的な人も内向的な人も理解され、どちらも温かく迎えてもらえます。つまり、どんな人でも、どんなコードを書いていても、皆さんの居場所はここにあります。

「DevFest は、ただの講演やワークショップではありません。大事なのは人と人の繋がりなのです」

お近くの DevFest イベントを探しましょう。コミュニティに参加し、他のデベロッパーからクラウド、Android、Flutter、機械学習などについて学びたい方は、devfest.withgoogle.com をご覧ください。


#DevFest #Community


Reviewed by Takuo Suzuki - Developer Relations Team

この記事は Chris Banes (Developer Programs Engineer) による Medium Blog の記事 "Gesture Navigation: Going edge-to-edge" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。



Android Q では新しいシステム ナビゲーション モードが追加され、前の画面に戻る、ホーム画面に移動する、デバイスでアシスタントを起動する、などの操作をジェスチャーで行えるようになりました。

Android Q での新しいジェスチャーのデモ

システム ナビゲーション用ジェスチャー モデルに移行することにより、アプリが利用できる画面の領域が広がります。つまり、ユーザーの没入感がさらに高まるようなアプリを提供できるようになるとも言えます。
ただし、ユーザーは今後もほとんどのデバイスで、自分が使いたいナビゲーション モードを選択できます。3 つのボタン（戻る、ホーム、最近）による従来のナビゲーション モードがなくなることは当面ありません。このモードは、Android Q 以降を搭載するデバイスでも必須となります。
ジェスチャー ナビゲーションに関して行われた調査やジェスチャーを決定する過程については、Android システム UI 担当プロダクト マネージャーが投稿した以下のブログ記事に詳しく書かれています。

ジェスチャー ナビゲーションの裏話

今回の投稿は、デベロッパーがアプリでジェスチャー ナビゲーションに対応する方法を中心に紹介する短い連載の第 1 回です。この連載では以下のトピックについて取り上げます。
1.アプリのコンテンツを画面いっぱいに表示できるようになる、エッジ ツー エッジへの対応
2.システム UI と視覚的に重なった場合の対処方法
3.アプリのジェスチャーがシステム ジェスチャーと競合した場合の対処方法
4.よくあるシナリオと、それぞれの対応方法
それでは早速、アプリが「エッジ ツー エッジ」に対応する方法をご紹介します。

エッジ ツー エッジ

ここで使っている「エッジ ツー エッジ」という表現には、アプリのウィンドウを全画面に拡張することでユーザーの没入感を高められる、という意味が込められています。アプリがデフォルトで配置されるのは、上部はステータスバーより下、下部はナビゲーション バーより上の領域です（2 つのバーを合わせて「システムバー」と呼びます）。
エッジ ツー エッジに対応することで、アプリはシステムバーの背後に配置されるようになります。これは、アプリのコンテンツを引き立てて、さらに没入感の高いユーザー エクスペリエンスを提供できるようにするためです。
実際に「エッジ ツー エッジ」のアプリにするには、次の 2 点を考慮する必要があります。

ナビゲーション バー背後の描画

ジェスチャー ナビゲーションに対応するにあたり最初に考慮すべき最重要事項は、ナビゲーション バーの背後に描画することです。ナビゲーション バーは以前より小さく、そして目立たなくなっています。そのため、Android Q 以降で動作するアプリについては、より魅力的な最新の UX を実現できるよう、ナビゲーション バーの背後にもコンテンツを描画することを強くおすすめします。
Android Pie 以前を搭載したデバイスでアプリを実行する場合は、ナビゲーション バー背後の描画は必ずしも必要ではなく、どの方法が合理的かを判断したうえで対応していただいてかまいません。とは言え、必要なほぼすべての API は API 21 にさかのぼって機能する（つまり AndroidX が違いを処理する）ので、Android Pie 以前のデバイスに対応するために必要な追加作業の量は最小限で済みます。Pie 以前のデバイスでも、ナビゲーション バーの背後に描画すればユーザーの没入感を高められますが、必要な作業やテストの量を最小限に抑えるため、デベロッパーの裁量に委ねることにしています。

ステータスバー背後の描画

次は、画面上部にあるステータスバーについてです。アプリのコンテンツやレイアウトとの兼ね合いで、ステータスバーの背後に描画するほうが有意義である場合はそのようにすることをおすすめします。たとえば、幅いっぱいに表示される画像は、ステータスバーの背後に描画するのが適したレイアウトと言えます。この場合、デベロッパーは AppBarLayout などを使用して、画面上部に画像を固定します。

ステータスバーの背後に全幅の画像を配置したアプリの例

一方、上部にツールバーを固定していくつかの項目を並べる UI を作成している場合は、ステータスバーの背後に描画してもあまり意味はないかもしれません。また、Android Pie 以前を搭載するデバイスで実行するアプリについては、ナビゲーション バーの場合と同様に、ステータスバー背後の描画に対応するかどうかは完全に任意です。

実装

「エッジ ツー エッジ」の描画は、以下の 3 つのステップで実装します。

1. 全画面配置をリクエストする

最初のステップは、アプリを（Y 軸上で）システムバーの背後に配置するようシステムに伝えることです。そのためには、ビューの API setSystemUiVisibility() を使用し、いくつかフラグを設定します。該当するフラグは次のとおりです。（ソースはこちら）


この設定により、ビューはナビゲーション バー背後の全画面に配置されるようになります。

アプリがナビゲーション バーの背後で全画面に配置された状態

2. システムバーの色を変更する

アプリが全画面に配置されるようになったら、システムバーの背後にあるコンテンツが見えるように、システムバーの色を変更する必要があります。

Android Q

Android Q で動作するアプリの場合、システムバーの色を完全な透明に設定するだけです。（ソースはこちら）


Android Q では、どのナビゲーション モードでも、システムバーの要素（時間、アイコン、ドラッグ ハンドルなど）の視覚的保護はすべてシステムが処理するようになりました。つまり、デベロッパー側で対応する必要はありません。システムで行われる処理は、次の 2 種類のいずれかとなります。

動的な色調整

システムバーの要素は、システムバーの背後にあるコンテンツに応じて色が変化します。たとえば、ハンドルの背後に明るい色のコンテンツがあるときは、ハンドルは暗めの色に変わります。反対に、背後に暗い色のコンテンツがあるときは、明るい色に変わります。この処理は、「動的な色調整」と呼ばれています。

Android Q の動的な色調整

半透明スクリム

システムバーの背後に半透明のスクリムを適用する場合もあります。ただしこの処理は、アプリが targetSdkVersion を 29 と宣言した場合にのみ適用されます。アプリのターゲット バージョンが SDK 28 以前の場合は、この自動スクリムは表示されず、ナビゲーション バーは透明になります。

Android Q のボタン ナビゲーション モードでスクリムが適用された状態

この 2 種類の処理はいずれも、システムバーの要素が常に見えるようにするために適用されるものです。システムがどちらの方法を採用するかは、いくつかの要因によって決まります。スクリムが適用されるのは次の場合です。

• いずれかのボタンモード（2 ボタンまたは 3 ボタン）が有効になっている。
• ジェスチャー ナビゲーション モードが有効な状態に対し、デバイスのメーカーが動的な色調整を無効にしている。この理由としては、そのデバイスで色調整処理を行うとパフォーマンスが低下する可能性があることが挙げられます。

ジェスチャー ナビゲーション モードでスクリムが使用されている例

それ以外の場合は、動的な色調整が採用されます。上記の理由は現時点で当てはまるものであり、今後変わる可能性があります。

Android Q でシステムバーの保護を無効にする

システムバーの要素を自動的に保護する処理を必要としない場合、アプリのテーマで android:enforceNavigationBarContrast または android:enforceStatusBarContrast、あるいはその両方を false に設定することで、この機能を無効にできます。

Android Pie 以前

Android Pie 以前のデバイスでもエッジ ツー エッジ対応にする場合は、システムバーの要素を保護するために、システムバーの色を半透明に設定する必要があります。システムバーが暗い色のテーマの場合、不透明度 70% の黒のスクリムから試してみることをおすすめします。（ソースはこちら）


この不透明度は、背後に表示されるコンテンツに応じて調整してください。明るい色のテーマであれば、明るい半透明の色（例: #B3FFFFFF）に設定してもよいでしょう。

暗い色のテーマと明るい色のテーマで、それぞれに適したスクリムを使用した例

3. 視覚的な重なり

以上の対応が済んだ後に、アプリの重要なビューがシステムバーの背後に隠れてしまっていることに気付く場合があるかもしれません。3 番目の（つまり最後の）ステップでは視覚的な重なりを処理しますが、これについてはこちらのブログ投稿で解説します。

Posted by Yuichi Araki - Developer Relations Team