アプリ開発者のための Windows Store App Labs が公開されました

本日は、30 以上の都市で開催されている、開発者、デザイナー、経営者や起業家など、アプリ開発にかかわるすべての皆さんのために Microsoft が開設した Windows Store App Labs (英語) をご紹介いたします。Windows Store App Labs では、最新の Windows 8 デバイスに実際に触れ、Windows エキスパートに技術的なアドバイスを聞き、最先端で活躍するデザイナーやデジタル マーケティング企業のデザイン ガイダンスを知ることができます。これらはすべて、無料でご利用いただけます。 最新の Windows 8 デバイスで実際にテストしてください ラボには最新の Windows 8 デバイスを揃えました。フォーム ファクターも、Microsoft Surface (英語)、Ultrabook、オールインワン型などの Windows RT タブレットなどを各種取り揃えているので、さまざまな画面サイズ、入力方式、アーキテクチャで皆さんのアプリを試していただけます。  皆さんのアプリを実行してテストしていただけるよう、Windows 8 デバイスを各種のフォーム ファクターで用意いたしました。 技術面のアドバイスは Windows 8 エキスパートから アプリを Microsoft の Windows エキスパートにお見せいただいて、必要なアドバイスを彼らから直接聞くことができます。皆さんのアプリが Windows ストアに無事提出されるよう、コーディングに関するヒントでお手伝いします。 デザインのアドバイスは、最先端で活躍するデザインのプロフェッショナルから アプリをもっと目立たせたいなどのデザインに関するヒントは、デザイナーやデジタル マーケティング企業に聞きましょう。アプリの試作版や完全版をお見せいただければ、アプリのレイアウト、ライブ タイル、ナビゲーション、UI 要素などにどのように手を入れればよいかアドバイスさせていただきます。 Windows…


位置情報とセンサーを使った魅力的なアプリの開発

Windows 8 のタブレットやコンバーチブル PC 向けアプリの開発では、センサーや位置情報を提供する最新のハードウェアとソフトウェア サービスを利用できます。これらのハードウェア機能を活用すれば、アプリに付加価値を追加できるだけでなく、アプリを楽しく便利なものにすることができます。 たとえば、ユーザーの現在の位置情報に基づいて 3D 環境を読み込み、3D 空間の中でタブレットを (パンや傾きの操作で) 動かして 3D の世界を自由に移動できるアプリを考えてみましょう。以下に紹介するのは、パノラマ写真アプリ Photosynth の画像です。Photosynth では、センサー フュージョンによってデバイスの方向と Photosynth のパノラマ写真が自然に連動します。センサー フュージョンは、加速度センサー、ジャイロスコープ、磁気センサーの出力を組み合わせて、それぞれのセンサー単体では実現できない優れたエクスペリエンスを提供します。センサー フュージョンは Windows.Devices.Sensors.OrientationSensor ランタイム型によって公開されます。 ユーザーがデバイスをまっすぐに持つと、Photosynth のパノラマ写真を正面からの視点で見た景色になります。 ユーザーがデバイスを上に向けると、パノラマ写真の中の視点も上を向きます。 デバイスを左右に動かしたときも同様の対話処理が行われます。パノラマ写真内のカメラがタブレットの方向に完全に連動しているような感じです。一人称視点のゲーム、地図を活用するエクスペリエンス、歩行者の道案内など、この機能を使ってできることはいくつも思い浮かぶでしょう。ここでは、このようなタイプの機能を Windows 8 向けに実装する方法について説明したいと思います。 センサーを使う理由 2011 年秋に開催された //Build カンファレンスでは、位置情報とセンサーに対する Windows 8 のハードウェア サポートの詳細 (英語) と、位置情報とセンサーのための Windows ランタイム API の情報 (英語) について私たちのチームから発表させていただきました。Windows 8 では、センサー サポートによって、画面の自動回転や輝度の自動調整といったシステム レベルの機能をユーザーが利用できるようになります。これらはもちろんすばらしい機能ですが、本当の魅力は位置情報対応アプリやセンサー対応アプリにあります。Windows 8 では、経路案内やコンパスを使うシナリオ、カジュアル ゲーム、拡張現実、対話型モーション…


Consumer Preview 以降のアプリ開発者向けの変更点

