まもなくやってくるWindows 8 時代のアプリ開発

岩永 信之

Windows 8

現在の状況と、来たる Windows 8

現在 とにかく多様化

ハードウェア x86/x64 と ARM デスクトップ / ノート PC 、 Slate 、 Phone

標準 vs プラットフォーム固有 間口の広さ ⇔ 表現力、性能、進化の速さ

言語・フレームワーク .NET 、ネイティブ（ C++ ）、 JavaScript

Windows 8/Windows RT ARM 対応、 Metro UI 、 WinRT

Windows 8x86/x64

Windows RTARM

CPUデスクトップ MetroUI

今まで通りの Windows• Win32 API を使う

提供はするものの…• Office などバンドル品のみ• 自由なアプリ配布無理

新環境• x86/x64/ARM 共通• ネイティブの場合、

3 バイナリ必要• WinRT API を使う• App Store 配布• 審査あり

Metro: 新 UI

デスクトップ（今まで通り）• マウスとキーボード操作• タスク バーとウィンドウ

Metro （新 UI ）• タッチ向け UI• 全画面、フリックで切り替え

OK

☎1

Metro UI と WinRT

☎1OK

デスクトップ Metro

Win32

伝統の API

C 言語スタイル

WinRT

新 API

OOP スタイル

主に Metro 用呼べなくはない（あまり意味ない）

主にデスクトップ用 一部だけ許可（ DirectX など）

Metro: XAML と HTML5 XAML か HTML5 で開発

Windows Kernel

WinRT （ Windows Runtime ） API

XAML HTML5

.NET C++ JavaScript

WPF や Silverlight と同じ開発スタイル 標準＋ WinRT API

多様化に対するささやかな抵抗

言語プロジェクション 言語 / フレームワークを超えてコンポーネント共有

WinRTコンポーネント

C++, C#, VBで書ける

C++ アプリ

Pro

jectio

n

CLR

Pro

jectio

n

C#/VB アプリ

Chakra

Pro

jectio

nHTML+JavaScrip

tアプリWindows

Metadata

.NET のメタデータを.NET 以外の世界に広げたも

の

C++ で書かれていても、.NET からは .NET クラスに見

える

WinRT

.NET の反省点と、 WinRT

ネイティブと .NET と WinRT WinRT = 振り子の真ん中

1990 年代ネイティブC++COM

2000 年代.NETC#, VB, F#, …

2010 年代WinRTネイティブ /.NET/JavaScript 連携

ネイティブ時代の課題

• メモリ管理が大変• セキュリティ保証が大

変• COM 大変• 複数 CPU 対応が大変

ネイティブ

全部をネイティブで書きたくな

い

ネイティブ→ .NET

• メモリ管理が大変• セキュリティ保証が大

変• 複数 CPU 対応が大変• COM 大変

ネイティブ

• メタデータ• メモリ自動管理• 中間コード

.NET

.NET 時代の課題

低層 API は必ずネイティブ 連携が面倒 .NET 向けラッパーの登場までにタイムラグ

• メタデータ• メモリ自動管理• 中間コード

.NET

手軽さを犠牲にしてでも性能が欲しい場面は残る• メモリ手動管理したい• CPU 依存の最適化をした

い

.NET→WinRT メタデータの適用範囲を拡大

.NET とネイティブが対等 ネイティブ API が即 .NET から使える JavaScript にも対応

• メタデータ• メモリ自動管理• 中間コード

.NET ネイティブ JavaScript

メタデータ WinMD （ Windows Matadata ）

ただし、現代風に再設計

言語プロジェクション 規約ベースで .NET/ ネイティブ /JavaScript 相互運

用 .NET の CTS （共通型システム）を、ネイティブと

JavaScript にも広げたもの WinMD （ Windows Metadata ）

相互運用のために必要なメタデータ ファイル形式的には .NET のメタデータ仕様と同じ .NET と比べると使える型に制限あり

壁のない世界 壁があっちゃいけない

サーバーとクライアント開発で 初心者とプロで

