Windows 8 アプリ開発者ブログ

promise の概要 (JavaScript による Windows ストアアプリ向け)

Windows 8 Team — Wed, 26 Jun 2013 15:53:52 GMT

Windows ストアアプリを JavaScript で記述する場合、非同期 API を含む処理を記述しようとすると、その種類にかかわらずすぐに promise (英語) と呼ばれるコンストラクターに遭遇します。間もなく、連続する非同期操作で自然にプロミスのチェーンを使うようになります。

また開発作業の中では、実際にどのような処理が行われているか完全には理解できないような promise の使用方法に出会うことも珍しくありません。そうした例が、HTML ListView のパフォーマンス最適化のサンプル (英語) にある、ListView コントロールのアイテムレンダリング関数の最適化です。これに関する記事も今後公開する予定ですが、//build 2012 で Josh Williams 氏が説明した WinJS の Deep Dive (英語) も参考になります (多少変更されています)。

list.reduce(function callback (prev, item, i) {
    var result = doOperationAsync(item);
    return WinJS.Promise.join({ prev: prev, result: result}).then(function (v) {
        console.log(i + ", item: " + item+ ", " + v.result);
    });
})

このスニペットでは、プロミスを結合して非同期並行操作を実行し、その結果を list の順序に従って連続的に提供しています。このコードを見て何をしているかがすぐに理解できる方は、この記事全体を飛ばしていただいて結構です。そうでない方は、promise の実際の動作と JavaScript 用 Windows ライブラリ (WinJS) での表記方法を詳しく見ていき、これらのパターンを理解できるようになりましょう。

promise とは、"約束" によって関係が構築されること

まずは、promise はコードコンストラクターまたは呼び出し規約に過ぎないという根本的な真実を押さえましょう。つまり promise は非同期操作に対する継承関係を持たないため、この点ではとても便利です。promise は、将来のある時点で利用できる値、または既に利用できる値を表したオブジェクトに過ぎません。そのため、promise (約束) の使われ方は、私たちがこの言葉を日常生活で使う方法とまったく同じになります。"12 個のドーナッツを渡す約束" と言えば、私が今すぐドーナッツを 12 個持っている必要はありません。これは、将来のいつかの時点でドーナッツを入手するという意志があるという意味になります。入手したら、それらを届けます。

2 つのエージェント間に関係があることを示しています。2 つのエージェントとは、品物を届けることを約束したオリジネーターと、約束の対象者であり品物の受領者であるコンシューマーです。オリジネーターが品物を入手する方法は、オリジネーターに任されます。同様に、コンシューマーは、promise 自体と届いた品物を好きなように活用できます。たとえば、他のコンシューマーと promise を共有することもできます。

オリジネーターとコンシューマーの間の関係には "作成 (creation)" と "履行 (fulfillment)" という 2 つの段階があります。このすべてのしくみは以下の図で説明できます。

図のフローを追っていくと、2 つの段階を持つ promise が非同期操作の提供と適切に連携できる理由を理解できます。重要な部分は、要求の確約 (promise) を受け取ったコンシューマーは、待機 (同期) せずにそれまでの処理を続行 (非同期) できるという点です。これは、コンシューマーが promise の履行を待ちながら、別の要求への応答など別の処理を実行できることを意味します。これは非同期 API の根本的な目的そのものです。既に品物を入手できる場合は promise がすぐに履行されるので、全体が同期呼び出し規約の一種に相当することになります。

もちろん、この関係の場合、考慮が必要なことは多少増えます。日常生活では、いくつかの約束を引き受け、自分に対してもいくつかの約束をしてもらいます。これらの約束の多くは果たされますが、多くの約束が果たされないこともまた現実です。注文したピザは、なんらかのアクシデントがあれば届けられません。日常生活でも非同期プログラミングにおいても、破られた約束は破られたものとして受け入れなければなりません。

これについて promise の関係で考慮すべきことは、1 つは、"ごめんなさい。この promise を履行できませんでした" というメッセージをオリジネーターがなんらかの方法で伝える必要があり、また、約束が破られたことをコンシューマーが何らかの方法で知る必要があること、2 つ目は、コンシューマーが promise の履行をいつでも気長に待てるとは限らないこと (このため、promise の履行の進行をオリジネーターが追跡できる場合、その情報を受け取る方法がコンシューマーにも必要です)、3 つ目は、コンシューマーは注文をキャンセルして、品物が不要になったことをオリジネーターに伝えてもかまわないことです。

これらの要件を追加すると、完全な関係図ができあがります。

では、この関係がコードではどのように表現されるかを見ていきましょう。

promise コンストラクターと promise のチェーン

promise については非常に多くの異なる提案がなされ、仕様が発表されています。Windows と WinJS が採用している Common JS/Promises A (英語) と呼ばれる仕様では、promise とは、将来提供する値を表現するためにオリジネーターが返すものであり、then と呼ばれる関数を持つオブジェクトであるとしています。コンシューマーは、then を呼び出すことによって promise の履行にサブスクライブします (Windows の promise は、同様の関数として done もサポートしています。promise のチェーンで使用されるこの関数については、後ほど簡単に説明します)。

この関数に対して、コンシューマーは最大 3 つのオプションの関数を以下の順序で渡すことができます。

completed ハンドラー: オリジネーターは promise された値が利用可能になった場合にこの関数を呼び出します。また、この値が既に利用可能な場合、then からすぐに (同期的に) completed ハンドラーが呼び出されます。
error ハンドラー (オプション): promise された値を取得できなかった場合に呼び出されます。あらゆる promise では、error ハンドラーが呼び出された場合 completed ハンドラーはいかなる場合も呼び出されません。
progress ハンドラー (オプション): 中間結果と共に定期的に呼び出されます (操作がサポートしている場合。WinRT では、この API に IAsync[Action | Operation]WithProgress の戻り値がある場合はサポートしており、IAsync[Action | Operation] の場合はサポートしていません)。

error ハンドラーだけをアタッチし completed ハンドラーをアタッチしない場合は、これらの引数に null を渡すことができます。

この関係では、コンシューマーは then を複数呼び出すことによって、同じ promise に任意の数の promise をサグスクライブすることができます。さらに promise を、重要コンテンツに対して then を呼び出す別のコンシューマーと共有することもできます。この処理は完全にサポートされています。

これは、promise が、受け取るすべてのハンドラーのリストを管理し、適切なタイミングで呼び出す必要があるということです。さらに promise は、完全な関係の図で説明したキャンセルにも対応する必要があります。

その他 Promises A 仕様には、then メソッド自身が promise を返すという要件も規定しています。この 2 つ目の promise は、最初の promise.then に付与された completed ハンドラーが返され、この 2 つ目の promise の結果として戻り値が提供された時点で履行されます。以下のコードスニペットをご確認ください。

var promise1 = someOperationAsync();
var promise2 = promise1.then(function completedHandler1 (result1) { return 7103; } );
promise2.then(function completedHandler2 (result2) { });

ここでは、someOperationAsync が開始され promise1 が返されることで実行が連結されます。操作の実行中に promise1.then を呼び出すと、その直後に promise2 が返されます。非同期操作の結果が既に利用可能な場合を除き、completedHandler1 は呼び出されないことに注意してください。ここでは引き続き待機している状態と仮定します。すぐに promise2.then の呼び出しに移りますが、この時点でも completedHandler2 は呼び出されません。

しばらくして someOperationAsync がたとえば値 14618 にて完了します。これで promise1 が履行されるため、この値で completedHandler1 を呼び出し、result1 が 14618 になります。今度は completedHandler1 が実行され、値 7103 を返します。この時点で promise2 が履行され、completedHandler2 が (7103 に等しい) result2 で呼び出されます。

では、completed ハンドラーが別の promise を返した場合について説明します。この場合は処理が多少変わります。上記のコードの completedHandler1 が以下のような promise を返した場合を考えてみます。

var promise2 = promise1.then(function completedHandler1 (result1) {
    var promise2a = anotherOperationAsync();
    return promise2a;
});

この場合、completedHandler2 の result2 は promise2a そのものではなく、promise2a が履行された値です。つまり、completed ハンドラーが promise を返すため、promise1.then から返される promise2 は、promise2a の結果によって履行されます。

連続する非同期操作の連結を可能にしているのは、チェーンに含まれる各操作の結果が次の操作に適用されるという、まさにこの特性です。中間変数や名前付きハンドラーがない場合に多く見られるのは、以下のようなパターンの promise チェーンです。

operation1().then(function (result1) {
    return operation2(result1)
}).then(function (result2) {
    return operation3(result2);
}).then(function (result3) {
    return operation4(result3);
}).then(function (result4) {
    return operation5(result4)
}).then(function (result5) {
    //And so on
});

各 completed ハンドラーは、それぞれが受け取る結果を使用してさらに何かを実行する場合がほとんどですが、あらゆるチェーンの基本的な構造はこのようになります。また、ここにあるすべての then メソッドは、順番に実行され、特定の completed ハンドラーの保存と別の promise を返すという処理を行っています。このため、このコードの末尾に到達するまでに開始されているのは operation1 だけで、completed ハンドラーは 1 つも呼び出されていません。しかし、すべての then 呼び出しからの中間 promise が多数作成され、相互に関連付けられることによって、チェーンが管理され連続的な操作が進行しています。

