Ben Srour Senior Program Manager Lead Microsoft Corporation 2017/3/4 APP-409T Fundamentals of Metro style apps: how and when your app will run Metro スタイル アプリの基礎: アプリ実行の方法とタイミング 皆さん、こんにちは。私は Ben Srour です。Windows ユーザー エクスペリエンス チームのプ ログラム マネージャーを務めています。この役職について 7 年になります。私のチームは、 Windows 8 の中で、プロセスのライフサイクルを管理する部分を担当しています。   今日は、「Metro スタイル アプリの基礎: アプリの実行方法とタイミング」についてお話しし ます。 Ben Srour Senior Program Manager Lead Microsoft Corporation © 2011 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

トランスクリプト付き日本語翻訳ファイルについて この PowerPoint ファイルには、「ノート」 セクションにセッションの講師が話し ている内容を書き起こしたもの (トランスクリプト) を入力しています。 ノートを参照するには、PowerPoint の表示モードを [標準] または [ノート] に設定 してください。[標準] の場合は、スライド表示ウィンドウの下 (ノート ペイン) に 表示されます。 ノート表示モードで見た際にノートが 1 ページに収まりきらない場合は、スライ ドを複製して複数ページにわたってノートを入力しています。そのため、オリジ ナルの英語版ファイルと比較して、スライド番号やスライドの枚数が異なる場合 があります。(本スライドが追加されている時点で、英語版とは枚数が異なります) ノートを印刷するには、[印刷プレビュー] または [印刷] 画面において、[印刷対象] を [ノート] に指定してください。

免責事項 本プレゼンテーション (以下、本書) で提供されている情報は、本書が 発表された時点における Microsoft の見解を述べたものです。市場 ニーズの変化に対応する必要があるため、本書は記載された内容の実 現に関する Microsoft の確約とはみなされないものとします。また本 書に記載された情報の正確さについて、保証するものではありません。 本書は情報の提供のみを目的としており、明示または黙示に関わらず、 本書について Microsoft はいかなる保証をするものでもありません。 本書に記載されている機能名や用語の日本語訳は、あくまでも暫定的 なものであり、将来変更される可能性があります。

アジェンダ アプリはいつ実行されるのか アプリはどのように実行されるのか アプリが常に実行中であるように見せるためのヒント 状態の保存と復元 ライブ タイルの使用 アプリのさまざまな実行方法について 理解していただきたいこと Windows 8 で Metro スタイル アプリが実行される方法と タイミング アプリの状態を保持する方法 最初に、新しいライフサイクル モデルを紹介し、Windows 8 においてアプリをどのようにイ ンスタンス化できるかを説明します。ご存知とは思いますが、アプリは常に実行中というわ けではありません。状態の保存とその復元によって実行中でないアプリを実行中であるよう に見せる方法、そしてライブ タイルの使用法についてお話しします。最後に、アプリのその 他の実行方法について簡単に説明します。今日は、アプリが常に実行中であるように見せる ための具体的な方法を紹介します。新しいライフサイクル モデルを完全に理解できるように なります。セッション終了後は、チームのメンバーと共に皆さんの質問にお答えします。

アプリを実行するタイミングの変更 多数のアプリを起動 フォアグラウンドのアプリを選択 ユーザーがアプリの存続を管理 Windows 7 では、ユーザーがアプリを起動し、ユーザーがその存続期間を管理するというモ デルが採用されています。ユーザーは、作業が終わるとアプリを終了します。バッテリ残量 が気になる場合やシステム パフォーマンスを向上させたい場合もアプリを終了します。 Windows 8 のモデルでは、フォアグラウンドにあるアプリが最重視されます。フォアグラウ ンドにあるアプリは、システム内で最も重要なアプリであると考えられるためです。バック グラウンドに置かれたアプリは、システム パフォーマンスに影響を与えないように、一時停 止されます。どのアプリの実行を保つかは、ユーザーではなくシステムが管理します。 ユーザーがアプリの存続を管理 システムがアプリの存続を管理

アプリは メモリの制約から 通知なしで終了される プロセスのライフサイクル アプリ 1 アプリ 2 アプリ 3 アプリ N 実行 … アプリは 短時間おいて 一時停止する アプリは 一時停止の状態から直ちに再開 一時停止 では、実際の処理を見ていきましょう。アプリ 1 をフルスクリーンで実行しています。アプ リ 2 を実行すると、アプリ 1 は直ちにバックグラウンドに移動し、その後少しの時間をおい て、一時停止メッセージを取得します。この一時停止メッセージは、コードが実行可能であ ることをアプリに示す最後の通知です。コードを実行可能なこの最後の機会を利用して、ア プリは状態を保存し、終了される場合に備えます。ユーザーは他にもアプリを起動できます。 この場合はアプリ 3 ですが、これによってアプリ 2 は画面から消え、その後、一時停止とな ります。さらに別のアプリを起動した場合も同様です。   ここで、メモリを大量に消費するゲームをプレイするとします。システムはメモリ不足への 対応として、一時停止状態のアプリを終了します。一見、先入れ先出しモデルのようですが、 そうではありません。メモリを最も消費しているアプリが標的になります。注意すべき点と して、アプリは実行状態から一時停止状態に変わるときには通知を受けます。しかし、シス テムがアプリを終了するときには、アプリへの通知は行われません。アプリはメモリから消 去されるだけです。 一時停止モデルの利点の 1 つとして、ユーザーは一時停止されているアプリを直ちに実行状 態に戻すことができます。つまり、アプリの切り替えが速くできます。ご覧のように、ユー ザーが 2 つ目のアプリに切り替える場合、そのアプリは既にメモリ内に存在しており、つま り、スレッド、スタック、ヒープが既に存在しているので、アプリは直ちに復帰し、前回と 同じ状態が復元されます。これが再開と言われる処理です。 アプリは メモリの制約から 通知なしで終了される 終了

