Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Windows 8 メトロスタイルア
プリに挑戦してみた
Windows Phone勉強会@四日市 第3回
2012/7/21
青木宣明 @kumar0001
Agenda (1 of 2)
Windows 8のメトロスタイルアプリ
 XAMLによるUI定義、ページ遷移のアプリ構
造など、Windows Phone 7と似た要素が
あります
 WP7アプリの開発経験を活かせないかと思
い、メトロ...
Agenda (2 of 2)
本セッションでは、Windows Phone 7とメトロ
スタイルアプリを同時に開発する試みについて、
現時点での状況を紹介します
 技量不足、時間不足でまだ途中ですが、何
か参考になればと思います
 ご意...
目次
1. アプリケーションのマルチプラットフォーム対応
2. Windows 8とメトロスタイルアプリ
3. Windows Phone 7アプリとの同時開発の試み
アプリケーションのマルチプラットフォー
ム対応
・マルチプラットフォーム対応の理由
増えるUIプラットフォーム
XAMLによるUIプラットフォーム(PF)
WPF
Silverlight
Windows Phone 7
Windows 8 メトロスタイルアプリ
Windows Phone 8
マルチPF対応の理由(1)
ある目的のために開発するアプリを、
様々なPFに展開したい
理由(パターン1)
 特性が異なるそれぞれのPFでリリース