後続の操作を直前の completed ハンドラー内に入れ子にすることで、同様のシーケンスを実現できる点に注目してください。この場合はすべての return ステートメントを使いません。ただし、このような入れ子処理は、特に then への呼び出しの 1 つひとつに progress ハンドラーと error ハンドラーを追加するような場合、インデントが非常に複雑になります。

また、WinJS の promise の機能では、チェーンのあらゆる部分で発生したエラーは、チェーンの末尾まで自動で伝播します。これは、then の最後の呼び出しに error ハンドラーを 1 つアタッチするだけで、すべてのレベルにハンドラーを設定する必要がなくなるということです。ただし、チェーンの最後のリンクが then への呼び出しである場合、このような要求は、さまざまな理由によって消去されてしまいます。このため WinJS では promise に done メソッドを用意しています。このメソッドは then と同じ引数を受け入れますが、示すのはチェーンの完了です (別の promise ではなく undefined を返します)。その後、チェーン全体のあらゆるエラーに対して、done にアタッチされたすべての error ハンドラーが呼び出されます。さらに、error ハンドラーが足りないことで、done はアプリケーションレベルで例外をスローし、この例外は WinJS.Application.onerror イベントの window.onerror によって処理されます。つまり、例外が特定され適切に処理されるためには、すべてのチェーンが done で終わることが理想的です。

もちろん、長い then 呼び出しチェーンから最後の promise を返すことを目的とする関数を記述する場合、末尾に then を使用します。この場合のエラー処理は、その promise を別のチェーンで使用する呼び出し元が引き受けます。

promise の作成: WinJS.Promise クラス

Promises A 仕様に基づき独自の promise クラスはいつでも作成できますが、非常に煩雑な作業になるため、ライブラリがあれば便利です。WinJS には堅牢かつ入念にテストされた、WinJS.Promise (英語) と呼ばれる柔軟な promise クラスがあります。これを活用することで、オリジネーター/コンシューマーの関係や then の動作を詳細に管理せずに、さまざまな値と操作の promise を簡単に作成できるようになります。

非同期操作と既存の (同期的な) 値の両方について promise を作成する際には、必要に応じて new WinJS.Promise またはヘルパー関数 (次のセクションで説明) を使用できます (使用する必要があります)。改めて、promise はコードコンストラクターに過ぎません。promise が非同期操作を含むあらゆる非同期的な処理をラップしなければならないという要件はありません。同様に、まれなケースとして promise のコードの一部をラップしても、それらが自動的に非同期で実行されることはなく、個別に対応する必要があります。

WinJS.Promise を直接使用する簡単な例として、処理の長い計算を考えてみます。ここでは 1 から順に特定の最大値まで数字を追加していく計算を、非同期で実行します。このような定形処理には独自のコールバックメカニズムを作成することもできますが、promise にラップすることで、この promise をその他の API からの別の promise と連結または結合できます (ここでは、WinJS.xhr (英語) 関数が JavaScript の非同期の XmlHttpRequest をラップするため、別の promise の特定のイベント構造は無視できます)。

処理の長い計算にはもちろん JavaScript ワーカーを使用できますが、説明上の都合から、JavaScript ワーカーは UI スレッド上に保持し、setImmediate を使用して操作を複数のステップに分割します。WinJS.Promise を使用して promise の構造内に実装する方法を以下に示します。

function calculateIntegerSum(max, step) {
    //The WinJS.Promise constructor's argument is an initializer function that receives 
    //dispatchers for completed, error, and progress cases.
    return new WinJS.Promise(function (completeDispatch, errorDispatch, progressDispatch) {
        var sum = 0;

        function iterate(args) {
            for (var i = args.start; i < args.end; i++) {
                sum += i;
            };

            if (i >= max) {
                //Complete--dispatch results to completed handlers
                completeDispatch(sum);
            } else {
                //Dispatch intermediate results to progress handlers
                progressDispatch(sum);
                setImmediate(iterate, { start: args.end, end: Math.min(args.end + step, max) });
            }
        }
            
        setImmediate(iterate, { start: 0, end: Math.min(step, max) });
    });
}

new WinJS.Promise を呼び出す際のコンストラクターは initializer 関数 (この場合は非同期) です。実行する操作は initializer によってカプセル化されますが、この関数自体は UI スレッド上で同期的に実行されます。このため、ここで setImmediate を使用せずに長い時間の計算を実行する場合は、UI スレッドを常にブロックします。繰り返しになりますが、promise 内にコードを配置しても自動的に非同期で実行されるようにはなりません。initializer 関数で個別に設定する必要があります。

引数については、initializer 関数は、promise がサポートする、完了 (completed)、エラー (error)、進行中 (progress) に対応した 3 種類のディスパッチャーを受け取ります。コードを見るとわかるように、これらのディスパッチャーが、操作の適切なタイミングで適切な引数によって呼び出されています。

これらの関数を "ディスパッチャー" と呼ぶ理由は、コンシューマーが promise の then メソッド (done もですが、以降は省略します) にサブスクライブするハンドラーとは異なるためです。内部的には、これらのハンドラーを WinJS が複数管理することで、任意の数のコンシューマーによる任意の数のハンドラーのサブスクライブが可能になっています。これらのディスパッチャーのいずれかを呼び出すと、WinJS は内部リストを反復処理し、これらのハンドラーすべてをユーザーに代わって呼び出します。また、連結を実現するために必要な別の promise を then が確実に返すようになるのも、WinJS.Promise があるためです。

まとめると、WinJS.Promise は、promise に伴う細かな処理をすべて提供しています。これによってユーザーは、initializer 関数に埋め込まれた、promise が示す重要な操作だけに集中できるようになります。

promise 作成用のヘルパー

promise を作成する主なヘルパー関数は、promise 内のすべての値をラップする静的メソッド WinJS.Promise.as (英語) です。既存の値に適用されたラッパーは、挙動を変え、then に渡されたすべての completed ハンドラーを呼び出します。これによって、既知の任意の値を promise として扱い、これらをその他の promise と (結合または連結を通して) 混合および組み合わせられるようになります。既存の promise に as を使用すると、その promise だけが返されます。

もう 1 つの静的ヘルパー関数は、setTimeout と setImmediate に関する便利なラッパーを提供する WinJS.Promise.timeout (英語) です。特定のミリ秒以内に履行されない場合に 2 つ目の promise をキャンセルする promise を作成することも可能です。

setTimeout および setImmediate に関する timeout promise は、undefined によって履行される点に注意してください。このとき、これらを使用して、タイムアウト後に別の結果を提供するためにはどうすればよいかという疑問が浮かびます。この疑問に対する回答には、then が、completed ハンドラーの戻り値で履行される別の promise を返すという事実が使用されます。このコード行の例を以下に示します。

var p = WinJS.Promise.timeout(1000).then(function () { return 12345; });

ここでは promise "p" が 1 秒後に値 12345 によって履行されます。言い換えると、WinJS.Promise.timeout(…).then(function () { return } ) のパターンによって、規定されたタイムアウトの後にが提供されます。自身が別の promise の場合は、タイムアウト後の特定時点における、その promise の履行値が提供されることになります。

キャンセルと promise エラーの生成

これまで見てきたコードでは、足りない点が 2 つあることにお気付きかもしれません。1 つ目は開始された操作をキャンセルする方法がないこと、2 つ目はエラーの処理が洗練されているとは言えないことです。

これら両方の原因は、promise を生成する calculateIntegerSum などの関数が常に promise を返す必要があるということです。操作が完了できない、または操作が最初に開始されない場合、その promise はエラー状態にあります。これは、呼ばれるのは error ハンドラーだけで、任意の completed ハンドラーに渡すことができる結果を promise が得られず、これからも得られないということを意味します。実際、コンシューマーが既にエラー状態にある promise で then を呼び出すと、promise はすぐに (同期的に) then に付与された error ハンドラーを呼び出します。

WinJS.Promise は、コンシューマーが cancel メソッドを呼び出すか、initializer 関数内のコードが error ディスパッチャーを呼び出すという 2 つの理由でエラー状態になります。エラーが発生すると、promise でどのようなエラー値が取得または伝播されたかに関係なく、error ハンドラーが付与されます。WinJS.Promise 内で操作を作成している場合、WinJS.ErrorFromName (英語) のインスタンスを使用することも可能です。これは、エラーを特定する name プロパティと詳細情報を格納する message プロパティを含む単なる JavaScript オブジェクトです。たとえば promise がキャンセルされると、error ハンドラーは、name と message の名前の両方が "Canceled" に設定されたエラーオブジェクトを受け取ります。

では、操作を最初に開始できない場合はどうすればよいのでしょうか。たとえば calculateIntegerSum を無効な引数 (0, 0 など) で呼び出した場合、カウントの開始さえ試行されずに、エラー状態の promise が返されます。静的メソッド WinJS.Promise.wrapError (英語) はこのような場合に使用します。ここでは、WinJS.ErrorFromName のインスタンスを使用して、この場合は新しい WinJS.Promise インスタンスの代わりに、エラー状態の promise を返します。

これについてもう 1 つ重要なのが、promise の cancel メソッドへの呼び出しによって promise 自身がエラー状態になる一方で、進行している非同期操作はどのように停止できるのかという疑問です。前述の calculateIntegerSum の実装では、作成した promise の状態に関係なく、操作が完了するまで setImmediate の呼び出しが継続されます。実際、promise のキャンセル後に操作によって complete ディスパッチャーが呼び出された場合、promise はその完了を無視します。

