DDLG: 4月 2015

2015年4月30日木曜日

Build2015 1日目メモ（何か作らないと死んでしまう人用）

MSの戦略だのUI哲学だのHoloLensだの、大所高所からのお話、未来のお話には特に触れないです。今何か作らせろや！！！という人用。

VS2015RC

出た GoLive
DL　community, enterprise RemoteToolsはページの下のほう
https://www.visualstudio.com/downloads/visual-studio-2015-downloads-vs

但し、現状以下の問題が有るので・・・新規にUWP Project作るのは中々ハードルが高い。

解説ではWin10SDKインストール要らないよ！となっているが、実際にはVS2015RCで新規にUAP Projectを作ろうとするとSDKのインストール解説ページに飛ばされ、コントロールパネルのプログラム追加削除→VS2015　RC→Modify SetupからSDKをインストールすれと。
で、実際やってみると…インストールの最後に「ユーザーによって取り消されました」というエラーになってしまいインストールできない。えー。

~~ここに多数報告が上がっているが現状回避策は無い。~~
https://social.msdn.microsoft.com/Forums/en-US/fd16256b-6a36-4aab-ac88-13d367471701/

→　直るまで、以下のページ右下のStandaloneSDKを使ってくれというガイドがフォーラムに出ていました。

https://dev.windows.com/en-US/downloads/windows-10-developer-tools

UWP

Universal Windows Platform
今までUAP, Universal Application Platformと呼んでいたけどこれからこっちになるのかな？

既存ProjectのMigration/Update
方法は色々載ってるんだけど、上に書いた問題があるのでまだお預け状態。もどかしい。
https://msdn.microsoft.com/en-us/library/dn975273(v=vs.140).aspx

※DeviceFamilyとXAMLの件
お勉強メモ
http://ddlgjp.blogspot.jp/2015/04/windows-10-uap.html
で触れたDeviceFamily毎のXAMLの件ですが…デモでやっていたような、電話を大きいモニタに繋げてPCの様に扱うという使い方を見せられると…やっぱこう、基本線としてはOne WindowsとしてRelative Panel 駆使して頑張るのが（MS的には）正しいのかなぁという気がしますね。

Developer Mode

今までのWin8~以前のWin10 Buildでは、Appをストア以外から入れる…サイドロードする場合、「開発者ライセンス」を当該Systemで取得する必要があった。今回のWin10 10074では「開発者モード」に変わった。
が、現状開発者モードのSettings UIは問題があるので、

Win10 Desktop: ポリシーエディタで手動で変えれ
Win10 Mobile: Windows Phone Developer Registration Tool を使え

というお達しが出ているので注意。
（PhoneのRegistrationToolは大体 C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Windows Phone SDK 8.1　あたりに入っています）

Enable your device for development
https://msdn.microsoft.com/library/windows/apps/xaml/dn706236.aspx

Store

解説
Distributing Windows Apps to the World
http://blogs.windows.com/buildingapps/2015/04/29/distributing-windows-apps-to-the-world/

Windows/Phone Store, PubcenterのDashboardが合流する
2013までは追加SDKだったPubcenterのAd、Ad Mediatorが最初からVS組み込みになる
HTMLベースのCorporate Storeが出来る
Win10 UAPの受付はまだダメ
App用のアフィリエイトプログラムを開始するんだと。まじか。

Dashboardのプレビュー版がオープンしている。今上げてるものの確認する機能のみにアクセス可能。
https://dev.windows.com/en-US/publish/dashboard-selection

UWP bridge

AndroidのApp, Objective-CのiOS App, 'Classic Windows Apps', web をストアに載せて動かそうぜ、という話。

Introducing the Universal Windows Platform Bridges
https://dev.windows.com/en-US/uwp-bridges/

Android, iOS, 'Classic Windows Apps' については「夏に詳しい情報出すよ」それまでは興味のある奴はメールを寄越せスタイル。

WebAppについては夏にRelease。

…Win10夏リリースという話がまだ生きているなら、WebApp以外の三者は別スケジュールなのかな？かな？という気がするけどどうなんでしょう。

