Weitere ähnliche Inhalte Ähnlich wie Windows 8時代のアプリ開発 (20) Kürzlich hochgeladen (11) Windows 8時代のアプリ開発3. 現在
とにかく多様化
ハードウェア
x86/x64とARM
デスクトップ/ノートPC、Slate、Phone
標準 vs プラットフォーム固有
間口の広さ ⇔ 表現力、性能、進化の速さ
言語・フレームワーク
.NET、ネイティブ(C++)、JavaScript
4. 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 • 自由なアプリ配布無理
5. Metro: 新UI
デスクトップ(今まで通
り)
OK
• マウスとキーボード操作
• タスク バーとウィンドウ
Metro(新UI)
• タッチ向けUI
• 全画面、フリックで切り替え 1 ☎
6. Metro UIとWinRT
デスクトップ Metro
OK 1 ☎
主にデスクトップ用 一部だけ許可 呼べなくはない 主にMetro用
(DirectXなど) (あまり意味ない)
Win32 WinRT
伝統のAPI 新API
C言語スタイル OOPスタイル
7. Metro: XAMLとHTML5
XAMLかHTML5で開発
XAML HTML5
.NET C++ JavaScript
WinRT(Windows Runtime) API
Windows Kernel
WPFやSilverlightと同じ
標準+WinRT API
開発スタイル
多様化に対するささやかな抵抗
8. 言語プロジェクション
言語/フレームワークを超えてコンポーネント共有
Projection
C++アプリ
WinRT
コンポーネント
Projection
CLR C#/VBアプリ
C++, C#, VB
で書ける
HTML+JavaScript
Projection
Chakra
アプリ
Windows
Metadata
C++で書かれていても、 .NETのメタデータを
.NETからは.NETクラスに見える .NET以外の世界に広げたもの
10. ネイティブと.NETとWinRT
WinRT = 振り子の真ん中
1990年代 2000年代
ネイティブ .NET
C++ C#, VB, F#, …
COM 2010年代
WinRT
ネイティブ/.NET/JavaScript連携
12. ネイティブ→.NET
ネイティブ .NET
• メモリ管理が大変 • メタデータ
• セキュリティ保証が大
変
• メモリ自動管理
• 複数CPU対応が大変 • 中間コード
• COM大変
13. .NET時代の課題
.NET
• メタデータ 手軽さを犠牲にしてでも
性能が欲しい場面は残る
• メモリ自動管理
• メモリ手動管理したい
• 中間コード • CPU依存の最適化をしたい
低層APIは必ずネイティブ
連携が面倒
.NET向けラッパーの登場までにタイムラグ
14. .NET→WinRT
メタデータの適用範囲を拡大
.NET ネイティブ JavaScript
メタデータ WinMD(Windows Matadata)
• メタデータ
• メモリ自動管理
ただし、現代風に再設計
• 中間コード
.NETとネイティブが対等
ネイティブAPIが即.NETから使える
JavaScriptにも対応
15. 言語プロジェクション
規約ベースで.NET/ネイティブ/JavaScript相互運用
.NETのCTS(共通型システム)を、ネイティブと
JavaScriptにも広げたもの
WinMD(Windows Metadata)
相互運用のために必要なメタデータ
ファイル形式的には.NETのメタデータ仕様と同じ
.NETと比べると使える型に制限あり
16. 壁のない世界
壁があっちゃいけない
サーバーとクライアント開発で
初心者とプロで
言語が違うからできない
フレームワークの作法が違うからできない
言語やフレームワークを超えた相互運用
WinMD(Windows Matadata)
17. Not Only "Win"
壁があっちゃいけない
サーバーとクライアント開発で
初心者とプロで
あまり名前が良くない
言語が違うからできない
• WinRT用なのは残念
• Windowsに閉じていい技術じゃない
フレームワークの作法が違うからできない
• 壁のない世界をWindows以外にも欲しい
言語やフレームワークを超えた相互運用
WinMD(Windows Matadata)
18. 現代風に再設計
.NETを参考にしたオブジェクト指向API
脱Win32
脱Variant
非同期API
XAML UI
19. .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不要
20. 非同期API
WinRTの方針:
50ミリ秒以上かかる可能性のあるAPIは
非同期APIしか提供しない
スレッドをブロックするのは思った以上にコストになる
UIスレッドを止めるとユーザーの印象悪い
同期処理するとまずい
まずいものは最初から提供しない
21. 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);
}
} • どこで、だれが、何を生成しているか全然わからない
• 実行してみるまで表示結果がわからない
• きっちりしたコード書くの大変(不正になりがち)
†画面に見えている分だけビューを生成
23. 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; }
}
24. 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.
25. 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>
27. 選択肢
Metro以外
WebとMetro デスクトップ
Metro
.NET
ネイティブ HTML5 それぞれの利用場面は?
C++ JavaScript それぞれにとってWinRTとは?
28. 選択肢
Metro以外
Web デスクトップ
Metro
.NET
ネイティブ HTML5
C++ JavaScript
29. Web = 標準ベース
Web VS Metro
標準 VS プラットフォーム固有
高度なUIがほしければ
環境B
クロス プラットフォーム 環境C プラットフォーム固有
を狙うなら標準ベースで 機能を使う
環境A
標準化指向 単一ベンダー指向
•○ 広い窓口 •○ 高機能
•× 機能が限られる •○ 迅速な新機能提供
•× 標準化に時間がかかる •× 狭い窓口
30. クロス プラットフォーム
クロスに作るのはそう簡単じゃないけれども
ブラウザー依存排し切れない
どうせUIは作り直し
タッチかマウスか、画面サイズどのくらいか
やっぱりかなり間口が広い
数倍大変でも、数倍以上のアクセス見込めるなら
まず第一にMetroの「高機能」が必要かどうか要検討
必要ないならWeb
31. Metroに求める「高機能」
パフォーマンス
DirectX
ユーザー データ
Music/Pictures/Videos Library
ハードウェア
Microphone、Webcam、Location
無制限の通信
Proximity: 近距離デバイス間通信
認証
ドメイン参加
スマート カードなどでのハードウェア認証
32. 選択肢
Metro以外
Web デスクトップ
Metro
.NET
ネイティブ HTML5
C++ JavaScript
33. デスクトップ アプリ
いきなりすべてのPCがタッチUIになるわけない
段階移行?
できるところからタッチ化
今はマウス&キーボードで、将来タッチ化
両方?
出先ではタッチ、オフィスではマウス&キーボード
今、デスクトップ アプリを作るなら?
注意: ARM版(Windows RT)はMetroのみ。デスクトップ不可
34. Metroに近いのは?
アセンブリ構造が一番近いのはSilverlight
ただ、同じXAML UIなWPFも十分近い
WinRT=脱Win32
Win32が色濃いものはつらい
×Windowsフォーム
×MFC
35. ただ1つだけ言えること
UIは陳腐化が激しい
Viewは短めの周期で差し替わる
Viewは極力小さく作るべき
Viewを小さく作る工夫
MVVMパターン
異なるUIフレームワークでModelを共有
Portable Class Library
Project Linker この辺りを押さえれば、
WPF/SilverlightからMetroへの移行
WPF/SilverlightとMetro同時開発
だいぶ楽
36. Portable Class Library
異なるフレームワークで共通して使えるライブラリ
使えるクラスは共通部分に限られる
ターゲットを切り替えること
で使えるクラスが変わる
※ 現状だと「共通部分」が狭すぎて
使い勝手はあまり良くない。
本格化はもう1世代後かも。
38. SilverlightかWPFか?
要件次第
Silverlight
デプロイ簡単
Smooth Streamingとかメディア系強い
WPF
フル機能の.NET
Windows 8であれば.NET 4.5標準搭載
39. 選択肢
Metro以外
Web デスクトップ
Metro
.NET
ネイティブ HTML5
C++ JavaScript
40. .NETにとって: デスクトップとMetro
デスクトップ OK
Metro 1 ☎
アプリ アプリ
標準ライブラリ 標準ライブラリ WinRT
• UI • LINQ • LINQ • UI
• File • Task • Task • File
• Network • MEF • MEF • Network
• … • … • …
CLR(.NETの実行環境)
WinRTとの重複削除
ついでにレガシー削除
実行環境は共通
41. .NETにとって: WinRT
かなり、Silverlightの延長
Silverlightも、中身はかなりInternal Call
つまり、中身はネイティブで、インターフェイスだけ.NET
一般開発者もそれできるようにしたようなもの
ネイティブだけど
結局、今まで通り
ネイティブと意識せず
タイムラグ0で利用可能 むしろ恩恵
なんだかんだ言って.NETは一番恩恵受けてる
42. .NETにとって: WinMD/言語プロジェクション
デスクトップと同じ実行環境
.NET
ネイティブやJavaScript
から使いたければ CLR
ネイティブ/JavaScript
プロジェクト タイプを winmd
WinMDに *.winmd *.exe
*.cs *.dll
*.js
.NETアプリ/ライブラリ exe/lib
*.exe
*.winmd
*.dll
*.cs
.NET for
WinRT
Metro
43. .NET for Metro Style
WinRTとの重複削除
UI、ファイル操作、通信ソケット、etc.
レガシー削除
非ジェネリック コレクション → ジェネリック版のみ
XmlSerializer → LINQ to XMLのみ
元々ポータビリティを考えて作らないと、デスク
トップ版からの移植そこそこ大変
Viewからの分離
レガシーは使わない
まず、Portable Class Library化を考える
44. WinRT→.NET
WinMDを介して通常の.NET型に見える
WinRT型→.NET型に、規約ベースで置き換え
対応表(一部)
.NETの型 WinRTの型
IList<T> IVector<T>
IReadOnlyList<T> IVectorView<T>
IEnumerable<T> IIteratable<T>
IDictionary<T> IMap<T>
45. .NET→WinRT
利用可能な型
プリミティブ(intとか)、string
TimeSpan、DateTimeOffsetなど
利用可能なユーザー定義型
classはsealed(継承不可)なもののみ
structはpublicなフィールドだけ持つもののみ
ジェネリックは、IVector<T>など、決まった型のみ
46. 選択肢
Metro以外
Web デスクトップ
Metro
.NET
ネイティブ HTML5
C++ JavaScript
47. ネイティブにとって: WinRT
基本的にCOM
C++/CXを使えば、自前実装不要
Win32 APIの呪縛からの脱却
WinRTは、現代的なすっきりしたクラス ライブラリに
なってる
WPF的なUIのネイティブ実装
C++からWPF的なものが使える
ある意味ではWPFのパフォーマンス改善
48. ネイティブの位置づけ
.NETでできることをネイティブでやっても意味ない
標準C++
DirectX
全部をネイティブ
性能が欲しければ
性能が欲しければ
でやらない
ネイティブ GPUを活用
GPUを活用
.NET/
C++ /CX C++ AMP GPU
JavaScript
利用
連携
Component Extensions Accelerated Massive Parallelism
49. 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実装も可能
50. C++/CX (2)
オーバーヘッドを最小に
*.winmd .NETやJavaScriptと相互運用可能
メタデータ (メタデータのみ。実際に呼ばれるのは
↓のCOM)
CX
COM相当の
他のCOMコンポーネントと相互運用可能
ネイティブ コード
*.cpp (プレーンなネイティブ コードのラッパー)
プレーンな
ネイティブ コード
オーバーヘッドなしで参照可能
(単なる仮想関数呼び出しに)
通常の
プレーンな
ネイティブ コード
*.cpp
51. 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による汎用目的計算)
52. 選択肢
Metro以外
Web デスクトップ
Metro
.NET
ネイティブ HTML5
C++ JavaScript
53. 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 ライブラリ)
+α
54. 標準+α (1): Metroに求める「高機能」
ユーザー データ
Music/Pictures/Videos Library
ハードウェア
Microphone、Webcam、Location
無制限の通信
Proximity: 近距離デバイス間通信
認証
ドメイン参加
スマート カードなどでのハードウェア認証
55. 標準+α (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の規格の範囲
56. HTML5+JavaScriptの位置づけ
UI用
+αがある時点で“別物”とはいえ…
HTML5とJavaScriptになじんだUIデザイナーは多い
ロジックは…
ViewModelまで.NETで作って、WinMD経由で参照するの
がよいかも
57. WinJSを使うかどうか
WinJSを使わない
UI部分に関しては完全に「標準」
UIガイドラインに沿ったUIを1から自前で作る必要あり
沿っていないと審査で落ちる可能性あり
ゲームならあまりうるさく言われない
WinJSを使う
ガイドライン通りのUIに
+αの部分を覚えるのはそれなりの負担
ならXAMLでいいのでは…
58. まとめ
Metro以外
Web デスクトップ
Metro
.NET
ネイティブ HTML5
C++ JavaScript
59. Web VS Metro
フル機能使いたかったらMetroで
GPU
Music/Pictures/Videos Library
Microphone、Webcam、Location
Proximity: 近距離デバイス間通信
ドメイン参加
スマート カードなどでのハードウェア認証
そんなの要らなかったらWebで
60. デスクトップ
段階移行 or 同時開発
同じXAML UIのSilverlightかWPFならそこそこ楽
確実に言えること:
UI技術は陳腐化が激しい
Viewを極力小さく
SilverlightかWPFか
要件次第。それぞれの特徴を活かして
61. Metro: .NET
SilverlightかWPFの経験者なら苦もなく作れる
XAML: Silverlightの延長線上
WinMD: .NETのメタデータの延長線上
開発しやすさは.NETが一番
特に非同期処理にはasync/await(C# 5.0)
サーバーとのコード共有の要求もたぶん出てくる
2重開発避けるためにも、サーバー側でも使える.NET
62. Metro: ネイティブ
.NETでできることをネイティブでやっても意味ない
ハイ パフォーマンス
特にゲームや大規模データ処理
DirectX, C++ AMP GPUの活用