Windows 8時代のアプリ開発

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

Windows 8

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

現在
 とにかく多様化
 ハードウェア
 x86/x64とARM
 デスクトップ/ノートPC、Slate、Phone
 標準 vs プラットフォーム固有
 間口の広さ ⇔ 表現力、性能、進化の速さ
 言語・フレームワーク
 .NET、ネイティブ（C++）、JavaScript

Windows 8/Windows RT
 ARM対応、Metro UI、WinRT
UI
デスクトップ Metro
CPU

Windows 8 今まで通りのWindows 新環境
• Win32 APIを使う • x86/x64/ARM共通
x86/x64 • ネイティブの場合、
3バイナリ必要
• WinRT APIを使う
提供はするものの… • App Store配布
Windows RT • Officeなどバンドル品のみ
• 審査あり
ARM • 自由なアプリ配布無理

Metro: 新UI

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

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

Metro UIとWinRT

デスクトップ Metro

OK 1 ☎

主にデスクトップ用一部だけ許可呼べなくはない主にMetro用
（DirectXなど）（あまり意味ない）

Win32 WinRT
伝統のAPI 新API

C言語スタイル OOPスタイル

Metro: XAMLとHTML5
 XAMLかHTML5で開発

XAML HTML5
.NET C++ JavaScript

WinRT（Windows Runtime） API

Windows Kernel

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

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

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

Projection
C++アプリ
WinRT
コンポーネント

Projection
CLR C#/VBアプリ
C++, C#, VB
で書ける
HTML+JavaScript

Projection

Chakra
アプリ
Windows
Metadata

C++で書かれていても、 .NETのメタデータを
.NETからは.NETクラスに見える .NET以外の世界に広げたもの

WinRT

.NETの反省点と、WinRT

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

1990年代 2000年代
ネイティブ .NET
C++ C#, VB, F#, …
COM 2010年代
WinRT
ネイティブ/.NET/JavaScript連携

ネイティブ時代の課題
ネイティブ

• メモリ管理が大変
• セキュリティ保証が大
変
• COM大変
• 複数CPU対応が大変

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

ネイティブ→.NET
ネイティブ .NET
• メモリ管理が大変 • メタデータ
• セキュリティ保証が大
変
• メモリ自動管理
• 複数CPU対応が大変 • 中間コード
• COM大変

.NET時代の課題
.NET

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

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

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

.NET ネイティブ JavaScript

メタデータ WinMD（Windows Matadata）
• メタデータ
ただし、現代風に再設計
• 中間コード

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

言語プロジェクション
 規約ベースで.NET/ネイティブ/JavaScript相互運用
 .NETのCTS（共通型システム）を、ネイティブと
JavaScriptにも広げたもの
 WinMD（Windows Metadata）
 相互運用のために必要なメタデータ
 ファイル形式的には.NETのメタデータ仕様と同じ
 .NETと比べると使える型に制限あり

壁のない世界
 壁があっちゃいけない
 サーバーとクライアント開発で
 初心者とプロで

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

 言語やフレームワークを超えた相互運用
WinMD（Windows Matadata）

Not Only "Win"
 壁があっちゃいけない
 サーバーとクライアント開発で
 初心者とプロで
あまり名前が良くない
 言語が違うからできない
• WinRT用なのは残念
 • Windowsに閉じていい技術じゃない
フレームワークの作法が違うからできない
• 壁のない世界をWindows以外にも欲しい

 言語やフレームワークを超えた相互運用
WinMD（Windows Matadata）

現代風に再設計
 .NETを参考にしたオブジェクト指向API
 脱Win32
 脱Variant
 非同期API
 XAML UI

.NETを参考に
 言われなければ.NETのライブラリかと間違うレベル
例
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クラス

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

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

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

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

XAML UI: 登場以前
 プログラミング言語でのUI記述の限界
