[go: up one dir, main page]

この記事はデベロッパー リレーションズ エンジニア、André Bandarra、プロダクト マネージャー、Chirag Desai による Chromium Blog の記事 "Better content sharing with Custom Tabs" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
カスタムタブは Chrome が導入したブラウザ機能で、現在では Android のほとんどの主要ブラウザでサポートされています。WebView を使わなくても、アプリでウェブ エクスペリエンスを細かく制御し、ネイティブ アプリとウェブ コンテンツの間のシームレスな画面遷移を実現できます。ブラウザを使っているときと同じように、ユーザーはカスタムタブに表示されたコンテンツを共有したいと考えることがよくあります。

カスタムタブはデフォルトで共有機能を提供しておらず、多くのアプリはユーザーがコンテンツを共有する方法をまったく提供していません。そのため、ユーザーはブラウザのオーバーフロー メニューから共有アクションを探さなければならず、ユーザー エクスペリエンスが低下します。この操作を行うと、ユーザーはアプリの外に移動してブラウザでリンクを開くことになるので、アプリのエンゲージメントも下がります。

Chrome 88 では、特定の状況で自動的にデフォルトの共有アクションを追加する実験を行っています。たとえば、アプリが独自のアクション ボタンを指定していない場合、トップバーにこのボタンを表示します。サイトで独自のトップバー アクション ボタンが指定されている場合は、デフォルトの共有アクションはオーバーフロー メニューに追加されます。

アプリでアクション ボタンが提供されていない場合、URL を共有するデフォルトのアクション ボタンがトップバーに追加される

 新しいデフォルトの共有アクション ボタンを使うために必要なこと 何もありません！アプリが独自のアクション ボタンを設定していなければ、デフォルトのアクション ボタンが自動的に追加されます。変更はブラウザ側で行われるので、カスタムタブを使っているすべてのアプリに自動的に適用されます。

注意事項: これは Chrome の動作の変更です。他のブラウザにも同様の機能が追加されることを期待しています。


アプリで共有アイコンを表示しないようにする方法

androidx.browser バージョン 1.3.0 以降では、CustomTabsIntent.Builder の setShareState() メソッドを使ってデフォルトの共有を無効にすることができます。

val customTabsIntent = CustomTabsIntent.Builder()

        .setShareState(CustomTabsIntent.SHARE_STATE_OFF)

        .build();


この変更の一環として、CustomTabsIntent.Builder の addDefaultShareMenuItem() メソッドと setDefaultShareMenuItemEnabled() メソッドは非推奨となっています。代わりに setShareState() を使うようにしてください。

アプリでカスタムタブを使っている方は、ぜひフィードバックをお寄せください。こちらのフォームから連絡することができます。



Reviewed by Eiji Kitamura - Developer Relations Team

この記事はプロダクト マネージャー、PJ McLachlan による Chromium Blog の記事 "Changes to quality criteria for PWAs using Trusted Web Activity" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Chrome 86 より、Trusted Web Activity がウェブアプリのエラーの一部をネイティブ アプリのクラッシュに委譲

Trusted Web Activity は、プログレッシブ ウェブアプリ（PWA）を Android アプリに組み込む場合に推奨されている方法です。Trusted Web Activity は WebView と異なり、Chrome ブラウザのインスタンスなため、常に最新のウェブ プラットフォーム API をすべて実装しています。私たちは、Trusted Web Activity のリリース以来、これを使ったアプリをネイティブ エコシステムに統合する機能の改善を行っています。具体的には、スプラッシュ画面の自動生成やウェブ通知の委譲などです。

Chrome 86 ではこの統合をさらに進め、ウェブ アプリケーションのクラッシュ イベントをネイティブの同等の機能に委譲できるようにします。
ウェブアプリのクラッシュは他とは異なる ウェブ デベロッパーは、クラッシュよりも「エラー」という考え方に慣れています。ユーザーがウェブアプリの中で 404 エラーや 5xx エラーなどの HTTP エラーに遭遇した場合、それは実質的にアプリケーションのクラッシュに相当します。クラッシュと見なせるウェブアプリのエラーのもう 1 つの例は、ユーザーがインターネットに接続できず、オフライン リソース リクエストを処理する ServiceWorker のハンドラがアプリに存在しないため、Chrome の恐竜のページが表示された場合です。エラーのハンドリングを行うこの種の ServiceWorker は、404 や 5xx によるリソース読み込みエラーにも使われます。
Android エコシステムのクラッシュ Android Vitals は、Android 端末の安定性とパフォーマンスを向上させる Google の取り組みです。Android Vitals のデータは Google Play Console に集約され、Android Vitals ダッシュボードに表示されます。Android Vitals の Problems は、質が低いために Play Store での低評価や検出可能性の低下につながる可能性があるアプリのユーザー エクスペリエンスを示しています。

