情報
要求されたトピックは次のとおりです。しかし、このトピックはこのライブラリには含まれていません。

Windows Phone 8 の高速アプリ再開

2014/06/18

対象: Windows Phone 8 および Windows Phone Silverlight 8.1 のみ

このトピックでは、Windows Phone 8 で高速なアプリ再開を有効にする方法について説明します。Windows Phone 8 では、ユーザーがアプリケーションから離れると、そのアプリケーションは中断され、アプリケーションの状態がメモリに保存されます。ユーザーが [戻る] ボタンを押すか、またはタスク スイッチャーを使用してアプリケーションに戻ると、アプリのインスタンスが再開されます。アプリはメモリに保存されているので、ユーザーが離れたときと同じ状態で、アプリがすばやく再開されます。このプロセスを Fast App Switching (FAS) といいます。アプリが中断された後、ユーザーがアプリ一覧からアプリ名をタップするか、アプリのプライマリ スタート タイルをタップするなどの方法で、そのアプリを再起動した場合、既定ではアプリの古いインスタンスが終了し、まったく新しいインスタンスが作成されます。このプロセスは、中断されたアプリの再開よりも低速で、提供されるユーザー エクスペリエンスも異なります。Windows Phone 8 では、通常はアプリを再起動するために使用するユーザー アクション (アプリのスタート タイルのタップなど) を要求して、中断されたアプリの中断されたインスタンス (存在する場合) を再開できる機能が導入されています。この機能を Fast Resume といいます。Windows Phone アプリのライフサイクルの詳細については、「Windows Phone 8 のアプリのアクティブ化および非アクティブ化」を参照してください。

Fast Resume は、簡単に有効にすることができます。必要な作業は、アプリのマニフェスト ファイルを少し変更するだけです。ただし、Fast Resume を有効にした場合、アプリの再開時に、以前使用されたページの Back スタックを管理する方法について、2、3 種類のオプションがあります。このトピックでは、再開エクスペリエンスを最適化するためのさまざまな方法を説明します。

注意注意:

Direct3D アプリでは、単純な起動とアプリの再起動が区別されません。この種のアプリは、常に以前のエクスペリエンスを再開します。XAML & Direct3D アプリ、および Direct3D with XAML アプリは、通常の XAML アプリと同様、Fast Resume を利用できます。

このトピックは、次のセクションで構成されています。

アプリで Fast Resume を有効にするには、WMAppManifest.xml で DefaultTask 要素に ActivationPolicy 属性を追加し、その値を “Resume” に設定します。 このタスクを実行するには、マニフェスト エディターを使用する代わりに、アプリ マニフェストを直接編集する必要があります。この操作を実行するには、WMAppManifest.xml を右クリックし、[プログラムから開く] をクリックし、[XML (テキスト) エディター] を選択します。

XAML アプリ、Direct3D アプリ、Direct3D with XAML アプリで、Fast Resume を有効にすることができます。XAML アプリおよび Direct3D アプリに対応する DefaultTask 要素を、次の例に示します。

<DefaultTask Name="_default" NavigationPage="MainPage.xaml" ActivationPolicy="Resume"/>

<DefaultTask Name="_default" ImagePath="PhoneDirect3DApp1.exe" ImageParams=""  ActivationPolicy="Resume"/>

Fast Resume を実装する際、電話に備わったさまざまな起動ポイントからアプリが起動した場合に、どのようなユーザー エクスペリエンスがアプリに最適であるかを判断する必要があります。

  • プライマリの起動ポイントでは、アプリのメイン ページがユーザーに表示されます。プライマリの起動ポイントとしては、スタート画面にあるアプリのプライマリ タイルや、アプリ一覧またはゲーム ハブのアプリ名があります。

  • ディープ リンクの場合、ユーザーはアプリ内の別のページに移動します。 ディープ リンクとしては、セカンダリ タイル、トースト通知、Search ハブや Photos ハブなどの拡張ポイントがあります。

Windows Phone アプリの場合、ユーザーがそのアプリ内でアクセスしたページの履歴がシステムによって維持されるので、ユーザーは [戻る] ボタンを使用して、スタックに保存されている以前のページへ順に移動することができます。Fast Resume を使用する場合、アプリが再開されると、システムは起動ポイントのターゲットに対応する新しいページ インスタンスを作成します。このページがアプリの既存の Back スタックの一番上に配置されます。この動作が発生した時点で、アプリは既存の Back スタックをクリアし、新しく作成されたページだけをスタックに残すことができます。この場合、“単純に” アプリを起動したときと同じユーザー エクスペリエンスになります。ユーザーが再開後のアプリから以前のページに移動すると、履歴にページがまったく存在しないので、スタート画面または直前に使用していたアプリに戻ることになります。Fast Resume を処理するもう 1 つの方法は、新しく作成されたページへの移動をキャンセルすることです。この場合、ユーザーが最後に表示していたアプリ ページが表示され、以前のセッションによる Back スタックがそのままの状態で残されています。以前のアプリ セッションをそのまま再開したような状態になります。

