オンデマンド モジュールにすると効果的な機能とは、大部分のユーザーがインストール時には必要としない機能です。オンデマンド モジュールに適したアプリの機能の例を以下に示します。
- 大多数のユーザーが動画の視聴のみを行うアプリでの、動画の編集とアップロード
- ほとんどのユーザーが他のユーザーのレシピのブラウジングと追従しか行わないアプリでの、レシピの追加
- ほとんどのユーザーがヘルプを必要としない場合やアプリ内のヘルプを求めていない場合の、ヘルプとサポート機能
- 使用頻度の少ない機能の大規模なライブラリ（詳細なバグのキャプチャの提供やレポートなど）
- 特定のお支払い方法や精算機能
- 超高解像度のメディア エクスペリエンスや VR / AR 機能
一般に、これらのモジュールのサイズが比較的小さく（10 MB 未満）、ネットワークやその他の障害がない場合、ユーザーはオンデマンド モジュールを瞬時にダウンロードして使用できます。つまり、アプリのインストール時にそのモジュールが存在していた場合と、便宜性はほとんど変わりません。
このページでは、以下の場合に効果的なおすすめの方法について説明します。
- 即座に読み込まれない比較的大きなモジュールのダウンロードや、モジュールのインストール エラーの場合、ユーザーが認識し、管理できると感じてもらう。
- 特に、ユーザーが特定のモジュールを必要とすると予想される状況で、モジュール配信のエクスペリエンスをさらに最適化する。
このガイドを読み終えたら、Play Core API サンプルアプリを試して、これらのおすすめの方法を実際にご確認ください。
ユーザーに情報を知らせる
機能をすぐに使用できない場合は、ユーザーに知らせる必要があります。ユーザーが Google Play から機能をダウンロードすることにした場合は、ダウンロードの進行状況を表示します。
リクエストの状態をモニタリングして、ダウンロードの進行状況とインストールの状態を表示できます。ただし、表示する UI の種類は、ダウンロードのサイズによって変えることをおすすめします。
- 瞬時にインストールできる比較的小さなモジュール（おおよそ 10 MB 以下）の場合は、スピナーなどのインジケーターや「コンテンツをダウンロードしています」という短いメッセージの表示を検討してください。
- ダウンロードとインストールに数秒以上かかる場合は、図 1 に示すように、ダウンロードとインストールの進行状況バーを表示することを検討します。
図 1. オンデマンド機能をダウンロード、インストールする際にメッセージと進行状況バーを表示する
インストールの遅延と失敗を適切に伝える
ダウンロードが失敗した場合、または予想より時間がかっている場合は、図 2 と図 3 に示すように、ダウンロードの状況と、ユーザーができる対処（存在する場合）を明確にわかりやすく伝えます。たとえば、ダウンロード リクエストの状態を確認したところ、アプリが API_NOT_AVAILABLE エラーを受け取っている場合は、デバイスがオンデマンド ダウンロードに対応していないことをユーザーに通知します。
図 2. 現時点で機能をインストールできない理由を知らせる
図 3. 機能のダウンロードに想定より時間がかかっている理由を説明する
サイズの大きいダウンロードで許可を求める前にそのメリットを提示する
オンデマンド モジュールのサイズが大きい場合（150 MB 以上）、Google Play はダウンロードする前にユーザーに同意を求めます。
モジュールをリクエストする前に、そのモジュールのメリットをユーザーに説明してください。アプリの権限をリクエストする場合と同様に、このリクエストの理由をユーザーに理解してもらうようにします。率直に伝えることで、ユーザーがダウンロードを受け入れる可能性が高まります。
たとえば、開発している e コマースアプリの機能のひとつとして、ユーザーが AR（拡張現実）を使って自宅の室内に直接家具を配置できるとします。その場合、「新しいソファをリビングルームに置いてみませんか？今すぐ拡張現実ビューアをインストールしましょう」というメッセージを表示するとよいでしょう。
ダウンロードとインストールをバックグラウンドで実行する
モジュールのダウンロードとインストールは常にバックグラウンドで実行する必要があります。つまり、機能が用意されるのを待っている間、ユーザーがアプリの他の部分を引き続き使用できるようにします。機能が使用可能な状態になったら、通知を表示し、ユーザーが自分の判断でその機能に切り替えられるようにする必要があります。
図 5 に示すように、ユーザーはアプリの使用を続けて、オンデマンド機能のインストールが完了すると通知を受け取ります。
図 5. モジュールのインストールが完了したら、ユーザーのコンテキストを突然変更するのではなく、リクエストした機能の準備が整ったことをユーザーに通知する
モジュールを使用する準備が整ったら、ユーザーに通知し、機能を起動するかどうかを選択できるようにします。これは、ユーザーに機能の利用のコンテキストとコントロールを提供するものです。
場合によっては、準備が整ったらすぐに機能を開始することもできます。しかし、その場合はユーザー エクスペリエンスを中断させる可能性があるため、この動作が想定されて適切かどうかを慎重に検討してください。
モジュールが不要になった場合はデバイスのストレージを解放する
すべての機能モジュールに共通する便利な特長は、個別にアンインストールできることです。機能モジュールが使用されなくなった場合、Google Play にモジュールのアンインストールをリクエストすることにより、ユーザーのデバイス上のアプリのサイズを削減できます。
たとえば、リッチメディアを豊富に使った本格的なオンボーディング フローをアプリに含める場合があります。ユーザーがオンボーディング フローを完了した後や、一定の期間アクティブ ユーザーとして過ごした後に、Play Feature Delivery API を使用して、アプリのそのコンポーネントのみをアンインストールするように Google Play にリクエストできます。
なお、アプリの初期インストール時に含めたモジュールを後でアンインストールすることもできます。たとえば、新規ユーザーにアプリの使い方を教えるモジュールは、ユーザーがそのアプリを初めて使用する場合には有益です。しかし、アプリのサイズを減らすため、トレーニングをユーザーが完了した後は、アプリからモジュールをアンインストールできます。
高度なヒント
通常は、ユーザーがオンデマンド機能モジュールの機能を使用したいという意思を明示した時点で対応する必要があります。
しかし、ユーザーが意思を示す前に、その機能を使用したくなるタイミングを予測できると便利です。次のガイドラインでは、料理のレシピのダウンロードと作成ができるアプリを例として、ユーザーのニーズを予測してモジュールの配信を最適化する方法について説明します。
現在のセッションでの機能に関するユーザーのニーズを予測する。自分のレシピを作成してコミュニティで共有したいユーザーのみ、レシピアプリのアカウントの作成が必要な場合を考えます。アカウントの作成を、ユーザーが「自分のレシピを追加」しようとする可能性の高いシグナルとして利用し、ユーザーが [レシピを追加] をタップする前に、その機能モジュールのダウンロードを開始することができます。この方法をアプリ内の他のユーザーフローにも適用すると、機能のダウンロード プロセスがよりシームレスになります。
今後のセッションでの機能に関するユーザーのニーズを予測する。オンデマンド モジュールをすぐにダウンロードしてインストールする必要がない場合は、アプリがバックグラウンドになるまでインストールを延期できます。ダウンロードとインストールは Google Play によって処理されます。たとえば、料理アプリで新しい季節のレシピを公開する場合、ユーザーの現在のセッションでの優先度は高くありません。このようなレシピは、アプリがバックグラウンドになったらダウンロードしてインストールするように Play にリクエストできます。この方法は、今は必要ないが今後必要になるであろうサイズの大きい（10 MB を超える）機能の場合に特に便利です。
アプリのインストールより前に機能に関するユーザーのニーズを予測する。ユーザーの国、デバイス ハードウェアの機能、API レベルに基づいてインストール時に機能を含める、条件付き配信のサポートを追加することもできます。たとえば、豚肉を使用するレシピを条件付きモジュールに含めておき、大部分の人が豚肉料理を避ける地域では、アプリのインストールからそのモジュールを省くことが考えられます。