またそのときが来ました。新しい Release Preview と新しい開発者ツールにより、Windows 8 は最終リリースに 1 歩近づきました。Consumer Preview と同じように、Windows 8 での開発エクスペリエンスをできる限り良いものとするため、エンジニアリング チームは開発プラットフォームの改良を重ねてきました。この記事では、取り組んできたいくつかの新機能について強調し、皆さんが既存の Consumer Preview アプリから Release Preview に移行するお手伝いをいたします。 Windows 開発プロセスに関して踏まえておきたいいくつかの点 Release Preview の新機能についてお話しする前に、チームが Release Preview マイルストーンにおける機能変更をどのように考えているかについていくつか説明しておきたいと思います。開発プロセスのこの時点で、Windows の大部分の機能はプラットフォームに組み込まれています。Release Preview における私たちの目標は、既存のエクスペリエンスを改良することです。 では、これは開発者の皆さんにとって何を意味するでしょうか。それは、Release Preview に見られる変更の大部分は Windows 8 の以前のリリースよりかなり小さいということです。新機能は、特定のニーズを満たすことを目的としています。変更の多くは、既存の Consumer Preview シナリオの動作を改善しているにすぎません。私たちは、プラットフォームのバグを修正し、パフォーマンスを高め (コードにわずかな変更を加えるだけで、アプリをこれまでより簡単に構築できるようにもしました)、結果に満足できる程度まで開発者エクスペリエンスを強化しました。 これは、Consumer Preview でのアプリ開発で得られた知識とスキルはすべて Release Preview でも十分に活用できることを意味しますので、皆さんにとってすばらしいことです。さらに、既存のアプリに加えなければならない変更が最小限で済みます。しかし、それと同時に開発プラットフォームがこれまでより改良されています。では、変更点を見ていきましょう。私たちが行ってきたことを気に入っていただけると思います。 アプリ設定の高優先度ローミング Windows 8 のアプリケーション データ (英語) を使うと、アプリ データのローミングにより、アプリ設定の “一度設定するだけで、どこででも使える”…


ピクセルを最大限に活用する – 表示状態の変更に適応する

Windows 8 のアプリは、さまざまな画面サイズとさまざまな表示状態で実行されます。ユーザーは、25 インチのデスクトップ モニターの側端にアプリをスナップすることもできますし、10 インチのワイドスクリーン タブレットの画面全体をアプリで埋めることも可能です。いずれの場合も、皆さんのアプリが利用可能なスペースを十分に活用することが望まれます。この記事では、アプリの現在のサイズと表示状態をコードで追跡する方法と、画面サイズと表示状態の変更を処理するために Windows 8 Consumer Preview でアプリを記述する方法について、ヒントを示します。 //build/ では、さまざまな画面シナリオに合わせてアプリを設計する方法について説明しました。たとえば、XAML に関する講演 (英語) や HTML に関する講演 (英語) をお聞きください。最近の Building Windows 8 ブログでは、画面のスケーリングの調査と設計に関する私たちの考えを少しお伝えしました。多くの場合、明示的なコードを記述しなくても、純粋なマークアップを使って画面サイズの変更に対応できます。しかし、アプリの表示状態 (英語) を追跡し (つまり、アプリが縦長モード、全画面モード、フィル モード、スナップ モードのどれであるか)、それに応じて反応するようにコードを記述することが必要になる場合があります。たとえば、HTML の ListView を使ってアイテムを表示する場合、次の図に示すように全画面モードでは GridLayout を使いますが、スナップ モードでは ListLayout を使います。XAML の場合、GridView コントロールと ListView コントロールを同様に切り替えることができます。このための方法を理解するために、まずはサイズ変更と表示状態の変更をコードで検出する方法を見てみましょう。 左の全画面表示状態では、GridLayout (HTML) または GridView コントロール (XAML) が使われている。 右のスナップ表示状態では、ListLayout (HTML) または ListView コントロール (XAML)…


優れたタイル エクスペリエンスを開発する (パート 2)