ここでは、ある一般的な XAML アプリにおける各種のユーザー エクスペリエンスについて、例を見ながら考察します。この XAML アプリは 3 つのページで構成されています。

  1. メイン ページ

  2. ページ 1 – メイン ページにあるリンクを通じてアクセス可能。

  3. ページ 2 – [スタート] に固定されたセカンダリ タイルからアクセス可能。

ユーザーがこのアプリを起動し、メイン ページを表示した後、ページ 1 に移動し、次に [スタート] ボタンを押したと仮定します。アプリの現在の Back スタックは、次の図のようになっています。

Fast Resume Series 1

ユーザーが電話を使用し、いずれかの時点でアプリのプライマリ タイルを使用して、再びアプリを [スタート] から起動したと仮定します。この時点で、システムはタイルに関連付けられた URI に対応する新しいページ (この場合、メイン ページ) を作成し、Back スタックの一番上にそのページを配置します。Back スタックは次のようになります。

Fast Resume Series 2

この時点でユーザーに対して表示されるのはメイン ページです。ユーザーが [戻る] ボタンを押すと、ページ 1 が表示され、続いて再びメイン ページが表示されます。[戻る] ボタンをさらに押すとアプリが終了します。これはユーザーが想定した動作ではありません。ユーザーは [スタート] からアプリを起動してメイン ページを表示したばかりなので、[戻る] ボタンを 1 回押せばスタート画面に戻ると想定しています。

この場合、アプリに最適なユーザー エクスペリエンスはどのようなものかを判断する必要があります。たとえば、ユーザーがアプリを離れてからの経過時間が短い場合には、アプリを再開する時点では最後に表示されていたページを表示し、アプリを離れてからの経過時間が長い場合には、メイン ページを表示するなどの判断が可能です。

“完全に新しいインスタンス” のエクスペリエンス

“完全に新しい” エクスペリエンスを提供するには、アプリを再開するとき、Back スタックのページをすべて削除し、ユーザーに対してメイン ページを表示します。次の図からわかるように、以前アクセスしたページが Back スタックから削除されているので、[戻る] ボタンを押すとアプリが終了します。

Fast Resume Series 3

“再開” エクスペリエンス

アプリを再開する時点で、以前のエクスペリエンスを再開するには、メイン ページへの移動をキャンセルします。この場合、ユーザーにはページ 1 が表示され、[戻る] ボタンを押すと期待どおりメイン ページが表示されます。

Fast Resume Series 4

以前のエクスペリエンスを再開するのが最も合理的なのは、アプリがプライマリの起動ポイント ([スタート] のプライマリ タイルなど) から起動された場合です。ディープ リンクの場合は、Back スタックをクリアする方がより合理的です。その理由を、次の例で具体的に説明します。

ユーザーがアプリを起動し、ページ 1 に移動した後、[スタート] ボタンを押すという、元のシナリオを考察してみましょう。アプリの Back スタックは、次の図のようになっています。

Fast Resume Series 1

その後、いずれかの時点でユーザーが再びアプリを起動します。今回は [スタート] のセカンダリ タイルからの起動です。このタイルの URI は、ページ 2 をポイントするディープ リンクです。今回、ユーザーに表示されるのはページ 2 です。ユーザーが [戻る] ボタンを押すと、ページ 1 が表示され、次にメイン ページが再び表示された後、ようやくアプリを終了することができます。 これもやはり、ユーザーが想定した動作ではありません。このシナリオでは、アプリケーションが Back スタックをクリアしてから、ページ 2 に移動するのが望ましい動作です。

Fast Resume Series 6

アプリケーションが再開されるとき、システムは RootFrame に対して、NavigationModeReset が設定された Navigated イベントを生成します。値 Reset は、アプリが再起動されることを通知します。この時点で、アプリは RootFrameRemoveBackEntry() を呼び出すことにより、Back スタックがクリアされるまで、ページ スタックをクリアすることができます。

while (RootFrame.RemoveBackEntry() != null);

次に、NavigationModeNewを使用して新しいページが作成され、そこへ移動します。

アプリケーションが再開されるとき、システムは RootFrame に対して、NavigationModeResetが設定された Navigated イベントを生成します。アプリで以前のページをクリアする必要がない場合、Back スタックの一番上にあるページは、NavigationModeReset が設定された OnNavigatedTo を受け取り、次に NavigationModeNew が設定された OnNavigatedFrom を受け取ります。この時点で、RootFrame の Navigating イベントの NavigatingCancelEventArgs パラメーターに e.Cancel = true を設定することにより、アプリで新しいページへの移動をキャンセルできます。

Back スタックの一番上のページと同じ URI を使用してアプリが再起動される場合、システムは新しいページを受け取らず、代わりに一番上のページに対し、最新の情報に更新する必要があることを通知します。Back スタックをクリアしたり、移動をキャンセルしたりする必要はありません。

このケースでは、バックスタックの上部のページに 2 回にわたって移動が行われます。1 回目はNavigationModeReset、2 回目は NavigationModeRefreshが使用されます。この 2 回目の移動が行われる時点で、アプリはクラウドから最新のデータを取得するなど、最新の情報に更新することができます。

Fast Resume を実装し Back スタックの管理を具体的に示したサンプル アプリを表示またはダウンロードするには、「Fast Resume の Back スタックのサンプル」を参照してください。

表示: