Windows 10
Windows 10 デバイス向け Windows アプリのビルドの概要
あらゆる種類の Windows デバイスで実行できる 1 つの Windows OS がついに実現します。これは、真のユニバーサル ハードウェア ドライバーを実現する単一の一デバイス プラットフォームであり、真のユニバーサル Windows アプリを実現する単一のアプリケーション プラットフォームです。これは、何年もの作成期間を経て成し遂げられた、エンジニアリング上重要な偉業です。
OS レベルでは、メンテナンスしやすい単一のアジャイル コード ベースを意味します。開発者にとっては、Raspberry Pi のようなモノのインターネット (IoT) デバイスから、スマートフォン、Xbox、タブレット、Microsoft Surface Hub、ノート PC、PC、高度なデバイス (Microsoft HoloLens など) に至るまで、あらゆる Windows デバイスに信頼性の高い統一 API サーフェイスが提供されます。図 1 に示すように、これは、ユニバーサル アプリ プラットフォーム (UAP) を備えた Windows 10 で、「一度書けば、どこでも実行できる」(WORA: write-once-run-everywhere) という公約が実現されることを意味します。
.jpg "すべての Windows デバイス ファミリで動作するアプリを実現するユニバーサル アプリ プラットフォーム")
図 1 すべての Windows デバイス ファミリで動作するアプリを実現するユニバーサル アプリ プラットフォーム
Windows 10 までの道のり
Windows が 1 つになることは、長い間待ち望まれてきました。2011 年までさかのぼると、マイクロソフトは、それぞれ 3 つの OS を備えた 3 つのプラットフォームを保持していました。PC とサーバーの OS は、Windows NT コード ベースを基盤に構築された Windows です。スマートフォンの OS は Windows Phone です。これは、Windows CE の流れを汲む OS で、サーフェイスレベルでは Windows NT と同じでしたが、コード ベースは異なります。Xbox 360 の OS は Windows NT ですが、10 年前に Windows NT からの別れ、独自の進化を遂げているため、こちらもコード ベースは独自のものです。
当時、マイクロソフトは、Internet Explorer を各プラットフォーム共通にすることに取り組んでいました。Windows コア、Windows プラットフォーム、UAP は影も形もありませんでした。前述の 3 つの OS に Internet Explorer を実装することには成功しましたが、かなりのエンジニアリング作業が必要でした。
Windows Phone 8 では、スマートフォンの Windows CE が Windows NT OS カーネルに置き換わります。こうして 1 つの Windows は、単一コード ベースに向けて動き出します。Windows、Windows Phone、Xbox 360 はすべて同じカーネルを利用するようになりますが、それぞれのコード ベースは依然独自のものです。2013 年、OS コアを Windows 8 と共有する Xbox One がリリースされます。これで、マイクロソフトは単一コード ベースにかなり近づいたように見えますが、OS は依然それぞれ独自のものです。
Windows 10 は、この 3 つの OS をまとめて、エンジニアリング作業を収束する機会になります。しかし、同時に、IoT、Microsoft HoloLens、Surface Hub、Windows デバイス ファミリに今後加えられるであろうメンバーなど、新たなテクノロジの登場により、より多くの Windows ターゲットを追加することが求められます。つまり、Windows 10 は、Windows、Windows Phone、Xbox だけでなく、今後登場するあらゆるプラットフォームをサポートする単一 OS になる必要があります。
マイクロソフトはこれを実現しました。Windows 10 は、フットプリントが少ない単一のコア OS になり、あらゆるデバイス ファミリで動作します。これは、ファイルに名前を付けて保存するような単純作業ではありませんでした。優秀な開発者がハードワークして、驚異的なスケジュールで実現した驚異のエンジニアリングの賜物です。Windows 10 は、UAP の実現に必須の単一コード ベースの OS です。今後マイクロソフト製品はすべて、Windows 10 を構成する単一コアに対して記述されることになります。
統一しても画一的ではない: コード ベースを 1 つのコア OS に統一することは、さまざまなデバイスの UI が 1 つになるということではありません。Windows Phone は、多くの人々に愛用される片手で操作できるスマートな インターフェイスを備えています。これは、Xbox の特徴である 10 フィート エクスペリエンスとはまったく別物です。同じことが、Surface Hub、Microsoft HoloLens、Raspberry Pi にも当てはまります。これらは、それぞれ独特のエクスペリエンスを提供することでその価値の大半を体現しています。しかし、OS と、そのライブラリ、ランタイム、フレームワークは同じです。デバイス プラットフォームもアプリケーション プラットフォームも同じです。ただし、UI とシェルの機能は独特で、デバイスごとに適切な使用モデルに合わせて微調整されるため、同じではありません。
理論上、このコア OS をブートし、アプリを実行することもできますが、このコア OS は 1 つのビルディング ブロックにすぎません。さまざまなフォーム ファクターを正しくサポートするには、デバイス特有のシェル コンポーネントをコア OS に追加します。たとえば、スタート メニュー、特定の HID サポート、デスクトップ アプリケーションなどのデバイス固有の機能を有効にするために必要な要素やパーツを追加します。このような追加コンポーネントによって、基本 OS が Windows、Server、Xbox、Microsoft HoloLens などの Microsoft 製品に見られるさまざまな OS SKU へと形成されていきます。
単一アプリケーション プラットフォーム: 手元に友人と一緒にプレイする楽しいゲームがあるとします。このゲームは、Microsoft アプリの最新イノベーションを駆使していますが、ターゲットは Windows 10 ではないといいます。どういうことでしょう。Windows の次世代アプリのターゲットは OS ではありません。ターゲットは、アプリケーション プラットフォームです。Windows では、すべての Windows デバイス間で一貫性が確保される、アプリケーション モデルと API サーフェイスを兼ね備えているのが UAP です。
UAP はランタイムではありません。Windows アプリは、マネージ言語 (Visual Basic や C# など) で作成されたとしても、他のアプリと同様、機械語にコンパイルされます。その機械語はランタイム内部では実行されません。ランタイムを必要ともしません。UAP はデバイス間の共通 API サーフェイスなので、UAP をターゲットにするということは、API の特定の API セットとバージョンをターゲットにするということです。
Windows のアプリやゲームは、使い慣れたツールやテクノロジを使用してビルドします。マネージ言語で記述された Windows アプリは相変わらず Microsoft .NET Framework を利用します。.NET Framework 自体は、インターフェイス、基本クラス、ヘルパー メソッドの集合体にすぎません。UAP をターゲットにするマネージ アプリで使用する .NET Framework は .NET Core と呼ばれ、これは完全版 .NET Framework のサブセットです。この .NET Core を補うために、UAP をターゲットにするアプリで使用する大半の API は Windows ランタイムに含まれています。この API はマネージ言語だけでなくすべての言語で利用できるようになっています。
あなどれない XAML: 今回はデモに XAML アプリを使用します。ただし、Windows 8 と同様 UAP でも、DirectX アプリや JavaScript アプリ (Windows Web アプリ) がサポートされます。とは言え、XML の新たな利用価値に目を向けることも大切です。XAML は、Windows Presentation Foundation (WPF)、ブラウザーや Windows Phone の Silverlight、現在の Windows UI プラットフォーム (以前のコード ネーム "Jupiter" ) など、多くの Microsoft プラットフォームに重要な要素です。
現在 UAP アプリ ファミリの一員となった Microsoft Office 2016 は、UI テクノロジに XAML を使用しています。この関係により、マイクロソフトやサードパーティの開発者は自身の Windows アプリに、豊富な機能やコントロールを備えた XAML プラットフォームを利用するようになっています。
スタート メニューやアクション センターなど、多くの新機能が導入された Windows デスクトップ シェルも、UI テクノロジに XAML を使用しています。この関係から、XAML プラットフォームは非常に高いパフォーマンスを発揮するようになっており、超高速のレンダリングが実現されます。
XAML に関して言えば、マイクロソフトはすべてにこれを利用しようとしています。フォトのような重要な OS アプリの多くや、ヘルスケアなどの MSN アプリも XAML UI プラットフォームを利用して、リッチな機能を実現しています。すべての開発者は、同じリッチな機能を自身の Windows アプリに利用できます。マイクロソフトのアプリを見れば、何ができるかわかります。すべての開発者にとっては、API サーフェイス領域だけでなく、XAML UI プラットフォームも同じになります。
ソフトウェア開発者にとっての価値: あらゆるデバイスで実行できるアプリを記述するだけでは不十分です。ユーザーに真の価値を提供するには、Windows アプリがさまざまなデバイスで真価を発揮する必要があります。UAP の拡張性により、すべてのデバイスで実行される単一バイナリに、デバイス固有のコードを含めることができます。
UAP を使って単一バイナリにするだけでなく、スマートフォン、タブレット、デスクトップ、Xbox の各アプリを登録するストアを 1 つにします。エクスペリエンスがシンプルになります。収益化方法も簡素化されます。マーケットプレースでの成功を評価する尺度も単純になります。
この 1 つのストアとプラットフォームにより、アセットを適切に配置できるようになります。つまり、Xbox エクスペリエンスをターゲットにするアセットがスマートフォンに送り込まれることがなくなります。特定の解像度やスケールをターゲットにするアセットをパッケージ化する Windows 8 の機能は UAP が担当します。
これまでどおり、開発者が制御できます。UAP がすべての Windows デバイスをサポートするからといって、すべての Windows デバイスをターゲットにする必要はありません。Windows アプリがどのデバイス ファミリをターゲットにするかは開発者が選択します。自身の Windows アプリのターゲットをスマートフォン専用、Xbox 専用、HoloLens 専用にすることも可能です。開発者が選択したデバイス ファミリにアプリを提供する役割は、Windows ストアが担当します。
その価値は、ターゲットが広がることだけでなく、全体的なエクスペリエンスが容易になることにもあります。Visual Studio や Blend for Visual Studio など、使い慣れた好みのツール セットを利用できます。JavaScript、.NET Framework (Visual Basic や C#)、C++/CX など、いつもの言語を使用できます。開発者や開発チームは、これまでどおりに Windows アプリをビルドできます。
多くの考慮事項
偉大な力を手に入れれば、伴う役割も大きくなります。UAP により、Windows アプリはあらゆる種類の Windows デバイスで実行できるようになります。これは素晴らしいことですが、注意しなければならないことも生じます。すべてのデバイスが同じ UX を提供するわけではありません。つまり、Web アプリに使用するレスポンシブ Web デザイン (RWD) 技法の多くを同じにするとしても、用途が異なるさまざまなデバイスでアプリを実行する場合は、アプリのワークフローをじっくりと考える必要があります。UAP が可能にするのは、さまざまなデバイスをサポートすることだけです。すべてのデバイスで優れた UX をビルドするのは開発者や設計者の仕事です。
マイクロソフトは、レスポンシブかつアダプティブな Windows アプリをビルドできるように、多くのツールを提供します。Visual Studio では、設計時に縦横比、スケール、サイズのシミュレーションを行えるようにします。また、ハードウェアを所有していなくても、特定のデバイス ターゲットをシミュレーション (場合によってはエミュレーション) することもできます。これにより、開発中に Windows アプリをテストして、エクスペリエンスを強化できます。
XAML ツールボックスには新しいコントロールや拡張機能が用意されているため、すべてのデバイスとすべてのサイズのディスプレイに美しく表示されるレスポンシブかつアダプティブなインターフェイスを作成できます。たとえば、XAML 開発者にとっては目新しい、RelativePanel があります。RelativePanel は、Grid や StackPanel などのレイアウト コントロールと同様に Panel から継承されますが、設計者や開発者が子要素を他の子要素と相対的に配置できるようにします。これを利用する XAML ビジュアル ツリーは、レンダリングがシンプルになり、レイアウトの変化に応じた操作が大幅に簡素化されます。表示状態も XAML 開発者向けに強化され、レイアウトの変化への対応が簡素化されています。
重要なのは、複数のデバイスをターゲットにする Windows アプリを作成することは、各デバイスに共通の最小限の機能を作成することではないということです。UI や機能セットもリッチにします。Windows.Foundation.Metadata.ApiInformation 名前空間を使用したランタイム チェックを利用して、あらゆるデバイスで最高の UX を実現するために、デバイス固有の機能をアプリに取り入れます。新しい機能や 1 つにまとまったコントロール群は、夢を大きく広げるために必要なビルディング ブロックにすぎません。
Windows アプリのしくみ
ここからは、すべてのデバイス ファミリで実行される Windows アプリの作成に不可欠なテクニックを見ていきます。ここでは、Windows 8.1 Windows ランタイム (WinRT) と XAML を使ったアプリ開発を理解していることを前提とします。Windows アプリは、このようなアプリが進化したものです。Microsoft Virtual Academy (aka.ms/w8learn、英語) のラーニング コースにある多くの資料を参考にしてください。ここでは、複数のデバイス ファミリで Windows アプリを実行するための UAP の新機能に注目します。
Visual Studio 2015 の [新しいプロジェクト] ダイアログで、ノードを [テンプレート]、[Visual C#]、[Windows] の順に展開すると、"空のアプリケーション"、"クラス ライブラリ"、"Windows ランタイム コンポーネント" など、複数のテンプレートが表示されます。Windows アプリをビルドする場合は "空のアプリケーション" テンプレートを使用します。"クラス ライブラリ" テンプレートと "Windows ランタイム コンポーネント" テンプレートでは、他のプロジェクトで再利用するために、UI とロジックをカプセル化できます。"クラス ライブラリ" テンプレートは UAP 以外のアプリをサポートしますが、マネージ言語に限定されます。"Windows ランタイム コンポーネント" は複数の言語 (JavaScript や C++/CX など) で共有できますが、パブリック API サーフェイスを制約する規則があります。
今回のサンプルには、"空のアプリケーション" を選択します (図 2 参照)。
.jpg "既定で、Windows アプリに使用される \"空のアプリケーション\" テンプレート")
図 2 既定で、Windows アプリに使用される "空のアプリケーション" テンプレート
他のすべてのテンプレートはどこにいったのでしょう。Windows 8 と同時にリリースされた "ハブ アプリケーション" テンプレートについて考えます。多くの開発者がこのテンプレートを使用しました。多くの開発者がこのテンプレートをコピーしました。その結果、"よく似た" アプリがたくさん開発され、Windows ストア内での見た目の一貫性は生み出されましたが、エコシステムの多様化には貢献しませんでした。そこで登場したのが "空のアプリケーション" テンプレートです。開発者は、見た目の一貫性を保ちながら、プラットフォーム固有のインターフェイスを作成できるようになります。コミュニティ ベースの多くのテンプレートが、Visual Studio ギャラリーに既に登場し始めています。筆者が作成した Template10 もその 1 つです。
最初のアプリケーション: これで最初の Windows アプリが作成されます。UI は空ですが、あらゆる Windows デバイスで実行できるようになっています。Visual Studio ソリューション エクスプローラーを見ると、基本 Windows アプリがいかにシンプルかがわかります。基本 Windows アプリは、App.xaml と、初期 UI 用の 1 つの MainPage.xaml ファイルを含む単一プロジェクトです。
ソリューションには、他にも見慣れたサポート ファイルが含まれています。Package.appxmanifest は、ユーザーの位置情報、カメラへのアクセス、ファイル システムなど、アプリが利用するユーザーのデバイス固有の機能を宣言します。XML スキーマが拡張されていますが、Windows 8.1 ユニバーサル アプリ用の appxmanifest ファイルとほぼ同じです。
2 つのヘッドという考え方はどうなったのでしょう。Windows 8 ユニバーサル アプリでは、Phone ヘッド プロジェクトと Windows ヘッド プロジェクトの 2 つが必要でした。UAP では複数のヘッドは必要ありません。代わりに、インターフェイスをアダプティブにして、Windows アプリを実行するデバイスに応じて調整します。ただし、開発チームのワークフローに適している場合は、複数ヘッドのソリューションを作成できることも確かです。どちらのアプローチも等しくサポートされます。
コンテンツを含める: MainPage.xaml を開くと、Visual Studio XAML のデザイン時エクスペリエンスが改善されていることがわかります。デザイナーの機能が豊富になり、速度が向上しています。縦横比やスケールのシミュレーションを行う機能が強化されています。ツール自体も拡張されています。ここで、図 3 に示す簡単な XAML を追加してみましょう (このサンプルを提供してくれた同僚の David Crawford に感謝します)。
図 3 シンプルな方法でインターフェイスをレイアウトできる RelativePanel
<Grid Background="{StaticResource EggshellBrush}">
<RelativePanel x:Name="PromoArea">
<Image x:Name="BannerImage" HorizontalAlignment="Right"
Height="280" Stretch="UniformToFill"
Source="Assets/clouds.png"
RelativePanel.AlignRightWithPanel="True"/>
<Grid x:Name="BannerText" Margin="24"
Background="{StaticResource BlueBrush}">
<StackPanel Margin="12" HorizontalAlignment="Stretch">
<TextBlock x:Name="Headline" Text="Come fly with us"
Margin="0,-32,0,0" FontSize="48"
Foreground="{StaticResource EggshellBrush}"
FontFamily="{StaticResource LustScriptFont}" />
<TextBlock x:Name="Subtitle" FontSize="21.333"
Foreground="{StaticResource EggshellBrush}"
FontFamily="{StaticResource DomusTitlingFont}">
<Run Text="Fly return to London"/>
<LineBreak/>
<Run Text="For only $800"/>
</TextBlock>
</StackPanel>
</Grid>
</RelativePanel>
</Grid>
図 3 のコードは、架空の航空会社向けの簡単なアプリのページ ヘッダーを作成します。具体的には、新しい XAML RelativePanel を利用して、単純な方法でインターフェイスを再配置できるようにしています。この RelativePanel は、ページの右側にバナー画像を配置し、航空会社の最新サービスを表示するグリッドを含みます。
アセットの追加: この XAML は、Assets フォルダーに追加した 3 つのファイル (画像ファイル Clouds.png と、2 つのカスタム フォント DomusTitlingFont.ttf と LustScriptFont.ttf) を参照します。フォント リソースとカスタム ブラシ リソースは、App.xaml で以下のように宣言されています。
<Application.Resources>
<SolidColorBrush x:Key="BlueBrush" Color="#FF1C90D1"/>
<SolidColorBrush x:Key="EggshellBrush" Color="#FFFAFFF7"/>
<FontFamily x:Key="LustScriptFont">
Assets/Fonts/LustScriptDisplay.otf#Lust Script Display
</FontFamily>
<FontFamily x:Key="DomusTitlingFont">
Assets/Fonts/DomusTitling.otf#Domus Titling
</FontFamily>
</Application.Resources>
これらのファイルは、本稿付属のコード ダウンロードに含めてあります。
ビットマップ画像は 1 つのスケールのものしかありません。高い解像度のデバイスに対応する場合は、アセットのスケール変換を行い、適切な倍率を指定します。したがって、他の倍率用のアセットをダウンロードすることなく、あらゆるユーザーに最高の視覚効果を提供できます。
デバイスでの実行: MainPage.xaml に戻り、UI を具体的なかたちにします。Visual Studio デバイス ターゲットのドロップダウンから、アプリを実行するターゲットを選択します。選択肢として、Windows Simulator (タッチ テスト用)、ローカル コンピューター、リモート コンピューター (ARM のテスト用) などがあるのがわかります。このリストには、スマートフォンのエミュレーターもあります。ローカル コンピューターを選択して実行してから、スマートフォンのエミュレーターの 1 つを選択して実行すれば、それぞれ独自にコンパイルすることなく、Windows アプリがさまざまなデバイスで実行されることを確認できます。
ローカル コンピューター (PC のデスクトップ) で Windows アプリを実行すると、ウィンドウ内でのエクスペリエンスになり、Windows 8 の全画面エクスペリエンスにはならないことがわかります。これは、アプリが Windows 10 のデスクトップ SKU で実行されるためです。Windows 10 のモバイル SKU で実行すれば、アプリが全画面で起動され、使いやすいタッチ操作によるナビゲーションが可能になります。ただし、タブレットやコンバーチブル型ノート PC の Continuum インターフェイスによるタッチ エクスペリエンスを選択すると、Windows 10 のデスクトップ SKU でも Windows アプリが全画面で起動されます。
アダプティブ インターフェイス: Windows アプリはどちらのデバイスでも実行されますが、よく見ると、スマートフォンの小型画面では UI がやや見劣りします。ヘッダー テキストが小型画面に大きすぎ、途切れています。これは、この Windows アプリに使用できるさまざまなデバイスでの UX をテストして改良するという、長い作業の始まりを意味します。
スマートフォンの幅の狭い画面を検出したら、ヘッダーのレイアウトを変更します。ただし、検出するのはスマートフォンであることではなく、画面の幅です。そうすれば、デスクトップでもスマートフォンでも画面幅が狭い状態でのエクスペリエンスに対応できます。
スマートフォンであることを検出する API はありません。ただし、スマートフォンや小型タブレット特有の片手操作が設計上必要であれば、カスタム表示状態トリガー (ここでは説明しません) で物理デバイスの対角線の長さをテストできます。
表示状態は XAML で以前から使用されています。Visual State Manager により、開発者や設計者は、さまざまな表示状態 (さなざまな画面レイアウト) を定義して、実行時にこれを切り替えることができるようになります。UAP では新しく Visual State Adaptive Triggers が提供されます。これにより、表示状態をプログラムで切り替える必要がなくなります。XAML で必要な表示状態を宣言するだけで、実際の作業は基盤となるプラットフォームが行います。
そこで、MainPage.XAML の XAML を変更します (図 4 参照)。
図 4 アダプティブ インターフェイス用の規則の宣言をサポートする XAML
<Grid Background="{StaticResource EggshellBrush}">
<VisualStateManager.VisualStateGroups>
<VisualStateGroup x:Name="WindowStates">
<VisualState x:Name="NarrowState">
<VisualState.StateTriggers>
<AdaptiveTrigger MinWindowWidth="1"/>
</VisualState.StateTriggers>
<VisualState.Setters>
<Setter Target="BannerImage.Height" Value="120"/>
<Setter Target="BannerText.(RelativePanel.Below)"
Value="BannerImage"/>
<Setter Target="BannerText.Width" Value="660"/>
<Setter Target="BannerText.Margin" Value="0,0,0,24"/>
<Setter Target="Headline.FontSize" Value="28"/>
<Setter Target="Subtitle.FontSize" Value="12"/>
</VisualState.Setters>
</VisualState>
<VisualState x:Name="MediumState">
<VisualState.StateTriggers>
<AdaptiveTrigger MinWindowWidth="660"/>
</VisualState.StateTriggers>
<VisualState.Setters>
<Setter Target="BannerImage.Height" Value="180" />
<Setter Target="BannerText.(RelativePanel.AlignTopWith)"
Value="BannerImage"/>
<Setter Target="Headline.FontSize" Value="28"/>
<Setter Target="Subtitle.FontSize" Value="14"/>
</VisualState.Setters>
</VisualState>
<VisualState x:Name="WideState">
<VisualState.StateTriggers>
<AdaptiveTrigger MinWindowWidth="1000"/>
</VisualState.StateTriggers>
<VisualState.Setters>
<Setter Target="BannerText.(RelativePanel.AlignTopWith)"
Value="BannerImage"/>
</VisualState.Setters>
</VisualState>
</VisualStateGroup>
</VisualStateManager.VisualStateGroups>
<RelativePanel...
図 4 では、NarrowState、WideState、MediumState という 3 つの表示状態を宣言しています。この 3 つの表示状態は、異なる範囲の画面幅に対応します。サポート対象のターゲット デバイス ファミリに必要な数の表示状態を自由に作成できます。表示状態に使用する名前に意味はありません。
この XAML では Visual State Setter の例も示しています。これも UAP の新機能で、ストーリーボード アニメーションのオーバーヘッドを必要としないで、個別のプロパティ値を設定できるようにします。上記の XAML では、このセッターを使用して子要素の RelativePanel の添付プロパティを設定することにより、RelativePanel 内での子要素の相対位置を変更しています。上記では、BannerImage の高さと text 要素のフォント サイズも変更しています。表示状態を準備しておけば、インターフェイスは狭い幅の画面に合せてその形状を変化させます。実行して確認してみましょう。
図 5 は、画面幅の変化に合わせて UI が変わるようすを示しています。Windows アプリでは、表示状態トリガーを利用して、ユーザーにとって最適な方法で要素を調整できます。
.jpg "画面幅の変化への対応")
図 5 画面幅の変化への対応
このサンプルの完全版 (本稿付属のダウンロードに収容) では、UI の開発がさらに進み、RelativePanel と表示状態トリガーによるアダプティブ UI を実装する例も追加で提供しています。
アダプティブ コード: UI はさまざまな画面に適合するようになりますが、デバイス間の違いは画面のサイズだけではありません。たとえば、スマートフォンには、戻るボタンやカメラ ボタンなどのハードウェア ボタンがあります。PC など、こうしたボタンを用意していないプラットフォームもあります。既定の UAP には Windows アプリに必要な多くの API サーフェイスが用意されていますが、デバイス固有の機能は、外部アセンブリとまったく同様の、プロジェクトに追加する拡張 SDK のかたちで利用できるようになります (図 6 参照)。この拡張 SDKにより、デバイス固有の機能の広範なセットを利用できるようになります。ただし、このアプリを他の種類のデバイスで実行する場合に、こうしたデバイス固有の機能を無効にする手間はかかりません。
.jpg "プロジェクト参照を追加するのと同じくらい簡単な拡張機能の追加")
図 6 プロジェクト参照を追加するのと同じくらい簡単な拡張機能の追加
最も一般的なプラットフォーム拡張 SDK には、デスクトップ拡張機能とモバイル拡張機能の 2 つがあり、それぞれ Windows SKU 独特の機能を有効にします。モバイル拡張機能では、たとえば、ハードウェア カメラ ボタンの使用に必要な API が有効になります。
Windows Mobile SKU は、スマートフォンや小型タブレットで実行できます。ただし、タブレット (スマートフォンでさえ) がすべてハードウェア カメラ ボタンを備えているわけではありません。拡張 SDK によりボタンのサポートは有効になりますが、ボタンがデバイスに配置されることはありません。このため、実行時にデバイスの機能をテストしてから、拡張 SDK の機能を呼び出す必要があります。
モバイルやデスクトップのようなプラットフォーム拡張 SDK によって Windows アプリでデバイス固有の機能を利用できるようになるのと同様、Kinect for Windows やサードパーティ製ハードウェアなどの追加コンポーネントのサポートを追加するカスタム拡張 SDK があります。この拡張 SDK も、他の種類のデバイスで実行されるアプリに影響を与えることはありません。
では、デバイスの機能をチェックするにはどうすればよいでしょう。それには、Windows.Foundation.Metadata.ApiInformation クラスのメソッドを利用します。このメソッドは、現在のデバイスで型やメソッドがサポートされているかどうかをシンプルなブール値で返します。次のようなコードを使用して、Windows アプリでカメラ ボタンを使用できるようにします。
if (Windows.Foundation.Metadata.ApiInformation.IsTypePresent(
"Windows.Phone.UI.Input.HardwareButtons"))
{
Windows.Phone.UI.Input.HardwareButtons.CameraPressed +=
HardwareButtons_CameraPressed;
}
デバイスで拡張 SDK が有効になっている場合のみ、Windows.Phone.UI.Input.HardwareButtons コードの実行を許可しているのがわかります。条件コンパイルとは異なり、機能のテストの結果として、複数のバイナリが生成されることはありません。つまり、現在のデバイスの機能に応じて UX を強化したり、適切にダウングレードすることができます。これは単一バイナリを実現する強力なアプローチで、無限のバリエーションが生み出され、開発した Windows アプリをさまざまなデバイス ファミリで最大限に活用できるようになります。
まとめ
Windows 8 のユニバーサル アプリを快適に開発している方は、UAP をターゲットにする Windows アプリのビルドも簡単だと感じていただけるはずです。Windows アプリは Windows 10 をターゲットにするわけではありません。ターゲットは UAP です。その結果、Windows SKU とは切り離されます。UAP は、Windows とは別に独自のペースでバージョンが更新されます。つまり、Windows アプリは、Windows OS のバージョンが変わってもターゲットを再設定する必要がありません。Windows アプリは、1 つ以上のバージョンの UAP をターゲットにし、デバイスの機能をテストするのと同様に、各バージョンの機能をテストします。この柔軟なアプローチによって、将来の機能を利用する際にも明確かつ優れた方法が提供されます。
Windows アプリをビルドすれば、任意の Windows デバイスで実行できるようになります。ただし、実際には多くの注意事項を伴います。UAP によってアプリは実行できるようになりますが、UI やコードをアダプティブにして、最高の UX を実現するのは開発者や設計者の仕事です。デバイスごとに固有のバイナリをビルドするのであれば、それも可能です。ただし、複数種類のデバイスをサポートする 1 つの Windows アプリをビルドするのであれば、ツールやインフラストラクチャがすべて揃っているため、成功に向けての準備は整っています。
Jerry Nixon は、マイクロソフトに勤務するコロラド出身の開発者エバンジェリストです。Windows、スマートフォン、デスクトップ開発の講師を務め、講演を行っています。彼の経歴は Microsoft SQL Server 6.5 から始まります。"データベース開発者" という言葉が耳新しく、データ中心のソリューションを提供していた時代です。セキュリティの取り組みで市民海軍表彰を受けたのは、いずれ Microsoft CRM となるプロジェクトの開始前のことです。彼は、15 年間、マイクロソフトを中心にモバイル ソリューションをビルドしています。最近は、イベント、コミュニティ、大学で XAML やモビリティについて講演しています。余暇のほとんどは、スタートレックのキャラクターの経歴やエピソードのプロットを 3 人の娘に教えて過ごしています。
Andy Wigley は、マイクロソフトに勤務する英国出身の開発者エバンジェリストです。2012 年にマイクロソフトに入社するまでは、コンサルタントとして働き、モバイル アプリ開発コミュニティの有名なメンバーでした。10 年連続 Microsoft Most Valuable Professional (MVP) に選出されたことが彼の誇りです。彼は、人気の高い Windows Phone ジャンプスタート ビデオ (channel9.msdn.com、英語) でよく知られており、Jerry Nixon と共に Windows アプリ開発のフォローアップ ビデオ シリーズに楽しく取り組んでいます。