この記事のパート 1 では、タイルの更新を設計する方法と、ライブ タイルに表示するコンテンツに合ったテンプレートを選択する方法について学びました。その中でアプリの既定のワイド タイルをセットアップしたので、タイルの更新を始める準備ができました。今回は具体的なコードを見ていきましょう。最初に、Contoso Food Trucks アプリ タイルでポーリングをセットアップする方法について説明します。Web サービス側のコードがどのようになるかもお見せします。次に、アプリにセカンダリ タイルを追加して、「Windows 8 SDK: アプリのタイルおよびバッジのサンプル」(英語) に含まれている NotificationsExtensions ライブラリを使ってそのタイルを更新します。では、早速始めましょう。 通知の配信方法の選択 タイルをどのように表示すればよいかはわかったので (パート 1 を思い出してください)、タイルを更新するタイミングを決める必要があります。 アプリでタイルを更新するには、4 とおりの方法があります (デベロッパー センターの「通知の配信方法の選択」(英語) を参照してください)。まず、ローカル通知を使ってタイルを更新することができます。これは、アプリの実行中に情報が変化する場合に便利です。また、アプリでタイルとトーストの更新をスケジュールして、正確な時刻に更新が行われるようにすることもできます。さらに、アプリが実行中でない場合にクラウドからタイル通知をプッシュまたはポーリングして、タイルを更新する方法もあります。ポーリングは、更新頻度の低いブロードキャスト コンテンツに適しています。プッシュは、すぐに届ける必要のあるトースト通知を送信する場合や、ユーザーごとに個別にタイルを更新する場合に適しています。この記事では、ポーリング更新とローカル更新に焦点を絞ってお話しします。 近くにいるフード トラックのためのポーリング 私たちのアプリでは、タイルの更新に 2 種類の異なる情報を使います。最も重要なのは、ユーザーが設定した既定のランチの場所の近くにいるフード トラックの情報です。アプリの実行時、ユーザーは、ランチを探す既定の場所をアプリ内で設定します。私たちは、その既定の場所の情報を使ってタイルを更新し、近くにいるトラックをユーザーに知らせます。下の画像は、この記事のパート 1 に掲載したアプリのタイルです。それでは、ポーリングを使ってこれらのタイルをアプリのタイルに表示する方法を見ていきましょう。     通常、フード トラックは、1 日中同じ場所に停まっているか、少なくともランチの時間帯は移動しません。フード トラックの場所はそれほど頻繁には変わらないので、タイルをリアルタイムで更新する必要はありません。このため、今回はプッシュ通知を除外することができます (プッシュ通知は、タイミングが重要となる通知に向いています)。ただし、このデータは少なくとも 1 日 1 回は更新したいので、定期的な通知を使って Web サービスをポーリングし、変更をチェックするのが最適な方法と考えられます。 クライアント側の実装: 近くにいるフード トラックのためのポーリング 定期通知をセットアップするクライアント側の実装は、ほんの数行のコードで完了します。ユーザーがアプリを起動するかアプリに切り替えたら、そのつど TileUpdater.startPeriodicUpdate (英語) を呼び出します。これにより、API…


優れたタイル エクスペリエンスを開発する (パート 1)

ライブ タイルは、ユーザーにアプリを継続的に使ってもらうようにするための優れた手段の 1 つです。この記事では、ポーリングとローカル API を使ってアプリのライブ タイルを更新し、Windows 8 のスタート画面上でアプリの魅力を直接アピールする方法について説明します。タイルを通して、アプリ側で発生している最も重要なことを最前線で伝えることができます。アプリ タイルはアプリの非常に重要な要素であり、ユーザーの目に最も多くさらされる部分でもあります。タイルを最大限に活用して、ユーザーに使い続けてもらえるアプリを作りましょう。 この記事では、サンプル アプリを通して次の方法について説明します。 タイルの更新を設計する タイルのコンテンツに最適なテンプレートを選択する アプリが実行されていない場合は、クラウドからポーリング通知を実行してタイルを更新する アプリの実行中は、SDK (「Windows 8 SDK: アプリのタイルおよびバッジのサンプル」(英語)) に含まれる NotificationsExtensions ライブラリを使ってタイルを更新する Contoso Food Trucks アプリについて では、サンプル アプリ Contoso Food Trucks について説明しましょう。ユーザーはこのアプリを使って、移動中のフード トラック (移動型レストラン) の情報を確認することができます。このアプリは、Metro スタイル アプリ用 Web サイトの事例 (英語) として紹介したものと同じアプリです。今回の記事では、このアプリにライブ タイルを追加する方法について説明します。 アプリの一番のセールス ポイントを知る タイルに表示すべきコンテンツの内容や、更新頻度を決めるうえで有効なことは、アプリの一番の長所を知ることです。 Contoso Food Trucks アプリが最も得意とするのは、ユーザーのお気に入りのフード トラックを探して追跡することと、ユーザーの近くにいるトラックを見つけることです。そこで、Contoso Food Trucks タイルの目標を次のように設定しましょう。 特定の場所の近くにいるフード…