言語が違うからできない フレームワークの作法が違うからできない

言語やフレームワークを超えた相互運用

WinMD （ Windows Matadata ）

Not Only "Win" 壁があっちゃいけない

サーバーとクライアント開発で 初心者とプロで

言語が違うからできない フレームワークの作法が違うからできない

言語やフレームワークを超えた相互運用

WinMD （ Windows Matadata ）

あまり名前が良くない• WinRT 用なのは残念• Windows に閉じていい技術じゃない• 壁のない世界を Windows 以外にも欲しい

現代風に再設計 .NET を参考にしたオブジェクト指向 API

脱Win32 脱 Variant

非同期 API XAML UI

.NET を参考に 言われなければ .NET のライブラリかと間違うレベ

ル

型はしっかりしている（ Variant とかない） P/Invoke不要

using (IRandomAccessStream readStream = await sampleFile.OpenAsync(FileAccessMode.Read)){ using (var dataReader = new DataReader(readStream)) { var size = (uint)readStream.Size; var bytesLoaded = await dataReader.LoadAsync(size); var fileContent = dataReader.ReadString(bytesLoaded); }}

例

※IRandomAccessStream や DataReader が WinRT クラス

非同期 API WinRT の方針 :

スレッドをブロックするのは思った以上にコストになる UI スレッドを止めるとユーザーの印象悪い

同期処理するとまずい まずいものは最初から提供しない

50ミリ秒以上かかる可能性のある API は非同期 API しか提供しない

XAML UI: 登場以前 プログラミング言語での UI記述の限界

private void UpdatePageData(){ panel.RemoveAll();

for (int i = 0; i < pageItems.Count; i++) { var item = pageItems[i]; var cardCharacter = item.Card; CardThumbnailView card = card = CreateCardThumbnail(item); thumbnailList.Add(card); card.isDeckSet = item.IsDeckSet;

card.gameObject.SetActiveRecursively(true); panel.AddItem(card.gameObject); }} • どこで、だれが、何を生成しているか全然わからない

• 実行してみるまで表示結果がわからない• きっちりしたコード書くの大変 (不正になりがち )

前と変わってないものまで再生成ビューに状態持っちゃってて、

仮想化†できない

† 画面に見えている分だけビューを生成

XAML UI: UI に特化した言語 ということで XAML†

WPF/Silverlight の延長

XAML

ツール連携 :表示結果が常に見える

HTML 的な階層記述

XAML UI: データ バインディング ビューからのデータ、ロジックの分離

public class CardViewModel{ public string ImagePath { get; }}public class CardListViewModel{ public IList<CardViewModel> CardList { get; }}

XAML

C# など

ビュー ( 表示部分 ) を記述

モデル ( データ、ロジック ) を記述

+View.DataContext = new CardListViewModel { … };

<ItemsControl ItemsSource="{Binding CardList}"> <ItemsControl.ItemTemplate> <DataTemplate> <Image Source="{Binding ImagePath}" Width="168" Height="254" /> </DataTemplate> </ItemsControl.ItemTemplate></ItemsControl>

「ここに X を表示したい」

という印だけを入れる

XAML UI: 共通型システム WinRT クラスを書けば、 UI 要素を増やせる

WinMD を介して言語中立 C++ .NET: C#, VB, etc.

<ItemsControl ItemsSource="{Binding CardList}"> <ItemsControl.ItemTemplate> <DataTemplate> <Image Source="{Binding ImagePath}" Width="168" Height="254" /> </DataTemplate> </ItemsControl.ItemTemplate></ItemsControl>

単なるクラスのインスタンス生成

XAML UI: 共通型システム WinRT クラスを書けば、 UI 要素を増やせる

× コードで UI 作ったり、 ×独自属性増やしたりはどうかと思う

div = body.appendChild( div = document.createElement( "div" ) );$.extend( div.style, { minHeight: "100px", height: "auto", padding: 0, borderWidth: 0});

<div data-win-control="WinJS.Binding.Template"> <div data-win-bind="style.backgroundColor: backgroundColor"></div> <div data-win-bind="textContent: title"></div> <div data-win-bind="textContent: description"></div></div>