ここで求められるのは、処理を続行する必要がなくなったことを promise から操作に伝える方法です。このために WinJS.Promise コンストラクターは、promise がキャンセルされると呼び出される、関数の 2 つ目の引数を使用します。今回の例では、この関数への呼び出しによって setImmediate に対する次の呼び出しを防止し、計算を停止する必要があります。この処理を、適切なエラー処理と共に以下に示します。

function calculateIntegerSum(max, step) {
    //Return a promise in the error state for bad arguments
    if (max < 1 || step < 1) {
        var err = new WinJS.ErrorFromName("calculateIntegerSum", "max and step must be 1 or greater");
        return WinJS.Promise.wrapError(err);
    }

    var _cancel = false;

    //The WinJS.Promise constructor's argument is an initializer function that receives 
    //dispatchers for completed, error, and progress cases.
    return new WinJS.Promise(function (completeDispatch, errorDispatch, progressDispatch) {
        var sum = 0;

        function iterate(args) {
            for (var i = args.start; i < args.end; i++) {
                sum += i;
            };

            //If for some reason there was an error, create the error with WinJS.ErrorFromName
            //and pass to errorDispatch
            if (false /* replace with any necessary error check -- we don’t have any here */) {
                errorDispatch(new WinJS.ErrorFromName("calculateIntegerSum (scenario 7)", "error occurred"));
            }

            if (i >= max) {
                //Complete--dispatch results to completed handlers
                completeDispatch(sum); 
            } else {
                //Dispatch intermediate results to progress handlers
                progressDispatch(sum);

                //Interrupt the operation if canceled
                if (!_cancel) {
                    setImmediate(iterate, { start: args.end, end: Math.min(args.end + step, max) });
                }
            }
        }
            
        setImmediate(iterate, { start: 0, end: Math.min(step, max) });
    },
    //Cancellation function for the WinJS.Promise constructor
    function () {
        _cancel = true;
    });
}

総括すると、WinJS.Promise のインスタンスを作成することで、さまざまな使用方法が提供されます。たとえば、その他の非同期的手法で Web サービスを利用するライブラリがある場合、これらの操作を promise にラップすることができます。また、新しい promise を使用して、ソースの異なる複数の非同期操作 (または別の promise) を 1 つの promise に結合し、すべての関係を管理することができます。WinJS.Promise の initializer のコード内では、その他の非同期操作とその promise のハンドラーを独自に設定できます。これらを使用することで、ネットワークタイムアウトなどを自動で再試行するメカニズムのカプセル化や、進行状況を示す汎用の UI の呼び出し、内部的なログ記録や分析の追加が可能になります。これらのすべてでは、処理の詳細をコードの残りの部分が認識する必要はなく、コンシューマーの立場で promise に対応するだけで問題ありません。

また、JavaScript ワーカーを promise にラップして、WinRT のその他の非同期操作と同様の外観と動作を与えることも簡単です。ご存知のように、ワーカーでは、postMessage 呼び出しによってアプリのワーカーオブジェクトに message イベントを発生させることで結果を提供します。以下のコードでは、このメッセージで提供される結果にかかわらず履行される promise に、このイベントをリンクさせています。

// This is the function variable we're wiring up.
var workerCompleteDispatch = null;

var promiseJS = new WinJS.Promise(function (completeDispatch, errorDispatch, progressDispatch) {
    workerCompleteDispatch = completeDispatch;
});

// Worker is created here and stored in the 'worker' variable

// Listen for worker events
worker.onmessage = function (e) {
    if (workerCompleteDispatch != null) {
        workerCompleteDispatch(e.data.results); /* event args depends on the worker */
    }
}

promiseJS.done(function (result) {
    // Output for JS worker
});

このコードを拡張してワーカーのエラー処理を含めることで、その他の変数における error ディスパッチャーを省略し、message イベントハンドラーによるイベント引数のエラー情報のチェックを実行し、complete ディスパッチャーの代わりに必要に応じて error ディスパッチャーを呼び出せるようになります。

並列した promise の結合

promise は多くの場合非同期操作のラップに使用されるため、複数の操作を並行して実行することが可能です。この場合に知る必要があるのは、グループ内のいずれか 1 つの promise が履行されるタイミング、またはグループ内のすべての promise が履行されるタイミングです。これを可能にするのが、静的関数 WinJS.Promise.any (英語) および WinJS.Promise.join (英語) です。

これらの関数は値の配列または値のプロパティが設定されたオブジェクトを受け入れます。これらの値は promise にすることができ、promise 以外の値は WinJS.Promise.any によってラップされ、配列またはオブジェクト全体が promise による構成になります。

any の特性を以下に示します。

any によって 1 つの promise が作成されます。この promise は、その他の promise の 1 つが履行された場合またはエラーによって失敗した場合に履行されます (論理 OR)。基本的には、any は、これらすべての promise に completed ハンドラーをアタッチし、1 つの completed ハンドラーが呼び出された直後に、any の promise 自身が受け取ったすべての completed ハンドラーを呼び出します。
any の promise が履行された後 (リスト内の最初の promise が履行された後)、リスト内のその他の操作は実行を継続し、これらの promise に個別に割り当てられている completed、error、または progress の各ハンドラーを呼び出します。
any からの promise をキャンセルした場合は、リスト内のすべての promise がキャンセルされます。

join の特性を以下に示します。

join によって 1 つの promise が作成されます。この promise は、その他のすべての promise が履行された場合またはエラーによって失敗した場合に履行されます (論理 AND)。基本的には、join は、これらすべての promise に completed ハンドラーと error ハンドラーをアタッチし、これらすべてのハンドラーが呼び出されるのを待機し、その後、自身が受け取るすべての completed ハンドラーを呼び出します。
join の promise は提供されたすべての progress ハンドラーに進行状況をレポートします。この場合の中間結果は、これまで履行された個々の promise の結果の配列となります。
join からの promise をキャンセルした場合は、保留中のその他すべての promise がキャンセルされます。

any と join に加えて、簡単に使用できる以下 2 つの静的 WinJS.Promise メソッドを覚えておくと便利です。

is (英語): 任意の値が promise かどうかを、ブール値を返すことで判定します。基本的には、"then" の名前を持つ関数が設定されたオブジェクトかどうかを確認し、"done" の場合のテストは実行しません。
theneach (英語): completed、error、および progress の各ハンドラーを (then を使用して) promise のグループに適用し、promise 内の別の値のグループとして結果を返します。いずれのハンドラーでも null が許可されます。

並列した promise の連続的な結果

WinJS.Promise.join および WinJS.Promise.any によって、並列した promise による作業、つまり非同期並行操作が可能になります。join によって返される promise が履行されるのは、配列内のすべての promise が履行されたときです。ただし、これらの promise は多くの場合ランダムな順序で履行されます。ここで、このように実行できる一連の操作があるものの、その結果を処理する順序は詳細に定義したい (配列内に promise が表示される順序にしたい) 場合はどうすればよいでしょうか。

これを実行するには、後続の promise を、直前のすべての promise の join に結合する必要があります。これは、この記事の最初に示したコードの一部を使用することで実現します。そのコードを改めて以下に示します。このコードは、promise を明示的にするための変更が行われています (list は、promise を生成する架空の非同期呼び出し doOperationAsync の引数として使用される値の配列とします)。

list.reduce(function callback (prev, item, i) {
    var opPromise = doOperationAsync(item);
    var join = WinJS.Promise.join({ prev: prev, result: opPromise});

    return join.then(function completed (v) {
        console.log(i + ", item: " + item+ ", " + v.result);
    });
})

このコードを理解するためには、配列の reduce (英語) メソッドがどのように動作するかを理解する必要があります。配列の各項目について、reduce は callback という関数の引数を呼び出し、4 つの引数を受け取ります (このコードでは 3 つのみ使用されています)。

prev: callback への以前の呼び出しから返された値です (最初の項目では null です)。
item: 配列からの最新の値です。
i: リスト内の項目のインデックスです。
source: 元の配列です。

リスト内の最初の項目では、opPromise₁ と呼ばれる promise が取得されます。prev は null のため、[WinJS.Promise.as(null), opPromise₁] を連結します。ただし、join 自体が返されているわけではなく、completed ハンドラー (この場合 completed) を join にアタッチし、その then から promise を返しています。

then から返される promise は completed ハンドラーが返されたときに履行されることを思い出してください。つまり、callback から返される promise は、opPromise₁ の結果を最初の項目の completed ハンドラーが処理するまで完了しません。また、join の結果は、元のリストの promise 空の結果を含むオブジェクトによって履行されます。これは、履行値 v には prev プロパティと result プロパティの両方が格納され、result プロパティが opPromise₁ の結果であるという意味です。

list の次の項目により、以前の join.then からの promise を含む prev を callback が受け取ります。その後 opPromise₁.then と opPromise₂ の新しい結合が作成されます。その結果、この join は、opPromise₂ が履行され、opPromise₁ の completed ハンドラーが返された後に完了します。これによって、この join にアタッチする completed₂ ハンドラーが、completed₁ が返されるまで呼び出されなくなります。

項目 n の join.then からの promise は completed_n が返るまで履行されないという依存関係を、リスト内の各アイテムに構築します。これによって completed ハンドラーが、リストと同じ順序で呼び出されるようになります。

終わりに