Chrome 86 以降では、重大なウェブ アプリケーションのクラッシュがネイティブ アプリのクラッシュ イベントと Android Vitals に統合されます。この変更により、イベントが処理されない場合は、ユーザーの目に見えるクラッシュが発生することになります。そのため、Trusted Web Activity を使っている、または使う予定のあるデベロッパーは、この投稿を注意深く確認する必要があります。

Chrome 86 に委譲される重大なウェブ アプリケーションのクラッシュは、以下のとおりです。
  1. アプリケーションで発生した HTTP 404 エラーまたは 5xx エラー
  2. HTTP 200 を返さなかったオフライン ネットワーク リソース リクエスト
  3. アプリケーション起動時の Digital Asset Links の検証失敗
この記事では、例外条件、アプリケーションの動作への影響、例外の回避方法について、詳しくお伝えします。
Chrome でこの変更を行う理由 Play ストアから Android アプリケーションをインストールしたユーザーは、アプリケーションがネイティブのように振る舞うことを期待します。ネイティブ アプリケーションには、404 エラーや 5xx エラーのページはありません。また、少なくとも独自のオフライン インジケーターを提供して、インターネット サービスの中断に対処しているはずです。さらに、Digital Asset Links の検証に失敗した場合は、アプリの所有者がウェブ コンテンツの所有者でもあることを検証できません。これまでは、このような状況が発生すると、Trusted Web Activity から Chrome Custom Tab（CCT）にフォールバックされていました。しかし実際には、CCT フォールバックはユーザーの期待を満たさないことがわかっています。さらに、サイレント フォールバックが行われるとフィードバック メカニズム（Play コンソールの障害レポート）が省略されてしまいます。フィードバックは、デベロッパーがアプリケーションの問題点を把握するうえで重要です。

クラッシュ イベントを Android Vitals と統合すると、Trusted Web Activity を使っている Android アプリのデベロッパーが Android Vitals ダッシュボードを利用してアプリのユーザー エクスペリエンス情報を参照できます。このアプローチは、高品質のアプリを作っているデベロッパーに報いるという面もあります。Android Vitals のスコアが高いアプリは Play ストアで見つけやすくなるからです。
動作の仕組みと行うべきこと
下の表は、ウェブ アプリケーションのクラッシュの発生条件、対応するアクション、推奨される対策について詳しく記したものです。Trusted Web Activity のクラッシュ イベントには、Android Console に表示できるログ メッセージが含まれます。デバッグがしやすくなるように、このメッセージから、例外を引き起こしたトリガーや例外が発生した URL に関する詳細情報を確認できます。


例外発生条件 アクション 推奨される対策
信頼するオリジンに対するメイン ドキュメントの HTTP リクエストで、HTTP エラーコード 404 または 5xx が返された Trusted Web Activity で例外が発生
  • アプリで 404 エラーや 5xx エラーが発生しないようにする
  • ServiceWorker のフェッチ イベント フォールバック レスポンスを使って 404 エラーや 5xx エラーに対処する
信頼するオリジンに対するメイン ドキュメントの HTTP リクエストで、オフライン時に HTTP 200 が返されなかった
  • ServiceWorker を使用する
  • ServiceWorker を使ってオフライン リソース リクエストを処理する [チュートリアル]
Digital Asset Links 検証が失敗した

（オフライン時の失敗を除く）
信頼するオリジンの TLS 検証に失敗した
  • TLS 証明書が有効であることを確認する

ネイティブ コードによる例外ハンドリング
Trusted Web Activity で発生する例外は、Android 例外ハンドリングを使って処理することもできます。ただし、上の表の推奨される対策で、例外自体の発生を回避することを検討してください。

まず、Trusted Web Activity 例外により、Chrome が終了します。 例外処理を行ったとしても、ユーザー エクスペリエンスはぎこちないものになります。

次に、ウェブアプリで対策を実装することで、すべてのウェブブラウザですべての PWA のユーザー エクスペリエンスが改善されます。
今後の Android Vitals の統合 ウェブ アプリケーションとネイティブ アプリケーションのユーザー エクスペリエンスを一致させるために、今後も重要なウェブ アプリケーションのイベントを Android Vitals に統合する作業を継続したいと考えています。