一時停止の導入 システム リソースはフォアグラウンドのアプリに優先的に割り当てられる 非アクティブなアプリはバッテリ持続時間や応答性に影響を及ぼさないように、OS によって一時停止される アプリを瞬時に切り替えられる 新たに導入された一時停止というプロセス状態によって、フォアグラウンド アプリにリソー スを集中できるようになります。ユーザーが利用していないアプリのためにシステム リソー スを浪費する必要はありません。フォアグラウンドにあるアプリが優先されます。バックグ ラウンドになったアプリはオペレーティング システムによって一時停止されます。また、即 時にすばやく切り替えられるという利点もあります。

アプリが終了されるケース アプリの終了は、アプリに通知されない システムのメモリ不足 ユーザーの切り替え システムのシャットダウン アプリのクラッシュ よく言われることですが、強制終了はいつでも起こり得ることです (ジョークはあまり得意で はないので、ここで笑ってもらえるのは五分五分以下だろうとは思っていたんですが) 。シス テム内で一時停止されているアプリは終了されることがあります。終了となるケースはいく つかあります。メモリ不足、ユーザー アカウントの切り替え、マシンの再起動、また当然で すが、アプリのクラッシュなどです。アプリのクラッシュについては後ほどお話しします。 アプリがクラッシュすると、一時停止されずにそのまま終了します。ここで強調しておきま すが、アプリは、一時停止状態になるときがコードを実行する最後のチャンスです。終了に 備える必要があります。では、実際に見ていきましょう。 アプリの終了は、アプリに通知されない

デモ プロセス ライフサイクルの考え方 ここに Windows 8 デバイスがあります。新しいタスク マネージャーに [Status]、[CPU]、 [Memory] の各列が表示されています。ここで天気予報のアプリを起動します。これは美しい フルスクリーン アプリで、これなら天気をチェックしたくなります。このアプリの優れた点 は動画を再生する点で、外観も美しくなっています。同時に、動画の再生は CPU を大量に消 費します。現在 CPU の 10% から 9% を占有しています。   このアプリをバックグラウンドに切り替えたとしても、ライフサイクルが管理されない環境 では、パフォーマンスとバッテリ残量に悪影響を及ぼします。表示されない動画をレンダリ ングする必要はないので、アプリは一時停止されます。アプリは、バックグラウンドに置か れると、短い時間をおいて一時停止状態になります。アプリが一時停止状態になり、CPU 列 の値は 10% から 0% になりました。アプリは一時停止メッセージを受信し、必要な処理をし てから、一時停止状態に入ります。現在、このアプリはシステムのリソースを消費していま せん。 しかし、このアプリにはすぐに戻ることができます。すぐに再開されます。タスク マネー ジャーで、アプリが即座に一時停止状態から実行状態に変わるのを確認できます。このよう に即座に状態が変化できるのはなぜでしょうか。これは、アプリが既にメモリ内に存在する ためです。ここに必要となる処理は、スレッドを再実行するようスケジューラに指示するこ とだけです。これでアプリが実行を開始します。 では、終了処理をお見せしましょう。アプリを一時停止します。たくさんのアプリを起動し ているとしましょう。このデバイスを何時間も使用し、メモリを大量に消費するアプリを使 い始めるとします。"usemem" という小さなコマンド ライン ツールを使って、終了が発生す る状況を作ります。これは、メモリ不足の状態をシミュレートします。 現在 2.1 GB の RAM を割り当てていますが、天気予報アプリ (Wether) は表示されなくなりま した。アプリは終了されました。これは、アプリの正常な終了であり、通常のライフサイク ルの一部です。メモリ不足の状態をシミュレートしただけですが、アプリはシステムによっ てクリーンに終了されました。これまでの内容をまとめます。

プロセスの状態の遷移 実行中の アプリ 一時停止 一時停止 状態の アプリ アプリの 終了 ユーザーがアプリを起動 メモリ不足 復帰 アプリは 5 秒間で 一時停止を処理 終了前に、アプリに通知は行われない 実行中の アプリ 一時停止 一時停止 状態の アプリ アプリの 終了 ユーザーがアプリを起動 メモリ不足 復帰 再開時、アプリには 通知が行われる 天気予報のアプリを起動すると、スプラッシュ スクリーンが表示されます。アプリが起動さ れます。この緑色はコードが実行されていることを示しています。次に、天気予報のアプリ から切り替えました。少しの時間遅れて、アプリは一時停止メッセージを受信しました。一 時停止メッセージを受信してから 5 秒以内にこのイベントを処理します。5 秒以上かかると、 アプリはクラッシュしているとみなされます。一時停止されます。アプリに戻ると、再び実 行中になります。この時点で、アプリは再開イベントを受信できます。このイベントはアプ リが一時停止状態から復帰することを示します。次に、メモリ不足の状況をシミュレートし ました。アプリは終了されます。先に述べたように、アプリはメモリ不足や、ユーザーの切 り替え、システム シャットダウンなど、さまざまな理由で終了されます。この場合、コード は実行されません。一時停止されたアプリの場合、コードはメモリに存在しますが実行はさ れません。もちろん、アプリがフォアグラウンドにある場合は実行されます。 スプラッシュ スクリーン コードが実行される コードは 実行されない アプリは非実行状態