この記事では、promise 自体は、多少強力ではあるものの、将来の任意の時点で値を提供するオリジネーターと、これらの値がいつ利用可能になるかを知りたいコンシューマーの間の固有の関係を示す、単なるコードコンストラクターまたは呼び出し規約に過ぎないということを確認しました。このような理由から、非同期操作の結果を示す場合に非常に便利な promise は、JavaScript で記述された Windows ストアアプリで幅広く活用されています。さらに promise の仕様では、連続する非同期操作を連結し、中間結果をリンク間で遷移させることも可能です。

JavaScript 用 Windows ライブラリ (WinJS) が提供する promise の強力な実装を活用することで、あらゆる操作を独自にラップすることができます。さらに WinJS は、並行操作を実現するための promise の結合などの共通シナリオのサポートにも対応しています。これらを活用することで、効率的かつ効果的な非同期操作を WinJS に基づき実行できるようになります。

Kraig Brockschmidt
- Windows エコシステム担当チーム、プログラムマネージャー
著書『HTML、CSS、JavaScript を使った Windows 8 アプリ開発』(英語)

ListView の項目レンダリングの最適化

Windows 8 Team — Tue, 25 Jun 2013 14:29:45 GMT

コレクションを利用する JavaScript を使って作成された Windows ストアアプリの場合、アプリのすばらしいパフォーマンスを実現するには、通常、WinJS ListView コントロール (英語) とのスムーズな連携がきわめて重要です。これは意外なことではなく、数千個にもなり得る項目の管理と表示を処理する場合、項目に対するすべての最適化がものを言います。最も重要なことは、各項目がどのように表示されるか、つまり、ListView コントロール内の各項目がどのように、また、どのタイミングで、DOM によって組み立てられ、アプリの一部として表示されるかです。実際、このプロセスの "タイミング" の部分は、リスト内ですばやくパン操作を行った場合に、そのスピードに遅れずにリストの表示が変わることが期待されている場合は、特に重要な要素になります。

ListView 内でレンダリングされる項目は、HTML で定義された宣言型テンプレートか、リスト内の項目ごとに呼び出されるカスタムの JavaScript "レンダリング関数" によって処理されます。宣言テンプレートを使う方法が最も簡単ですが、このプロセスに対して特定の制御を行う場合の自由度は限られます。一方、レンダリング関数を使うと、項目ごとにレンダリングをカスタマイズでき、HTML ListView パフォーマンス最適化のサンプル (英語) に実装されているように、複数の最適化が可能です。この関数では、次のような最適化を実現できます。

項目データと表示要素の非同期配信の実現。これには、基本のレンダリング関数を使用します。
ListView の全体的なレイアウトを決めるために必要な、項目の形状の作成と、内部の要素との分離。これには、プレースホルダーレンダラーを使用します。
以前作成した項目要素 (とその子) のデータを置き換えて再利用。要素作成の大半のステップを省略できます。これには、プレースホルダー再利用レンダラーを使用します。
項目が表示され、ListView のパン操作のスピードが落ち着くまで、イメージの読み込みやアニメーションなど、負荷の高いビジュアル操作の遅延。これには、多段階レンダラーを使用します。
同じビジュアル操作をまとめて、DOM の再レンダリングを最小限に抑制。これには、多段階レンダラーを使用します。

この記事では、上記の全ステージを取り上げ、各ステージが ListView の項目レンダリングプロセスとどのように連携するかを説明します。お察しのとおり、項目をレンダリングするタイミングの最適化には、非同期操作、ひいては promise を多用します。したがって、この記事を読み進むにつれて、promise 自体の理解も、このブログの前回の記事「promise の詳細」(英語) の知識からさらに深めることができます。

すべてのレンダラーに言えることですが、常に、中心となる項目のレンダリング時間 (遅延操作を除く) を最小限に抑えることが重要です。ListView の最終的なパフォーマンスは、ListView の更新と画面の更新間隔がどの程度同期するかに大きく左右されるため、1 つの項目レンダラーで数ミリ秒余分にかかると、次の画面の更新までの間の ListView 全体のレンダリング時間が増大し、結果としてフレーム落ちや画面の乱れが発生します。つまり、項目レンダラーは、JavaScript コードの最適化を図る場合、本当に有効な領域です。

基本レンダラー

まず、項目レンダリング機能 (以降は、シンプルに "レンダラー" と呼びます) とはどのようなものかを簡単に確認しましょう。レンダラーは、テンプレート名の代わりに、ListView の itemTemplate (英語) プロパティに割り当てられる関数で、この関数は ListView から DOM に追加される項目に対して、必要に応じて呼び出されます (レンダラーの基本的な情報については、itemTemplate を参照してください。ただし、この最適化が本当によくわかるのはサンプルの方です)。

項目レンダリング関数は、単純に ListView のデータソースから項目が渡されたら、その特定の項目に必要な HTML 要素を作成し、ListView が DOM に追加できるルート要素を返すと思われるでしょうか。基本的にはそうですが、さらに 2 点、考慮することがあります。まず、項目データ自体が非同期に読み込まれる可能性があるため、要素の作成をそのデータが提供されるタイミングに合わせる方がよいでしょう。また、項目自体のレンダリングプロセスには、リモート URI からのイメージの読み込みや、項目データで指定されている他のファイルのデータの読み取りなど、他の非同期作業も含まれる場合があります。この記事で説明するさまざまなレベルの最適化では、実際、項目の要素が要求されてから、要求された項目が実際に提供されるまでの非同期の度合いを自由に決定できます。

したがって、やはり、promise が使われると予測できます。まず、ListView では項目データを直接レンダラーに渡さず、そのデータの promise を提供します。また、項目のルート要素を直接返す関数の代わりに、その要素の promise を返します。この方法により、ListView ではさまざまな項目レンダリング promise を組み合わせて、ページ全体の項目がレンダリングされるまで、(非同期に) 待機できます。実際、このように処理することで、ListView では複数のページの作成方法を管理しています。まず、表示される項目のページを作成したら、ユーザーのパン操作の結果、この次に表示されると思われる前後の 2 種類のページを非表示で作成します。また、このような promise をすべて用意しておけば、ユーザーのパン操作によって画面が変わった場合、表示が完了していない項目のレンダリングを ListView によって簡単にキャンセルでき、無駄な要素作成を行わずに済みます。

これらの promise の使用方法は、サンプルの simpleRenderer 関数を見るとわかります。

function simpleRenderer(itemPromise) {
    return itemPromise.then(function (item) {
        var element = document.createElement("div");
        element.className = "itemTempl";
        element.innerHTML = " + item.data.thumbnail +
            "' alt='Databound image' />" + item.data.title + "
";
        return element;
    });
}

このコードでは、最初に、completed ハンドラーを itemPromise にアタッチしています。ハンドラーは、項目データが提供され、それを受けて要素が実際に作成された時点で呼び出されます。ただし、実は要素を直接返さず、その要素がフルフィルメント (提供) される promise を返していることに、改めて注意してください。つまり、itemPromise.then() からの戻り値は、ListView によって要素が必要になった場合に必要なタイミングで、"element" がフルフィルメントされる promise です。

promise を返すことで、必要に応じて他の非同期作業を実行できます。この場合は、レンダラーは単に中間の promise をチェーンにまとめ、チェーン内の最後の then から promise を返しています。以下に例を示します。

function someRenderer(itemPromise) {
    return itemPromise.then(function (item) {
        return doSomeWorkAsync(item.data);
    }).then(function (results) {
        return doMoreWorkAsync(results1);
    }).then(function (results2) {
        var element = document.createElement("div");
        // use results2 to configure the element
        return element;
    });
}

これは、最後の then 呼び出しから promise を返しているので、チェーンの最後に done を使わないケースになります。エラーが発生した場合は、ListView によってエラーは処理されます。

プレースホルダーレンダラー

ListView の最適化の次の段階では、要素の作成を 2 段階に分ける "プレースホルダーレンダラー" を使います。このレンダラーを使うことで、ListView から、リスト全体のレイアウトの定義に必要な要素の部分のみを要求でき、各項目内の要素すべてを作成する必要がありません。その結果、ListView はレイアウトパスを短時間で完成して、この後の入力でも高い応答性を保つことができます。パスが完成したら、後で、要素の残りの部分を要求できます。

プレースホルダーレンダラーでは、promise を 1 つだけ返すのではなく、以下の 2 つのプロパティを持つオブジェクトが 1 つ返されます。

"element": 項目の構造内の最上位の要素で、項目のサイズと形状を定義できる必要最低限の、項目データに依存しない要素を示します。
"renderComplete": 要素のコンテンツの残りが作成された時点で、フルフィルメントされる promise を示します。つまり、前と同様に itemPromise.then で始まるチェーンから promise を返します。

ListView では、レンダラーが promise を返す (前と同様に基本のケース) か、element および renderComplete プロパティを返す (より高度なケース) かどうかを確認できます。したがって、前回の simpleRenderer と同等のプレースホルダーレンダラー (サンプル内) は次のようになります。

function placeholderRenderer(itemPromise) {
    // create a basic template for the item that doesn't depend on the data
    var element = document.createElement("div");
    element.className = "itemTempl";
    element.innerHTML = "...
";

    // return the element as the placeholder, and a callback to update it when data is available
    return {
        element: element,

        // specifies a promise that will be completed when rendering is complete
        // itemPromise will complete when the data is available
        renderComplete: itemPromise.then(function (item) {
            // mutate the element to include the data
            element.querySelector(".content").innerText = item.data.title;
            element.insertAdjacentHTML("afterBegin", " +
                item.data.thumbnail + "' alt='Databound image' />");
        })
    };
}

