特集：XAMLファミリ共通開発のすゝめ（前編） Windows 8時代のGUI開発を考える 岩永 信之 2011/12/02
Page1 Page2 Page3

■WinRT

　Metroでは、.NET Frameworkにはクロス・プラットフォームで利用可能な最小限のクラスだけを残して、多くのクラスが「WinRT（Windows Runtime）」という別フレームワークに分離された。

　現在、スレート型のタッチ・デバイスへの対応がWindowsの最優先事項であるため、WinRTは差し当たってMetroからの対応となっている。しかし、今後は随時、同様の方針がほかの環境にも広がっていくことが予想される。

　そこで、このWinRTについても説明しておこう。

◆WinRTとは

　.NET FrameworkからWinRTとして切り離されたのは、大まかにいうと以下の2点だ。

• GUI部分など、環境依存の激しい部分
• ファイル、ネットワーク、カメラ、マイクなど、慎重な取り扱いが必要な部分

　この2点は、「GUIフレームワークの分岐」での説明したとおり、あまり共通化を考えない方がよい部分である。

　同時に、Figure 10に示すように、WinRTは、.NETからだけでなく、ネイティブ（C++）やJavaScriptからも参照できるようになっている（WinRT自身はネイティブ実装されている*7）。

Figure 10: WinRTとMetroアプリ

*7　「分離された」、「ネイティブ実装になった」などと言っても、.NET Frameworkからその差が見えるわけではない。.NET開発者にとっては、ただ単に「名前空間がSystem.WindowsからWindows.UIに変わったWPF」程度の認識でまったく問題ない。

●ネイティブ実装

　WinRTでは、.NET Frameworkではまだ不十分だったネイティブとマネージの間の溝を埋めようとしている。本稿の主題から外れるため、要点とキーワードの紹介のみとなるが、WinRTとともに以下のようなものが導入されている。

• 今までのCOMに足りなかったリフレクション相当の部分を埋める → IInspectableインターフェイス
• 面倒だったCOMの実装を簡素にする → C++/CX（Component Extensions）
• 面倒だった.NETからのCOM参照を簡素にする → WinMD（Windows Metadata）ファイル

●ストア配布

　「配布形態の差」で触れたように、Metroはストア（＝審査付きのオンライン販売。Metro用のストアの正式名称は未定）を通して配布される。

　審査付きのストアならではのセキュリティ・モデルとして、Metroでは、慎重な取り扱いが必要な機能に関して、アプリ登録時にマニフェストに宣言する方式を採る（宣言に虚偽があれば審査に落ちる）。宣言内容をストア上に表示することで、エンド・ユーザーが知らないところで勝手にユーザー・リソースが使われるというような問題を避ける。

　宣言が必要な項目に関しては、以下のページを参照してほしい。

• Access to user resources using the Windows Runtime

◆WinRTに見る.NET FrameworkとSilverlightの反省点

　ここまでの話で、現状の.NET FrameworkやSilverlightの反省点が見えてくる。少しまとめてみよう。

●GUI層のクロス・プラットフォームを狙いすぎない

　前述のとおり、クロス・プラットフォームを狙うのであれば、どうしても最大公約数的な機能になってしまう。それは単一ベンダでやるべきではなく、標準化ベースにすべきだろう。

　一方で、GUI層は、環境依存が激しく、変化も早い。標準化ベースでは、機能の不足や、標準化にかかる時間が問題になることも多い。従って、ベンダ手動によるプラットフォーム固有のアプローチも必要である。

　100％の共通化ができないとなると、せめて考え得るのは、一貫した開発スタイルを提供することで学習コストを下げることだろう。

●標準ライブラリに多くを含めすぎない

　現状の.NET Frameworkには、含んではいけないものまで含んでしまっていることに起因する問題もある。

○GUIとPowerShell

　2006年にPowerShellが公開されて以来、コマンドラインによる文字ベースのWindows管理ツールも充実してきた。

　ところで、.NET Frameworkには、バージョン1.0当初から「Windowsフォーム」というGUIフレームワークが含まれている。

　これで何が問題になるかというと、実はこれまで、Server Core（＝Windows Serverの、GUI抜きエディション）にPowerShellを含めることができなかったのだ。PowerShellが.NET Frameworkに、.NET FrameworkがGUIに依存しているためである*8。

　.NET FrameworkからGUI層を分離するというのは、Windows ServerのGUI脱却のためにも必要なのだ。

*8　実際には、Server Coreでもメッセージボックスなどは表示されるため、完全にGUIなしというわけではない。後から提供されたServer Core向けの.NET FrameworkにもWindowsフォームは入っている（一方で、WPF関連のクラスはすべて削除されている）。

○ファイル読み書き

　ネットワーク越しに気軽にアプリを実行できる昨今、慎重な取り扱いが必要なファイルの読み書きは、もはや標準ライブラリに含めるべきものではなくなった（Streamクラス（System.IO名前空間）など、一段階抽象度の高いものだけを標準ライブラリに含めるべき）。

　例えば、Visual Studio 11のさらに次の世代に向けて、コードネーム「Roslyn」というプロジェクトが進行中である。Roslynでは、C#をスクリプト言語として自由にアプリに組み込むことができる。

　C#をスクリプト言語として使う場合、使われてまずい機能を除外することも考えなければならない。その手っ取り早い方法は、不用意にアセンブリを参照しないことだ。

　ところが、現状の.NET Frameworkでは、Fileクラス（System.IO名前空間）が、mscorlibという、基礎中の基礎、実行に必須となるアセンブリに含まれてしまっている。除外したくても除外できないのである（.NET Coreならばこの問題は起きない）。もし、Fileクラスの利用を制限したければ、別途何らかの面倒な仕組みが必要になるだろう。

●共通型システムは.NET Framework以外でも有用

　「XAMLファミリ間の差」で、.NET Frameworkを実行環境とプロファイルを分けて考える話をしたが、もう1つさらに、共通型システムについても分けるべきだろう。共通型システムは、.NET Framework以外でも有用である。

　ITシステムが複雑化する現在、開発者の学習負担としては、プログラミング言語の文法が占める部分は少なく、ライブラリの使い方を覚えることが大部分を占めている。従って、複数のプログラミング言語から同じライブラリを参照するための共通型システムは非常に重要である。

　今までも、.NET Frameworkという閉じた世界においては共通型システムがうまく機能していた。しかし、この共通型システムは、.NET Frameworkだけで閉じるには惜しいのだ。.NET Framework以外でも、型に関するメタデータは共有できる。

■まとめ

　プラットフォームの性能を最大限に引き出すことを考えると、どうしてもGUIフレームワークの分岐が起きる。これは不可避だが、せめて考えるべき点として、以下のようなものが挙げられる

• 異なるGUIフレームワークでも、一貫性のある開発スタイルを採る
• モデルに関しては共通化する
• ビューとモデルの分離をきっちり行う
• GUIフレームワーク間で共有できる部分を把握する

■

　次回は、Portable Class Libraryを使った実際のクロス開発について、具体的に説明をしていこう。

INDEX
	特集：XAMLファミリ共通開発のすゝめ（前編）
	WINDOWS 8時代のGUI開発を考える
	1．“XAMLファミリ”／GUIフレームワークの分岐
	2．一貫性のある開発スタイル／XAMLファミリ間の差
	3．WinRT
	特集：XAMLファミリ共通開発のすゝめ（後編）
	MVVMパターンを使ったクロス・ターゲット開発
	1．ソース・コード共有の方法／サンプル・アプリ
	2．Portableプロジェクト／リンク・プロジェクト／個別プロジェクト

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）