多様な選択肢

それぞれにとっての WinRT

それぞれの利用場面

選択肢

Metro 以外

Web と Metro デスクトップ

.NETネイティ

ブC++

HTML5JavaScri

pt

Metro

それぞれの利用場面は？それぞれにとって WinRT とは？

選択肢

Metro 以外

Web デスクトップ

.NETネイティ

ブC++

HTML5JavaScri

pt

Metro

Web = 標準ベース Web VS Metro

標準 VS プラットフォーム固有

環境 A

…

環境 B環境 C

…

標準化指向•○ 広い窓口•× 機能が限られる•× 標準化に時間がかかる

単一ベンダー指向•○ 高機能•○ 迅速な新機能提供•× 狭い窓口

クロス プラットフォームを狙うなら標準ベースで

高度な UI がほしければ

プラットフォーム固有機能を使う

クロス プラットフォーム クロスに作るのはそう簡単じゃないけれども

ブラウザー依存排し切れない どうせ UI は作り直し

タッチかマウスか、画面サイズどのくらいか

やっぱりかなり間口が広い 数倍大変でも、数倍以上のアクセス見込めるなら

まず第一に Metro の「高機能」が必要かどうか要検討

必要ないなら Web

Metro に求める「高機能」 パフォーマンス

DirectX ユーザー データ

Music/Pictures/Videos Library ハードウェア

Microphone 、 Webcam 、 Location 無制限の通信

Proximity: 近距離デバイス間通信 認証

ドメイン参加 スマート カードなどでのハードウェア認証

選択肢

Metro 以外

Web デスクトップ

.NETネイティ

ブC++

HTML5JavaScri

pt

Metro

デスクトップ アプリ いきなりすべての PC がタッチ UI になるわけない 段階移行？

できるところからタッチ化 今はマウス＆キーボードで、将来タッチ化

両方？ 出先ではタッチ、オフィスではマウス＆キーボード

今、デスクトップ アプリを作るなら？

注意 : ARM版（ Windows RT ）は Metro のみ。デスクトップ不可

Metro に近いのは？ アセンブリ構造が一番近いのは Silverlight

ただ、同じ XAML UI な WPF も十分近い WinRT=脱Win32

Win32 が色濃いものはつらい ×Windows フォーム ×MFC

ただ 1つだけ言えること UI は陳腐化が激しい

View は短めの周期で差し替わる View は極力小さく作るべき

View を小さく作る工夫 MVVM パターン

異なる UI フレームワークで Model を共有 Portable Class Library Project Linker

この辺りを押さえれば、WPF/Silverlight から Metroへの移行WPF/Silverlight と Metro 同時開発だいぶ楽

Portable Class Library 異なるフレームワークで共通して使えるライブラリ

使えるクラスは共通部分に限られる

※現状だと「共通部分」が狭すぎて使い勝手はあまり良くない。本格化はもう 1 世代後かも。

ターゲットを切り替えることで使えるクラスが変わる

Project Linker 複数のプロジェクト間でソースコードを自動共有

リンク

※現状、 VS 2010 のみ

共有元を指定

Silverlight か WPF か？ 要件次第

Silverlight デプロイ簡単 Smooth Streaming とかメディア系強い

WPF フル機能の .NET Windows 8 であれば .NET 4.5 標準搭載

選択肢

Metro 以外

Web デスクトップ

.NETネイティ

ブC++

HTML5JavaScri

pt

Metro

.NET にとって : デスクトップと Metro

☎1OKデスクトップ Metro

CLR （ .NET の実行環境）

標準ライブラリ• UI• File• Network

標準ライブラリ• LINQ• Task• MEF• …

WinRT• UI• File• Network• …

アプリ アプリ

• LINQ• Task• MEF• …

実行環境は共通

WinRT との重複削除ついでにレガシー削除

.NET にとって : WinRT かなり、 Silverlight の延長