element.innerHTML の割り当ては、renderComplete 内に移動することもできます。これは、サンプルの css/scenario1.css ファイルの itemTempl クラスで、項目の幅と高さを直接指定しているためです。element プロパティに含まれている理由は、プレースホルダーに既定の "…" テキストを提供するためです。方法は簡単で、すべての項目で共有される、小さいパッケージ内リソースを参照する (したがって短時間でレンダリングされる) img 要素を使用するだけです。

プレースホルダーの再利用レンダラー

次の最適化の "プレースホルダーの再利用" レンダラーでは、promise に関しては、新しいものは何もありません。recycled というレンダラーにある 2 つ目のパラメーターに注目してください。これは、前にレンダリングされていて、現在は非表示になっている項目のルート要素です。つまり、再利用された要素には既に子要素が作成されているので、データを置き換えて、おそらく子要素のいくつかを調整するだけです。これにより、再利用をせず、まったく新しい項目をレンダリングする際に必要になる、不可の高い要素作成呼び出しのほとんどを回避し、レンダリングプロセスの時間を大幅に節約できます。

ListView は、loadingBehavior (英語) を "randomaccess" に設定すると、再利用した要素を提供できます。"recycled" が指定された場合、要素 (とその子要素) からデータを消去し、プレースホルダーとしてこれを返します。その後、データを設定し、(必要に応じて) renderComplete 内に追加の子を作成します。再利用された要素が提供されない場合 (ListView が初めて作成されたか、loadingBehavior が "incremental" の場合)、要素を新たに作成します。以下は、その動作のコードをサンプルから抜粋したものです。

function recyclingPlaceholderRenderer(itemPromise, recycled) {
    var element, img, label;
    if (!recycled) {
        // create a basic template for the item that doesn't depend on the data
        element = document.createElement("div");
        element.className = "itemTempl";
        element.innerHTML = "" +
            "...
";
    }
    else {
        // clean up the recycled element so that we can reuse it 
        element = recycled;
        label = element.querySelector(".content");
        label.innerHTML = "...";
        img = element.querySelector("img");
        img.style.visibility = "hidden";
    }
    return {
        element: element,
        renderComplete: itemPromise.then(function (item) {
            // mutate the element to include the data
            if (!label) {
                label = element.querySelector(".content");
                img = element.querySelector("img");
            }
            label.innerText = item.data.title;
            img.src = item.data.thumbnail;
            img.style.visibility = "visible";
        })
    };
}

"renderComplete" では、"label" など、新しいプレースホルダーに作成しない要素があるかを必ず確認し、必要に応じてここで作成してください。

より一般的に再利用された項目からデータを消去する場合は、ListView の resetItem (英語) プロパティに関数を設定できます。この関数には、上記と同様のコードが含まれます。項目だけでなくグループヘッダーにもテンプレート関数を使用できるので、resetGroupHeader (プロパティ) についても同じことが言えます。グループヘッダーははるかに少なく、通常、予想されるパフォーマンスは同じになるので、これまでそれほど詳しくは説明していませんが、この機能は存在しています。

多段階レンダラー

次は、最後から 2 番目の最適化、"多段階レンダラー" です。このレンダラーは、プレースホルダー再利用レンダラーを拡張して、DOM に項目の残りの要素が完全に追加されるまで、イメージや他のメディアの読み込みを遅延します。また、項目が実際に画面に表示されるまで、アニメーションなどの効果も遅延します。これは、ユーザーが ListView 内ではかなりすばやくパンを行うことが多いので、ListView の動きが落ち着くまで、負荷の高い操作を非同期に遅延することが有効なためです。

ListView は、itemPromise から生成された item のメンバーとして必要なフックを提供します。これらは、ready というプロパティ (promise) と、(さらに) promise を返す loadImage および isOnScreen の 2 つのメソッドです。以下が、そのコードです。

renderComplete: itemPromise.then(function (item) {
    // item.ready, item.loadImage, and item.isOnScreen available
})

これらの使い方を説明します。

ready チェーン内で最初に completed ハンドラーからこの promise を返します。この promise は、要素の構造全体がレンダリングされ、表示できるようになった時点で、フルフィルメントされます。つまり、completed ハンドラーを使って別の then をチェーンし、そのチェーン内で、イメージの読み込みなど、他の表示後の作業を実行できます。
loadImage URI からイメージをダウンロードして、指定されている "img" 要素内に URI 表示し、この要素によってフルフィルメントされる promise を返します。この promise に completed ハンドラーをアタッチします。このハンドラー自体は、isOnScreen から promise を返します。"img" 要素が提供されていない場合は、loadImage によって作成され、completed ハンドラーに渡されます。
isOnScreen 項目が表示されるかどうかを示すブール値をフルフィルメント値として取る promise を返します。現在の実装では、これは既知の値になるため、promise は同期的にフルフィルメントされます。ただし、これを promise を使ってラップすることで、より長いチェーンで使用できます。

これらはすべてサンプルの multistageRenderer 関数内で使われています。この関数では、イメージの読み込みの完了を合図に、フェードインアニメーションを開始します。以下に、"renderComplete" promise から返される内容のみを示します。

renderComplete: itemPromise.then(function (item) {
    // mutate the element to update only the title
    if (!label) { label = element.querySelector(".content"); }
    label.innerText = item.data.title;

    // use the item.ready promise to delay the more expensive work
    return item.ready;
    // use the ability to chain promises, to enable work to be cancelled
}).then(function (item) {
    // use the image loader to queue the loading of the image
    if (!img) { img = element.querySelector("img"); }
    return item.loadImage(item.data.thumbnail, img).then(function () {
        // once loaded check if the item is visible
        return item.isOnScreen();
    });
}).then(function (onscreen) {
    if (!onscreen) {
        // if the item is not visible, don't animate its opacity
        img.style.opacity = 1;
    } else {
        // if the item is visible, animate the opacity of the image
        WinJS.UI.Animation.fadeIn(img);
    }
})

ここではさまざまな処理をしていますが、基本の promise チェーンしかないことに変わりありません。レンダラー内の最初の同期操作によって、テキストなど、項目の要素構造でシンプルな要素のみが更新されます。次に、item.ready で promise を返しています。promise がフルフィルメントされるとき (より正確には、その promise が実行される場合) に、項目の非同期の loadImage メソッドを使ってイメージのダウンロードを開始し、item.isOnScreen promise をその completed ハンドラーから返します。つまり、可視性を示す "onscreen" フラグがチェーン内で最後に completed ハンドラーに渡されます。その isOnScreen promise がフルフィルメントされる場合、つまり、項目が実際に表示される時点で、アニメーションなどの関連操作を実行できます。

"場合" を強調するのは、これらの処理が行われている最中に、ユーザーが ListView 内でパン操作を行う可能性があるためです。この場合も、これらの promise すべてをチェーンにまとめることで、これらの項目がパン操作によってビューやバッファー済みのページから外れた場合に、ListView では非同期操作をキャンセルできます。ListView コントロールに対して、ここまでで "さまざまな" パフォーマンステストが実行されたと言えるでしょう。

また、やはり "renderComplete" プロパティ内のレンダリング関数から promise を返しているため、これらのどのチェーンでも全体で then を使用していることに改めて注意してください。これらのレンダラー内でチェーンの最後に到達することはないため、done をレンダラーの最後に使うことはありません。

縮小表示のバッチ処理

最後の最適化は、まさに ListView コントロールにとって "最後の一撃" です。以下のコードの batchRenderer という関数内に、"renderComplete" を対象とするこの構造があります (ほとんどのコードは省略)。

renderComplete: itemPromise.then(function (item) {
    // mutate the element to update only the title
    if (!label) { label = element.querySelector(".content"); }
    label.innerText = item.data.title;

    // use the item.ready promise to delay the more expensive work
    return item.ready;
    // use the ability to chain promises, to enable work to be cancelled
}).then(function (item) {
    // use the image loader to queue the loading of the image
    if (!img) { img = element.querySelector("img"); }
    return item.loadImage(item.data.thumbnail, img).then(function () {
        // once loaded check if the item is visible
        return item.isOnScreen();
    });
}).then(function (onscreen) {
    if (!onscreen) {
        // if the item is not visible, don't animate its opacity
        img.style.opacity = 1;
    } else {
        // if the item is visible, animate the opacity of the image
        WinJS.UI.Animation.fadeIn(img);
    }
})

これは、multistageRenderer とほぼ同じですが、item.loadImage 呼び出しと item.isOnScreen チェックの間にある、この不思議な thumbnailBatch という関数への呼び出しが挿入されている点が異なります。チェーン内に thumbnailBatch がある場合、これは、その戻り値が、別の promise を返す completed ハンドラーになる必要があることを示しています。

わかりにくいでしょうか? これについては、詳しく説明しますが、最初に、ここで何をしようとしているか、少し背景を説明する必要があります。

項目が 1 つしかない ListView だけなら、さまざまな読み込みの最適化の効果はわからないでしょう。しかし、通常、ListViews には多数の項目があり、レンダリング関数は項目ごとに呼び出されます。前のセクションの multistageRenderer 内で、各項目のレンダリングによって、非同期の item.loadImage 操作が開始され、任意の URI から縮小表示がダウンロードされます。この操作のそれぞれに、時間がかかります。したがって、リスト全体では、多数の loadImage 呼び出しが同時に実行され、特定の縮小表示が完成するのを各項目のレンダリングが待機することになる可能性があります。ここまではよいでしょう。