一時停止と再開の登録は簡単 //Suspending イベントを登録し、イベントを受信したら suspendingHandler を呼び出す Windows.UI.WebUI.WebUIApplication.addEventListener("suspending", suspendingHandler); //Suspending イベントを処理し、WinJS sessionState を使用して現在のユーザー セッションを保存 function suspendingHandler(eventArgs) { //一時停止状態に入る } //Resuming イベントを登録し、イベントを受信したら resumingHandler を呼び出す Windows.UI.WebUI.WebUIApplication.addEventListener("resuming", resumingHandler); function resumingHandler() { //再開される。通常、特に処理は行わない 一時停止と再開の登録はとても簡単です。suspending コールバックのイベント リスナーを追 加して、イベント ハンドラーを用意するだけです。一時停止を登録し、コールバックを指定 します。アプリが画面に表示されなくなったら、"suspendingHandler" を呼び出し、 suspendingHandler 関数がコールバックを取得するようにします。このとき、アプリは状態を 保存し、終了の準備をします。これ以降はコードを実行する機会がない可能性もあります。   Windows の周辺機器は非常に多様です。搭載メモリ量がとても多いマシンもあれば、ごくわ ずかなマシンもあります。本当に優れた Metro スタイル アプリを構築しようとするのであれ ば、幅広い種類のデバイスで確実に機能させる必要があります。デバイスによっては、きわ めて頻繁にアプリの終了が発生することになるでしょう。 再開も一時停止とほぼ同様の方法で登録できます。再開用のイベント リスナーを用意します。 再開の addEventListener を呼び出し、コールバックを指定します。resumingHandler 関数をそ こで定義します。 ただし、通常の場合、アプリは既にメモリ内に存在するので、大半のアプリでは resumingHandler を使用する必要はありません。スレッドもスタックもヒープもメモリ内に存 在するので、先ほどの天気予報アプリのように、アプリは瞬時に再開されます。 しかし、Web サービスにデータ バインドされている一覧表のようなものはどうでしょうか。 Web サービスは、ユーザーがアプリを前回使用した後に変更されたデータを公開している可 能性があります。このような場合は再開のタイミングでビューを更新するのがお勧めです。 データ ソースを再作成して、最新のビューをアプリに表示します。この例は JavaScript でお 見せしましたが、XAML または C++ でもほぼ同じ方法で実現できます。

一時停止のしくみ 一時停止状態のアプリは NT カーネルのスケジューリング対象外 CPU、ディスク、ネットワークの消費はゼロ すべてのスレッドが一時停止される アプリはメモリ内に残る システム全体がデッドロック状態に陥るようなクリティカル セ クション内でアプリが一時停止されることがないよう、カーネ ルが管理 アプリはフォアグラウンドに移動されると瞬時に一時停止状態 から復帰 では一時停止の実際の処理をもう少し詳しく見ていきましょう。アプリの一時停止は、NT カーネルのスケジュール対象外となることを意味しています。アプリはメモリ内に残ります が、プロセス内の命令は実行されません。CPU やディスク、ネットワークにも影響を及ぼし ません。ちょうど Visual Studio でアプリのデバッグ時に一時停止ボタンをクリックしたよう な状態です。一時停止ボタンをクリックした場合、すべてのスレッドが存在し、アプリはメ モリ内に存在しますが、実行はされていません。再開すると、アプリの実行が続行されます。 このモデルの利点は、アプリがメモリ内に存在するため、アプリに瞬時に戻ることができる 点です。 ここでのカーネル チームの大きな功績の 1 つは、アプリが一時停止される場合、コードのク リティカル セクション内で一時停止されることがないよう最適化を行ったことです。アプリ の一時停止時に、システム全体が不安定になったり、デッドロック状態に陥ったりすること がないように、カーネルが管理しています。

アプリの起動 プロセスのライフサイクル モデルをより理解いただけたと思います。 では、ライフサイクルの始まりについて少しお話ししましょう。アプリの起動時には何が発 生するでしょうか。

変化するユーザーの要望 さまざまな情報を、 いち早く、少しずつ アプリ間で情報共有 コンテキスト内で検索 Windows 8 の計画を進める中で、私たちはユーザーの要望が変化していることに気付きまし た。これについては昨日 Jensen が詳しく取り上げました。短時間でたくさんの情報を入手し たいという要望は、タイルの誕生につながり、アプリ間での情報共有したいという要望は、 共有をシステムの重要機能とする取り組みにつながっています。ご存知のとおり、検索はき わめてよく使われる機能ですが、それがそのコンテキスト内で実行されること、つまり検索 機能が重要な位置づけであることも非常に重要です。Windows 7 でのアプリの起動方法とは まったく異なったものになっています。 アプリ間で情報共有 コンテキスト内で検索

アプリを開始する方法の変更 [スタート] メニューから起動 タイル、検索、共有などから アクティブ化 Windows 7 では、アイコンをダブルクリックしてアプリを起動します。Windows 8 では、ア プリはコントラクトの結果としてアクティブ化されます。システムには、おそらく 10 を超え るたくさんのコントラクトが存在します。優れたアプリは多くのコントラクトと統合してい ます。今日は起動コントラクト、検索コントラクト、共有コントラクトについてお話ししま す。

コントラクトによるアプリのアクティブ化 kind アプリはコントラクトに よってアクティブ化される 起動、検索、共有など アプリはコントラクト別に 処理を初期化する必要がある コンテキストは提供される 実行中の アプリ Launch shareTarget activated kind Search アプリがコントラクトの結果としてアクティブ化された場合、最も重要なのはそのコントラ クトを実行することです。 アプリが検索のためにアクティブ化された場合は、アプリが実行されたことを確認して、 ユーザーを誘導します。検索のためのアクティブ化であることを知るためには、"kind" という プロパティをチェックします。検索のためのアクティブ化であることがわかったら、検索 UI にユーザーを誘導し、アクティブ化のコンテキストを取得して、検索を実行します。共有に ついてもほぼ同様です。共有の実行、初期化という手順になります。   アプリがアクティブになると、JavaScript と HTML では、activated コールバックを取得します。 このコールバックが発生すると、アクティブ化に関する情報をチェックできます。たとえば "kind" プロパティはアプリがどのような方法でアクティブ化されたかを示します。また、 activated イベントは他にも便利な属性が用意されています。これについては後ほど説明しま す。XAML および C++ のアクティブ化モデルは異なります。XAML では、さまざまなコント ラクトのコールバックを特定の関数で取得します。onSearch 関数のようなものが呼び出され ます。onLaunch 関数や onShare 関数もあります。言語によって若干異なりますが、概念は同 じで "アクティブ化" と呼ばれます。

