私はおじさんなので、一度見てもすぐ忘れてｱﾙｪｰどのセッションであれ言ってたっけ…となるので今年はメモ取って見よう、という趣旨の記事です。
基本的には後でMSDNの文書が更新されるのでそっち見れば済む話ではあるのですが…API Referenceだと、この仕組みが要る背景、どれが大事か、というような背景の話が無くてどのMethodもFlatに説明される事が多いです（QuickStartやOverview等で説明の入る部分も多いですが、全部では無い）。作った奴が自分で説明する話を聞くのは貴重であり、価値があるものです（「詳しい使用者」の話にもまた価値があるのですが、それはまた別種のものでしょう）。
2-660 Surface Hub: Building Windows Universal Apps for Surface Hub and the Large Screen
2-664 All That is New in the Windows Store
2-672 Bring Fluid, Responsive, and Highly Scalable UI Experiences to Your Universal Windows Apps with the New Visual Layer
2-679 From the Small Screen to the Big Screen: Building Universal Windows App Experiences with XAML
2-681 Introducing DirectInk: Learn How to Unlock New Opportunities Using Ink in Your App
3-610 Compiling Objective-C Using the Visual Studio 2015 C++ Code Generation that Builds Windows, SQL, .Net, and Office
2-692 'Project Centennial': Converting your Classic Windows App (Win32, .Net, COM) to a Universal Windows App for Distribution in the Windows Store
2-695 App Packaging and Deployment for Universal Windows Apps
2-702 “PROJECT ASTORIA“: Build Great Windows Apps with Your Android Code
2-703 Optimizing Windows Apps for Continuum
2-790 Deep Dive into XAML and .NET Universal Windows App Development
3-698 XAML Performance: Techniques for Maximizing Universal Windows App Experiences Built with XAML
3-705 Harness the Full Power of Digital Inking in Your Universal Windows App with Ink Recognition, Advanced Ink Processing, and More
3-710 Store: Deep Dive on Publishing Universal Windows Apps
2-724 Windows for Makers: Raspberry Pi 2, Arduino and More
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
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を繋ぐ
でも、
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でやるよ！
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分取ってるけど略）
「皆電話が大好きよね、私も好きだわ！日本のティーンの９０％はシャワー中も電話をそばに置いているそうよ」 （そうなの？）
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億
（このセッション、何があったか知らんけどタイトルが明らかに間違いで 全部.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
- 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
#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
- それぞれのファミリで必要とする最低限のバージョンを指定できる
プロセッサ
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＋ロボットキットが貰えたようだ よかったね