ただし、multistageRenderer からは計り知れない重要な特徴は、縮小表示の "img" 要素は "既に" DOM 内にあり、ダウンロードの完了しだい、loadImage 関数によってそのイメージの src 属性が設定されることです。属性が設定されたら、promise チェーンの残りが返されしだい、レンダリングエンジンが更新されます。これ以降は、基本的に同期的に処理されます。

さらにその後、多数の縮小表示が、短時間のうちに UI スレッドに返される可能性があります。これにより、レンダリングエンジンに過剰なチャーンが発生し、ビジュアルパフォーマンスがかなり低下します。このチャーンを避けるため、これらの "img" 要素が DOM に渡される "前" に、完全に img 要素を作成して、バッチに追加し、これらの要素がすべて単一のレンダリングパスで処理されるようにします。

サンプルでは、promise の一部 (createBatch という魔法の関数) で、これを実装しています。createBatch は、アプリ全体で 1 度だけ呼び出され、その結果 (別の関数) は thumbnailBatch という名前の変数に格納されます。

var thumbnailBatch;
thumbnailBatch = createBatch();

この thumbnailBatch 関数への呼び出しは、これ以降参照することになりますが、やはりレンダラーの promise チェーンに挿入されます。この挿入の目的は、この後すぐに説明するバッチ処理コードの性質を踏まえて、読み込まれた複数の "img" 要素をグループにまとめ、適切な間を置いて次の処理に渡すことです。レンダラーの promise チェーンだけを見ても、やはり thumbnailBatch() の呼び出しは、promise を返す completed ハンドラー関数を返す必要があります。また、その promise のフルフィルメント値 (チェーンの次のステップを参照) は、DOM に追加できる "img" 要素である必要があります。バッチ処理が実行された "後" で、これらのイメージを DOM に追加することで、グループ全体を同じレンダリングパスにまとめています。

これは、batchRenderer と、前のセクションの multistageRenderer との重要な違いです。後者では、縮小表示の "img" 要素が既に DOM 内に存在し、2 番目のパラメーターとして loadImage に渡されます。したがって、loadImage がイメージの "src" 属性が設定されるときに、レンダリングの更新が発生します。ただし、batchRenderer 内では、その "img" 要素は、loadImage 内 (ここでも "src" が設定されている) で別に作成されますが、"img" はまだ DOM に追加されていません。thumbnailBatch ステップが完了しないと DOM に追加されません。これにより、同一のレイアウトパス内にグループを組み込んでいます。

では、このバッチ処理のしくみを見ていきましょう。以下は、createBatch 関数の全容です。

function createBatch(waitPeriod) {
    var batchTimeout = WinJS.Promise.as();
    var batchedItems = [];

    function completeBatch() {
        var callbacks = batchedItems;
        batchedItems = [];
        for (var i = 0; i < callbacks.length; i++) {
            callbacks[i]();
        }
    }

    return function () {
        batchTimeout.cancel();
        batchTimeout = WinJS.Promise.timeout(waitPeriod || 64).then(completeBatch);

        var delayedPromise = new WinJS.Promise(function (c) {
            batchedItems.push(c);
        });

        return function (v) {
            return delayedPromise.then(function () {
                return v;
            });
        };
    };
}

この場合も、createBatch は "1 度だけ" 呼び出され、その結果の thumbnailBatch がリスト内のレンダリングされた項目のそれぞれに対して呼び出されています。thumbnailBatch が生成した completed ハンドラーは、loadImage 操作が完了するたびに呼び出されます。

このような completed ハンドラーは、同程度の手間で、直接レンダリング関数に挿入することもできますが、ここでは、項目ごとではなく、複数の項目全体でアクティビティを調整することが目的です。この調整は、createBatch の始めに作成および初期化される、2 つの変数によって実現されます。空の promise を初期化している "batchedTimeout" と、最初は空の関数の配列を初期化している "batchedItems" です。createBatch では関数 completeBatch も宣言していて、配列内の各関数を呼び出し、batchedItems を空にします。

function createBatch(waitPeriod) {
    var batchTimeout = WinJS.Promise.as();
    var batchedItems = [];

    function completeBatch() {
        var callbacks = batchedItems;
        batchedItems = [];
        for (var i = 0; i < callbacks.length; i++) {
            callbacks[i]();
        }
    }

    return function () {
        batchTimeout.cancel();
        batchTimeout = WinJS.Promise.timeout(waitPeriod || 64).then(completeBatch);

        var delayedPromise = new WinJS.Promise(function (c) {
            batchedItems.push(c);
        });

        return function (v) {
            return delayedPromise.then(function () {
                return v;
            });
        };
    };
}

今度は、thumbnailBatch (createBatch から返される関数) 内の処理を見ていきましょう。これも、レンダリングされる項目ごとに呼び出されます。最初に、既存の batchedTimeout をキャンセルし、すぐに作成し直します。

batchTimeout.cancel();
        batchTimeout = WinJS.Promise.timeout(waitPeriod || 64).then(completeBatch);

2 行目は、「promise の詳細」の記事で説明している、将来の配信/フルフィルメントパターンです。ここでは、"waitPeriod" に指定された遅延 (ミリ秒単位、既定値は 64 ミリ秒) の後に、completeBatch を呼び出しています。したがって、thumbnailBatch が以前の呼び出しの "waitPeriod" で再び呼び出される限り、batchTimeout は新しい waitPeriod にリセットされます。また、thumbnailBatch は、item.loadImage 呼び出しが完了した "後で" しか呼び出されないため、以前の呼び出しの "waitPeriod" 内で完了する loadImage 操作は同じバッチ内に含めることができます。"waitPeriod" に指定されている間隔を過ぎると、バッチが処理され (DOM にイメージが追加され)、次のバッチが開始されます。

このタイムアウト操作が処理されたら、thumbnailBatch によって新しい promise が作成され、この promise が完了ディスパッチャー関数を "batchedItems" 配列にプッシュします。

var delayedPromise = new WinJS.Promise(function (c) {
         batchedItems.push(c);
     });

「promise の詳細」では、promise はコードコンストラクトに過ぎず、ここにはそれしかありません。新しく作成される promise 自体には、非同期動作はありません。完了ディスパッチャー関数の "c" を "batchedItems" に追加しているだけです。ただし、もちろん、"batchedTimeout" が非同期に完了するまで、ディスパッチャーによる処理は何も実行されないため、ここでは実際に非同期な関係が成立しています。タイムアウトが発生し、バッチを消去したら (completeBatch 内)、別の場所にある completed ハンドラーを delayedPromise.then に呼び出します。

今度は、createBatch の最後のコード行です。これは、thumbnailBatch が実際に返される関数です。この関数こそが、レンダラーの promise チェーン全体に挿入される completed ハンドラーです。

return function (v) {
           return delayedPromise.then(function () {
               return v;
           });
       };

実際、このコードを直接 promise チェーンに挿入し、最終的な関係を見てみましょう。