パフォーマンス キラーに立ち向かう: Metro スタイル アプリの一般的なパフォーマンスの問題

高速で滑らかなアプリの作成に役立つメソドロジやツールを紹介した前回の記事「Metro スタイル アプリのパフォーマンスを改善する方法」を読んでいただけたかと思うので、今回は、アプリでこれまで目にした一般的なパフォーマンス キラーについて詳しく説明したいと思います。この記事では、JavaScript ベースでも XAML ベースでも、Metro スタイル アプリのパフォーマンスを計測可能なかたちで顕著に改善できた、最も有効な指針を提供します。また、使用している言語に関係なく、大きな違いを生む 5 つの具体的なプラクティスを紹介します。さいわい、これらのプラクティスは、巧妙なトリックや複雑な操作を利用しません。ここで紹介するガイドラインに従うことで、アプリのパフォーマンスは大幅に改善すると確信しています。コメントで、この記事のガイダンスについての感想をお知らせください。また皆さん独自のヒントも紹介していただけるとさいわいです。 基本のガイダンス ネットワーク コンテンツではなく、パッケージしたコンテンツを基本的に利用します。 ローカルのイメージやファイルは、ネットワーク上のイメージやファイルよりも、例外なく速く取得できます。 アプリが “ライブ” イメージを読み込む必要がある場合は、ライブ イメージの取得中に、ローカルのイメージをプレースホルダーとして使用することをお勧めします。 ローカル イメージを適切なサイズに調整します。 イメージが必ず同じ解像度で表示される場合は、その解像度にあらかじめ調整したイメージをパッケージします。これにより、イメージが表示されるたびに、実行時にサイズを調整する必要がなくなり、アプリのライフサイクルを通じて何度も発生したはずのパフォーマンスの低下要素を排除できます。 イメージが表示される解像度が複数ある場合は、大きな理由がない限り、イメージの複数のバージョンをパッケージします。 最近のアプリにふさわしく、起動時間は短くします。 ネットワーク操作は、必ずスプラッシュ スクリーンが消えてから実行するようにします。 アプリのアクティブ化中は、データベースなどサイズの大きいメモリ内オブジェクトの読み込みを遅らせます。 実行負荷の高いタスクがある場合は、カスタムのスプラッシュ スクリーンまたはシンプルなランディング ページを用意して、アプリがこのようなタスクをバックグラウンドで実行できるようにします。 Windows 8 はさまざまなデバイスで実行されるので、ユーザーの解像度に合ったメディア コンテンツを使用します。 読み込んだコンテンツがユーザーの解像度に対して小さすぎると、画像の忠実度が失われます。 読み込んだコンテンツがユーザーの解像度に対して大きすぎると、システムのリソースに不要な負荷がかかります。 アプリの応答性を重視します。 同期 API によって UI スレッドをブロックしないようにします。非同期 API を使うか、(別のスレッドからなど) ブロックをしないコンテキストで同期 API を呼び出します。 時間のかかる計算は、UI スレッドではないスレッドに移動します。遅延は 100 ミリ秒を超えると、ユーザーに認識される可能性が高いので、この点は重要です。 時間のかかる作業は小さく分けて、合間に UI スレッドがユーザー入力をリッスンできるようにします。 Web…


Metro スタイル アプリのパフォーマンスを改善する方法

