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

標準＋α (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  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は標準＋αだけど…  ＋αある時点で…

Windows 8時代のアプリ開発

by 信之岩永 on May 28, 2012

Accessibility

Categories

Upload Details

Usage Rights

2 Embeds 8

Statistics