DDLG: Build2015 Day2 Session 視聴メモ

2-660 Surface Hub: Building Windows Universal Apps for Surface Hub and the Large Screen

James Fiduccia, Eric Flo, Roberto Sonnino
お薦め度　1億（DeviceFamilyとトリガの使い方のところ）
http://channel9.msdn.com/Events/Build/2015/2-660

(最初音が聞こえなかったが、何度か一時停止・再生してると聞こえた）

Surface Hub runs UWP 'Only' ... Win32, StoreAppは動かない　へー
DeviceFamilyは「Windows Team」
Neutral, x86 or x64で作れ　（ARM無しのintel systemという事？）
Surface hub上でSessionを作成する事にAppは毎回「初回起動」の如く動作する（後述）
ペン・タッチに特化　一応ソフトキーボードもある（けど使いにくいﾖﾅ…との事）

Session Cleanup　重要！

セッション開始…会議始めるとか…、で使い終わってセッション終了時に、AppData、文書、画像、テンポラリファイルは全て消去される　
保存したい場合は自分でCloudに保存（つまりSurface Hub自身はStorageLessなDesign）
セッション開始＝アプリにとってはクリーンインストール後の初回起動になるので、ここに色々くっつけている（チュートリアルだのようこそ画面だの）とSurfaceHubでは使いづらいものになる

Interaction and consumption zones

Zone 1 : 操作者、直接操作する人のゾーン　腕を伸ばせばSurface Hubに届く範囲　1.3m程度,
Zone 2：出席者、プレゼンを見る人ゾーン　1.3-4m(55inch), 1.3-6m(84inch model)
このゾーンを考慮してUIを作る　また、操作者に近いところにもってくる

デモ　…Small sizeを考慮して作ったアプリをSurface hub対応にする

SplitView, Button, ContentにFlipViewを持つシンプルなもの　明るい青色背景
そのまま起動すると…Hubの画面一杯に同じアプリが表示される　それなりに動く　ただ背景が明るすぎる、サイズでかすぎ、NavMenuのサイズは常にOpenのほうが良い等…直すところが出てくる
VSでの作業…SurfaceHub用のVisualStateを作る　ここでは既定とWindowsTeam用を作る　Blendを使うと簡単　サイズ、色等をいじる　ここではPresentaionよりはCollaborationに特化したいのでMaxWidth/Heightで小さくする
又、VisualStateを二つ定義するだけでは勿論ダメで、Stateを変更するTriggerも書く　ここでは、サイズでなく「DeviceFamily」そのものをトリガにする。 3000x2000のNotebookと同じUIを出したいわけではないから。　　Windows.System.Profiles.AnalyticsInfo.VersionInfo.DeviceFamilyが目的のファミリだったらばアクティブにする、という「DeviceFamilyStateTrigger」クラスを、StateTriggerBaseから派生させて作っている　動画の36分あたり　
ここで作ったトリガを、Xamlの中でDeviceFamily="Windows.Team"として指定する。Oh!
DataTemplateの切り替え…ここではInkCanvas付きを使う。あれ、切り替えの話飛ばされた気配
ここからは同一Viewを使うのでなく、SurfaceHub専用のView（XAML）を作る話
ここでは、App.xaml.csからrootFrame.Navigateで飛ばす際、AnalyticsInfo.VersionInfo.DeviceFamily == "Windows.Team"ならSurfaceHub用のViewに飛ばす、というやり方を使っている

SurfaceHub特有のUI

操作者の数に応じてUIを変える　ペンのIDを見て、ユニークなペンが2本現れたら二人、と見なして「いいね！」ボタンを2セット見せるとか　面白い

Wrap-up

Collaboration Scenarioを真剣に検討すべき SurfaceHubでは複数の人が使うシナリオがメインであるし、また遠隔地と繋げて使う事もあるだろう　一人だけで使うアプリから頭の切り替えが要る

2-664 All That is New in the Windows Store

Ashish Babbar, Adrian Maziak
http://channel9.msdn.com/Events/Build/2015/2-664

動画がまだ無くスライドのみなのでざっと眺めるだけ…大体は既知の話が多いけど

Page18

Application Flighting 今はWPだけのBetaTesting、UWP全部で使えるようになるのかな？かな？スライドの一行だけなのでわからんけど！期待

Page21

Engage ... 'Public and private response' 今はWPだけでPrivateResponseが使える状態だけど　あれ実際使ってみると結構便利という印象なので期待

Page22

Monetize ... subscription modelがサポートされる

2-672 Bring Fluid, Responsive, and Highly Scalable UI Experiences to Your Universal Windows Apps with the New Visual Layer

James Clarke
お薦め度　3
http://channel9.msdn.com/Events/Build/2015/2-672

「Visual Layer」の今後の話　VisualLayerが具体的に何を指すのかは後述
最初にかっこいいUIのデモビデオ　ここに至るにはどうしよう、という話

New programming model - WinRT Composition API

Windows.UI.Composition c#, standard c++, C++/CX
All UWPで使用可
In preview .... まだ出来て無い！

振り返り　Win8.1のVisual Layer

App→Framework Layer (XAML)→Visual Layer(DirectComposition / DirectManipulation)→Graphics Layer(DirectX)
VisualLayerについてはVistaでDWMとして入ってきた部分　ただWin8まではAPIとしてApp開発者には特に意識される部分では無かった　AppはFrameworkLayerとしてXAMLを、GraphicsLayerとしてDirectXを触っていたがVisualLayerにはInterfaceが無かった（Win32には少しあったが）

Win10のVisual Layer

App→Framework Layer (XAML)→Visual Layer(Windows.UI.Composition)→Graphics Layer(DirectX)
今までWinRT Worldからは見えない・触れない所に居たVisualLayerに触れるようになる

デモ・TweetWall

Streamを見せるApp　呟いてる人のアイコン多数がAlphaBlend付きで滑らかに流れる　（HTML/JSでも出来そうだけどﾅ）一人アニメアイコンが居るな？
UWPなので電話でも動く

Light-Weight Visual Layer

CompositionObjectの親がVisual Object
派生　SolidColorVisual, ImageVisual, EffectVisual　今後増える予定 Geometryとか
ContainerVisualが子供としてVisualsを持つ

Visualで何ができるか

Resize, Positioning, Clipping, Transforms, Properties, BuildTree

デモ：Visual Types

うｎ　画面にがりがりVisual Objectで物を描いていくデモ　ただベタ書きではなくVisualTreeの構造は持っているのが面白いところ　UI ElementとしてRichなXAMLでは無く、純粋にVisualLayer上の存在なのが違う所なのかな

デモ：Transforms　　Doomチックな迷路表示

XAML and Composition

Visual Layerを使う理由...より複雑なアニメーション・エフェクト、多数のXAML Elementのアニメーション、を少ないコードで実現可能（確かに…XAMLでやるのは大騒ぎになりがちではある　VisualLayerでCodeだけで書けるのは便利かもしれない）
使うには…使いたいUI ElementをWindows.UI.Xaml.Hosting.ElementCompositionPreview に渡してContainerVisualを取得し、Compositorにアクセス（今後変わるかも）

デモ：XAML Integration

Effects

Blend/Composite/…。将来的にはシェーダを使ったエフェクトも

Animations

Keyframe/Duration等…XAMLと似てる　というよりはXAMLがこれ使ってるのかも
42分　Tweetium作者がアイコンで写ってる（笑）

DirectX Interop

スケジュール

Insider buildのWin10「では」動く
Win10 RTM Buildではinbox-callerだけが使える（つまり普通のアプリからは使えない）　（えーーーー）
2015年末にはV1 APIをリリースし、アプリから使えるようになる予定

感想…XAMLだけでは無理なCosmeticな効果、アニメーションをつけたい！場合に役に立つかもしれない。

2-679 From the Small Screen to the Big Screen: Building Universal Windows App Experiences with XAML

Tim Heuer, Harini Kannan
お薦め度　5

http://channel9.msdn.com/Events/Build/2015/2-679

XAML親分Timのお話

Tim的にはUWPでのXAML UIは「ほぼ」ウィンドウサイズで切り替え、必要ならCapabilityで解決できるという立場　（ただ、上のSurfaceHubであったようにDeviceFamilyで切り替える場合も出てくるのだろう）
PopupMenuがマウス・タッチでサイズが変わる話（3回目）
Pivotの紹介　Windowが狭くなると自動的に左右にタブ部分のスクロールコントロールが出る

Scalingの話

100、200、400を（Bitmap）Assetでサポートするのが大事
別セッションで詳しくやるよ！

デモ　Kliva app...UWPへのMigration

SplitView, VisualState, Trigger, RelativePanel等既知の話が続くので略（Speakerのお姉ちゃんが早口すぎて付いてけないというのもありますが）
「幅が変わったらVisualStateでRelativePanelの取り付き先を切り替える」というデモをしてる　なんかこう・・・うーｎ・・・この時点で既に茨の道な気がすんだけど

VisualStateTriggerおさらい

ここではSurfaceHubでやってたDeviceFamilyで切り替えるという荒業は紹介されない…

RelativePanelおさらい

SplitViewおさらい

ApiInformation...XAMLだけではどうもならん場合

Windows.Fouindation.Metadata.ApiInformation

デモ：Custom Trigger　説明は41分あたり

基本的には上のSurfaceHubでやってたのと同じ StateTriggerBaseから派生させる　
ここではポインタのDeviceTypeを拾い、マウスだったらTriggerを飛ばす形にしている　
話としてはSurfaceHubの説明のほうが判りやすい　が、タッチだったらUI大きくするのはこれ使うと簡単にできるのかもしれない

GithubにCustomTriggerのサンプルがあるよ！
http://github.com/dotMorten/WindowsStateTriggers

KeyMessage

繰り返し「UWPのVisualState変更はほぼほぼWindowSizeで出来る　必要ならCapabilityを使う」　　（Tim的にはまず前者でやってほしい、というのがMessageなようだ）
Win10のInboxAppはほぼ前者である
ContinuumModeだと話が少し変わる　この場合Capabilityを見る必要があるかも
Xbox, Surface HubのようなUnique物は後者にならざるを得ない　これはレアケースである（ここでフォルダ分けを使ったDeviceFamily別XAMLの画像が一枚だけ入る…）

（感想　Desktop/Mobileの切り替えをDeviceFamily別XAMLでさらっと済ませたい人も多いんでないかなぁと思うが　ただContinuumな使い方を考えると、安易にDesktop/Mobileで分けるのはあまり宜しくないはず）

2-681 Introducing DirectInk: Learn How to Unlock New Opportunities Using Ink in Your App

Sriram Subramanian
http://channel9.msdn.com/Events/Build/2015/2-681

（概要の話だったので略）

3-610 Compiling Objective-C Using the Visual Studio 2015 C++ Code Generation that Builds Windows, SQL, .Net, and Office

Salmaan Ahmed, Jim Radigan
http://channel9.msdn.com/Events/Build/2015/3-610

…僕には難しくて良く判りません（特に前半）後半は僕がiOS全然わからんのでわからない所が多い
後半、本当にVS2015でObjectiveCをBuildしてアプリが普通に動き、普通のC++のようにデバッガの機能が動いている　すげえ

UWP APIとiOS apiを使うことができる、Objective-Cで書くUWP
OperationMode - formfactorを吸収する
電話Onlyでは「ない」…Win10 各DeviceFamilyで動き、ARM/x86/x64で動作（このあたりも確かにUWP）

API

iOS APIのSubset
特定のVersionに合わせている訳ではない
良く使われるAPIから実装
Games...OpenGL, OpenAL, Sensors
UI...UIKit, CoreAnimation, CoreGraphics, CoreText, Touch (IMEはどうなるんだろう？）
OSの機能はWindowsにRedirectする　Sharing, Notifcations,Camera, Store In-App Purchase, FileSystem(mapped), etc

これから

SDKを夏にリリース
詳しく知りたい人はProject IslandwoodにMail送ってね

Q&A

UIControlの見た目はどうなるの？…（Win10）持ちのResourceはWinのもの　ただAppが変えるのは勝手
二つ目…ライブラリ話？（聞き取れない）
Swiftは？もうObjective-Cはあんまり使ってないぜ？...今日はコメントできません:)（どっと笑い）
XcodeからVSにMigrateしたProjectに加えた変更はどうなるの？…Oneway　共有ソースは勿論シェアされるが

2-692 "Project Centennial": Converting your Classic Windows App (Win32, .Net, COM) to a Universal Windows App for Distribution in the Windows Store

John Sheehan, David Tepper
http://channel9.msdn.com/Events/Build/2015/2-692

「SUBPOP」

「未完成、夏にSDK」

Classic Windows App（CWA） → Universal Windows AppへのBridge
MSI is 'brittle'（脆い）
→　CWAを既にあるUWPに持っていくには

今のUWP（StoreApp, AppX）のDeployModelは良く出来てる

SingleClick
自動アップデート
落ちない
「ユーザーが信頼できる仕組み」アンインストールで綺麗に戻る

デモ：PhotoShop Elements（WindowsAppsの下に入ってる　確かにStoreAppと同じ）Directoryを覗く

FilsSystemMetadata.xml
Registry.dat...仮想化されたRegisty Hive AppはこのRegistryにアクセスする
AppxManifest.xml...StoreAppと大体同じ　FullTrustAppとしてEXEがEntryPoint　他にはFileAssosiation, LiveTile等が入る
Directory VFS ... System32だのなんだの、全部では無いが・・・・Oh・・・仮想化されている（パッケージどうなるんだろう　すげえでかくならない？うまくやるんだろうか）
Assets...LiveTileのBitmapだの

どうやって作るか・・・変換

MSI→変換→AppX
MSIで入れるものをCaptureしAppXを生成する
テスト、そして（MSIの）更新が要る
全部出来る訳じゃ無い　ターゲットはApp　SystemServiceやDriverはターゲット外

Namespace merging...Appが見るのはMergedView SystemのNameSpaceにApp Namespaceを重ねたもの　例えばAppがSystem32に置くMsvcrtは実際にはApp Namespaceに置かれる WriteOPはリダイレクトされる（32bit→64Bitの時の仮想化Filesystem/Registryと雰囲気が似てる）
FullTrust Activation...AppX世界のApp ContainerとFullTrustを繋ぐ

でも、

UWPに移行するのが正道

Q&A

AppXのSideloadは？...他のUWPと同じ
SingleUser/MultiUserは？...（質問がうまく伝わらなかったっぽい）

（感想…ElegantなIslandWoodにくらべるとこう…運用で解決というか、シス管的解決を図ってる感じがある　MSIから変換する訳だけど、一発でうまくいくものもあれば結構変えないといけないものもあるだろう　）

2-695 App Packaging and Deployment for Universal Windows Apps

Barclay Hill, Jason Salameh
お薦め度　1億
http://channel9.msdn.com/Events/Build/2015/2-695

UWP appxの利点　AppX、三つの利点…配置が簡単、マニフェストによる宣言、容量の削減

Incremental Update…V1からV2で共通のファイルは転送を省く　ファイルごとにHashを取って比較している　新しいファイルのみを転送　（知らなかった）これはMobileで特に効果的
File Single Instanting...二つのアプリ…例えばMSGameStudioの二つのゲームが同じコンポーネントを使っている場合…広告モジュール等　この共通ファイルはストア上でシェアされる　（これも知らなかった）
部分リソースダウンロード...例えばスケール毎にリソースを持っている場合…デバイスに必要なものだけがダウンロードされる　（これも）
（このあたりはWin/WP8.1のAppXで既に使ってる機能との事　AppXすごい）

UWP App Deployment

インストール済みのWP7/8.x、Desktop8AppをUWPで更新 (Desktop8==storeapp)
一つ又は複数のデバイスファミリをターゲットに　Manifestで宣言
開発者モードの新設…開発者ライセンスに変わるもの　（既知　ただし現状UIはあるけど動いてない状態　PolicyEditorで変える　このBlogではDay１まとめで書いてある）
Sideload...やり過ぎ注意

デモ…Packaging

開発者モードの有効化
Package.AppxManifestの説明（まだManifestDesigner無いもんﾅ…作るんだよね？）
PhoneProductId…Phone用Appと紐づける（Win8Universalでもやってたやつ）
TargetDeviceFamily…Name, MinVersion, MaxVersionTested (Testedがｲｲね）Versionは Featureの追加で増える
複数のファミリをサポートする場合、複数のTargetDeviceFamily Elementを宣言する（コードの実行上の必要な要素としてのデバイスファミリとは又別なのかな？）
ストア用パッケージのビルド、PS1を使ったInstall…このあたりは8.1とあんまり変わって無い
Phoneでの開発者モード有効化
お　Deploy用のコマンドラインツール　　WinAppDeployCmd install -file hogehoge.appx -ip A.B.C.D
デプロイしたのはボタンクリックで例のペガサス猫を表示するアプリ　猫人気過ぎる

ストレージの改善

Win10ではリッチデバイスから小さいデバイスまでターゲットが広いよね？
ストレージの小さいデバイスにより多くのAppを入れるために…Phone8.1で入れたExternalMediaへのインストール機能をWin10に持ってきた (mjk!)
外部メディアへのインストール又は移動が可能　（素晴らしい）
外部メディア上でのアプリ（ユーザー＋アプリ）データは暗号化される
同一パブリッシャーのアプリ間でストレージを共有可能　（後述）

デモ：外部メディア上のアプリ

Settings→System→Storage　ここからアプリ・ゲームの保存先を変更できる　（10074で既に使用可能）ここでポイント・デバイス毎に暗号化されるので、あるデバイスでカードにアプリをインストールした場合、そのカードを別の他のデバイスに挿しても使用できない　　（同じアカウントの場合はどうなんだろう）
インストール済みアプリのストレージ変更はSettings→System→Storage→コンテンツ上部の「PC」又は外部メディアのバーグラフをクリック→「アプリとゲーム」、で「インストールされたアプリと機能」画面に遷移　ここからアプリ毎にストレージを移動・アンインストール可能

デモ：パブリッシャー共有ストレージ(Win10での新機能）

例えばパブリッシャーDDLGでアプリAとアプリBを出してる場合、この二つのアプリ間で（デバイス上に）共有のストレージを持てる
Package.AppxManifestの中にExtensionを作り、Category Attributeに"windows.publisherCacheFolders"をセット　この子要素でフォルダの名前を定義
Code上からStorageにAccessするには…ApplicationData.Current.GetPublisherCacheFolder(Manifestで定義した名前）でStorageFolderを取得できる　以降は普通にStorageFolderとして使える

サポートの継続

これまでのAppXパッケージフォーマットは今後も利用可能
これからも拡張します
AppXの歴史…ベースはWPのXAP　現在抜けているのはAppX自身の暗号化

EnterpriseのDeployについてはIgniteでやるよ！

2-702 “PROJECT ASTORIA“: Build Great Windows Apps with Your Android Code

John Justice, Rajesh Sundaram
http://channel9.msdn.com/Events/Build/2015/2-702

AstoriaではAndroid StudioのIDEを使う　（IslandwoodではVSそのまま使ってた　個人的にはVSのほうがｲｲﾅｰ）

デモ　アンドロアプリの移植

画像、地図サービス、共有、ソフトキーボード入力を使うサンプルアプリ、Android上で動いてるものをまず見せる
次、WP上で動いてるアプリ　共有ではWPのShare、地図ではBingMap、入力はWPのキーボード、そしてアプリからWPのライブタイルを更新

Astoria App Analysis ページを開設してます

Webフォーム上にAPKをドロップするとAnalyzeして…推奨する変更箇所を教えてくれる　対応するWindowsサービスを表示　GooglePlayサービスはWindowsStoreAppに変えれ、GoogleMapはBingMapに変えれ等

Android Studioでのデモ

ProductFlavor"windows"/"android"
WPEmulatorに接続、デプロイ　APK→APPX
デバッグは普通にできる　BP,Stepin/out AndroidStudio上で
WindowsServiceが使える…LiveTile Notification, Windows Notification Service,...
（WNSへのMappingは良く出来てるなぁ）
（拍手を欲しがるPresenter　ｲｴｰｰｰ）
開発はMacでも可能（WPEmuがOSXで動いてる画面　Oh）

Windows does the heavy lifting for you (Islandwoodと同じスライドだ）

「AstoriaでBuildしたAppは、Windows Appである」

Copy&Pasteも勿論できる　（WPもWin10からだけどな！）
MSのCloudServiceも使える ApplicationInsights, MS Ads, In-App purchase, WNS, Xbox live services, Bing Maps, Location Services, ...

Astoriaの構造

スライド　APKを内包するAPPXがあり、それがAstoria Subsystemの上に載っている（PureなAPPXという訳では無いんだね　またSubsystemLayerもIslandwoodの説明では出てこなかったパーツ　ちょっと仕組みが違うのかな）
Astoria Subsystemは直にWindowsKernelの上で動く、という説明（この言い方も何も言って無い気がするが）

まとめ

ターゲットはWin10 Mobileのみ　
IDEは好きなのを使え　AndroidStudio, IntelliJ, Eclipse, それぞれにAstoriaPluginがある
開発はPC/MacどちらでもOK

Q&A (20分取ってるけど略）

2-703 Optimizing Windows Apps for Continuum

Keri Moran, Gino Sega, Liz Threlkeld
お薦め度　5億
http://channel9.msdn.com/Events/Build/2015/2-703

「皆電話が大好きよね、私も好きだわ！日本のティーンの９０％はシャワー中も電話をそばに置いているそうよ」　（そうなの？）
Continuumによって…電話で動くUWPはどの画面でも使えるようになる　これはまさに「Write once, run everywhere」　　　（死亡フラグっぽくていやだなこれ）

デモ

Keynoteの後聞かれたけども…Continuumに特別はハードウェアは必要無い　このデモで使うのも、Win10の電話、Bluetooth Keyboard/Mouse、Miracastなモニタ、これだけである
電話でExcelを起動し、NotificationCenterからMiracastで外部モニタに接続…するとWin10 Desktopとスタートメニューが画面に写る　「ようこそContinuumへ、ようこそ未来へ」（ドヤァ）
このスタートメニュー、PCのスタートメニューと少し違う　左ペインのListViewが無く、右のタイルのみが表示される　このタイルは電話のスタート画面のタイルと同じ
この時点ではExcelは電話上で動いている
スタートメニューのExcelをタップすると、Excelは外部モニタに移動する　電話はスタート画面
電話の通知センターから「Continuum（Control）」を起動　すると電話はタッチパッド画面（何も表示してないが）になる　これで電話をタッチパッドにして外部モニタ上のアプリを操作できる
外部モニタ上でHDビデオを全画面再生　この間も電話上ではカレンダー、Mailアプリを使うことが出来る

（この一連のContinuumのデモは今回のBuildでは１、２を争うAttractiveさだと思う）

新興市場のようなスマートフォンがFirstDeviceである市場にもPC UserExperienceを届ける事が可能　（日本のヤングにも当てはまる話ﾀﾞﾅこれ）

Continuumが想定するConfiguration

Wired Dock
Wireless Dock
Wireless Dongle （HDMI直差しスティックみたいなの）

Continuum対応アプリを作るには…Effective Pixelの理解が鍵　（TimのUWPセッションでも出てきたやつ）、スクリーンサイズへの動的な対応が必要

大事な三要素…Fluid UI, Responsive UI, Tailored UI

Fluid UI

「Screen」のResizeに動的に追随する必要がある　WrapGridを使ってContentをReflowさせるのがお勧め
別の例…２ペインレイアウトでは絶対サイズではなく相対サイズを使う .3*/.7*みたいな
RelativePanelも鍵

Responsive UI

例えば　Effective Width <= 768なら電話UI、＞768ならBigScreen UI
AdaptiveTriggerを使って表示を動的に変更

Tailored UI

Viewに応じてコントロールそのものを切り替える　ListView→GridViewとか　NavigationModelも切り替える
ここでも切り替え契機はAdaptiveTrigger

デモ
天気アプリ

BigScreenではSplitViewのSmallSizeを常に見せてるスタイル、Phoneではハンバーガーのみ
ContentはBigではWrapGridで横に並べる、電話では縦に並べる

Mail

BigではMultiColumn、電話ではSingleColumn

カレンダー（失敗）

Packaging…AdaptiveなUWPを作ればそれはContinuum対応である

デモ…フォト、ファイル

Scaling

Scale 300, 100, 150, ...
今の電話はScale 200-400, PCは大体Scale 100-150　だが300のもある
Downscaling...400で作っておくと、それから100、150を自動的に縮小して作る　だが予め高品質なDowscaledを作っておく方がいいのは当然
Assetsはファイル名にhogehoge.scale-300.png とScaleを入れる方法と、Scale毎に「Scale-ABC」フォルダを作りその中にhogehoge.pngを入れる方法がある　どちらにしても表示ディスプレイに応じたScaleのResourceが選択され、ms-appx:///Assets/hogehoge.png でアクセス可能

Multi-Screen

Cast API...MediaElementを特定のモニタに全画面表示する
ProjectionManager API...Appで複数モニタ表示を制御　例：rootFrame.NavigateでPageを作った後rtProjectingAsync(rootpage.id, thisviewid) として指定のモニタに表、await ProjectionManager.Sta示する　StopProjectingもある　　例えば…PresentationAppで、外部モニタにプレゼン本体、電話にプレゼンのノートを表示する等

まとめ

UWP対応アプリを作って！
アプリが電話・PCどちらでも動くことを確認
Big/Small用のアセットをアプリに含める
MultiScreenAPIも使ってみて

（大きな拍手）

2-790 Deep Dive into XAML and .NET Universal Windows App Development

Unni Ravindranathan
お薦め度　1億

http://channel9.msdn.com/Events/Build/2015/2-790

（このセッション、何があったか知らんけどタイトルが明らかに間違いで　全部.NET Nativeの話） unniのXAML話は2-697で聞けるらしい

.NET Native ... 「全てのWin10 .NET Appは.NET NativeでCompileされたものがユーザーデバイスに届けられる」　

何故.NET Native？
「Mobileのため」

NoJITでCPU負荷が減る
Coldで最大60%、Warmで40%StartupTimeが減らせる
最大30%メモリ占有量を減らせる

「Adaptive Appsのため」

UWPは複数のDeviceFamilyで動くため、対応していないContractを呼んでしまうエラーケースが増える（はず）SDK、Contractのアップデートが重なるにつれさらに増える
この場合JITだとそこで落ちる
.NET Nativeの場合は「大丈夫」（何故JITだとダメで.NET NativeだとOKなのか、詳しくは説明してくれなかった　興味ある　→　同じ質問を会場の人がしてて答えてたが　JITがダメでNativeが良い答えにはなって無かったような）

「更新ペースを早めるため」

AppとClient Systemの.NET Gapが存在しなくなる
（今まであったような）.NET X の普及を見てそろそろ移行…的な事がなくなる

.NET Nativeの開発フロー

開発中も.NET Native Chainを有効にしてDebugしてほしい、というのがメッセージみたい　（VS2013＋.Net Native に比べるとVS2015RCの.NET Native buildは偉く速いのでここはOnのままで大丈夫と思う）
AppX VersionのRevision Field（4桁の一番最後）はStore側でのコンパイル用にReserve　つまりユーザー（開発者）はRevision Fieldを使えない　（初耳）

VS2015RTM での既定のパッケージング

Debug…AppX: MSIL .appxupload: no build
Release…AppX:.NET Native, .appxupload: MSIL (.NET NativeへのビルドはStoreが行う)

Runtime Directives

ほぼほぼ既定のままでOK
弄ってApp Footprintを減らすことも可能

.NET Native best practices

開発中はDebugビルド
ただ、マメにRelease（.NET Native)でビルドしてテストを行うべき

Libraryについて

PCL….NETCore 4.5.1
Native Win/Phone 8.1 ... VS2013 CRT
Native UWP ... VS2015 CRT

3-698 XAML Performance: Techniques for Maximizing Universal Windows App Experiences Built with XAML

Mark Alcazar, Kiran Kumar
お薦め度　3
http://channel9.msdn.com/Events/Build/2015/3-698

XAMLは充分なパフォーマンスを出せるか？...完全にYes
XAMLが車だったとしたら…どんなタイプの車だろうか？　パフォーマンスだけのフォーミュラカー？快適（生産性）だけのリムジン？いや違う、素晴らしいパフォーマンスと高い快適性（生産性）をバランスよく両立させたAudi A4みたいな車がXAMLだ！（ドヤ）　（A5？　アウディがお好きらしい）

パフォーマンス１０の原則

パフォーマンスの「禅」を受け入れよ
問題を明らかにし目標を定めよ
UWPに変換すれ
アプリのプロファイリングをすれ
スタートアップの改善
要素を減らせ
仮想化を使え
バインディングを最適化せよ
画像を最適化せよ
テキスト描画を最適化せよ

#1 Zen of Performance...「最も速いコードは実行しないコードである」（禅だ…）

具体的には...

機能とパフォーマンスのバランスを取るよう努力せよ
後で出来るタスクは後でやる
可能な限り整理する

デモ：WP8.1のカレンダー　

右上に天気を表示してる　この為にWebServiceにアクセスし天気を取得してる　ただこれのために遅くなってる　これはカレンダーの本質じゃない　このためカレンダーAppチームに行ったアドバイスは「まずカレンダーの予定を表示し、後で天気を取得」するようにCodeを変えることだった

#2 問題と目標を定める

何が問題？

アプリのスタートアップが遅い
電話で（メモリが足りなくて）Hang
スクロール等の反応

何がゴール？

１、2秒に収める
メモリ50MB以下のSystemでの動作
Responsiveなスクロール

#3 UWPへの移行

Win10では多くのパフォーマンスの改善がシェル・アプリ共に行われた
多くのパフォーマンス最適化コードがWin10に入っている
x:Bind, x:DeferLoadStrategy 等はUWPだけで使用できる
UWPへの移行でスタートアップ時間は15%-30%、メモリ使用量は25%-40%の改善が見られる

#4 アプリのプロファイリング

プロファイリングを行い、どこが問題点かを明らかにする
VS2015を活用…タイムラインツール、遅いコードの同定、メモリ使用量の確認、診断

デモ：お馴染のFabrikam
起動から画面表示までがやたら遅い
DebugのAnalyzeDashboardを表示　ここからTimelineを選択して「Start」…実行した結果のタイムラインビューが表示される　起動から終了までの各タスクに掛かった時間　アプリのコード、Layout, Rendering, etc UIスレッド内の割合等　Parsing…SystemがXAMLのParseに掛けてる時間
このデモではスタートアップに数秒掛かってる　Layoutにやたら時間掛かってる

#5 スタートアップの改善

初期化タスクを別スレッドに移す
ロード中・進行中表示を上手に使う

#6 要素の数を減らす

ざっくり言って、1000エレメントで1秒くらいの感じ　1万エレメントなら10秒くらい掛かっちゃう
スタートアップ時にParseに掛かる要素の数をチェック
使って無いスタイルを探す
テンプレートをチェック

x:DeferLoadStrategy

Win10 XAMLの新機能
UIの部分をロードするのに大変便利
特定のエレメントツリーのインスタンス化を遅らせる事ができる
MVVMで特に便利

使用例

XAML...<StackPanel x:Name="hogePanel"... x:DeferLoadStrategy="Lazy"></StackPanel>
Codebehind...var deferredPanel ＝ FindName("hogePanel"); ←-ここでインスタンス化

デモ：エレメント数の削減（略）

(飽きてきた…）

#7 仮想化

List/Gridviewの仮想化を使うべき
落とし穴…ScrollViewerの中にListViewを置く、ListView/GridViewで使ってるPanelを変更する

#8 binding

DataTemplateは極力シンプルに
x:Bind...compiled time databindingを使う x:BindについてはDay1 のSessionに詳しいので略
x:Phase, ContainerContentChanging ... 同じくDay1のSession

3-635 Data Binding: Boost Your Apps' Performance Through New Enhancements to XAML Data Binding

#9 画像

大きな画像はメモリ食う
大体はFramework側で最適化するが…
DecodePixelWidth/Height で必要なサイズにデコードすれ　（このあたりはお馴染の話なので略）

#10 テキスト

Win10はテキストレンダリングが50%速くなった！
既定で有効
幾つかのTypography Featureは無効にできる　CharacterSpacings, Typography, LineStackingStrategy,...　　（Win10は既定で無効、と言いたいのだと思う、多分　後のデモと合わせると）
新API IsTextPerformanceVisualizationEnabled ... TextのDebug表示

デモ　TextとImage

App.xaml.cs で一発IsTextPerformanceVisualizationEnabledを呼ぶ　Framerate表示と同じ雰囲気
TextがGreenで表示される部分は「速く」表示されているという意味　つまりOK
Greenにならない所は遅いという意味　デモではDataTemplateでCharacterSpacingを1に指定していたため、黒表示になっていた

まとめ

UWPに移行しよう
このSessionのTop10Listに従ってパフォーマンスを改善しよう
更新版のパフォーマンスWhitePaperを出す予定です
XAMLとOfficeの組み合わせも速いんだ！ロケットバスだ！詳しくはDay3のSessionで！

3-705 Harness the Full Power of Digital Inking in Your Universal Windows App with Ink Recognition, Advanced Ink Processing, and More

Xiao Tu, Francis Zhou
お薦め度　2
http://channel9.msdn.com/Events/Build/2015/3-705

DirectInk... Rich built-in functions, flexible APIs, extensible design

デモ

CodeでInkCanvasのInkPresenterに色・太さを持つペンを作ってる
（Stroke・Colorを選ばせる組み込みのツールパレット的なのは無いのかな？）
文字列への変換はInkRecognizer
手書き…StrokeはStorkeContainerが保持
35言語の手書き文字認識に対応　デモでは「Microsoft 中文」Recognizerを指定して中国語を認識させている
StrokeCollection…　ひと塊のStrokeをCollectionにし、サイズを変えて画面の別部分にそのStroke Putが可能　UserDefinedBrushのStroke版みたいな感じ

（後でSlideとDocument読めば充分な感じなので中断）

3-710 Store: Deep Dive on Publishing Universal Windows Apps

Matthew Cowan, Ted Driggs, Jonathan Garrigues
お薦め度　5
http://channel9.msdn.com/Events/Build/2015/3-710

同一アプリの場合、電話・Desktop共通の価格、ストア上の表示、IAP
明日詳しい所をBlogに載せるから見てほしい　→

Get ready for the Unified Dev Center dashboard preview and upcoming Store changes
http://blogs.windows.com/buildingapps/2015/05/01/get-ready-for-the-unified-dev-center-dashboard-preview-and-upcoming-store-changes/

↑読んでおくべき

StoreでのDesktopAppのListingは終了との事（UWP Bridgeがあるしね）

Packaging （これはBlogに載って無い所）
ユーザーのデバイスにおいて、Manifestで宣言するこれらの定義を満たすアプリがListingされる
Device Family

Universal, Desktop, Mobile, Xbox, Team(surface hub), Holographic
それぞれのファミリで必要とする最低限のバージョンを指定できる

プロセッサ

ARM, x86, x64, Neutral

Foreground Memory (Optional)

アプリをForegroundで実行時に使用するメモリ量を指定
300MB, 750MB, 1000MB, 2000MB

DirectX (Optional)

必要なDirectX APIのVersion, DirectX HardwareのFeatureLevelを指定

Selection

複数パッケージが存在する場合、ストアはManifestのRequirementを満たし、もっとも新しいバージョンのものをPickする
DeviceFamilyのVersion、DirectXのVersion等複数ファクタが絡んでくると案外ややこしいので注意

Listing

ストア上のアプリの説明文は全デバイスファミリで共通
スクリーンショットも「共通」…登録したスクリーンショットは全デバイスファミリで表示される
説明とスクリーンショット以外の要素は全てOptional

デモ…アプリの登録

（スクリーンショット、登録上はDesktopとMobileでカテゴリ分けされている）

ハードウェアの必要要件

必要なハードウェア条件を定義するとストアはそれを表示
アプリのレビューは、この条件を満たすシステムからの投稿のみを受け付ける
タッチスクリーン、マウス、キーボード、カメラ、NFC HCE（？）、NFC、Bluetooth LE、Telephony

Business Store

Enterprise Userは自前のBusiness Store内に向け自前アプリを配布可能

Q&A

Business Storeについて…詳しくはIgniteで！

2-724 Windows for Makers: Raspberry Pi 2, Arduino and More

Steve Teixeira
http://channel9.msdn.com/Events/Build/2015/2-724

（前半のRasPi2は特にメモする事が無かった）

Project Margherita: Windows Virtual Shield for Arduinoは面白い

Shield山盛りのArduinoよりLumia530のほうが安い！　（Lumiaは安すぎるしArduinoは部品として使うには高価だﾖﾅ…　物の値段はﾑﾂｶｼｲ…）
LumiaをArduinoのShiledの代わりにして入力をArduinoに送ってあげる
そういう動作をするUWPをLumiaで動かす

デモ：Lumiaのカメラで写真を撮り、BluetoothでArduinoに転送（でも肝心のArduino側表示をセッションのカメラが映してくれないという…）

デモ：Wikipediaから取得した色をArduinoで表示（これもArduino側は映してくれない）

デモ：.NET Micro ... 略

Sessionに出た人はRasPI2＋ロボットキットが貰えたようだ　よかったね

DDLG

2015年5月2日土曜日

Build2015 Day2 Session 視聴メモ