return item.loadImage(item.data.thumbnail);
          }).then(function (v) {
              return delayedPromise.then(function () {
                  return v;
              });
          ).then(function (newimg) {

これで、引数 "v" が item.loadImage の結果であることがわかります。これは作成された "img" 要素です。バッチ処理を行わない場合は、return WinJS.Promise.as(v) と記述するだけでも、チェーン全体は機能します。その場合 "v" は同期的に渡され、次のステップの "newimg" に設定されます。

しかし、ここでは、delayedPromise.then から promise を返しています。これは、現在の "batchedTimeout" がフルフィルメントされるまで、("v" によって) 実行されません。その時点で (ここでも 1 つ目の loadImage が完了してから "waitPeriod" で指定されている間隔が空けられます)、"img" 要素がチェーン内の次のステップに渡され、そこで DOM に追加されます。

以上です。

終わりに

HTML ListView パフォーマンス最適化のサンプル (英語) に実装されている 5 種類のレンダリング関数すべてに共通することが、1 つあります。それは、promise によって表現される、ListView とレンダラー間の非同期の関係によって、レンダラーがリスト内の項目の要素を生成する方法とタイミングを非常に柔軟にコントロールできることです。独自のアプリを作成する際に、ListView の最適化にどのような戦略を使うかは、データソースのサイズ、項目自体の複雑さ、(リモートイメージのダウンロードなど) それらの項目に非同期で取得するデータの量に大きく依存します。それでも、パフォーマンス目標を達成できるように、項目レンダラーはできるだけシンプルにしたいと思うのは当然です。しかし、いずれにせよ、ListView (とアプリ) のパフォーマンスを最大限引き出すために必要なツールは、これですべて揃いました。

Kraig Brockschmidt
- Windows エコシステム担当チーム、プログラムマネージャー
著書『HTML、CSS、JavaScript を使った Windows 8 アプリ開発』(英語)

Game On Virtual Event にご参加ください

Windows 8 Team — Wed, 12 Jun 2013 11:38:41 GMT

ゲームは、Windows ストアにおける重要なアプリの 1 つです。Windows ストアのゲーム開発の方法を模索している皆様に、ゲーム開発支援を目的とした仮想イベントをお知らせいたします。これは、初めての開発者にもプロの開発者にも役立つ、参加無料のイベントです。

本イベントでは、YoYo Games の GameMaker: Studio (英語) を使って、高品質なゲームをかつてないスピードで開発、公開する方法をお伝えします。GameMaker:Studio には豊富な設計オプションが組み込まれ、各ツールはドラッグアンドドロップで操作できるので、ゲームのアイデアがなくても、また開発経験を持たない方でも開発を始めることができます。もちろん、プロフェッショナルの皆様の要求に応える高度なツールも備えておりますので、独自のゲームエクスペリエンスの開発に挑戦していただくことができます。

このオンラインイベントは 6 月 15 日午前 10 時 (太平洋夏時間) に開催されます。ローンチセッションとライブチャットで幕を開け、さまざまなゲームの種類、基本的なゲームにグラフィック、レベル、サウンドを追加する方法、ゲームにオリジナリティを加える方法などを紹介していきます。サポートは 1 週間にわたり継続され、GameMaker フォーラムを通して 1 対 1 のサポートが提供される予定です。

学生の皆様、開発を初めたばかりの方、経験豊かなプロフェッショナルの皆様は、ゲームの開発を開始、アップロードし、Windows ストアに公開するために必要なすべての情報を、イベントを通して学ぶことができます。イベントの詳細、登録方法、無料のツールとリソースに関する情報については、http://msdnevents.com/gameon/ (英語) をご覧ください。

--Robert Rodriguez-Lawson、シニアコンテンツパブリッシングマネージャー、Windows 開発者コンテンツチーム

資格情報保管ボックス: Windows ストアアプリのユーザー名とパスワード処理のソリューション

Windows 8 Team — Tue, 04 Jun 2013 19:42:00 GMT

Windows ストアアプリで使用できる資格情報保管ボックスついてご存知なければ、ここでぜひ知っておいてください。理由は、資格情報保管ボックスを使うと、ユーザー資格情報の格納と取得の作業を簡略化できるだけでなく、資格情報を安全に格納でき、ユーザーの Microsoft アカウントと合わせて "無料で" ローミングできるからです。

たとえば、メディアファイルやソーシャルネットワークなど、保護されたリソースにアクセスするサービスに接続するアプリがあるとします。サービスを利用するには、ユーザーごとにログイン情報が必要です。そこで、ユーザーのユーザー名とパスワードを取得し、それを使ってサービスにユーザーをログインする UI をアプリに組み込みました。すべてがスムーズに機能しています。

今度はさらに、ユーザーの利便性を考えて、アプリを使うたびにログインしなくても済むようにログイン情報を安全に格納したいと考えました。そこで、資格情報保管ボックスの出番です。資格情報保管ボックス API を何回か呼び出すだけで、ユーザーのユーザー名とパスワードを格納し、ユーザーが次にアプリを開くときに、簡単に格納した情報を取得して、自動でユーザーのログインを処理できます。

安全な保存スペース

アプリにとっての資格情報保管ボックスの最大のメリットは、ユーザー資格情報が安全な場所に格納されることです。資格情報は、ディスク上に格納されるとき、暗号化されます。もちろん、アプリに使うユーザー資格情報をファイルに保存してローカルの保存スペースに格納することもできますが、ユーザー資格情報をプレーンテキストで格納すると、大きなセキュリティホールになります。ユーザーのシステムが何かの形で侵害された場合、ユーザーのユーザー名とパスワードにアクセスして操作することは簡単です。ユーザー名とパスワードが資格情報保管ボックスを使って格納されていれば、悪意のあるソースは暗号化されたファイルを入手するのが関の山です。

資格情報保管ボックスは各 Windows PC ユーザーに一意であり、資格情報を格納したアプリしか、その資格情報にアクセスできません。つまり、その特定のアプリのために格納した資格情報以外は取得できません。同様に、他のアプリは、この特定のアプリによって資格情報保管ボックスに格納されている資格情報にはアクセスできません。

資格情報のローミング

ユーザーに提供できるもう 1 つのメリットは、資格情報保管ボックスを使ってユーザー名とパスワードを格納すると、格納された資格情報はユーザーの Microsoft アカウントと共に、ユーザーがその Microsoft アカウントを使う限りどの信頼済みコンピューターにもローミングされることです。その結果、ユーザーの Microsoft アカウントに関連付けられていて、アプリがインストールされていれば、どの信頼済みコンピューターからでも、ユーザーはアプリに自動的にログインできる (ユーザーに資格情報の入力が求められない) ため、セキュリティで保護されたアプリはユーザーにとってさらに便利なものになります。

ドメインアカウントの場合は、処理が少し異なります。Microsoft アカウントを使って格納されている資格情報があり、そのアカウントをドメインアカウント (仕事で使うアカウントなど) に関連付けている場合、資格情報はそのドメインアカウントにローミングされます。ただし、そのドメインアカウント使ってサインオンするときに追加された新しい資格情報は、ローミングされません。これにより、そのドメイン固有の資格情報が、ドメイン外部に知られないようにしています。

ユーザー資格情報の格納

資格情報保管ボックスへのユーザー資格情報の格納は、簡単な 2 ステップのプロセスです。最初に、Windows.Security.Credentials 名前空間の PasswordVault オブジェクトを使って、資格情報保管ボックスへの参照を取得します。次に、アプリの識別子、ユーザー名およびパスワードを保持する PasswordCredential オブジェクトを作成し、このオブジェクトを PasswordVault.Add() メソッドに渡して、資格情報を資格情報保管ボックスに追加します。

var vault = new Windows.Security.Credentials.PasswordVault();
vault.Add(new Windows.Security.Credentials.PasswordCredential(
    "My App", username, password));

JavaScript

var vault = new Windows.Security.Credentials.PasswordVault();
vault.add(new Windows.Security.Credentials.PasswordCredential(
    "My App", username, password));

ユーザー資格情報の取得

PasswordVault オブジェクトの参照を取得したら、資格情報保管ボックスからユーザー資格情報を取得する方法はいくつかあります。

PasswordVault.RetrieveAll() メソッドを使うと、ユーザーがアプリ用に資格情報保管ボックスに格納している資格情報をすべて取得できます。
格納されている資格情報のユーザー名がわかっている場合は、PasswordVault.FindAllByUserName() メソッドを使って、そのユーザー名の資格情報をすべて取得できます。
格納されている資格情報のリソース名がわかっている場合は、PasswordVault.FindAllByResource() メソッドを使って、そのリソース名の資格情報をすべて取得できます。
資格情報のユーザー名とリソース名がわかっている場合は、PasswordVault.Retrieve() メソッドを使って、その資格情報のみを取得できます。

では、リソース名がグローバルにアプリに格納されていて、ユーザーの資格情報を見つけることができた場合、自動的にユーザーがログインできるサンプルを見てみましょう。ユーザーの資格情報が複数見つかった場合は、ログオン時に使用する既定の資格情報を選択するようにユーザーに求めます。

private string resourceName = "My App";
private string defaultUserName;

private void Login()
{
    var loginCredential = GetCredentialFromLocker();

    if (loginCredential != null)
    {
        // There is a credential stored in the locker.
        // Populate the Password property of the credential
        // for automatic login.
        loginCredential.RetrievePassword();
    }
    else
    {
        // There is no credential stored in the locker.
        // Display UI to get user credentials.
        loginCredential = GetLoginCredentialUI();
    }

    // Log the user in.
    ServerLogin(loginCredential.UserName, loginCredential.Password);
}


private Windows.Security.Credentials.PasswordCredential GetCredentialFromLocker()
{
    Windows.Security.Credentials.PasswordCredential credential = null;

    var vault = new Windows.Security.Credentials.PasswordVault();
    var credentialList = vault.FindAllByResource(resourceName);
    if (credentialList.Count > 0)
    {
        if (credentialList.Count == 1)
        {
            credential = credentialList[0];
        }
        else
        {
            // When there are multiple usernames,
            // retrieve the default username. If one doesn’t
            // exist, then display UI to have the user select
            // a default username.

            defaultUserName = GetDefaultUserNameUI();

            credential = vault.Retrieve(resourceName, defaultUserName);
        }
    }

    return credential;
}

JavaScript

var resourceName = "My App";
var defaultUserName;

function login() {
    var loginCredential = getCredentialFromLocker();

    if (loginCredential != null) {
        // There is a credential stored in the locker.
        // Populate the Password property of the credential
        // for automatic login.
        loginCredential.retrievePassword();
    } else {
        // There is no credential stored in the locker.
        // Display UI to get user credentials.
        loginCredential = getLoginCredentialUI();
    }

    // Log the user in.
    serverLogin(loginCredential.userName, loginCredential.password);
}


function GetCredentialFromLocker() {
    var credential = null;

    var vault = new Windows.Security.Credentials.PasswordVault();
    var credentialList = vault.findAllByResource(resourceName);
    if (credentialList.length > 0) {
        if (credentialList.length == 1) {
            credential = credentialList[0];
        } else {
            // When there are multiple usernames,
            // retrieve the default username. If one doesn’t
            // exist, display UI to have the user select
            // a default username.

            defaultUserName = getDefaultUserNameUI();
            credential = vault.retrieve(resourceName, defaultUserName);
        }
    }

    return credential;
}

ユーザー資格情報の削除

資格情報保管ボックスへのユーザー資格情報の削除も、簡単な 2 ステップのプロセスです。この場合も、Windows.Security.Credentials 名前空間の PasswordVault オブジェクトを使って、資格情報保管ボックスへの参照を取得します。次に、削除する資格情報を PasswordVault.Remove() メソッドに渡します。

var vault = new Windows.Security.Credentials.PasswordVault();
vault.Remove(new Windows.Security.Credentials.PasswordCredential(
    "My App", username, password));

JavaScript

var vault = new Windows.Security.Credentials.PasswordVault();
vault.remove(new Windows.Security.Credentials.PasswordCredential(
    "My App", username, password));

簡単で安全

このように、資格情報保管ボックスは、より簡単に、しかも非常に安全に、ユーザーを認証し、ユーザーの資格情報を将来再利用する目的で格納できる、使いやすい機能です。

その他の Windows 8 アプリの認証に関するトピックには、Web サイトからの認証トークン (OAuth など) の取得に使用できる Web 認証ブローカーや、ユーザーの Microsoft アカウントを基にしたアプリのカスタマイズがあります。

詳細については、以下のリンクをご覧ください。

--Doug Rothaus、Windows 開発者コンテンツチーム、シニアコンテンツ開発者

今回の記事作成にあたっては、Yashar Bahman 氏にご協力いただきました。ありがとうございました。

位置情報と Bing マップを使用して位置認識アプリを作成する

Windows 8 Team — Tue, 28 May 2013 11:04:04 GMT

ユーザーの位置情報とアプリのビジネスロジックを組み合わせることによって、天気、クーポン、スポーツイベント、コンサートの一覧などの情報を、アプリユーザーの現在地に合わせて簡単に提供できるようになります。Windows 8 の位置情報機能を Bing マップ SDK と共に使用することで、強力な位置認識 Windows ストアアプリを開発できます。

この記事では、位置情報サービスを使用するアプリが、IP アドレス、Wi-Fi ネットワーク、GPS データのいずれかを使用してその場所固有の情報をユーザーに提供する方法について説明します。位置情報を取得した後は、Bing マップ SDK を使用して現在地を表示します。

位置情報を取得する

位置情報の取得には Windows.Devices.Geolocation 名前空間を使用します。GPS、Wi-Fi ネットワーク、IP アドレスうちどの情報をユーザーの位置情報の取得に使用するかは、主に以下の 2 つの要因がかかわってきます。

要求される精度の正確性: アプリの必要性に応じた最適な精度です。
位置情報データの利用可能性: GPS 機能を搭載していないデバイスがある、または、ネットワークや Wi-Fi 接続が利用できない状況で位置情報が要求される場合があるということです。

適切な精度

位置情報を要求する場合は、アプリが適切な精度を指定して、指定した精度の範囲内で位置情報データが最も速く返されるようにする必要があります。精度のレベルは、位置情報の種類に応じてそれぞれ以下のように異なります。

GPS - GPS は、約 10 m という最も高い精度を提供します。ただしGPS センサーを起動状態にして衛星データを取得し、データを三角測量する場合、詳細な位置情報を返すのに 1 ～ 2 分間かかる場合があります。一方、GPS が衛星との接続を確立した後は、次の位置情報ポイントは最初よりも早く取得されます。もちろん GPS の使用頻度が高くなると消費電力も高くなります。GPS を有効化してデータを取得するには、Geolocator.DesiredAccuracy プロパティを High に設定する必要があります。
Wi-Fi - Wi-Fi 接続の精度は 300 ～ 500 m の範囲となります。Wi-Fi 接続を利用できる場合、衛星接続を取得する GPS の場合よりもデータが速く返されます。Wi-Fi を使用して位置情報を取得するには、DesiredAccuracy プロパティを Default に設定します。
IP - IP レベルの感度の場合は 1 km レベルの精度になります。ネットワーク接続を利用できる場合、衛星接続を取得する GPS の場合よりもデータが速く返されます。IP を使用して位置情報を取得する場合も、設定する DesiredAccuracy プロパティは Default です。位置情報サービスは可能な最大精度でデータを返し、その精度のレベルを Geocoordinate.Accuracy プロパティ内で通知します。

アプリのパフォーマンスと消費電力に影響するため、適切な精度の値は慎重に検討する必要があります。たとえば天気予報を提供するアプリの場合、高精度な GPS はほぼ必要ありません。また、返されるデータの精度に基づいて誤差範囲を表示し、データの精度を必ず示す必要があります。適切な精度を設定する C# のコードは以下のようになります。

Geolocator geolocator = new Geolocator();
geolocator.DesiredAccuracy = Windows.Devices.Geolocation.PositionAccuracy.High;

精度のレベルにかかわらず、位置情報を取得する呼び出しは以下のようになります。

Geoposition pos = await geolocator.GetGeopositionAsync().AsTask(token);

Geolocator クラスのインスタンスを作成し、適切な精度を設定し、現在地を取得する JavaScript コードは以下のようになります。以下の 'promise' 変数が WinJS.Promise (英語) オブジェクトである点に注意してください。つまり、getGeopositionAsync への呼び出しからデータにアクセスするには done (英語)メソッドを使用する必要があります。

JavaScript

var geolocator = Windows.Devices.Geolocation.Geolocator();
geolocator.desiredAccuracy =
Windows.Devices.Geolocation.PositionAccuracy.high;

// Get the geoposition, capturing the request in a 'promise' object.
var promise = geolocator.getGeopositionAsync();

適切な精度を High に設定しても、PC に GPS 機能が搭載されていない、無効化している、Wi-Fi に接続していないなどの理由により、ユーザーのデバイスが高精度なデータを返さない可能性があることに注意してください。低精度データのインスタンスを適切に処理できるよう常に備えておく必要がありますが、その方法はアプリの機能によって異なります。低精度でも処理を続行する必要があるか、GPS レベルの精度が必要かどうかなど、詳細については、「位置認識アプリのガイドライン」を参照してください。

Bing マップ

利用できる位置情報の精度に対応するアプリの良い例が Bing マップアプリです。GPS や Wi-Fi が利用できないことが多いデスクトップ PC の場合、Bing マップアプリは IP アドレスに基づき位置情報を特定し、広域図にズームして現在地をマップに示します。ラップトップの場合は通常ワイヤレスカードが搭載されているため、Wi-Fi を使用してより正確な位置情報を取得し、さらに詳細図にズームして現在地を示すことができます。ユーザーがさらにズームすると、現在地アイコンに誤差範囲が表示されます。

Bing 天気

前述のとおり、Bing 天気アプリは広域の情報のみを必要とします。このため、このアプリが要求および指定する精度は低精度だけになり、位置情報の値も迅速に返され、ユーザーに対するアプリの応答性も高くなります。広域図レベルの情報しか必要としないその他の例としては、ラジオ局ガイド、買い物クーポン、地域のニュースフィードなどのアプリがあります。

Bing マップ SDK を使用して位置情報を表示する

GetGeopositionAsync への呼び出しから位置情報を取得した後は、情報をマップに表示します。

最初に、以下のコードを使用して、Geoposition を Bing マップで使用できる Location (英語) に変換します。

Location location = new Location(pos.Coordinate.Latitude, pos.Coordinate.Longitude);

JavaScript

promise.done(
  function (pos) {
    // Get the coordinates of the current location.
    var coord = pos.coordinate,
    location = new Microsoft.Maps.Location(coord.latitude, coord.longitude);
 
  },
  function (err) {
    // Handle the error.
  });

次に Bing マップを使用して位置情報を表示します。Bing マップ SDK はここ (英語) から入手できます。また、Bing ポータルに登録して Bing マップキーの入手 (英語) 手順に従い、Bing マップキーも入手する必要があります。登録の際は、キーの種類ごとの使用量制限を確認のうえ、アプリに最適なキーを選択してください。
Bing マップコントロールをデザイナーに追加し、資格情報にキーを挿入します。

<Page
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:SimpleMapping"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    xmlns:Maps="using:Bing.Maps"
    x:Class="SimpleMapping.MainPage"
    mc:Ignorable="d">

    <Grid Background="{StaticResource ApplicationPageBackgroundThemeBrush}">
        <Maps:Map x:Name="Map" Margin="0,120,0,0" Credentials="Insert Your Bing Maps Key Here"/>
    Grid>
Page>

次に、マップが表示されるアプリ内のページで、以下のコードを使用します。これによってマップのズームレベルが設定され、位置情報が表示されます。ズームレベルの詳細については、「Bing Map 上の位置情報を表示する方法」を参照してください。

double zoomLevel = 13.0f;

Map.SetView(location, zoomLevel);

JavaScript と HTML で Bing マップコントロールをアプリに追加する場合は、もう少し作業が必要です。以下の

Windows 8 アプリ開発者ブログ

promise の概要 (JavaScript による Windows ストア アプリ向け)

promise とは、"約束" によって関係が構築されること

promise コンストラクターと promise のチェーン

promise の作成: WinJS.Promise クラス

promise 作成用のヘルパー

キャンセルと promise エラーの生成

並列した promise の結合

並列した promise の連続的な結果

終わりに

ListView の項目レンダリングの最適化

基本レンダラー

プレースホルダー レンダラー

プレースホルダーの再利用レンダラー

多段階レンダラー

縮小表示のバッチ処理

終わりに

Game On Virtual Event にご参加ください

資格情報保管ボックス: Windows ストア アプリのユーザー名とパスワード処理のソリューション

安全な保存スペース

資格情報のローミング

ユーザー資格情報の格納

ユーザー資格情報の取得

ユーザー資格情報の削除

簡単で安全

位置情報と Bing マップを使用して位置認識アプリを作成する

位置情報を取得する

適切な精度

Bing マップ

Bing 天気

Bing マップ SDK を使用して位置情報を表示する

promise の概要 (JavaScript による Windows ストアアプリ向け)

プレースホルダーレンダラー

資格情報保管ボックス: Windows ストアアプリのユーザー名とパスワード処理のソリューション