private void UpdatePageData()
{
panel.RemoveAll();

for (int i = 0; i < pageItems.Count; i++)
{
var item = pageItems[i]; 前と変わってないものまで再生成
ビューに状態持っちゃってて、 = item.Card;
var cardCharacter
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の延長表示結果が常に見える

HTML的な階層記述

XAML

XAML UI: データバインディング
 ビューからのデータ、ロジックの分離
XAML 「ここにXを表示したい」
ビュー(表示部分)を記述という印だけを入れる
<ItemsControl ItemsSource="{Binding CardList}">
<ItemsControl.ItemTemplate>
<DataTemplate>
<Image Source="{Binding ImagePath}"
Width="168" Height="254" />
</DataTemplate>
</ItemsControl.ItemTemplate>
</ItemsControl>

+ View.DataContext = new CardListViewModel { … };

C#など
モデル(データ、ロジック)を記述
public class CardViewModel
{
public string ImagePath { get; }
}
public class CardListViewModel
{
public IList<CardViewModel> CardList { get; }
}

XAML UI: 共通型システム
 WinRTクラスを書けば、UI要素を増やせる
<ItemsControl ItemsSource="{Binding CardList}">
単なるクラスの <ItemsControl.ItemTemplate>
インスタンス生成 <DataTemplate>
<Image Source="{Binding ImagePath}"
Width="168" Height="254" />
</DataTemplate>
</ItemsControl.ItemTemplate>
</ItemsControl>

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

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

 ×コードでUI作ったり、
 ×独自属性増やしたりはどうかと思う
div = body.appendChild(
div = document.createElement( "div" ) );
<div data-win-control="WinJS.Binding.Template">
$.extend( div.style, { <div data-win-bind="style.backgroundColor: backgroundColo
minHeight: "100px", height: "auto", <div data-win-bind="textContent: title"></div>
padding: 0, borderWidth: 0}); <div data-win-bind="textContent: description"></div>
</div>

多様な選択肢

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

選択肢

Metro以外

WebとMetro デスクトップ

Metro

.NET
ネイティブ HTML5 それぞれの利用場面は？
C++ JavaScript それぞれにとってWinRTとは？

選択肢

Metro以外

Web デスクトップ

Metro

.NET
ネイティブ HTML5
C++ JavaScript

Web = 標準ベース
 Web VS Metro

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

高度なUIがほしければ
環境B
クロスプラットフォーム環境C プラットフォーム固有
を狙うなら標準ベースで機能を使う
環境A
標準化指向単一ベンダー指向
•○ 広い窓口 •○ 高機能
•× 機能が限られる •○ 迅速な新機能提供
•× 標準化に時間がかかる •× 狭い窓口

クロスプラットフォーム
 クロスに作るのはそう簡単じゃないけれども
 ブラウザー依存排し切れない
 どうせUIは作り直し
 タッチかマウスか、画面サイズどのくらいか

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

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

Metroに求める「高機能」
 パフォーマンス
 DirectX
 ユーザーデータ
 Music/Pictures/Videos Library
 Microphone、Webcam、Location
 無制限の通信
 Proximity: 近距離デバイス間通信
 認証
 ドメイン参加
 スマートカードなどでのハードウェア認証

デスクトップアプリ
 いきなりすべての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標準搭載

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

アプリアプリ

標準ライブラリ標準ライブラリ WinRT
• UI • LINQ • LINQ • UI
• File • Task • Task • File
• Network • MEF • MEF • Network
• … • … • …

CLR（.NETの実行環境）
WinRTとの重複削除
ついでにレガシー削除
実行環境は共通

.NETにとって: WinRT
 かなり、Silverlightの延長
 Silverlightも、中身はかなりInternal Call
 つまり、中身はネイティブで、インターフェイスだけ.NET
 一般開発者もそれできるようにしたようなもの
 ネイティブだけど
結局、今まで通り
 ネイティブと意識せず
 タイムラグ0で利用可能むしろ恩恵

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

.NETにとって: WinMD/言語プロジェクション
デスクトップと同じ実行環境
.NET
ネイティブやJavaScript
から使いたければ CLR
ネイティブ/JavaScript
プロジェクトタイプを winmd
WinMDに *.winmd *.exe
*.cs *.dll
*.js
.NETアプリ/ライブラリ exe/lib
*.exe
*.winmd
*.dll
*.cs

.NET for
WinRT
Metro

.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>など、決まった型のみ

ネイティブにとって: WinRT
 基本的にCOM
 C++/CXを使えば、自前実装不要
 Win32 APIの呪縛からの脱却
 WinRTは、現代的なすっきりしたクラスライブラリに
なってる
 WPF的なUIのネイティブ実装
 C++からWPF的なものが使える
 ある意味ではWPFのパフォーマンス改善

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

標準C++
DirectX
全部をネイティブ
性能が欲しければ
性能が欲しければ
でやらない
ネイティブ GPUを活用
GPUを活用
.NET/
C++ /CX C++ AMP GPU
JavaScript
利用
連携
Component Extensions Accelerated Massive Parallelism

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 .NETやJavaScriptと相互運用可能
メタデータ（メタデータのみ。実際に呼ばれるのは
↓のCOM）
CX
COM相当の
他のCOMコンポーネントと相互運用可能
ネイティブコード
*.cpp （プレーンなネイティブコードのラッパー）
プレーンな
オーバーヘッドなしで参照可能
（単なる仮想関数呼び出しに）
通常の
プレーンな
*.cpp

C++ AMP
 C++ Accelerated Massive Parallelism
 C++でGPGPU†するための拡張
 構文的にはrestrict句の追加のみ
 ほとんどライブラリ
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) CPU実行かGPU実行か
{ をrestrict句で指定
sum[idx] = a[idx] + b[idx];
});

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