デモ コントラクトによるアプリのアクティブ化 アプリのアクティブ化の例をいくつか順を追って見ていきましょう。 メモリを開放します。   最初にチャーム バーを表示し、「Windows 8」と入力して Tweet@rama で検索します。最初 にスプラッシュ スクリーンが表示されます。これについてはすぐに説明しますが、続いて Tweet@rama アプリの検索ビューがすぐに表示されます。Tweet@rama アプリはアクティブ化 されたことを認識し、さらに検索のためのアクティブ化であることも認識します。提供され たコンテキストを使って、ユーザーを検索画面に誘導し、最初の画面を表示し、検索を実行 しました。 では、次に共有のためのアクティブ化について説明します。Socialite アプリに移動し、Photos でアルバムを選択し、Share に移動して Tweet@rama と共有します。ご覧のように Tweet@rama アプリはこのフライアウト ウィンドウでアクティブ化され、2 つのアプリ間の 通信が可能になりました。2 つのアプリ間でコンテキスト、この場合この写真がある場所の URI が渡されました。

アクティブ化処理中のスプラッシュ スクリーン システムが提供するスプラッシュ スクリーンによって、一貫性のある アプリ切り替えが実現される Windows がアプリを起動している ときに表示 表示されているのは、アクティブ化処理が行われている間 開発者は、アプリ マニフェストで 色と画像を指定 アプリがアクティブ化処理の 15 秒間内にウィンドウを表示できない場合、そのアプリは終了される スプラッシュ スクリーンはこれまでも何回か表示されていました。スプラッシュ スクリーン はアプリの一貫した開始処理で、アプリが起動中に表示されます。つまり Windows がアプリ を起動している時間です。短い時間ですが、スプラッシュ スクリーンが Windows によって表 示されます。この画面は完全に Windows によって制御されます。数ミリ秒の間ですが、スプ ラッシュ スクリーンが表示されている間に、アプリはアクティブ化処理を実行します。   スプラッシュ スクリーンはロゴと色の 2 つの要素から成ります。両方ともアプリ マニフェス トで指定します。Visual Studio で右側に表示されるリスト ビューまたはツリー ビューからア プリ マニフェスト エディターを選択すると、マニフェストがきれいな UI で表示されます。 色とロゴを指定すると、それらがアプリのアクティブ化時に使用されます。 アプリ起動時にユーザーを長時間待たせるのは避けるべきです。アプリが 15 秒以内に完全に アクティブにならなかった場合、Windows はアプリがクラッシュしたとみなし、ユーザーに もアプリがクラッシュしたように見えます。

延長スプラッシュ スクリーン 読み込みに時間がかかる アプリもある アプリの最初の表示内容を スプラッシュ スクリーンと 同一にする スプラッシュ スクリーンを 手動で表示するには、 Splash Screen API を使用 "読み込み時間はそれではちょっと短すぎる" と思われるかもしれません。読み込み時間がか かる処理としてよく挙げられるのは、データ ソースの処理です。   アプリ起動時に情報を取得またはチェックしたい Web サービスがあるとします。その I/O の 長さは状況によって変わります。3G ネットワークで接続している場合は 15 秒以上かかるこ ともあります。そのような場合は、延長スプラッシュ スクリーンの使用をお勧めします。 延長スプラッシュ スクリーンは、基本的にはスプラッシュ スクリーンの一種ですが、これは アプリが最初に表示する画面です。Splash Screen API を呼び出して、ロゴの配置場所と使用す る色を決定します。これにより、システムによって表示されるスプラッシュ スクリーンから 延長スプラッシュ スクリーンにスムーズに移行できます。これを実現しているアプリの例が 先ほどの天気予報のアプリです。テキストとアニメーションを使用した進行状況インジケー ターがあり、これはシステムではなくアプリによって制御されています。これは延長スプ ラッシュ スクリーンを使用することにより実現されていますが、Splash Screen API を使って いるので、画面はスムーズに移行します。詳しい内容については、Splash Screen SDK をご覧 になることをお勧めします。 Splash Screen SDK のサンプルを参照してください。

タイル起動によるアクティブ化 アプリの実行 activated イベント スプラッシュ スクリーンの表示 launch ユーザーが タイルをタップ launch 以上を 1 つにまとめます。順に見ていきましょう。アプリをタイルから起動するには、 Tweet@rama タイルをタップします。kind プロパティがタイル起動からのアクティブ化を表 す Launch に設定されます。activated コールバックが発生し、引数の eventArgs が渡され、ア クティブ化の種類をチェックできるようになります。このコールバック発生時にスプラッ シュ スクリーンが表示されます。アプリを初期化し指定されたコントラクトを実行します。   1 つ前のスライドで言い忘れたのですが、JavaScript と HTML の場合スプラッシュ スクリーン はアクティブ化処理が完了すると閉じられます。コールバックから戻るだけで、必要な処理 は完了です。XAML アプリまたは C++ アプリを構築している場合は、ウィンドウを表示する 必要があります。ウィンドウを表示する明示的な呼び出しが、アクティブ化終了の目印とな ります。赤線は、ウィンドウの表示、または activated コールバックの完了によって、アク ティブ化処理が完了したことを表しています。アプリが実行されます。 eventArgs.kind スプラッシュ スクリーンの表示