たとえば、アプリの起動時間、電池使用量、アクセス許可の拒否や応答しないアプリケーション（ANR）などのイベントです。
Trusted Web Activity 品質基準についてのリマインダー
  1. ポリシー。Trusted Web Activity を使う Android アプリは、Play ストアのすべてのポリシーに準拠する必要があります。これには、Trusted Web Activity のウェブ コンテンツや、アプリ内購入、その他デジタル商品の支払いポリシーなどが含まれます。
  2. エクスペリエンスの質を確保するには、Trusted Web Activity のコンテンツは PWA のインストール可能基準を満たし、開始 URL から高速に読み込める必要があります。読み込み速度は、Trusted Web Activity の開始 URL で Lighthouse を使って測定し、パフォーマンス スコア 80 以上が必要です。
Lighthouse は、オープンソースの自動ツールで、パフォーマンスとプログレッシブ ウェブアプリの監査を行います。ベンチマークとしても、優れたウェブサイトを作る上でも役立ちます。
高品質な Trusted Web Activity を開発するデベロッパーをサポート Trusted Web Activity がリリースされてから、オープンソース ユーティリティ ライブラリ Bubblewrap を作成しました。このライブラリは、PWA を使って高品質な Android アプリケーションを作る際に役立ちます。Trusted Web Activity クイック スタートガイドを利用すると、Trusted Web Activity や Bubblewrap を初めて使うデベロッパーでも短時間で開発できます。

デベロッパーが Trusted Web Activity を使って高品質な Android アプリを簡単に構築できるように、またビルド時によくある間違いについて警告を提供するために、私たちは Bubblewrap の改善を続け、ツールや土台を追加しています。

Reviewed by Eiji Kitamura - Developer Relations Team

この記事は プロダクト マネージャー、Peter Mclachlan による Chromium Blog の記事 "Introducing a Trusted Web Activity for Android" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 


Trusted Web Activity（TWA）は、Android アプリ内でブラウザの UI がない Chrome ブラウザを全画面表示します。型どおりに Chrome Custom Tab（CCT）や WebView を使えば Android アプリにウェブ コンテンツを含めることができますが、アプリ内で全画面モードで Chrome のパフォーマンスや機能を活用したい場合は、TWA を使うと他にはないメリットを得ることができます。

この投稿では、TWA の概要や推奨ユースケースについて説明し、使い始める際に役立つリソースへのリンクを紹介します。

Trusted Web Activity の特徴  

Trusted Web Activity は、Android アプリ内で Chrome ブラウザを全画面で実行します。アプリ内に URL バーなどのブラウザの UI は表示されません。これは強力な機能なので、アプリとサイトが同じデベロッパーのものであること、すなわち「信頼できる」ことを検証しなければなりません。アプリと TWA で開いたサイトが同じデベロッパーのものであることを検証するために、TWA は Digital Asset Links を使って所有権を確認します。

TWA は特殊な Chrome Custom Tab（CCT）なので、WebView では利用できない多くの機能を含め、すべての Chrome 機能にアクセスできます。Chrome Custom Tab についてよく知らないという方は、こちらの記事で詳細を確認できます。WebView では利用できない TWA の機能には、ウェブ プッシュ通知、バックグラウンド同期、Chrome のフォーム自動入力、Media Source Extensions（MSE）、Sharing API などがあります。

CCT と同じように、TWA に読み込まれたウェブサイトは Cookie などの Chrome ブラウザに格納されているデータを共有します。ということは、セッションの状態が共有されます。つまり、ユーザーが以前に Chrome でログインしたことがあるほとんどのウェブサイトでは、TWA でもログインが実行されることになります。

TWA の用途  

TWA は、Android アプリの全画面ウェブ コンテンツで WebView では利用できない Chrome 機能を使いたい場合や、Chrome ブラウザとオリジン ストレージを共有することでユーザーのナビゲーションが便利になる場合などに適しています。

この例として、製品ページがネイティブ ビューで実装されているにもかかわらず、購入フローはウェブサイト上で行われる e コマースサイトがあげられます。アプリで TWA を使うと、Chrome のパフォーマンスや自動フォーム入力機能を活用できます。

Trusted Web Activity の条件

TWA のすべてのコンテンツは、アプリ内購入などのデジタル商品の支払いポリシーを含め、Play ストアのポリシーに従う必要があります。