JavaScriptにとって: WinRT
 WinRTのUI（要するにXAML）は使わない
 IEと同じ描画エンジン（Trident）で
 IEと同じJavaScript実行エンジン（Chakra）
JavaScript
あくまで標準
.NET/ネイティブ
Trident/Chakra HTML5 +
*.winmd JavaScript

WinRTの WinRT *.js *.html
XAML UIは UI
WinJS
使わない File +α
(JavaScript
Network ライブラリ)

+α

標準＋α (1): Metroに求める「高機能」
 ユーザーデータ
 無制限の通信
 認証

標準＋α (2 ): WinJS
 XAML相当のUIを書くためのJavaScriptライブラリ
 ↓こんなHTMLを書く
<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>

 data-なんとか属性…
 独自属性使ってデータバインディング
 Blend5で編集可能
 処理を行ってくれてるのはWinJS中のJavaScript
 一応は、HTML5の規格の範囲

HTML5+JavaScriptの位置づけ
 UI用
 +αがある時点で“別物”とはいえ…
 HTML5とJavaScriptになじんだUIデザイナーは多い
 ロジックは…
 ViewModelまで.NETで作って、WinMD経由で参照するの
がよいかも

WinJSを使うかどうか
 WinJSを使わない
 UI部分に関しては完全に「標準」
 UIガイドラインに沿ったUIを1から自前で作る必要あり
 沿っていないと審査で落ちる可能性あり
 ゲームならあまりうるさく言われない
 WinJSを使う
 ガイドライン通りのUIに
 +αの部分を覚えるのはそれなりの負担
 ならXAMLでいいのでは…

まとめ

Metro以外

Web デスクトップ

Metro

.NET
ネイティブ HTML5
C++ JavaScript

Web VS Metro
 フル機能使いたかったらMetroで
 GPU
 そんなの要らなかったら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は標準＋αだけど…
 ＋αある時点で…

Windows 8時代のアプリ開発

Recommended

Recommended

More Related Content

Similar to Windows 8時代のアプリ開発

Similar to Windows 8時代のアプリ開発 (20)

More from 信之岩永

More from 信之岩永 (20)

Recently uploaded

Recently uploaded (9)