アクティブ化 Windows.UI.WebUI.WebUIApplication.addEventListener("activated", activatedHandler); function activatedHandler(eventArgs) { //タイルからのアクティブ化の初期化ロジック if (eventArgs.kind == Windows.ApplicationModel.Activation.ActivationKind.launch) { } //共有からのアクティブ化の初期化ロジック else if (eventArgs.kind == Windows.ApplicationModel.Activation.ActivationKind.shareTarget) { アクティブ化の登録は簡単です。activated イベントのイベント リスナーを追加し、コール バックを指定するだけです。アクティブ化の eventArgs については先に説明しました。チェッ クすべきプロパティの 1 つが kind プロパティです。kind プロパティをチェックして、アク ティブ化の種類を判別します。この最初の if ステートメントで起動アクティブ化かどうかを チェックします。起動アクティブ化の場合と共有アクティブ化の場合で別の処理を実行しま す。共有アクティブ化の処理は 2 つ目のブロックの "else if" です。   eventArgs には他にも興味深いプロパティがあります。その 1 つが PreviousExecutionState で、 前回使用時にアプリがクラッシュしたかどうかわかります。これについては後ほどお話しし ます。

アプリを常に実行しているように見せるためのヒント これまでプロセスの新しいライフサイクル モデルについて説明してきました。また、アプリ の起動、つまりライフサイクルの開始についてお話ししました。   Windows 8 ではアプリが常に実行中というわけではないので、実行しているように見せる方 法のヒントをいくつかご紹介したいと思います。

実際には実行されてなくても 実行中であるように見えるアプリが 洗練されたアプリです。 Windows 8 の洗練されたアプリは、実際は実行中ではないのに実行中であるかのように見え ます。    先にも述べたとおり、デバイスは非常に多様です。搭載メモリが少ないデバイスではアプリ の終了がより頻繁に発生するので、安定したユーザー エクスペリエンスを常に提供する必要 があります。

ユーザー データをこまめに保存 作業内容は消失 作業内容を保存 アプリの状態を常に保存し復元できるアプリが望ましい 第一に、ユーザー データをこまめに保存してください。ユーザーがアプリを使い終えるのを 待たず、アプリを使用している間にユーザー データを保存してください。左にノート アプリ の例があります。私はこれを使用して BUILD の開始前に発表の準備をしていました。別のア プリに切り替えて他の作業をしていたのですが、アプリが終了されていても戻ると常にデー タが保持されていました。   データが消え、To-do リストが消えてしまった場合を想像してください。非常に困りますね。 ユーザーをイライラさせる原因です。これまでの発想を変え、こまめに保存できるようにア プリを再設計してください。優れたアプリは、常に状態を保存し復元できます。 アプリの状態を常に保存し復元できるアプリが望ましい

アプリ データの保存 アプリの使用中にアプリ データをこまめに保存 アプリ データは、 アプリ独自のカスタムなデータ構造 Windows.Storage.ApplicationData 必要に応じてファイル I/O を使用 アプリ データの保存もきわめて重要です。John Sheehan が担当のセッションでこの話題をよ り詳しく取り上げる予定です。アプリ データとは各自の設定情報です。Tweet@rama アプリ の場合は、ユーザー名とパスワードや、生成された認証トークンです。これらをアプリ デー タに保存すると、アプリと一緒にローミングできます。ユーザーが接続済みアカウントを 持っている場合は、各種デバイスからログインでき、設定が保持されます。Jensen が昨日述 べたように、ユーザーに同じようなことを何回も繰り返させる必要はありません。   この機能を実装するには、Windows.Storage.ApplicationData を活用します。これはファイル I/O のラッパーにすぎません。ファイル I/O を使用しても構いませんが、ローミングの利点が 必ずしも得られるわけではありません。

ユーザー セッション状態の保存と復元 単にユーザー セッション メタデータを保存し、復元する HTML/JS XAML および C++ ユーザーがアプリを使用している最中に HTML/JS WinJS.Application.sessionState オブジェクトを使用 プロパティ バッグは一時停止時に自動的にシリアル化されて ディスクへ保存 アクティブ化時にディスクからプロパティ バッグを再読み込み アプリがクラッシュした場合は状態を再読み込みしない XAML および C++ SuspensionManager クラス (SDK サンプルを参照) は HTML/JS の sessionState と同等の機能を提供 セッション状態についても明確にしたいと思います。セッション状態とは、ある時点のユー ザーのアプリの状態を言います。テキスト ボックスに入力途中の状態、チェックボックスを オンにした状態、ウィザードの 4 ページ目に進んだ状態などがセッションです。   アプリが一時停止されたら、ユーザーの状態をチェック ポイントとして保存し、そこに戻れ るようにします。これにはいくつかの方法があります。もちろんファイル I/O を使用できま す。WinJS ツールキットにはsessionStateという便利なオブジェクトがあります。これの良い 点は、単なる JavaScript オブジェクトであるということです。ここにはキーと値を設定できま す。アプリが一時停止されるとこのオブジェクトは自動的にシリアル化されます。 アプリが再度アクティブ化されると、JavaScript オブジェクトが自動的に復元されます。アプ リがクラッシュした場合はデータを復元しない方が賢明です。XAML と C++ のクラス "SuspensionManager" も基本的に同じ処理を行います。

アプリがクラッシュしたら、再起動 アプリのフリーズは当然避けたいが… 以下のような場合には突然終了される可能性がある 読み込み時間が長すぎる 一時停止するのに時間がかかりすぎる 入力メッセージの処理が停止 (UI スレッドの I/O がブロックされる) タスク マネージャー ユーザーをホームに戻し、保存されているユーザー セッション 状態は無視 アクティブ化イベント引数で previousExecutionState が 提供される クラッシュについてお話ししました。クラッシュと言っても、Windows 8 では、アプリはさ まざまな理由でクラッシュします。アプリが停止状態に陥るのをユーザーが嫌うことは私達 も十分に承知しています。ユーザーは動作に一貫性のないアプリを嫌います。バグは当然修 正しなければなりませんが、Windows 8 ではアプリはさまざまな理由でクラッシュします。 その 1 つが長すぎる読み込み時間です。15 秒以内にウィンドウを表示しなければならないと 先ほど述べましたが、アクティブ化の処理は短時間で完了するようにします。15 秒以上かか る場合は延長スプラッシュ スクリーンを使用して問題を回避します。一時停止するのに 5 秒 以上かかるとアプリは終了され、ユーザーにはクラッシュしたように見えます。また、あっ てはならないことですが、UI スレッドの I/O をブロックしてメッセージの配信をブロックし てしまうと、UI はシステムによってクラッシュされます。   ユーザーはいつでもタスク マネージャーからアプリを終了できますが、これはユーザーに とってはクラッシュと同じです。こうした事態が発生したら、ユーザーをホームに戻します。 クラッシュの発生は、previousExecutionState というプロパティを調べることによってわかり ます。このプロパティは、アクティブ化の処理中に eventArgs から取得できる変数です。

状態の保存と復元のベスト プラクティス シナリオ 推奨される処理 ユーザーがアプリを使用している ユーザー データをこまめに保存 別のアプリに切り替え (一時停止する) 現在のユーザーの状態 (開いている画面など) を保存 非実行状態のアプリをユーザーが 起動 (アクティブ化) ユーザー セッションを復元して、 元の状態を完全に再現 一時停止状態のアプリをユーザーが起動 (再開する) 処理は不要 以上をまとめると、ベスト プラクティスとして、ユーザーがアプリを使用中にデータをこま めに保存することをお勧めします。ユーザーがアプリから離れたら、一時停止コールバック でユーザーのセッション状態を保存します。セッション状態やファイル I/O を使用して、 ユーザーの状態を保存してください。   アプリがアクティブ化されたら、前回使用時の状態を復元します。こうすることで、ずっと 実行されていたかのように見せることができます。一般的に、アプリが一時停止状態から再 開するときに処理は必要ありません。ただし、データ ビューを更新したい場合などは、再開 イベントを取得して処理を行うことをお勧めします。

デモ 状態の保存と復元 では少し本腰を入れて、状態の保存をアプリに追加してみましょう。   Tweet@rama アプリを使います。この Tweet@rama アプリはテスト バージョンです。再ログインします。 Tweet@rama アプリが表示されました。左や右にパンできます。ツイートも入力できます。「BUILD で デモをするのは本当に楽しい～」。間違えました。見なかったことにしておいてください。 たとえば、アプリを使用している途中で、突然、別の作業を頼まれることがあります。メールをチェッ クすることもありますし、別のアプリを使用したい場合もあります。では、やってみましょう。別のア プリ、つまり今まで使用していた Tweet@rama 以外のアプリに切り替えます。しばらくすると、使用し ていた Tweet@rama アプリは一時停止状態になります。もう一度試してみます。 エクスプローラーを再起動します。Tweet@rama に戻ってから他のアプリに切り替えると、Tweet@rama アプリは一時停止されるはずです。されない場合は、デモの神のご加護に恵まれなかったということで す。一時停止されました。デモの神は見捨てずにいてくれました。 アプリが一時停止されたので、先ほどのようなメモリ不足の状態を作ってみましょう。Tweet@rama ア プリは終了されます。終了されました。次にどうするかは想像がつくと思いますが、アプリに戻ります。 先ほどの書きかけの愉快なツイートや前回使用時の状態は復元されません。また最初からやり直さなけ ればなりません。 既に指摘したように、これはユーザーにとっては好ましくないエクスペリエンスです。不完全であるよ うな印象を与えてしまい、洗練されているとはとても言えません。ユーザーが前回使用した状態が常に 復元されるのが、本当に優れたアプリです。状態を保存する機能をこのアプリに追加してみましょう。 とても簡単にできるはずです。 まずこれをメモリから消去して、アンインストールします。このソース コードはこちらです。まず一時 停止を登録します。一時停止用のイベント リスナーを追加します。ここにドラッグします。いくつか前 のスライドで suspendingHandler にコールバックを指定したときのコードと似ています。アプリが一時 停止されると、suspendingHandler が呼び出されます。

デモ 状態の保存と復元 (続き) この "suspendingHandler" 関数をドラッグし、その内部で "saveState" を実行します。"saveState" という関 数を簡単に定義します。本当はもう少し複雑なのですが。新しい JavaScript オブジェクトを作成し、 ページの mainGrid 要素から scrollLeft プロパティを取得します。これはスクロールしたピクセル数です。 この値をこの JavaScript オブジェクトの "currentScrollPosition" に格納します。続いて、書きかけのツイー トのテキスト ボックスの値を取得し、同じくこの JavaScript オブジェクトに格納します。   最後の行でこれをファイルに書き出します。最初に JSON.stringify を呼び出して JavaScript オブジェクト を文字列にシリアル化し、ディスクに書き込みます。以上がセッション状態の基本的な処理で、WinJS セッション状態オブジェクトも同様なので、これを使用することもお勧めします。ここでは実際にどの ような処理をしているかをお見せしました。 では、"loadState" という関数に取り掛かりましょう。この関数をアプリの初期化時に呼び出します。も う 1 つ状態オブジェクトを作成します。新しい JavaScript オブジェクトを作成し、"_session.json" ファイ ルから読み込みます。readText API の非同期コールバックで、再構築します。ディスクから読み込んだ 文字列を JavaScript オブジェクトに変換して状態オブジェクトに代入します。現在のスクロール位置が null かどうかを確かめます。null でない場合は、mainGrid 要素の scrollLeft プロパティを更新して前回の 位置を指定します。さらに、このオブジェクトで書きかけのツイートがあるかどうかをチェックします。 null でない場合は、テキスト ボックスの値をこのプロパティ値で更新します。 この loadState 関数を初期化コード内で呼び出します。ビルドして、展開します。では、Tweet@rama に 戻ります。アンインストールして再展開したので、データはすべてなくなっています。再読み込みしな くてはなりません。再度ログインします。ツイートを途中まで書いて、半分程度スクロールした状態に します。アプリをバックグラウンドに切り替えると、Tweet@rama は一時停止されます。 アプリが一時停止されました。メモリ不足の状況をシミュレートしましょう。有効期間マネージャーに よってアプリが終了されます。アプリを再起動すると、以前の状態が復元されます。テキスト ボックス には書きかけのテキストが表示されます。 ご覧のように、まるで初めて使用するかのようにアプリが再表示されるより、ユーザーにとってずっと 優れたエクスペリエンスが提供されます。

ライブ タイルを使って 常に実行中に見せる 状態の保存について説明しました。次に、アプリを常に実行中であるように見せるもう 1 つ の手法であるライブ タイルの使用について説明していきます。

ライブ タイルを使って実行中に見せる タイルを利用して、ユーザーがアプリを使用していない ときも価値を提供 何らかの処理が行われているように見せることで、 ユーザーがアプリに戻るのを促す効果 スタート画面上のタイルを更新する 2 つの方法 ライブ タイルを使うと、ユーザーがアプリを使用していないときも価値を提供できます。 ユーザーは、アプリを使用していなくても何らかの処理が行われているように感じます。   タイルは通知を使用して機能します。タイルの更新は、テンプレートを基にした少量の XML で行われます。3 種類のテンプレートがご覧いただけると思います。これらのテンプレート は、基本的にはいくつかの画像の参照と文字列で構成されます。この XML 内部では、たとえ ば、テンプレート 1 を指定します。テンプレート 1 には 2 つの文字列と 1 つの画像がありま す。参照する画像には、インターネット経由で取得するクラウド上の画像や、パッケージ内 のローカル画像を使用できます。

Local Notification API を呼び出す タイルのローカル更新 アプリの実行中にローカル通知を使用してタイルを更新 アプリの状態を反映するのに最適 ダウンロードした画像 今開いている本のページ タイルを更新する方法は 2 つあります。1 つはローカルでの更新で、"ローカル通知" と呼ば れます。クラウド サービスを使用しないアプリや、ローカル専用アプリに最適です。ゲーム ならば前回のスコアを保存できます。アプリでダウンロードした画像を閲覧できる場合は、 たとえば画像を数枚スライド表示した状態など、最後に実行した状態でタイルに表示できま す。電子書籍の場合は、ユーザーが読んでいる箇所やその章の見出しを表示できます。   ここで注意すべき点は、このような処理はコードが実行中の場合のみ可能だということです。 ユーザーがアプリを使用している間に処理を実行するか、アプリが一時停止されるときに処 理を呼び出します。 実行中のアプリ Local Notification API を呼び出す

Windows プッシュ通知 サービス (WNS) プッシュ通知を使用したライブ タイル アプリ クラウド サービス アプリが実行中でなくても タイルを更新できる! プッシュ通知を使用して、 スタート画面のタイルを リモート更新可能 最新コンテンツをユーザーに 提供するのに最適 詳細情報: [396] Using tiles and notifications HTTP POST Windows プッシュ通知 サービス (WNS) 通知を配信 では、アプリが実行中でない場合はどうすればよいでしょうか。その場合はプッシュ通知を 使用します。プッシュ通知はタイルの更新に最適な手段です。これは、ユーザーがアプリを 使用してないときでも、またアプリが実行中でないときでも、何らかの処理が行われている ように見せることができます。これは、新たに利用できるようになった最新のコンテンツを ユーザーに提供するのに適しています。   アプリを起動し、通知 API を呼び出して "チャネル" を受信します。チャネルはユーザーのデ バイスとアカウントを指す一意な識別子です。チャネルは、基本的には単なる長い URL です が、これをクラウド サービスに送信します。ユーザーと関連付け、アプリで認証し、これを 保管します。ユーザーに提供したい新しいデータがある場合は、先ほど説明した同じタイル XML を使用して、この URI に対して HTTP POST を実行します。メッセージは Windows 通知 サービスに送信されます。この Windows プッシュ通知サービスは WNS とも呼ばれます。通 知はユーザーのスタート画面に表示され、アプリが実行状態でなくても最新の情報が表示さ れます。つまり、クラウド サービスがタイルを最新の状態に更新します。 詳しく説明すると長くなるのでこれ以上は深く立ち入りません。タイルと通知の使用につい ての別のセッションをご覧ください。Jensen がその全容をわかりやすく解説してくれるはず です。

その他の アプリ実行方法 プロセスのライフサイクル モデルについて説明しました。ライフサイクルの始まりであるア プリの起動について、また、アプリを常に実行中であるように見せるいくつかの方法につい て説明しました。では次に、アプリをバックグラウンドで実行する方法をいくつか説明しま しょう。

バックグラウンド オーディオの再生 アプリはバックグラウンドでオーディオを再生できる 開発者は、アプリ マニフェストでバックグラウンド オーディオを指定 オーディオ ストリームはそれぞれ特定の型を持つ (通信、メディア、ゲーム) 一度に 1 つのオーディオ ストリームの 型を再生可能 詳細情報: [778] Media fundamentals of a communications app 最初にバックグラウンド メディアを使用した方法です。ユーザーが楽しめるように BGM を 流すアプリはいくつかあります。バックグラウンド オーディオは簡単に再生する方法があり ます。マニフェストの Background Tasks セクションでバックグラウンド オーディオの列挙型 を指定します。オーディオ API を呼び出して、ストリーム型の種類、再生するオーディオの 種類を指定すると、アプリはバックグラウンドでオーディオを再生できます。同時再生可能 なオーディオの数には制限があります。ストリームの種類にもよりますが、3 つ程度のはず です。これに関する詳しい情報については、Johnny が担当するセッション「Media Fundamentals of a Communication App」をご覧ください。

バックグラウンドでの アップロードとダウンロード BackgroundTransfer API を使用すると、HTTP経由でのデータのアップロードまたはダウンロードがバックグラウンドで実行可能 フォアグラウンドのときに開始したアップロードまたはダウンロードを、一時停止中も継続できる 詳細情報: [581] Making apps social and connected with HTTP services バックグラウンドでアップロードやダウンロードを実行したい場合もあるでしょう。これに は BackgroundTransfer API を使用します。BackgroundTransfer API を使うと、HTTP 経由での アップロードやダウンロードを開始し、アプリの一時停止中もその処理を続行することがで きます。アプリは実行状態にならず、一時停止状態のままで、アップロードやダウンロード が行われます。ユーザーがアプリに戻ったときに、ファイルがダウンロードされていれば、 それを使用することができます。   これに関する詳細情報については、「Making Apps Social and Connected with HTTP Services」 というセッションをぜひご聴講ください。Suhail が素晴らしい説明をするはずです。

ロック画面アプリ バックグラウンドで実行可能なアプリ リアルタイム通信アプリ向け (メール、IM、VoIP) バックグラウンドで TCP ソケットを保持 定期的にコードを実行 システム イベント (ユーザー ログイン) に応答する形でコードを実行 最後に、ロック画面アプリを取り上げます。ロック画面アプリは、デバイスを使用中でない 場合にも通知を行うことができるアプリです。こうしたアプリは、バックグラウンドでの実 行の自由度が高く、電子メール、IM、VoIP などのリアルタイム通信アプリに適しています。   ロック画面アプリの利点の 1 つは、バックグラウンドでの TCP ソケット接続を維持できるこ とです。例を挙げると、Exchange Server や IM サーフェイスなどへのソケット接続の維持で す。また、コードは定期的に実行できます。たとえば、15 分ごとにコードをバックグラウン ドで実行するということが可能です。これは、電子メール アプリに適しており、15 分ごとに POP3 メール サービスを使用してメールをチェックできます。POP3 メール チェックを実行 し、ロック画面に表示されるバッジを更新するか、新着メールを知らせるトースト通知を表 示します。 また、ロック画面は、ユーザーが Windows にログインしたときにシステムがコードを実行で きる唯一の機会です。たとえば、IM サービスのログインや、ログイン時での最新の未読メー ル数を表示するのに使用できます。 金曜日のセッションで、Raghu と Kamal がこの話題を集中的に説明する予定です。スライド の最後でも紹介しています。

まとめ 以上すべての内容をまとめます。

アクティブ化のベスト プラクティス すばやくアクティブ化する アプリを初期化する 処理は必要になるまで、できるだけ先に延ばす ユーザーが最後に使用した状態を復元する 15 秒以上必要な場合は、延長スプラッシュ スクリーンを表示する アクティブ化のベスト プラクティスです。最も重要なのは、すばやくアクティブ化すること です。15 秒しかありません。ユーザーの前回使用時の状態を復元し、15 秒以上かかる場合は 延長スプラッシュ スクリーンを使用します。

一時停止のベスト プラクティス 状態をすばやく (5 秒以内に) 保存する 終了されることを前提に、ユーザー セッション データを 保存する アプリのタイルを更新する 共有リソース (ファイル、デバイス、ネットワークなど) への 排他的アクセスを解放する 一時停止前から、アプリ データをこまめに保存する アプリを一時停止するときには、必ず、状態が保存されているようにします。ユーザー デー タの保存は、一時停止時まで待つ必要はありません。一時停止処理の時間は 5 秒しかありま せん。データ ファイルがあって、独自のデータ構造体をディスクにシリアル化していると、 5 秒以上かかる場合もあります。5 秒以上かかるのであれば、こうした処理を一時停止時に行 うことはお勧めしません。ユーザー データを消失させないためには、ユーザーがアプリを使 用している途中でユーザー データを保存します。ユーザーがアプリを使用している間に、タ イルを更新し、状態をこまめに保存するようにしてください。とは言っても、一時停止は セッション状態のチェック ポイントとして良い機会です。アプリが実行中であるうちに、 ユーザーの状態のチェックポイントを設定します。一時停止は、アプリが停止される前に コードを実行する最後の機会です。

まとめ Windows アプリの実行方法に関する新しい考え方 アプリを常に最新の状態にするには、 バックグラウンドにあるアプリは、一時停止され、 最終的には終了される アプリを常に最新の状態にするには、 状態を保存/復元 ライブ タイルの活用 以上がこれまでのすべての説明のまとめです。Windows 8 ではプロセスのライフサイクルに ついて新しい考え方が導入されています。アプリは、バックグラウンドに置かれると一時停 止され、最終的には終了されます。状態の保存および復元、ライブ タイルの使用を通じてア プリを常に最新の状態に、また実行中であるように見せるためのベスト プラクティスがいく つかあります。

関連セッション [APP-162T] Building high performance Metro style apps using HTML5 [APP-737T] Metro style apps using XAML: what you need to know [PLAT-475T] Create experiences that span devices [APP-396T] Using tiles and notifications [SAC-963H] SMB2 in a continuously available file server [PLAT-581T] Making apps social and connected with HTTP services [APP-405T] Share: your app powers the Windows 8 share experience [APP-406T] Search: integrating into the Windows 8 search experience [PLAT-778T] Media fundamentals of a communications app [APP-410T] Real time communication: keep your Metro style app connected whether it is running or suspended 関連するセッションをいくつか紹介します。私と私のチームがこちらで皆様のご質問にお答 えします。その他のセッションもぜひお楽しみください。

リンク アプリのライフサイクル (英語) アプリをアクティブ化する方法 (英語) アプリを一時停止する方法 (英語) アプリを再開する方法 (英語) WNS と Live Connect のアプリ管理サイトでプッシュ通知の 使用を始められます。 https://manage.dev.live.com/build バックグラウンド タスクの概要 (英語)

その他の参照リソースとドキュメント SDK サンプル アクティブ化と有効期間 スプラッシュ スクリーン タイルと通知 共有 検索

thank you Feedback and questions http://forums.dev.windows.com Session feedback http://bldw.in/SessionFeedback

2017/3/4 © 2011 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION. © 2011 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.