Silverlight も、中身はかなり Internal Call つまり、中身はネイティブで、インターフェイスだけ .NET 一般開発者もそれできるようにしたようなもの

ネイティブだけど ネイティブと意識せず タイムラグ 0 で利用可能

結局、今まで通り

むしろ恩恵

なんだかんだ言って .NET は一番恩恵受けてる

.NET にとって : WinMD/ 言語プロジェクション

.NET for Metro

*.cs

winmd

exe/lib

*.cs

*.exe*.dll

*.winmd

CLRネイティブ /JavaScript

デスクトップと同じ実行環境

ネイティブやJavaScript から使いた

ければプロジェクト タイプを

WinMD に

.NET アプリ / ライブラリ*.winmd

*.exe*.dll*.js

WinRT

.NET

.NET for Metro Style WinRT との重複削除

UI 、ファイル操作、通信ソケット、 etc. レガシー削除

非ジェネリック コレクション → ジェネリック版のみ XmlSerializer → LINQ to XML のみ

元々ポータビリティを考えて作らないと、デスクトップ版からの移植そこそこ大変 View からの分離 レガシーは使わない まず、 Portable Class Library 化を考える

WinRT→.NET WinMD を介して通常の .NET 型に見える

WinRT 型→ .NET 型に、規約ベースで置き換え

.NET の型 WinRT の型

IList<T> IVector<T>

IReadOnlyList<T> IVectorView<T>

IEnumerable<T> IIteratable<T>

IDictionary<T> IMap<T>

対応表（一部）

.NET→WinRT 利用可能な型

プリミティブ（ int とか）、 string TimeSpan 、 DateTimeOffset など

利用可能なユーザー定義型 class は sealed （継承不可）なもののみ struct は public なフィールドだけ持つもののみ ジェネリックは、 IVector<T> など、決まった型のみ

選択肢

Metro 以外

Web デスクトップ

.NETネイティ

ブC++

HTML5JavaScri

pt

Metro

ネイティブにとって : WinRT 基本的に COM

C++/CX を使えば、自前実装不要 Win32 API の呪縛からの脱却

WinRT は、現代的なすっきりしたクラス ライブラリになってる

WPF 的な UI のネイティブ実装 C++ から WPF 的なものが使える ある意味では WPF のパフォーマンス改善

ネイティブの位置づけ .NET でできることをネイティブでやっても意味な

い

ネイティブ

標準 C++

C++ AMPC++ /CX GPU

利用

.NET/JavaScript連携

Component Extensions Accelerated Massive Parallelism

性能が欲しければGPU を活用

DirectX

性能が欲しければ GPU を活用

全部をネイティブでやらない

C++/CX (1) WinRT は内部的には COM なのだけども

COM めんどくさい

C++ with Component Extensions （ C++/CX ） C++/CLI に似た構文で、 COM コードを生成

（あくまでネイティブ）public ref class ImageWithLabelControl sealed : public Windows::UI::Xaml::Controls::Control { public: property Platform::String^ Label { Platform::String^ get() { return (Platform::String^)GetValue(LabelProperty); } void set(Platform::String^ value) { SetValue(LabelProperty, value); } }};

※ WRL というライブラリを使って、自前で COM実装も可能

C++/CX (2) オーバーヘッドを最小に

*.winmdメタデータ

プレーンなネイティブ コード

プレーンなネイティブ コード

オーバーヘッドなしで参照可能（単なる仮想関数呼び出しに）

他の COM コンポーネントと相互運用可能（プレーンなネイティブ コードのラッパー）

.NET や JavaScript と相互運用可能（メタデータのみ。実際に呼ばれるのは ↓の COM ）

COM 相当のネイティブ コード

*.cpp

CX

*.cpp

通常の

C++ AMP C++ Accelerated Massive Parallelism

C++ で GPGPU† するための拡張 構文的には restrict句の追加のみ ほとんどライブラリ

† General-purpose computing on GPU （ GPU による汎用目的計算）

int aCPP[] = {1, 2, 3, 4, 5};int bCPP[] = {6, 7, 8, 9, 10};int sumCPP[5] = {0, 0, 0, 0, 0};