アプリのユーザーは、自分の端末で快適な操作ができることを期待しています。操作の質を保証するため、TWA は PWA のインストール基準を満たし、高速に読み込めるものである必要があります。読み込み速度は、Lighthouse を使って測定します。TWA のウェブ コンテンツは、80 以上のパフォーマンス スコアを獲得しなければなりません。Lighthouse は、オープンソースの自動ツールで、パフォーマンスとプログレッシブ ウェブアプリの監査を行います。ベンチマークとしても、優れたウェブサイトを作る上でも役立ちます。

すべての Play アプリと同様に、今後、品質条件が追加される可能性もあります。TWA 品質要件や Play ストアポリシーを満たさないアプリは、登録が拒否されたり、ストアに掲載されなくなったりする場合があります。

Trusted Web Activity のコンテンツ セキュリティとバージョン可用性

TWA のコンテンツは保護されており、母体となるアプリから読み取ったり変更したりすることはできません。つまり、状態を共有できるのは、初期化の際にアプリから TWA へクエリ文字列パラメータを渡すときだけです。Android アプリから TWA にコンテンツを挿入することはできません。

TWA は、Android KitKat 以降の端末（Android 端末の 95% 以上）に Chrome がインストールされている場合に利用できます。ユーザーが Chrome のアップデートを無効にしている場合など、古い Chrome がインストールされている場合は、自動的に TWA の代わりに Chrome Custom Tab が利用されます。

初めての Trusted Web Activity

TWA のスタートガイド ドキュメントやサンプルコードは、現在作成中で、近日中にリリースされる予定です。それまでの間は、以下のリファレンス ドキュメントをご覧ください。


Reviewed by Eiji Kitamura - Developer Relations Team


[この記事は Yusuf Ozuysal、チーフ タブ カスタマイザーによる Android Developers Blog の記事 "Chrome custom tabs smooth the transition between apps and the web" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

ウェブのコンテンツを Android アプリで表示しようとするとき、開発者は難しい問題に直面します。ユーザーにとってなじみがあって実装も容易なのは、ブラウザでリンクを開ける動作ですが、アプリとウェブ間のデータ移行が重くなってしまいます。WebView をカスタマイズすれば、よりきめ細かい制御が可能になりますが、技術的に複雑になり、ユーザーにとっても操作しずらくなります。最新バージョンの Chrome の新機能、カスタム タブを使えば、Chrome のルック アンド フィールをカスタマイズして、アプリからウェブ コンテンツへの遷移を素早くシームレスに行えるようになります。
プレローディングを使った Chrome カスタム タブとChrome および WebView
Chrome カスタム タブを使用すると、使い慣れたウェブ エクスペリエンスをアプリ ユーザーに素早く提供することができます。カスタム タブは、WebView や Chrome の既存の起動方法より早く読み込めるように最適化されています。上記のように、アプリがバックグラウンドでページをプリローディングできるので、ユーザーの操作とほぼ同時に読み込んで表示されます。Chrome のルック アンド フィールもカスタマイズできます。ツールバーの色や遷移アニメーションを変えたり、さらにはツールバーにアクションを追加してアプリに合わせることができるので、ユーザーはカスタム タブからアプリ固有のアクションを直接実行できます。

カスタム タブは、Chrome の高度なセキュリティ機能 (マルチプロセス アーキテクチャや堅牢なパーミッション モデルなど) を活用しています。Chrome と同じ Cookie ジャーを使用しているため、ユーザー情報の安全を確保しながら、使い慣れたブラウジング操作が可能になります。たとえば、Chrome でユーザーがあるウェブサイトにログインしている場合、カスタム タブで同じサイトに行けば同様にログインされます。ユーザーのウェブ ブラウジングを容易にするその他の機能として、パスワード自動保存、オートフィル機能、「タップして検索」機能、Sync 機能などもカスタム タブで利用できます。
既存の VIEW インテントのパラメータを幾つか微調整すれば、開発者はカスタム タブをアプリに容易に組み込むことができます。数行のコードを追加するだけで、基本的なインテグレーションが行えます。また、サポート ライブラリを活用すると、複雑なインテグレーションも簡単に完了できます。カスタム タブは Chrome 機能の 1 つなので、最新の Chrome が使えるどのバージョンの Android でも利用できます。

ユーザーがまもなくカスタム タブを使えるようになるのは、Feedly や、The Guardian、Medium、Player.fm、Skyscanner、Stack Overflow、Tumblr、Twitter ですが、順次増えていきます。ご自分のアプリケーションでカスタム タブを利用し始めたい方は、デベロッパー ガイドをご覧ください。


Posted by Eiji Kitamura - Developer Relations Team