→アプリの役割をそれぞれ変える
• 画面は小さいけどいつでもどこでも→WP7
• 大きな画...
WP7アプリ⇔デスクトップアプリ
WP7とデスクトップPCの環境を比較すると…
Windows Phone 7 デスクトップPC
ハードウェア スマートフォン デスクトップPC
ノートPC
画面サイズ 小さい (800×480) 大きい (少...
マルチPF対応の理由(2)
たとえば
 アプリをデスクトップPCとモバイル向け
にリリース
• デスクトップ向けでデータ入力・編集
• モバイルでデータ検索・閲覧
マルチPF対応の理由(3)
理由(パターン2 )
 プラットフォームの過渡期において、新
旧のプラットフォームにリリースしたい
• Windows Phone 8が発売されても、しば
らくはWindows Phone 7が存在
Windo...
マルチPF対応の理由(4)
様々な要件で、複数のUIプラットフォーム
にアプリをリリースする場合がある
 アプリの目的は同じ=対象とするデー
タは同じ
 アプリの動作環境が異なる
どう対応すればいいのか?
マルチPF対応の対象アプリ
ATND Beta検索アプリ
 ATND betaのAPIを使って、イベントを
検索する
• 検索キー
イベントID、日付、キーワード、参加者
 結果のイベントを一覧表示
 選択されたイベントの詳細を表示
...
ATND BETAサイト
イベントの情報 参加者の情報
ATND BETA API
イベントの検索と参加者を取得するAPIが
提供されている
 http://api.atnd.org/
主な仕様
 HTTP GETでアクセス
 XML/JSON/Atom/JSONP/iCalend
arで...
アプリの対象PF
対象プラットフォーム
 Windows Phone 7に対応させる
• 外出先へと持ち歩くメインデバイス
 Windows 8のメトロスタイルアプリとし
てもリリースする
• スレートPC/デスクトップPCでの閲覧性
•...
Windows 8とメトロスタイルアプリ
・主な特徴
メトロスタイルアプリ
Windows 8から登場する新しいスタイル
のアプリケーション
特徴
 コンテンツへの没入
 余計な飾りを省いたデザイン、タイポ
グラフィによる表現
 タッチ操作を意識
メトロスタイルアプリの要素
メトロスタイルデザイン
 没入感、コンテンツ優先
タイルでユーザとつながる
スナップ、スケール
コントラクトでOS・他APとつながる
オンラインで鮮度を保つ
クラウドへのローミングでデバイスをまた
いで...
没入感、コンテンツ優先
メトロスタイルアプリ版 Internet Explorer 10
スタート画面
ライブタイルが並ぶ
解像度に応じてタイルの並び方が変化
解像度 1920×1200
スレートPCでのスタート画面
解像度 1366×768
タイルの操作
タイルを選択(右クリック or 上にフリック)
するとタイルを操作可能
チャーム
画面右側に表示
5個のチャーム
 検索コントラクト
 共有コントラクト
 スタート画面呼び出し
 デバイス連携
 設定コントラクト
スタート以外のAP画面か
らの呼び出し可能
画面解像度
最低解像度 1024×768
推奨解像度 1366×768
 両者の差(342×768)はスナップの表
示のため
• スナップ表示とは?
画面の左右の端に常駐させる形の表示形式
推奨解像度未満の場合、スナップは利用不可
画面解像度
320px
1366px
768
px
スナップ 通常表示
画面解像度
画面の回転に対応
参考
 Building Windows 8 「横向きと縦向きの両方に
向けた最適化」
タッチ操作
メトロスタイルアプリはタッチ操作に対応
 基本操作にUIコントロールが対応して
いるので、アプリは自動的にタッチ対
応になる
ナビゲーション
画面上部にスワイプすると表示される領域
画面遷移などナビゲーションに関する項目
を配置する
 Internet Exploreのタブ切り替え
ナビゲーションの例
画面遷移の制御
アプリバー
画面端をスワイプすると下部に表示され
る帯状の領域
アプリケーションの機能を実行するコマン
ドを提供する
左右に分かれていて、それぞれ使い方の
指針が出されている
 左側: 画面固有の機能(ローカル)
 右側: AP全体の...
アプリバーの領域
表示されている画面に拠ら
ないグローバルな機能
表示されている画面に
拠るローカルな機能
コントラクト
他のアプリやWindowsと連携する仕組み
 App to App Picking (ファイル選択)
 Cached file updater (ソース共有)
 Play To (メディアファイル再生)
 Search ...
コントラクト
提供する機能は決まっていて、
指定された時点でその処理を提
供可能なアプリを探す
検索の例
 検索チャームを選択する
 その時点で検索機能を提供す
るアプリで処理
• スタート画面→アプリの検索
• メール→メール内容の検索
コントラクト
参考
 Dev Center - App contracts and
extensions (Metro style apps)
 Building Windows 8 「アプリで
Windows 8 のコントラクトのアクテ...
クラウドとの連携
アプリのデータをSkyDriveに保存して、
他のデバイスにインストールしたアプリと
同期できる
 デスクトップPC、スレートPCにインス
トールしたアプリが同じデータを同期
 アプリ情報を引き継ぐことで、デバイス
をま...
ガイドライン
メトロスタイルアプリのガイドラインはたく
さんあって読むだけでも大変…
Windows 8アプリの認定の要件
 これが一番重要
「Metro スタイルアプリのガイドライン一
覧 (沢山あるよ~)」 @biacさん
 一覧...
情報源
デベロッパー センター - Metro スタイル
アプリ
 http://msdn.microsoft.com/ja-
jp/windows/apps
メトロスタイルアプリの特性
没入感 (immersive)
 ユーザがコンテンツに没頭できるように
コンテンツ優先 (contents before
chrome)
 画面にはコンテンツに関係する要素だ
けを配置する。余計な飾りは置かない
その他の要素
セマンティックズーム
通知
Windowsストア
 試用版
ピクセル密度
 ビットマップ画像は3種類用意する
Windows Phone 7アプリとの同時開発
の試み
・アプリケーションの構造
・開発環境の差異
・ソリューション構成
例題のアプリ
ATND Beta検索アプリ
 まずイベントの検索、結果の一覧表示
までを実装してみる
 WP7とメトロスタイルアプリのそれぞれ
で実装する
WP7とメトロスタイルアプリ(1)
WP7とメトロスタイルを比較すると…
Windows Phone 7 メトロスタイルアプリ
ハードウェア スマートフォン スレートPC
デスクトップPC
ノートPC
画面サイズ 小さい (800×480) ...
メトロスタイルデザインでの考慮
没入感、コンテンツ優先の画面構成にす
る必要がある
• 審査への影響度は把握していませんが…
スナップへの対応は必須
• 未対応だと審査に通らない
• 逃げ方はいろいろあるようですが…
WP7とメトロスタイルアプリ(2)
Windows Phone 7 メトロスタイルアプリ
開発言語 C#/VB C#/VB
C/C++
HTML/CSS + JavaScript
UI構築 XAML XAML
画面構成 ページ遷移
解像度: 8...
ライフサイクル
WP7=3つの状態
 Running
 Domant
 Tombstoned
イベントは4種類
 Launching
 Activated
 Deactivated
 Closing
MSDN(“Executi...
ライフサイクル
メトロスタイルアプリ=3つの状態
 NotRunning, Running, Suspended
イベントは3種類
 Activated, Suspending, Resuming
MSDN(“Application l...
メトロスタイルアプリのアーキテ
クチャ
「Building Windows 8」から引用
http://blogs.msdn.com/b/b8/archive/2012/02/09/building-
windows-for-the-arm-p...
共通化を見据えたアプリ構造
アプリケーションがUIプラットフォームに
依存する箇所、依存しない箇所は?
まずXAMLプラットフォームにおけるアプ
リケーションの一般的なアーキテクチャを
考えてみる
⇒MVVMパターン
MVVMパターン(1)
UIのアーキテクチャパターンの1つ
WPF/SilverlightのXAMLを使ったUI向
けのパターン
 XAMLのデータバインディング、仮想
化を考慮すると自然と導かれる
 参考情報
• 「MVVMパターンが...
MVVMパターン(2)
アプリを3要素に分けて捉える
 View
• UIの見た目、構造を定義
 ViewModel
• Viewの状態を保持・管理
• Viewのサポート(入力値検査など持っていな
い機能を補完)
 Model
• ア...
MVVMパターン(3)
View
View
Model
Model
参照・更新
イベント
データ
バインディング
Viewの状態を
保持・管理
UIの見た目、
構造を定義
アプリ本来の
問題領域
UIプラットフォームによる差異(1)
UIプラットフォームが違うと何が変わる
か?
アプリケーションの見せ方が変わる
 UIそのものの違い
 UIデザインの考え方の違い
UIプラットフォームによる差異(2)
プラットフォームの特性、狙い、制約によりView
はそれぞれ異なる
メトロスタイル
 モバイル環境でも利用されるが、通信量には
寛容?
 画面が大きい (1024×768~)
 コンテンツファース...
UIの見せ方の違い
UIの見せ方が違うと?
 Viewはそれぞれ構築するしかない
• ライフサイクルなどUIプラットフォームの差
を吸収しきれない面も
 Viewが違う⇒ViewModelが違う
• Viewの持つデータ構造が同じ場合は少...
共通化できる箇所
どこが共通化できるか?
Viewが変わってもアプリの目的は変わら
ない
 アプリの問題領域は同じ
View/ViewModel以外のModelは同じ
 Modelにアクセスする部分(サービス
層?)は、Viewの見せ...
UIプラットフォームとAP構造
Modelの共通化を踏まえると、APの構造は
以下のようになる
 View, ViewModelをそれぞれ構築する
 Modelは共有する
ViewModel
(WP7)
View
(WP7)
ViewMo...
Portable Class Libraryについて
ライブラリのアセンブリを複数のプラットフォーム
で利用可能にする
 Windows, Silverlight, Windows Phone,
Xbox 360
通常はプラットフォームご...
Portable Class Libraryについて
PCLでModelを構築すると、プロジェクトは1
個で済むか?
ModelでのHTTP通信は、WP7もメトロスタ
イルアプリも非同期で行う
 Reactive Extension(Rx...
プラットフォームの差異@Model
本来の問題領域に関わる部分は、
Modelは共通化できる
ただし、プラットフォームの違いによって、
それを吸収する層が必要になると考えて
いる
 Viewの見せ方の違いによって、
Modelへのアクセス...
プラットフォームの差異の吸収
差異を吸収するには
 Modelをラップするサービス層で、Modelへのア
クセス方法を多様化
 APIアクセスの箇所をPFごとに変える
• #ifとかプロジェクトを分けるとか…
ViewModel
(WP7...
開発環境
メトロスタイルアプリの開発
 WP7アプリ開発でも使ったツールで開発
• Visual Studio 2012 (現在はRC版)
• Blend for Visual Studio
開発環境の違い
Windows Phone 7アプリ
 現時点ではVisual Studio 2012RC
での開発は不可
• VS2010SP1+Blend4、もしくはExpress
Editionで
メトロスタイルアプリ
 Visu...
ソリューションの構成
Windows Phone 7アプリをVisual
Studio 2012RCで開発できないため、ソ
リューションを分ける
 Windows Phone 7用
• Visual Studio 2010で
 メトロスタ...
Modelの共有
Modelはそれぞれのソリューションで共
有する
 Modelのプロジェクト(Classライブラリ)
を各ソリューションで作成
• ポータブル化が実現したら1プロジェクトで
よくなるが現状はこの方法で
 Modelのコー...
UIのプロジェクト作成
UIは通常通りにプロジェクトを作成する
 Modelのプロジェクトを参照する
ソリューションの構成
UIはそれぞれでプロ
ジェクトを作成する
Modelは共通の
コードをリンクとして
追加する
まとめ
Windows Phone 7とメトロスタイルアプリは、Model
を共通化させて、View/ViewModelをそれぞれに開
発する必要がある
 同じXAMLによるUIアーキテクチャだが、UIの見
せ方が違う
Modelの共通化...
Upcoming SlideShare
Loading in …5
×

Metrostyleappに挑戦してみた

896 views

Published on

第3回まどべんよっかいち(2012/7/21)での発表スライドです。

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Metrostyleappに挑戦してみた

  1. 1. Windows 8 メトロスタイルア プリに挑戦してみた Windows Phone勉強会@四日市 第3回 2012/7/21 青木宣明 @kumar0001
  2. 2. Agenda (1 of 2) Windows 8のメトロスタイルアプリ  XAMLによるUI定義、ページ遷移のアプリ構 造など、Windows Phone 7と似た要素が あります  WP7アプリの開発経験を活かせないかと思 い、メトロスタイルアプリに挑戦してみました
  3. 3. Agenda (2 of 2) 本セッションでは、Windows Phone 7とメトロ スタイルアプリを同時に開発する試みについて、 現時点での状況を紹介します  技量不足、時間不足でまだ途中ですが、何 か参考になればと思います  ご意見があれば是非聞かせてください
  4. 4. 目次 1. アプリケーションのマルチプラットフォーム対応 2. Windows 8とメトロスタイルアプリ 3. Windows Phone 7アプリとの同時開発の試み
  5. 5. アプリケーションのマルチプラットフォー ム対応 ・マルチプラットフォーム対応の理由
  6. 6. 増えるUIプラットフォーム XAMLによるUIプラットフォーム(PF) WPF Silverlight Windows Phone 7 Windows 8 メトロスタイルアプリ Windows Phone 8
  7. 7. マルチPF対応の理由(1) ある目的のために開発するアプリを、 様々なPFに展開したい 理由(パターン1)  特性が異なるそれぞれのPFでリリース →アプリの役割をそれぞれ変える • 画面は小さいけどいつでもどこでも→WP7 • 大きな画面で直観的なタッチ操作→スレー トPC(メトロスタイルアプリ) • 大画面での閲覧性とキーボード・マウスで の効率的な操作→デスクトップPC(WPF)
  8. 8. WP7アプリ⇔デスクトップアプリ WP7とデスクトップPCの環境を比較すると… Windows Phone 7 デスクトップPC ハードウェア スマートフォン デスクトップPC ノートPC 画面サイズ 小さい (800×480) 大きい (少なくとも1024×768) 利用環境 モバイル オフィスでの固定利用 ノートは外出先でも 通信環境 主にモバイル回線 (3G) せいぜい5~6Mbps? 固定LAN(100Mbps~) 無線LAN(54Mbps~) 操作 タッチパネル ソフトウェアキーボード(SIP) マウス キーボード ペンタブレットとかのデバイスは 稀?
  9. 9. マルチPF対応の理由(2) たとえば  アプリをデスクトップPCとモバイル向け にリリース • デスクトップ向けでデータ入力・編集 • モバイルでデータ検索・閲覧
  10. 10. マルチPF対応の理由(3) 理由(パターン2 )  プラットフォームの過渡期において、新 旧のプラットフォームにリリースしたい • Windows Phone 8が発売されても、しば らくはWindows Phone 7が存在 Windows Phone 7.8にアップデートするとWP8 とは同一コードで動くか? ダメならそれぞれに対応が必要 • メトロスタイルアプリの普及はいつ頃…? それまでWPF版と並行してリリースする、とか
  11. 11. マルチPF対応の理由(4) 様々な要件で、複数のUIプラットフォーム にアプリをリリースする場合がある  アプリの目的は同じ=対象とするデー タは同じ  アプリの動作環境が異なる どう対応すればいいのか?
  12. 12. マルチPF対応の対象アプリ ATND Beta検索アプリ  ATND betaのAPIを使って、イベントを 検索する • 検索キー イベントID、日付、キーワード、参加者  結果のイベントを一覧表示  選択されたイベントの詳細を表示  参加者の一覧表示もしたい
  13. 13. ATND BETAサイト イベントの情報 参加者の情報
  14. 14. ATND BETA API イベントの検索と参加者を取得するAPIが 提供されている  http://api.atnd.org/ 主な仕様  HTTP GETでアクセス  XML/JSON/Atom/JSONP/iCalend arで結果を取得 • イベントや参加者の情報を含む
  15. 15. アプリの対象PF 対象プラットフォーム  Windows Phone 7に対応させる • 外出先へと持ち歩くメインデバイス  Windows 8のメトロスタイルアプリとし てもリリースする • スレートPC/デスクトップPCでの閲覧性 • まだATND検索アプリがない • スレートPCが今後普及するだろうから、今 のうちに作っておきたい
  16. 16. Windows 8とメトロスタイルアプリ ・主な特徴
  17. 17. メトロスタイルアプリ Windows 8から登場する新しいスタイル のアプリケーション 特徴  コンテンツへの没入  余計な飾りを省いたデザイン、タイポ グラフィによる表現  タッチ操作を意識
  18. 18. メトロスタイルアプリの要素 メトロスタイルデザイン  没入感、コンテンツ優先 タイルでユーザとつながる スナップ、スケール コントラクトでOS・他APとつながる オンラインで鮮度を保つ クラウドへのローミングでデバイスをまた いで継続する
  19. 19. 没入感、コンテンツ優先 メトロスタイルアプリ版 Internet Explorer 10
  20. 20. スタート画面 ライブタイルが並ぶ 解像度に応じてタイルの並び方が変化 解像度 1920×1200
  21. 21. スレートPCでのスタート画面 解像度 1366×768
  22. 22. タイルの操作 タイルを選択(右クリック or 上にフリック) するとタイルを操作可能
  23. 23. チャーム 画面右側に表示 5個のチャーム  検索コントラクト  共有コントラクト  スタート画面呼び出し  デバイス連携  設定コントラクト スタート以外のAP画面か らの呼び出し可能
  24. 24. 画面解像度 最低解像度 1024×768 推奨解像度 1366×768  両者の差(342×768)はスナップの表 示のため • スナップ表示とは? 画面の左右の端に常駐させる形の表示形式 推奨解像度未満の場合、スナップは利用不可
  25. 25. 画面解像度 320px 1366px 768 px スナップ 通常表示
  26. 26. 画面解像度 画面の回転に対応 参考  Building Windows 8 「横向きと縦向きの両方に 向けた最適化」
  27. 27. タッチ操作 メトロスタイルアプリはタッチ操作に対応  基本操作にUIコントロールが対応して いるので、アプリは自動的にタッチ対 応になる
  28. 28. ナビゲーション 画面上部にスワイプすると表示される領域 画面遷移などナビゲーションに関する項目 を配置する  Internet Exploreのタブ切り替え
  29. 29. ナビゲーションの例 画面遷移の制御
  30. 30. アプリバー 画面端をスワイプすると下部に表示され る帯状の領域 アプリケーションの機能を実行するコマン ドを提供する 左右に分かれていて、それぞれ使い方の 指針が出されている  左側: 画面固有の機能(ローカル)  右側: AP全体の機能(グローバル)
  31. 31. アプリバーの領域 表示されている画面に拠ら ないグローバルな機能 表示されている画面に 拠るローカルな機能
  32. 32. コントラクト 他のアプリやWindowsと連携する仕組み  App to App Picking (ファイル選択)  Cached file updater (ソース共有)  Play To (メディアファイル再生)  Search (検索)  Settings (設定)  Share (ターゲット共有)
  33. 33. コントラクト 提供する機能は決まっていて、 指定された時点でその処理を提 供可能なアプリを探す 検索の例  検索チャームを選択する  その時点で検索機能を提供す るアプリで処理 • スタート画面→アプリの検索 • メール→メール内容の検索
  34. 34. コントラクト 参考  Dev Center - App contracts and extensions (Metro style apps)  Building Windows 8 「アプリで Windows 8 のコントラクトのアクティ ベーションを行う 」  Windows 8の新機能「コントラクト」で アプリ連携が簡単に (ascii.jp)
  35. 35. クラウドとの連携 アプリのデータをSkyDriveに保存して、 他のデバイスにインストールしたアプリと 同期できる  デスクトップPC、スレートPCにインス トールしたアプリが同じデータを同期  アプリ情報を引き継ぐことで、デバイス をまたいで作業を継続可能 • あまり大きなデータは不可
  36. 36. ガイドライン メトロスタイルアプリのガイドラインはたく さんあって読むだけでも大変… Windows 8アプリの認定の要件  これが一番重要 「Metro スタイルアプリのガイドライン一 覧 (沢山あるよ~)」 @biacさん  一覧にまとめられている
  37. 37. 情報源 デベロッパー センター - Metro スタイル アプリ  http://msdn.microsoft.com/ja- jp/windows/apps
  38. 38. メトロスタイルアプリの特性 没入感 (immersive)  ユーザがコンテンツに没頭できるように コンテンツ優先 (contents before chrome)  画面にはコンテンツに関係する要素だ けを配置する。余計な飾りは置かない
  39. 39. その他の要素 セマンティックズーム 通知 Windowsストア  試用版 ピクセル密度  ビットマップ画像は3種類用意する
  40. 40. Windows Phone 7アプリとの同時開発 の試み ・アプリケーションの構造 ・開発環境の差異 ・ソリューション構成
  41. 41. 例題のアプリ ATND Beta検索アプリ  まずイベントの検索、結果の一覧表示 までを実装してみる  WP7とメトロスタイルアプリのそれぞれ で実装する
  42. 42. WP7とメトロスタイルアプリ(1) WP7とメトロスタイルを比較すると… Windows Phone 7 メトロスタイルアプリ ハードウェア スマートフォン スレートPC デスクトップPC ノートPC 画面サイズ 小さい (800×480) 大きい (1024×768以上) 利用環境 モバイル モバイル オフィスでも? 通信環境 主にモバイル回線 (3G) 無線LAN? モバイル回線? 操作 タッチパネル ソフトウェアキーボード(SIP) タッチパネル マウス・キーボードがある場合も
  43. 43. メトロスタイルデザインでの考慮 没入感、コンテンツ優先の画面構成にす る必要がある • 審査への影響度は把握していませんが… スナップへの対応は必須 • 未対応だと審査に通らない • 逃げ方はいろいろあるようですが…
  44. 44. WP7とメトロスタイルアプリ(2) Windows Phone 7 メトロスタイルアプリ 開発言語 C#/VB C#/VB C/C++ HTML/CSS + JavaScript UI構築 XAML XAML 画面構成 ページ遷移 解像度: 800×480 画面の回転: 有り ページ遷移 解像度: 1024×768以上 画面の回転: 有り スナップ表示 開発環境 Windows Phone SDK 7.1 Visual Studio 2010 SP1 Expression Blend 4 Visual Studio 2012 Blend for Visual Studio ライフサイクル アプリの活性化・非活性化をAP 自身で管理 ⇒Tombstoning処理 Launching, Activated, Deactivated, Closingイベント 3種類の状態遷移 APはResume・Suspendの遷移 に対応 ⇒Suspending, Resumingイベ ント
  45. 45. ライフサイクル WP7=3つの状態  Running  Domant  Tombstoned イベントは4種類  Launching  Activated  Deactivated  Closing MSDN(“Execution Model Overview for Windows Phone“)から引用 http://msdn.microsoft.com/en- us/library/ff817008(v=VS.92).aspx
  46. 46. ライフサイクル メトロスタイルアプリ=3つの状態  NotRunning, Running, Suspended イベントは3種類  Activated, Suspending, Resuming MSDN(“Application lifecycle (Metro style apps) “)から引用 http://msdn.microsoft.com/en- us/library/windows/apps/hh464925.aspx
  47. 47. メトロスタイルアプリのアーキテ クチャ 「Building Windows 8」から引用 http://blogs.msdn.com/b/b8/archive/2012/02/09/building- windows-for-the-arm-processor-architecture.aspx WinRTを使って APを構築する 開発言語は3パターン ・C#,VB & XAML ・C/C++ & XAML ・HTML/CSS/JS
  48. 48. 共通化を見据えたアプリ構造 アプリケーションがUIプラットフォームに 依存する箇所、依存しない箇所は? まずXAMLプラットフォームにおけるアプ リケーションの一般的なアーキテクチャを 考えてみる ⇒MVVMパターン
  49. 49. MVVMパターン(1) UIのアーキテクチャパターンの1つ WPF/SilverlightのXAMLを使ったUI向 けのパターン  XAMLのデータバインディング、仮想 化を考慮すると自然と導かれる  参考情報 • 「MVVMパターンが必要な理由」啓蒙用資 料公開 (尾上氏) http://ugaya40.net/mvvm/mvvm_docum ent.html
  50. 50. MVVMパターン(2) アプリを3要素に分けて捉える  View • UIの見た目、構造を定義  ViewModel • Viewの状態を保持・管理 • Viewのサポート(入力値検査など持っていな い機能を補完)  Model • アプリ本来の問題領域(ビジネスドメイン) • 通信、DBなどViewとViewModel以外の箇所 全部
  51. 51. MVVMパターン(3) View View Model Model 参照・更新 イベント データ バインディング Viewの状態を 保持・管理 UIの見た目、 構造を定義 アプリ本来の 問題領域
  52. 52. UIプラットフォームによる差異(1) UIプラットフォームが違うと何が変わる か? アプリケーションの見せ方が変わる  UIそのものの違い  UIデザインの考え方の違い
  53. 53. UIプラットフォームによる差異(2) プラットフォームの特性、狙い、制約によりView はそれぞれ異なる メトロスタイル  モバイル環境でも利用されるが、通信量には 寛容?  画面が大きい (1024×768~)  コンテンツファースト Windows Phone  モバイル環境のため、通信量は抑えたい  画面が小さい (800×480~) • データをうまく見せる工夫(Panorama、Pivot) • 複数の画面で構成するしかない
  54. 54. UIの見せ方の違い UIの見せ方が違うと?  Viewはそれぞれ構築するしかない • ライフサイクルなどUIプラットフォームの差 を吸収しきれない面も  Viewが違う⇒ViewModelが違う • Viewの持つデータ構造が同じ場合は少な いはず
  55. 55. 共通化できる箇所 どこが共通化できるか? Viewが変わってもアプリの目的は変わら ない  アプリの問題領域は同じ View/ViewModel以外のModelは同じ  Modelにアクセスする部分(サービス 層?)は、Viewの見せ方の違いによっ て影響があり得ると思います
  56. 56. UIプラットフォームとAP構造 Modelの共通化を踏まえると、APの構造は 以下のようになる  View, ViewModelをそれぞれ構築する  Modelは共有する ViewModel (WP7) View (WP7) ViewModel (metro) View (metro) Model
  57. 57. Portable Class Libraryについて ライブラリのアセンブリを複数のプラットフォーム で利用可能にする  Windows, Silverlight, Windows Phone, Xbox 360 通常はプラットフォームごとにライブラリのアセン ブリは異なる Visual Studio 2012から標準で対応
  58. 58. Portable Class Libraryについて PCLでModelを構築すると、プロジェクトは1 個で済むか? ModelでのHTTP通信は、WP7もメトロスタ イルアプリも非同期で行う  Reactive Extension(Rx)と呼ばれるライ ブラリを活用する Rxが現状ではPCLに対応していない  2.0RCが出ているので詳細を調査中 ModelをPCLで構築することは、現状では難 しいのでは?  非同期処理がない単純なAPなら可能?
  59. 59. プラットフォームの差異@Model 本来の問題領域に関わる部分は、 Modelは共通化できる ただし、プラットフォームの違いによって、 それを吸収する層が必要になると考えて いる  Viewの見せ方の違いによって、 Modelへのアクセスの仕方が変わる  Modelが利用するAPIが違う • システム関連、通信、非同期処理、DBなど
  60. 60. プラットフォームの差異の吸収 差異を吸収するには  Modelをラップするサービス層で、Modelへのア クセス方法を多様化  APIアクセスの箇所をPFごとに変える • #ifとかプロジェクトを分けるとか… ViewModel (WP7) View (WP7) ViewModel (metro) View (metro) Model Model (WP7) Model (metro)
  61. 61. 開発環境 メトロスタイルアプリの開発  WP7アプリ開発でも使ったツールで開発 • Visual Studio 2012 (現在はRC版) • Blend for Visual Studio
  62. 62. 開発環境の違い Windows Phone 7アプリ  現時点ではVisual Studio 2012RC での開発は不可 • VS2010SP1+Blend4、もしくはExpress Editionで メトロスタイルアプリ  Visual Studio 2012RCが必須  Blend for Visual Studio
  63. 63. ソリューションの構成 Windows Phone 7アプリをVisual Studio 2012RCで開発できないため、ソ リューションを分ける  Windows Phone 7用 • Visual Studio 2010で  メトロスタイルアプリ用 • Visual Studio 2012RCで
  64. 64. Modelの共有 Modelはそれぞれのソリューションで共 有する  Modelのプロジェクト(Classライブラリ) を各ソリューションで作成 • ポータブル化が実現したら1プロジェクトで よくなるが現状はこの方法で  Modelのコードを、各プロジェクトにリ ンクとして追加する
  65. 65. UIのプロジェクト作成 UIは通常通りにプロジェクトを作成する  Modelのプロジェクトを参照する
  66. 66. ソリューションの構成 UIはそれぞれでプロ ジェクトを作成する Modelは共通の コードをリンクとして 追加する
  67. 67. まとめ Windows Phone 7とメトロスタイルアプリは、Model を共通化させて、View/ViewModelをそれぞれに開 発する必要がある  同じXAMLによるUIアーキテクチャだが、UIの見 せ方が違う Modelの共通化は、現状ではPortable Class Libraryの利用は厳しいため、別プロジェクトになる  ライブラリなど環境面の変化によって、将来的に は共通化できる可能性がある 現時点では、開発環境が異なるため、それぞれでソ リューションを作成する必要がある  これも環境面の変化で、将来的に解決する可能 性がある

×