array_view<int, 1> a(5, aCPP);array_view<int, 1> b(5, bCPP);array_view<int, 1> sum(5, sumCPP);

parallel_for_each(sum.extent, [=](index<1> idx) restrict(amp) { sum[idx] = a[idx] + b[idx]; });

ライブラリ提供

CPU実行か GPU実行かを restrict句で指定

選択肢

Metro 以外

Web デスクトップ

.NETネイティ

ブC++

HTML5JavaScri

pt

Metro

JavaScript にとって : WinRT WinRT の UI （要するに XAML ）は使わない

IE と同じ描画エンジン（ Trident ）で IE と同じ JavaScript実行エンジン（ Chakra ）

UI

FileNetwor

k

Trident/Chakra

*.js *.html

WinJS(JavaScriptライブラリ )

WinRT

.NET/ ネイティブ

*.winmd

JavaScriptあくまで標準

HTML5 + JavaScript

+α

WinRT のXAML UI は

使わない

+α

標準＋ α (1): Metro に求める「高機能」 ユーザー データ

Music/Pictures/Videos Library ハードウェア

Microphone 、 Webcam 、 Location 無制限の通信

Proximity: 近距離デバイス間通信 認証

ドメイン参加 スマート カードなどでのハードウェア認証

標準＋ α (2 ): WinJS XAML 相当の UI を書くための JavaScript ライブラ

リ ↓こんな HTML を書く

data- なんとか属性… 独自属性使ってデータ バインディング

Blend5 で編集可能 処理を行ってくれてるのは WinJS 中の JavaScript

一応は、 HTML5 の規格の範囲

<div data-win-control="WinJS.Binding.Template"> <div data-win-bind="style.backgroundColor: backgroundColor"></div> <div data-win-bind="textContent: title"></div> <div data-win-bind="textContent: description"></div></div>

HTML5+JavaScript の位置づけ UI 用

+α がある時点で“別物”とはいえ… HTML5 と JavaScript になじんだ UI デザイナーは多い

ロジックは… ViewModel まで .NET で作って、 WinMD経由で参照す

るのがよいかも

WinJS を使うかどうか WinJS を使わない

UI 部分に関しては完全に「標準」 UIガイドラインに沿った UI を 1 から自前で作る必要あ

り 沿っていないと審査で落ちる可能性あり ゲームならあまりうるさく言われない

WinJS を使う ガイドライン通りの UI に +α の部分を覚えるのはそれなりの負担

なら XAML でいいのでは…

まとめ

Metro 以外

Web デスクトップ

.NETネイティ

ブC++

HTML5JavaScri

pt

Metro

Web VS Metro フル機能使いたかったら Metro で

GPU Music/Pictures/Videos Library Microphone 、 Webcam 、 Location Proximity: 近距離デバイス間通信 ドメイン参加 スマート カードなどでのハードウェア認証

そんなの要らなかったら Web で

デスクトップ 段階移行 or 同時開発

同じ XAML UI の Silverlight か WPF ならそこそこ楽 確実に言えること :

UI 技術は陳腐化が激しい View を極力小さく

Silverlight か WPF か 要件次第。それぞれの特徴を活かして

Metro: .NET Silverlight か WPF の経験者なら苦もなく作れる

XAML: Silverlight の延長線上 WinMD: .NET のメタデータの延長線上

開発しやすさは .NET が一番 特に非同期処理には async/await （ C# 5.0 ） サーバーとのコード共有の要求もたぶん出てくる

2重開発避けるためにも、サーバー側でも使える .NET

Metro: ネイティブ .NET でできることをネイティブでやっても意味な

い

ハイ パフォーマンス 特にゲームや大規模データ処理

DirectX, C++ AMP

GPU の活用

Metro: HTML5+JavaScript UI 用

ロジックは .NET や C++ で書いてしまう WinMD経由で参照

利点は UI デザイナー人口多いこと Metro HTML は標準＋ α だけど…

＋ α ある時点で…