また、UWP（UAP）のDeviceFamily Model…　全ファミリがCoreをサポートし、ファミリ事に追加のExtensionをサポートする…というスタイルと、このUWP Bridgeがどう折り合いつけるのが興味があるんだけど、そういう話はまだ出ていない。夏まで待てと。

2015年4月6日月曜日

Windows 10 UAP : Photo っぽいSplitView を作るには（途中）

Win10 UAP のお手本として参考にしているMicrosoft の「Photo」、良く見ると結構謎な動きをしていて…

Win10 の Photo
ダンジョン出会いの奴面白いですね作画もいいし（関係無い）

動作からすると画面上部のバーはCommandBar (※)
CommandBarの上には基本AppBarButton、AppBarToggleButton, Splitterくらいしか置けないはずなんだけど何故か「Collection」という字が乗っている
CommandBar、の親のTopAppBar・BottomAppBarはPageに生やすので、その上に何か乗ったりはしないはずなんだけど、SplitViewのPaneを展開すると上に被さってるように見える

※ CommandBar・AppBar共に見え方がWin8.1から変わっています　既定はボタンが見えてる状態の「Compact」State 　昔のツールバーチックな使い方が想定されてるように見えます。

どうやってんでしょうね？

うーｎうーｎとそれっぽいのを作ってみたのが下です。

フォトのまねっこ

実現のキモとしては、

CommandBarのCompositeModeをMinBlendにして、他のElementの上書きを許す　又下の文字を透かす
そのままだとAppBarButtonのHoverが効かないので、ボタンのCompositeModeはそれぞれSourceOverに設定
そのままだとSplitViewのPaneを展開したときにCommandBarのBgColorが透けて見えてしまうので、PaneのOpen・Closeに合わせてCommandBarのLeftMarginを変える（ダサい…）
「CommandBar上の」TextBlockは、実はCommandBarでは無くその下のRelativePanelに置いてしまう（ダサい…）

現状、動作の面でPhotoと違うのはCommandBar右端の「…」のHoverEffectが効かない所です。

ただ、ご覧になると判るようにかなり無理やりなので、今後の保守性・拡張性、また電話用にVisualState をくっつけていくと破綻するのでは…等、大いに不安が残る所です。
話半分で見て下さい。

加えて、CodeBehindでCommandBarのMarginを変えています。

 

        private void Button_Click(object sender, RoutedEventArgs e)
        {
            if (mySplitter.IsPaneOpen)
            {
                cbTop.Margin = new Thickness(mySplitter.CompactPaneLength, 0, 0, 0);
                mySplitter.IsPaneOpen = false;
            }
            else
            {
                cbTop.Margin = new Thickness(gdSplitterPane.ActualWidth, 0, 0, 0);
                mySplitter.IsPaneOpen = true;
            }
        }

2015年4月4日土曜日

Windows 10 UAP お勉強メモ

5/23 追記… //build 2015から一か月経ち、MSDNのドキュメントも大分整備されているので…ここの古い記述よりも、MSDNやBuild セッション等、MSの一次情報を見て頂いたほうがいいかと思います。

Build2015 Day1 Session 視聴メモ
http://ddlgjp.blogspot.jp/2015/05/build2015-session.html

Build2015 Day2 Session 視聴メモ
http://ddlgjp.blogspot.jp/2015/05/build2015-day2-session.html