動作の遅いアプリや、応答性の悪いアプリを好む人はいません。ユーザーは、タッチ、タップ、クリック、ジェスチャ、キーの押下に即座に反応するアプリを求めています。アニメーションがスムーズに動き、音楽やビデオの再生、一時停止、再開を軽快に行うことができ、ユーザーの操作にアプリが追いつくのを待つ必要もない、そんな動作をユーザーは期待しています。この記事は、あなたのアプリを “高速で滑らか” にする方法を紹介するシリーズの第 1 回です。 エンジニアリング チームでは、Metro スタイル アプリのパフォーマンス確保の方法について、長期間にわたり検討されました。その過程で私たちは、高速で滑らかなパフォーマンスを実現するためにプラットフォームで何ができるかを見いだし、優れたエクスペリエンスを提供するアプリの構築において何が有効で何が有効でないかも理解しました。このブログでは、ユーザーにとって最良のエクスペリエンスを皆さんが構築するために役立つと思われる私たち自身が経験した苦いレッスンの一部をお伝えします。 パフォーマンスの心理学 パフォーマンスは、単にストップウォッチによる時間計測と効率的なアルゴリズムだけで決まるものではありません。パフォーマンスについて考えるとき、私は全体的な視点に立って、ユーザーがアプリの使用中にどのように時間が経過するかという点を考慮するようにしています。高速で滑らかとは、アプリにとって何を意味するのでしょうか。1 つの考え方として、ユーザーのエクスペリエンスを、知覚、許容、および応答性という 3 つのカテゴリに分類することができます。 知覚: いつになっても終わらない 知覚は、”高速で滑らか” のうちの “高速” の認識にかかわります。パフォーマンスに対するユーザーの知覚は、アプリ内でなんらかの作業を実行するためにかかった時間の長さが、ユーザーにとってどの程度好意的に感じられたかという点で定義されます。ユーザーの認識が現実と一致するのが理想的ですが、実際には、ユーザーに認識される時間の方が現実よりも重要である場合が多いのです。インストールが自動的に進んで終了することを期待して席を離れたのに、戻ってきたら途中で停止していて、あなたの応答を待つメッセージが表示されていた経験はありませんか。 1 つの処理について思い出されるステップが多いほど、速度は遅く感じられるものです。 するべきこと: 作業完了までにユーザーが実行する必要のある各アクティビティの間隔を短くする。 ユーザーに質問する必要がある場合は必ず、すべての質問を前もってたずねるようにし、また他に質問がないことを明確にする。 してはいけないこと: ユーザー アクティビティの間になんらかの処理時間が発生し、アクティビティが複数の期間に分断される。 許容: 楽しい時間は早く過ぎる 許容は、”高速で滑らか” のうちの “高速” と “滑らか” の両方にかかわります。知覚が経過時間に対するユーザーの記憶を測るものだとしたら、許容とは、その時間の経過がどの程度好意的に受け入れられるかを測る尺度と言えます。 操作の完了までにかかる時間がわからなければ、待ち時間は苦痛になるものです。たとえば、写真を編集するアプリを使っているとしましょう。フィルターを適用するコマンドをクリックしたら、アプリが応答しなくなりました。フリーズしたままで時間が過ぎていくと、たとえそれがほんの数秒だったとしても、すぐに我慢の限界に達してしまいます。 フォト アプリでは、フィルターを適用中であることを示す進捗状況バーや小さいアニメーションを追加して、この問題を解消しています。不明瞭なまま放置されるわけではないので、操作の完了までの待ち時間が長くなってもユーザーは許容してくれます。アプリは高速かつ滑らかに感じられるため、大きな違いになります。 するべきこと: アプリの中で、読み込みに長い時間 (1 秒以上) がかかる部分を特定する。 特定されたシナリオにおいて、ユーザーにとって先が見えない状況を取り除くか少なくする。 処理の進行状況と、完了までの予想時間をユーザーが視覚的に確認できるようにする。 UI スレッドがブロックされ、アプリがフリーズしたように見えるのを防ぐために、非同期 API を使用する。 してはいけないこと: ユーザーにフィードバックを提供せずに長時間処理を実行し続ける。 応答性: 反射 <…


Windows 8 デベロッパー キャンプで、アプリ開発にエキスパートのサポートを

ブログとフォーラムに寄せられたコメントや質問を読み、Metro スタイル アプリが多くの皆さんにご興味をお持ちいただいていることを実感していますが、それでもまだ、解消されていない疑問が多く残されているのではないでしょうか。そのような皆さんの悩みを解決するのにぴったりの場所が Windows 8 デベロッパー キャンプ (英語) です。デベロッパー キャンプは、デベロッパー センターの各種リソースを補完する目的で開催され、実際の技術に触れていただきながら解説することで、Metro スタイル アプリ開発者としての皆さんのスキルアップをサポートします。 Windows 8 デベロッパー キャンプは、皆さんのような開発者がだれでも参加できる、アプリ開発について深く学ぶための無料イベントです。アプリ開発のエキスパートと言葉を交わしながら学び、直接アドバイスをもらうことができます。既に現在、世界中のさまざまな場所でキャンプが開催されています。 キャンプのテーマは場所ごとにさまざまに異なりますが、開発プラットフォーム、Metro スタイル デザイン、Windows ストアの基礎知識についてはすべてのキャンプで共通して学習できます。タイルと通知を使ってアプリをもっと便利にする、Windows 8 のコントラクトと統合するといった、基礎知識からさらに踏み込んだ内容については、キャンプごとに異なるトピックを用意しています。 キャンプについてご興味をお持ちいただけたら http://www.devcamps.ms/windows (英語) にアクセスしてみてください。世界中で今まさに開催されているすべてのキャンプをご覧いただけます。現在お申し込みいただけるキャンプは 100 以上、さらに毎日次々に追加されています。キャンプは無料で参加できますので、スケジュールをチェックして興味のあるキャンプを見つけたら、ぜひお申し込みください。 Neil Hutson プラットフォーム エバンジェリズム担当シニア ディレクター


Windows ランタイムの非同期性により高速で滑らかなアプリにする

人間はもともと非同期な生き物です。このことは、私たちがアプリの反応に何を期待するかに直接影響を与えます。Windows ランタイム (WinRT) では、高速で滑らかな Metro スタイル アプリを構築するための一級市民としてこの非同期性が採用されています。Metro スタイル アプリを構築する場合、ある時点で非同期コードを記述する必要があります。この記事では、WinRT で非同期プログラミングがなぜ非常に一般的になっているかについてお話しし、アプリで非同期プログラミングを使用する基本的な方法やそのしくみの背景について説明します。 高速で滑らかなアプリは反応性が高くなければならない Windows アプリを使っていて応答が止まったことや、アプリがグレー表示になってドーナツ型のカーソルが回転したことは何回くらいありますか。間違いなく、予想される最悪の時間に思えます。さらに悪いことに、このような状況に陥ると、努力してきた作業がたくさん失われてしまう可能性があります。 ユーザーは、アプリがすべての対話的操作に応答することを期待します。お気に入りのニュース閲覧アプリを使うとき、ニュース フィードを追加したり、新しい記事を読んだり、新しい記事を保存したりします。アプリがインターネットから最新の記事を取得しているときでも、ユーザーがこれらの操作をすべて行うことができる必要があります。 これは、ユーザーがタッチを使ってアプリを操作しているときは特に重要です。ユーザーは、アプリが “指に吸い付かない” ことに気付きます。パフォーマンス上の小さい問題でも、ユーザー エクスペリエンスが低下し、高速で滑らかな感覚が失われる可能性があります。 ユーザーの入力時にアプリの応答が停止する場合、アプリは高速で滑らかとは言えません。では、アプリが応答を停止するのはなぜでしょうか。主な理由は、アプリが同期的であるということです。ある処理が終わるのを待っているとき (インターネットからデータを取得するなど)、ユーザーの入力には応答できません。 最近のアプリの多くは、ソーシャル Web サイトに接続したり、クラウドにデータを保存したり、ハード ディスク上のファイルを操作したり、他のガジェットやデバイスと通信したりします。これらの要因によって予測できないレイテンシが生じると、高速で滑らかなアプリの作成が難しくなることがあります。正しく構築しないと、アプリが外部環境の待機に使う時間が長くなり、ユーザーのニーズへの応答に使う時間が短くなります。 私たちが Windows ランタイム (WinRT) の API を設計し始めた頃、いつでもつながるこの世界に対応することが中心的な原則でした。高速で滑らかなアプリにつながる強力な API サーフェスを既定で提供することが重要と感じていました。 これらの目標を達成するため、Windows ランタイムで I/O にバインドされる可能性がある多くの API を非同期にしました。同期的に記述した場合、視覚的なパフォーマンスが低下する可能性が高いものがあります (実行に 50 ミリ秒以上長く時間がかかる可能性があるなど)。API へのこのような非同期アプローチにより、高速で滑らかなコードを既定で記述できるようになり、Metro スタイル アプリ開発におけるアプリの応答性の重要性が高まります。 非同期パターンに慣れていない方は、WinRT の非同期性を、ある人に電話越しにコールバック番号を教えることに置き換えてみてください。その人にコールバック番号を教えて電話を切り、必要な他の仕事を続けます。その人があなたと話す準備ができたら、教えてもらった番号であなたにコールバックできます。これが WinRT における非同期性の本質的なしくみです。 WinRT の非同期的な性質についてよく理解するため、まずこれらの非同期 API を直接的な方法で使う方法を見てみます。次に、WinRT に導入された非同期プリミティブ…