(三日目は見る前にMSDN側の文書が出てきたので結局見てないです）

↓のメモ、そんなに外してはいないのですが… 一個大きく外しているのはデバイスファミリの扱いです。結局ファミリを直で読めるAPIは存在しており、ファミリ毎に別個のUIを作ることができます。

ただBuildのセッションを見ていると、デバイスファミリとUIの持ち方については場合によりけりなのかな、という感じがします。

XAML Teamのセッションで強く打ち出されていたのは、各デバイスファミリで共通のXAML を使用し、画面サイズのみに依存して画面構成をAdaptiveに変更することで基本的にはいける、という考え方でした。
ファミリ毎に異なるUIを複数持つのは手間であり、また、Continuumのように「Win10 Mobileで動作するが、大きなモニタに接続した場合はWin10 Desktop『のような』UIを表示したい」　場合を考えると、安易にデバイスファミリ毎にUIを別に持つのは確かに危ない感じがあります。

一方、「SurfaceHub」…80インチの巨大画面を持つWin10システム、デバイスファミリは「Windows Team」…に合わせたアプリを書こう、というセッションは、あっさりデバイスファミリで場合分けして別UIをもりもり作る、というデモでした。　SurfaceHubの場合 Win10 Desktop / Mobile とはアプリのUsage Model が大きく異なるため、これもまた理にかなった書き方なのだろうと思います。

※ ContinuumについてはXAMLのUI Elementに怪しい感じのPropertyが生えているようなので…この先説明がされると思うんですが、現状まだよくわからん所はあります。

以下は4月頭時点での記述です。

-----

Windows 10 UAP について、2015年4月4日現在で一番詳しく書いているのはこの文書と思われます。

Guide to Windows universal apps
https://msdn.microsoft.com/library/windows/apps/dn894631.aspx

これを読んで自分なりに気の付いた所をまとめたよというお勉強メモです。//Build 前でもあり、予想・憶測が多めに含まれているのでご注意下さい。

※分量が多くて全部見切れていないのですが、Microsoft Virtual Academyの動画

A Developer's Guide to Windows 10 Preview
http://www.microsoftvirtualacademy.com/training-courses/a-developers-guide-to-windows-10-preview

こちらではみんな大好きJerry Nixon がかなり突っ込んだ所まで動画で説明してくれてるようです。これもお勧め。字幕が無くてつらいけども。

※2015.04.19 - デバイスファミリをRuntimeに見分ける件について追記しました
※2015.04.25 - 複数のXAMLでCodeBehindをShareする件について追記しました

★★★

Win8.1 / WP8.1 "Universal" app

まず、今までの「Universal」Appについて軽く復習して何が違うのか理解の助けにしようと。

Win・WPそれぞれの実行バイナリは別、プロジェクトも別
両者を１つのソリューション内に整理し、共用コードはShared フォルダに納める
Shared内での差分はIFDEFで吸収

物凄く雑に言うと、二つの別バイナリを楽に作るための仕組み。

こう書くと結局設計時に分けてるだけで全然別じゃん？という印象であるが、実際作ってみるとUI等非共用部でも…WinRTとしては同じところが凄く多いので簡単ではある。
ただ、似たコードが増えるので保守的にはあまり宜しく無い。
CodeBehind から又ViewModel として共通部分を分離していけば綺麗にはなるが、毎回毎回MVVMだなんだと頑張るのもちょっとなーという所はあった。

Win10 UAP

実行時にデバイスのCapabilityを見て使うAPIを判断する、One Binary形式。

ルートにいるのがUniversal。

子供の各デバイスは全てUniversal App Platform としての機能と、加えてデバイス特有の機能を「Contract」として持つ。

※各Contract は排他では無い事に注意。例えばWindows.Devices.SmartCards.SmartCardDeviceContract はPC・電話両方に同じものが存在する。

VS2015 でテンプレート「Win10 UAP」で作成したアプリは「.NET for Windows Store App」と「Universal App Platform」をReferenceとして持つ。

このUniversal App Platform のNamespace範囲内で書く分には、それは上に挙げた全部で「動作」する。

（「動作」…動くけども、UIとして各デバイス用に作りこむかはまた別の話と思われる。この辺りの話は下のほうで又触れる。）

今までのWin8.1 / WP8.1 で言えば、例えばWindows.Storage, Windows.Storage.Stream 、それとUI…GridViewであるとか。そういう基本的な所はUniversal App Platform に格納されており、これらだけを使う分には Win10 では全てのDevice で使う事ができる。はず。

各デバイス特有の機能を使う場合、設計時にプロジェクトへExtension 単位で追加することになる。
現在使用できるのは

Windows Desktop Extension SDK　　（所謂Win32 DesktopApp の事ではなく、PC・タブレットの事）
Windows Mobile Extension SDK　　（電話　だがドキュメント読んでると、こっちに入る小さなタブレットも想定には入っているようだ）

の二つ。
例えばPC・電話両方で動くOne Binary なアプリを作る場合、上二つのExtension 両方をReference として追加する事になる。

それぞれのデバイスが対応するContract 一覧はSDKManifest.xmlに書いてある。XBOX・IoT のExtensionはまだ拾えていない。

Desktop…PC・タブレット等がサポートするContract

Mobile 電話がサポートするContract

実行時のCapability 確認

設計時から分かれているWin8.1/WP Universal とは対照的にUAP はOne binaryであるため、実行時にDevice のCapability を確認する作業が必要になる。

そのためのAPIがWindows.Foundation.Metadata.ApiInformation。

型・イベント・メソッド単位で「これは現在実行中のデバイスで使用可能か」を取得し、OKなら使ってよし、という書き方が可能

Windows.Foundation.Metadata.ApiInformation
IsTypePresent
IsEventPresent
IsMethodPresent
...

ただメソッド単位とかやってられんので、IsApiContractPresent 、Contract 単位で見るのが現実的な感じ。

手元のVS2015で試してみた様子

例えば、PC・電話両方のExtension を追加したアプリで、電話だけにある機能 Windows.Phone.StartScreen.DualSimTile を「PC上で」使おうとした場合…

var obj = new Windows.Phone.StartScreen.DualSimTile();

実はこれはPCで実行してもエラーにならない。
こいつを

await obj.UpdateAsync();

とすると、ここで初めて例外となる（DualSimTile ではたまたまコンストラクタで何もしてないからエラーにならないだけかも。ただインスタンスとして作れてしまうことは判る）。

勿論、正しい書き方は上で出たAPIを使い、

if( Windows.Foundation.Metadata.ApiInformation.IsApiContractPresent("Windows.Phone.StartScreen.DualSimTileContract", 1, 0)
{
　　// hogehoge
}

というように、デバイスのCapability を見ることになる。

なお、Windows.Foundation.Metadata.ApiInformation には特にメタデータ変わったイベント等は無いので…アプリ動作中にデバイスが変わる心配はしなくて良い、はず。

Extension と Contract …デバイス間の境界はどこにあるのか

ここまでで気づくのは、設計時と実行時でCapability の粒度が異なる所。

設計時　　Extension　　デバイス種別単位
実行時　　Contractが最大　　各機能単位

（おそらく）実行時にコード上で「もしデバイスが電話なら」「もしPCなら」と切り分けができるようなAPI は用意されていないように見える。最大の単位はContract。

※もしあったらごめんなさい。ただ今回の見ててもそれっぽいのがなく、またWin8.1/WP8.1の時もWindows.Security.ExchangeActiveSyncProvisioning.EasClientDeviceInformation みたいな妙な所にしか無かったので…意図的に作って無い感じがするんですよねこれ。One Windows だから？

※2015/04/19 追記
以下の記事によると、Windows.ApplicationModel.Resources.Core.ResourceContext.GetForCurrentView().QualifierValues の Key"DeviceFamily" にファミリ名が入っているとの事です。実機でみた所、PCでは"Desktop", 電話では"Mobile"が入っていました。
Using Custom Visual State Triggers
http://www.sharpgis.net/post/2015/03/24/Using-Custom-Visual-State-Triggers

※2015/04/25 追記
以下の記事によると、
特定のDeviceFamily用にXAMLを持つことが可能であり、またXAMLは一つのCodeBehindを共有できるとの事です。

デバイスファミリ名のフォルダを作り、そこに同名のXAML（のみ）を置く
例）フォルダ'DeviceFamily-Mobile' 内に’MainPage.xaml'を置く
CodeBehindはRootのMainPage.xaml.csをシェア

又は
XAMLのファイル名をIdentifier付きにする
既定のDeviceFamily用→「MainPage.xaml」
特定のDeviceFamily用→「MainPage.DeviceFamily-Mobile.xaml」

（記事にある「XAML Viewの追加」メニューは僕のVS2015CTP6には無く、手動でフォルダにXAMLをコピーする必要がありました。）

Building adaptive layout in Windows 10 with RelativePanel and AdaptiveTrigger
http://blog.galasoft.ch/posts/2015/04/building-adaptive-layout-in-windows-10-with-relativepanel-and-adaptivetrigger/

電話用のMainPage.xaml がフォルダ DeviceFamily-Mobileに置いてある様子

XAMLのファイル名にIdentifierつけるのもアリ
CodeBehindは共通のMainPage.xaml.cs

既定の3カラムレイアウトがDesktopで動いている様子

電話用1カラムが動いている様子
（ScreenCaptureが動かないので写真です…）

例えば実行時にExtension 単位で見分けることが出来れば便利かもしれないが、Extension は結局Reference であるため…設計時にそれを追加したという話でしかない。つまり「アプリが走っているこのデバイスで使用可能かどうか」という情報では無い。

今回追加になったContract ではWindows.Fountation.Metadata.ApiInformationによってデバイスがその機能を実行可能かどうか、（アプリ）実行中に知ることができるようになったと。そんな理解で良いのではないかと思う。

また、Contract がこのように実行時にCapability を提供できるということは、デバイス自身がメタデータとして「自分は何を実行できるのか」情報を持っているという事でもある。

今のところは電話・PCで大別して「電話ならこれらのContractを全てサポート」という切り方だけども、将来的には「電話だけどこのコントラクトをAdditionalにサポート」みたいなデバイスも作ることはできるのかもしれない（出す出さないでなく、APIのありかたとして可能という意味）

UIと入力

ここまで見てきたCapability についてはデバイスにより有り・無しの厳然とした違いがあり、コードは実行時に確認することができた。

だがしかし、UIと入力については様子が随分異なる。

新規に追加されたRelativePanel と、拡張されたVisualState とInkCanvas 等を駆使してUnifiedな一つのXAMLを、対象とするデバイス全てについて動かそうという考え方に見える。つまり、XAMLを「分ける」…Win8.1/WP Universal Appの様な「電話用XAML・PC用XAML」的な作り方はあまり想定されていないように見える。

勿論、電話用・PC用XAMLを作り分けページ遷移時に切り分ける、という方法はテクニカルには可能かもしれない。
だけれども、上のExtension とContract の扱いで分かるように、Win10 UAP では実行時環境を「デバイス単位」で切り分ける手段が（おそらく）無いため、間接的に「電話にしかないContract があるから電話」という切り方にならざるを得ず…この方法は可能だが正しいとは言いづらい。DualSimTile を持つPCが出てこないとは言えない。

むしろ、作り分けをせざるを得ないのならそもそもアプリを一つにまとめるのが無理な話で、アプリ別々に作ればいいのでは？と。UAP はそういうスタンスなのだろう、多分。

ストアへのDeploy(まだ情報が出て無い部分）

ここはまだ情報が出ていない。
１バイナリのUAPが完成したとして、それをストアへデプロイする際デバイス種別はどうなるの？ストアが勝手に分ける？その場合スクリーンショットは全デバイスで撮るの？全部で撮るんなら超めんどくせえな！！的な謎な部分は多い。

上の例で言えば、UAPの範囲内で作ったので動かせば全デバイスで動作はしてしまうけども、UIのサイズとしては電話しか想定していないアプリ、というのは当然存在するはずで、デプロイ時に開発者が「このアプリはこのデバイス用」と宣言する、のが自然な形なのではと思う。

また、Win8.1/WP Universalのように「バイナリ・パッケージは別だが、AppIDを共有しているので購入情報やRoaming Storageを同期している」電話用・PC用 Win10 UAP、という形もサポートされていると便利だと思うけど。どうなのかな。

余談

結局、Win8.1 / WP8.1 の「Universal」Appは僅か1年でお役御免となった訳ですが…というか、MFC で10年以上ご飯食べられていた時代を思うとびっくりしちゃいますね。

登録: 投稿 (Atom)

DDLG