How to know the current processor architecture from UWP app

Unfortunately, WinRT does not have such of API. We, in 2019,  need to use pinvoke.

--start--
--end--

You may noticed that this unfamiliar name "api-ms-win-core-sysinfo-l1-2-3.dll". This is a sort of "OneCore Umbrella library".

OneCore.lib umbrella library
https://docs.microsoft.com/ja-jp/windows/desktop/apiindex/umbrella-lib-onecore-alpha

I could not tell you how this works, but works. :) It's too difficult for me. For detail, this site may helps you.

Runtime DLL name resolution: ApiSetSchema - Quarkslab's blog
https://blog.quarkslab.com/runtime-dll-name-resolution-apisetschema-part-i.html
https://blog.quarkslab.com/runtime-dll-name-resolution-apisetschema-part-ii.html

The API Set Schema - Geoff Chappell
http://www.geoffchappell.com/studies/windows/win32/apisetschema/index.htm


Note - UWP Community toolkit have the System Helper API. By using this, you can get the propertry "SystemInformation.OperatingSystemArchitecture". The document tell that  this property is "Gets used processor architecture" but actually not. It just return the "target" architecture of the UWP app package.

SystemInformation - UWP Community Toolkit
https://docs.microsoft.com/ja-jp/windows/communitytoolkit/helpers/systeminformation

UWP Multi Instance support - Part 2

I have a simple sample program 'DDLG.MultiInstanceTrial' on Microsoft Store and GitHub. Let me explain the hint & tips of UWP multi instance by using this sample.

DDLG.MultiInstanceTrial - Microsoft Store
https://www.microsoft.com/en-us/p/ddlgmultiinstancetrial/9nrdjtp6bdnx

Source
https://github.com/pnp0a03/MultiInstanceTrial

This post is part 2 of the series - UWP Multi Instance Support.
UWP App の Multi Instance サポート その１(in japanese)
https://ddlgjp.blogspot.com/2018/05/uwp-app-multi-instance-1.html

Enabling

To enable the multi instance, just update your Package.appxmanifest. 1) Update the namespace at "Package" element,  and 2) Add attribute "SupportsMultipleInstances" to "Application" element.
Oh, at first, you need to use the Win10 1803 or later (and SDK).

- start - Package.appxmanifest
- end -

Behavior of Protocol Activation

If you register the app as protocol handler and the app is enabled as multi instance, the behavior is differ from the single instance. When the protocol activation happen, always new instance created. On single instance, same instance's OnActivate is called again.

Resources

It seems that each instances are running on same AppContainer. This means, each instances share the one LocalSettings/LocalFolder/Etc.
You can use my sample app to see the behavior. On the right side, you can show the image file. This file name is shared by LocalSettings, then each instances can use the same value.

Event?

In this trial, I'm using the most easiest way to share the event - ApplicationData.Current.DataChanged.

ApplicationData.DataChanged
https://docs.microsoft.com/en-us/uwp/api/windows.storage.applicationdata.datachanged

When you create or modify the applicationdata, the event signaled. You can also signal it manually.

Note - This event will be signaled with background thread. It's need to use dispatcher to use it with UI thread. You can see the sample on the source above.

Memory Mapped File

As of same app container, you can share the data by using memory mapped file. In my sample, the center pane use the one.

WinMR Environment - Desktop and MR

On WinMR enabled system, you can use both the windows desktop and WinMR 3D environment.
You can run your app on both. And, it seems that both share the same app container. By using this app, I could confirm that.

Building UWP Apps as ARM64 with Visual Studio 2017

Yes, we have toolings that support ARM64 UWP Apps but there are several caviets and pitfalls. I've attempt to describe my experiences to support ARM64 on my UWP app with this short post. I wish this helps you.

Updating your tools

As of Mar 2019,

• Visual Studio 2017 15.9.7 or later
• Windows SDK 17763 or later

Modifying your .csproj to add ARM64 build configuration

This step is described at blogs.windows.com.

Official support for Windows 10 on ARM development
https://blogs.windows.com/buildingapps/2018/11/15/official-support-for-windows-10-on-arm-development/

But.. in my cases, it didn't work. I have to modify my .csproj manually. However it's easy.

1. Make the ARM64 debug/release config by copy and paste the ARM config. then,
2. Make ARM64 build config by VS IDE (as described on the blog post).
3. Adding win10-arm64 and win10-arm64-aot to runtimeidentifier. It seems that not necessary

I've just paste the before/after of my .csproj on gist. To compare it, please download both and use your favorite diff tools :)

WWC csproj 17763 vs 17134
https://gist.github.com/pnp0a03/bac76f72bc2526e674860c9e512605ba

Updating Microsoft.NETCore.UniversalWindowsPlatform

In fact, 6.2.x or above support the ARM64. 6.1.x is NOT. You need to use it. But.. currently (as of the end of jan 2019), 6.2.2 have issues -  build may success locally, but you will see the 1201 error when you submit the appx package to Microsoft Store. You need to pick the 6.2.3 or above.

https://github.com/Microsoft/dotnet/issues/924

To use the 6.2.3, just edit your .csproj manually.

(Added 14 March 2019 - 6.2.8 released. I could confirm that it works and ok for store upload.)

Updating Microsoft.Advertising.XAML to 10.1811.22001

If you use the Microsoft Advertisement SDK, you need to update to 10.1811.x.
There are two type of deployments - one is VSIX , another one is NuGet package.

My recommendation is, if you're currently using the VSIX, you should use the VSIX for the next version. Same for the NuGet.

If you want to switch to the NuGet from VSIX(This is my case), you must uninstall the VSIX from Add/Remove the Programs. But this way may be painfull for you, because the uninstallation of VSIX may affect to all other your project that use the Microsoft Advertisement.

Even if you did it as above, you may see the some of build error. My advises are .. 1) Restart the system, 2) Clear the nuget cache, 3) check the reference settings, and 4) Take a cup of coffee.

...Done?

Here is a my app that support Arm64. But... I have not tried yet with actual Arm64 system :) If you have a chance to try it, please let me know the result.

Wheel World Clock
https://www.microsoft.com/en-us/p/wheel-world-clock/9nblggh10zzn

UWP App の Multi Instance サポート その１

Windows 10 April 2018 Update (1803, RS4)からUWP App がMulti Instance、いわゆるアプリの複数起動をサポートするようになりました。実は今迄使えなかったんですね。

(This post is part 1 of the series - UWP Multi Instance Support.)
UWP Multi Instance support - Part 2, sample app and source
https://ddlgjp.blogspot.com/2019/03/uwp-app-multi-instance-2.html


まずは実際動かして試してみましょう。拙作のUWP App Wheel World Clockが既にMulti Instance に対応しています。

UWP App を複数起動している様子

Wheel World Clock ダウンロードはこちらからどうぞ

タスクマネージャーを見ると、実際にインスタンスが複数作成されているのがわかります。またこのアプリはちょっと仕込みが入っていて、文字盤の画像貼り換えを行うと他インスタンスに設定変更が通知されるようになっています。

ただ…Windows、Desktop上でAppを普通に使っている身からすると、

• 「アプリが同時起動」って当たり前なのでは？
• 今迄なんでできなかったの？
• 2018年になって今更？

という疑問が湧くのは当然…という気がします。そこで、Multi Instance をキーにしてApp Model発展の経緯を俯瞰し、なんとなく分かった気になってみようというのが今回の記事です。

• その１　UWP App Model の経緯と今回のMulti Instance対応、今後の展望　（この記事）
• その２　Multi Instance 実際の対応作業と注意点

という予定です。

StoreApp / UWP App Model の変遷

Win8 - Single Instance, Single View (2012)

現在のUWP App の源流となるWin8 StoreApp、またそれの元となったWindows Phone環境は別名「Immersive UI」、没入型UI等と言われていました。タブレットやPCの画面「全体」をアプリが占有するイメージです。この環境では所謂デスクトップそのものが存在せず、あるアプリが同時に起動できるのは一つだけになっていました。
また、Immersive UIではこの当時から画面分割、Splitをサポートしていましたが、Win8の頃は「別アプリ同士」で画面を分割する形でした。

Win8/8.1 用 StoreApp 拙作のfuta8 です。
配布は終了しています。

Win8.1 - Single Instance, Multi View (2014)

"Multi View"がサポートされました。同時起動できるアプリのInstance
は引き続き一つだけですが、そこから複数の「View*1」を別スレッドで持つことが出来るというものです。画面分割に対し、一つのアプリが複数のViewを同時に表示できるようになりました。ただこの頃はStore AppでMulti Viewをサポートしたものは少なかったように記憶しています。

Win10 - Single Instance, Multi Window (2015)

「Immersive」の看板はそっと後ろに下げられ、Win10 UWP Appはデスクトップ上「でも」普通に使えるものとして再定義され、これまでの「View」が「Window」としてデスクトップ上に表示されるようになりました。Tablet / Phoneに軸足を置いたApp Modelから、デスクトップ / Win32 App と一緒に使える方向に大きく舵を切り直したのが Win10 UWP Appと言えると思います。

ただ、Win8.1 のSingle Instance なモデルは維持されました。プロセス自体の仕組みはそのままで、所謂Multi Window な動作を実現するためにはMulti Viewが引き続き使われていました。

Win10 UWP App F10 Image bbs browser
右がスレ・カタログを扱うメインウインドウ、
左の二つがスレ画像を表示する画像ウィンドウ、のMulti Viewを使っています。

MultiView を採用している、おそらく一番馴染みのあるUWP App は…Win10標準の「電卓」だろうと思います。一見複数起動しているように見えるのですが、実はプロセスとしては一つだけです。なお、電卓はRS4でもこの仕組みのままです。*2

UWP App「電卓」のMulti View動作
一見沢山起動しているように見えるけどInstanceは一つだけ
「起動」の度に一つのInstanceのOnLaunchedが呼ばれ、その都度Window（View）を作成しています。

このように、対応すればそれなりに色々な事が出来るMulti Viewですが…過剰というかオーバーキルというか、マルチスレッドの実装が大袈裟過ぎるという弱点があります。
上の例のF10 image bbs browser のような、Window一枚がドキュメント一つに対応しているSDI / MDI的なアプリならば頑張る価値はあるのですが、

• 電卓のように、単に複数起動したい　→ 素直にMulti Instanceでいいのでは？
• メインウィンドウの脇にサブウィンドウを表示したい　→　同一スレッドでポンとWindow出したい…マルチスレッドにするほどでも無い…

という具合で、実際 Win10 UWP App でもMulti View を使っているアプリは少ないです。*3

また、Win10 UWPでは「ContentDialog」が追加になりました。Desktop＋Window化に伴い、「簡単に使える」Win32のモーダルダイアログ的な物を狙ったのかもしれません。しかし、これはこれでアプリ画面の真ん中に固定で表示されるだけでした。帯にも襷にも短すぎた感じです。

アプリ情報をContent Dialog で表示している様子
表示位置はアプリ表示領域の中心固定です。
Win32 Appで良くある、入力用サブウィンドウやツールウィンドウをポンと自由な位置に出すというのが
実はUWP Appでは結構面倒なんですね。

このように、「一応」Desktop 上でWin32 App っぽく動く最初の一歩は踏み出したものの、Win32 Appで普通にやっていたようなMainWindow + ToolWindowものを気軽に書けるには至りませんでした。*4

こういうサブウィンドウをぽこぽこ出すスタイルが、
今…RS4までのUWP Appでは書くのが大変

Win10 RS4 - Multi Instance, Multi Window (2018)

前のセクションで上げたうちの前者、「単に複数起動したい」…電卓系を叶えるのがRS4 で導入された Multi Instance、と考えると理解しやすいです。Opt-In 形式になっており、MultiInstance を使う！とAppxManifest で宣言したアプリのみがMulti Instanceになります。
実際の対応作業や注意点等詳しい所は次の記事にまとめる予定ですが、Multi Instance 対応が期待されるUWP Appを考えると…以下のような使い方に向いているかなと思います。

• 電卓系、シンプルアプリ
• 他のWin32 Appから起動して使うもの … 起動＝新インスタンス生成、タスク終了でインスタンスも消える、でないとWin32ものと仲良くしづらい所があります。そしてこれはMultiViewで救える話でもありません。
• Sets … Sets で複数タブ表示を行いたい場合、Multi Instance 対応が必要です。

Win10 RS5 以降

今後どうしていくつもりなのか、2018年5月の開発者会議 Build2018でチラ見せがありました。上の例で挙げた後者、「メインウィンドウの脇にサブウィンドウを表示したい」系のMultiWindow AppをMulti View無しで簡単に記述できるようになるのだそうです。

こういう、サブウィンドウをメインウィンドウの外に出して
自由に配置可能なもの

MultiViewでは無くこういう形で簡単に書ける

ただ、Win32のDesktop Window Modelをそのまま再発明しても仕方ないので
WindowingEnvironment でDevice Familyでの差を吸収する
今だと、Hololens / Windows MRが特にWindowingとして
普通のDesktopとは異なる扱いが必要になりそうです。

それそれのDeviceにあった形のWindowing
"That new thing" … さて…

左が「2018年夏」予定のアイテム
予定は予定

予定通りなら、左の「2018 Summer」がおそらくRS5でしょう。ただしあくまでも予定です。Buildでの発表後にスケジュール変わった例はこれまでも多いです。


次の記事では、Multi Instance 対応 を実際の作業に即して書いてみます。



*1) 元がImmersive UI だった経緯もあり、WinRT APIでは「Window」という単語はあまり使われないです。
*2) このあたり、Multi Viewの解説とサンプルコードを以前Stack Overflow に載せた事があるので興味があればどうぞ。…今回の記事は、この2015年当時の回答を現状に即して書き直したような所があります。

Multiple instances of a Windows Universal App (Windows 10)
https://stackoverflow.com/questions/32807090/multiple-instances-of-a-windows-universal-app-windows-10/

*3) なおUWP Appとして扱われる事の多いEdge Browser ですが、アプリケーションとしての成り立ちは他のUWP Appとは全く異なっており、タブ毎に独立したプロセスが走っています。現在我々開発者が使う事の出来るUWP AppModelでこういうものを作る事はできません。出来るのは現在の所Microsoft だけです。また、Edge の仕組みをUWP App Genericに使えるように仕立て直したのが「Sets」と呼べるかもしれません。
*4) Win10の当初、2015年末まではWindows 10 Mobile がまだ…まだ生きていたため、そういう意味ではImmersive Deviceへの軸足を残していた…のかもしれないですね。その後2016年になるとWindows 10 Mobile への投資はパタリと途絶え、緩慢な死へと向かっていったのはご存知の通りです。

DDLG: Windows 10 Mobile について 
https://ddlgjp.blogspot.jp/2017/04/windows-10-mobile.html

WinGo-Maps の紹介

イランのお兄ちゃん達が作っているGoogle Map のUWP Client です。

https://www.microsoft.com/store/productId/9NMJ42V775GT
https://github.com/MahStudio/WinGo-Maps

Reddit の/r/Windows Apps で紹介されていたので知ったのですが、
https://www.reddit.com/r/windowsapps/comments/8b0hrz/wingo_maps_is_an_unofficial_google_map_open/
楽しげだったので日本語リソースの追加で協力しました。

日本語化した画面

与野が中心なのは、たまたま埼玉県の中心だからです

PC・HoloLens 等各Win10 Device Family で使えますが、主なターゲットはWindows 10 Mobile であるようです。
特にオフラインで使う場合、このアプリのマップDL機能がかなり便利と思われます。予め必要になりそうな領域を選択してマップの保存・またバックアップとリストアが可能です。イラン、中東はオフライン運用対応へのデマンドが多いのかも。

マップのダウンロード画面

一方、PC で使う場合はStreet View や3D表示が不可能、検索が微妙等、Webブラウザでの表示に比べると劣る部分が目立ってしまう所はあります。PCで普段使いするかと言われると…うーんそれは無いかな…という。
現時点ではまだ粗が多いのですが、実装の体力は備えている人達に見えるので…その内何とかしてしまうのではと思います。


※「このアプリをイランで購入するには」ですが、カードが使えない場合このページから購入手続きを行うと、開発者からプロモーションコード…ストアで特定のアプリ支払いに使えるクーポン、が届くという仕組みのようです。珍しい使い方。ストアの規約的にはびみょいかもしれない。

Twitter が採用したHosted Web Apps とは

2018年3月、Twitter社が Win10 IP RS4向けに新しいバージョンのTwitter Appをリリースしました。順次自動更新されているのですが、それが今までのUWP Appではなく、Hosted Web App だったことで少し話題になっています。

最初はRichard Hay さんのTwitterで知りました。その後記事にされています。

Official Twitter App for Windows 10 Finally Updated
https://www.windowsobserver.com/2018/03/23/official-twitter-app-for-windows-10-finally-updated/

どれどれ、とインストールしてアプリのフォルダを見ると…

既定だと、Program Files\WindowsApps 以下にインストールされます。

管理者権限付きのConsoleで探すのが楽です。

おお、まさにHosted Web Apps でした。

Hosted Web Apps って何？

HostされたWebアプリ
https://developer.microsoft.com/ja-jp/windows/bridges/hosted-web-apps

所謂UWP App …C#/VB/JS/C++ で動かすNative App とは根本的に世界が違います。

Hosted Web Appを構成する要素に、いわゆるソースコードとなるものは実はローカルには存在しません。AppxManifest.xml によるアプリの定義があるだけです。

AppxManifest の一部 

全部見たい人はAppをインストールするとアプリのフォルダに入ってます。

ここに書いてある mobile.twitter.com をそのまま表示する 100%Webブラウザの窓、というのが正しいです。Twitter のAppをインストールするとわかりますが、表示されるのは100%、mobile.twitter.com そのままです。これに何かUIをXAMLで追加する、ローカルのコードビハインドで処理をする、等の世界では無いわけです。

「TwitterのHosted Web App」の画面。

mobile.twitter.comそのままです。

なお、ストアに乗せるにはマイクロソフトのテストを通す必要があり、他のUWP Appとまったく同様に掲載されます。特に何か差がつけられるという事はありません。

それって…ただのブックマークでは？

いや、それは明らかに違います。上のAppxManifestで定義したサイト内のHTMLから、ローカルのWinRT APIを直で使うことが可能だからです。

今回のTwitter Appでは、この機能を使ってRTやいいねがされた場合に通知トーストを送信しています。

（Chrome等ブラウザでも許可すれば似たような事出来るじゃん、というのはありますが）

「普通のWeb」ではもちろん、ローカルのAPIを叩くなど絶対許されないのですが、Hosted Web Appでは良いよ！という事になっています。
「普通のWeb」とは異なり、

• ストアに出す時点で製作者の身元が明らかになっている
• Microsoft によるコンプライアンス　テストが行われる（※１）
• ユーザーがインストールする時点で同意している

等々…でOK…なのかしら。
ただ、※１には抜け穴があります。後述します。

ソースは全部Webの上

上で説明したように、ローカルにインストールされるのは定義ファイルと、タイルのアイコンに使うビットマップくらいです。他…WebViewで表示されるHTML、その中で使うリソース…画像、CSS、その他色々、そしてJavaScript、全てWeb上のものがそのままロードされ、使われます。 「Hosted Web App」、Webでホストされたアプリという…MS先生にしては珍しく、名が正しく体を表しているネーミングです。 なおキャッシュなどの仕組みは特にないため、ネットから切れていると動きません。こちらについてはProgressive Web Apps のService Worker で使えるようになる…はず。

UWP App に対するアドバンテージ

UWP App の場合、ストアに乗せているアプリを変更する際は、原則、マイクロソフトの人力、人の目によるコンプライアンス チェックが行われます。変更の多少にかかわらずチェックはアプリ全ての部分で行われ、人力の場合２、３日かかります。このタイムラグがUWP App 稼業の大変つらいところです。そしてたまに意味の分からないいちゃもんをつけられたり。消耗すること甚だしいです。

（原則、というのは、場合によっては自動化テストのみ、数十分で通過する場合があるからです。アプリによります。ちなみにF10は毎回100%人力テストです。なんで…）



ですが、Hosted Web Appsの場合、上で説明したようにソースは全てWebであり、MSのストアに載っている訳ではありません。
つまり、アプリの改変がマイクロソフトのチェックを通さずにやりたい放題という事になっています。これは別に開発者が見つけた抜け穴ではなく、MS自身がアドバンテージとしてアピールしています。それでいいの？という気はちょっとしますが…
それと、さすがにあまり無茶するとお取りつぶしなどは当然あると思います。教育アプリがある日突然ふたばのJun君を表示するとかそういう。

Progressive Web Apps とは違うの？

基本的にはネーミングの話かなと思います。Hosted Web Apps の進化系がProgressive Web Apps (以下PWA）と言うのが正しいはずですが、ただ他のメディアの紹介を見ているとTwitterはPWA だ！という所もありました。どちらもそれはそれで正しい気がします。

また、PWA 自体、別にMSの持ち物という訳ではなく…AndroidにはAndroid のPWA があります。おそらく、これに大体そろえる感じで各機能入れるんだろうなと思います。Service Workerが入り、オフラインで使用可能なもっと「ちゃんとした」アプリになる…のだと思います。 ちなみに、WindowsでのPWA の情報自体まだ出きっていないのが実情です。おそらくは2018年5月のBuild 2018 でお披露目・・かな？と思います。今のところは以下、2018年2月のBlogの情報が詳しいです。


Welcoming Progressive Web Apps to Microsoft Edge and Windows 10
https://blogs.windows.com/msedgedev/2018/02/06/welcoming-progressive-web-apps-edge-windows-10/

私はいいと思う

Progressive Web Apps 、前身のHosted Web Appsも含めてなんつうかこう…Windows 開発者の間ではあんまり人気が無い、気がします。理由はなんとなくわかります。ただWeb表示してるだけじゃん？アプリじゃねえじゃん、という。ある程度正しいと思います。

また、Win10 のUWP、Win8.1のStore App でもそうでしたが…ストアを埋め尽くす低品質アプリの代表格が、アプリのメインウィンドウにWebViewを張り付けてWebのコンテンツを表示するだけの「アプリ」でした。こういう嫌な経験も影響しているのだろうと思います。私も何度DLして起動して脱力したことか…あ、WebViewアプリ様だ……


ただ、だがしかし。私はPWA、いいと思っています。
「アプリ」の主戦場がローカルからWebに移行して随分経ちました。個人的にも、GMail、Google Maps, あすけん（カロリーチェックのWebです）, Slack, Twitter, OneDrive, Office Web Apps, ふたば, etc, etc... 一日を過ごすPC体験の殆どはWebです。そのうち一部…ふたばはF10を使っていますが、あれもWebのコンテンツを再解釈してXAMLで表示しているアプリであり、本質的にはWebアプリのVariationと思っています。
このようにWeb側の表現力、機能が十分に進化している場合、それをAPIを使って再解釈して「ローカルアプリ」として仕立てるのって…本当に要るのかな？という疑問は常にあるわけです。

もちろん、今回のHosted Web Apps のTwitterを見ればわかるように、今のレベルではローカルアプリと同じとは言いづらいです。ですが、今後のPWA、そしてまた進化していくであろう次のバージョンを考えると…「PWAでいいよね」となるエリアは今後拡大していくんだろうな、と思います。

※追記 2018/04/02 ... 常用に挑戦してみたけど…結構キツいですねこれ。まずリロードのやり方が良く分からないょぅ…通知等他のタブに一旦切り替えて戻るしか無くない？　Twitter PWA, 思った以上に将来性の塊（マイルド表現）でした。これRS4向けに本当に一般公開するんだろうか…

App を Windows Timeline に対応させる 2/2

UWP App のTimeline 対応、実践編です。拙作のApp F10 image bbs browser で行った作業に即して説明してみます。

この記事は
App を Windows Timeline に対応させる 1/2
の続きです。

Windows Timeline 表示例

前準備

Fall Creators Update レベルのAPIを使うため、App のプロジェクト プロパティ→アプリケーションでMinVersionを 10.0.16299 にします。

必須では無いですが、このNuGetパッケージも追加します。後述するAdaptive Cards のJson 生成はこれが無いとやってられないです。

AdaptiveCards - NuGet Gallery

https://www.nuget.org/packages/AdaptiveCards/

※注意！！！ (Added 7 March 2018)
NuGet には上のものとは別に、"Microsoft.AdaptiveCards" が存在します。こちらは既に更新が終了しており、もう使われていません。ただ困ったことにGoogleで"NuGet AdaptiveCards" で検索するとこちらが表示されてしまうようです。気を付けてくださいね。

Microsoft.AdaptiveCards (Deprecated)
https://www.nuget.org/packages/Microsoft.AdaptiveCards/


UserActivity を生成するClassには以下二つのusingを追加します。

using Windows.ApplicationModel.UserActivities;
using AdaptiveCards;

User Activity の作成とOS への登録

前の記事でも触れましたが、App 上の作業の節目…ドキュメントを開いた時など…のタイミングでUserActivity を生成し、OSに登録します。OS はTimeline 上にこのUserActivity をタイルとして表示します。

UserActivity の作成と登録

基本、これだけでUserActivityの登録が可能です。ただこの例では Adaptive Cards を使っていないため、Timeline 上の表示は以下のように大変シンプルなものになります。実際には殆どの場合、これから説明するAdaptive Cards を使ってタイルの中身を組み立てていくことになるでしょう。

Adaptive Cards を使わない表示例

Adaptive Cards

詳しい説明は省きますが、Microsoft が考える通知カードの標準形といったところです。カードの中身…データのJSONスキームと、コンテナ…カードを表示するデバイスの能力を記述するスキームが分離してあるのが特徴でしょうか。
Microsoft のAdaptive Cards 紹介ページを見て頂くと感じが判るかと思います。

Weather Compact - AdaptiveCards Sample

画面の右ペインにコンボボックスがあり、ここから表示するコンテナを選択できます。共通のJSONデータに対して、各デバイス…Windows の通知トースト、タイル、Teams, FacebookにKik、そしておそらくは他プラットフォーム…で「大体」意味が伝わるように表示しますよ、という。

その各デバイスの中にWindows Timeline も並んでいます。触っていると、表現力は他のデバイスと比べてそれほど高くはないようです。また、入力系のようにそもそもTimeline の使用方法にそぐわないものもあります。

さて、F10 ではこのようなJSONを渡しています。以下のような背景画像付きのTileになります。

Adaptive Cards を使った例

このJSON文字列、素から文字列を足し合わせて気合で作っても良いのですが…上品に行うために 、「前準備」で触れた AdaptiveCards NuGet パッケージがあります。このパッケージ、別にUWP App用というわけでも無いので…Xamarin、その他 Desktop App等でも、.NET 環境でAdaptive Cards を作る場合は全部これでいけるはずです。

これで、この一つ上で貼ったJSON文字列が生成されます。

Protocol Activation によるAppの起動・アクティベーション対応

ここは特にTimeline ユニークな話でもないので省略しますが、このような作業になります。

• Package.AppxManifest で自アプリのプロトコル名を登録する
• Appx.Xaml.cs にOnActivate を追加し、args.Kind == ActivationKind.Protocol だったらばパラメータを拾ってページを作る・または渡す

URI のアクティブ化の処理

注意など

• たまに、Timeline 上の表示が正しく行われない場合があります。特にこちらでAppのUserActivity 生成コードを弄った場合等に多いようです。この場合、一旦ログオフ→ログオンで元に戻る場合が多いです。
• 良くあるのは、作成したAdaptive Cards JSON文字列が不正で登録に失敗する場合です。この場合 userActivity.SaveAsync() で黙って落ち、特に例外が発生しないため大変分かりにくいです。 はまりがち。
• 上でも触れましたが、Timeline 上のAdaptive Card ではあまり凝った表現は出来ないようです。先にAdaptiveCards.io のテストサイトで表現が実現可能かどうか確認すると良いでしょう。
• Windows Timeline 上の画面からインクリメンタルサーチが可能ですが、ここで検索対象となるのはuserActivity.VisualElements.DisplayText と、Applicationの名前です。Adaptive Cards の中身は使われないようです。逆にAdaptive Cards を使用する場合 DisplayText は表示されませんので、ここに検索で拾ってほしいキーワードを追加しておくと良いです。

App を Windows Timeline に対応させる 1/2

まとめ

• Windows Timeline は対応が簡単な割に得られる物が大きい
• ただ、アプリにより向き不向きがある

Windows Timeline、最近のWindows 10 Insider Preview で使えるようになりました。UWP App をこのWindows Timelineに対応させる開発者向けガイドも出ています。今回自分のApp を対応させる機会があり、作業量が少ない割には効果が大きかったので紹介しようという趣旨の記事です。

※この記事には続きがあります。
App を Windows Timeline に対応させる 2/2

Windows Timeline とは

Windows 10 の次期大規模更新（RS4？）に入ると言われている新機能です。2018年1月時点では Insider Preview Build 17063 で使うことが可能です。アプリではWebブラウザ Edge、フォト等が対応しています。宣伝になりますが、拙作の画像掲示板ブラウザ F10 も対応しています。

F10 Image bbs browser
https://www.microsoft.com/store/apps/9nblggh1ntrd

なお、API 自体はWindows 10 Fall Creators Update （FCU） から入っており、SDKもFCUレベルの16299から既に対応しています。このため、現時点でもWindows Timeline 対応アプリをビルドし、ストアに上げることが可能になっています。

Windows Timeline
タスクバー左から3番目のアイコン、またはWin+Tabで表示されます

※以降、仕組みについては推測込みです。ウソが混じっているかもしれません。またIP 17063 の動作を元に書いているため、今後変わるかもしれません。

対応に必要な作業と得られる効果

仕組み・方法を説明する前に、得られる効果を書きましょう。Timeline に対応するためにアプリ側でやる事は主に二つで、

• 適切なタイミングでUserActivityをOSに投げる
• Protocol Activation …Uriを使った起動・アクティベーションに対応する

前者はかなり楽に済みます。後者は…アプリに依るのですが、いわゆるブラウザ系、URLのように文字列一本でアプリの状態を記述できる場合は楽に対応できるのではと思います。ここは後でまた触れます。

これらを行うだけで、アプリの操作履歴の同期がデバイス間で、OS組み込みの洗練されたUIで可能になります。PC＋ノート＋タブレット…PC複数持ちが当たり前の昨今、簡単に作業状態をデバイス間で引き継げるのは使ってみると大変に便利です。

この操作履歴の同期、Timeline無しで自分でやるのは結構手間でして…

• Roaming Folder を使ってデバイス間で同期する…Appの履歴DBから一部をRoamingFolderに書き出し、変更を検知してDBに取り込む等
• Project Romeを使う…リモートデバイスを列挙し履歴データを送受信する仕掛けをRemote AppServiceで作る

等を行う事になります。どちらもある程度安定動作させるにはそこそこ工数がかかります。拙作のブラウザ F10ではこの両方を実装してあるのですが、それに比べると今回のUserActivity を使ったWindows Timeline への対応は圧倒的に簡単、そしてユーザビリティは優れています。お得過ぎる。

右上の検索ボックスからインクリメンタルサーチが出来ます。便利。
検索対象になるのはVisualElements.Title と Appの名前で、AdaptiveCardの中は見てくれないようです。
この例ではVisualElements.Titleにスレ名＋板名＋BBS名をまとめて登録していますが、表示しているのはAdaptiveCard になっています。

同じMicrosoft Account を使うデバイスにFall Creators Update のシステムが居る場合、
UserActivityはこのようにActionCenter上に表示されます。
クリックするとTimeline同様にAppが起動します。
FCUから登録したUserActivityは、他の17063 システムのTimeline上に表示されます。

他のデバイスで登録されたUserActivityは、右上にそのデバイス名が表示されます。

Windows Timeline の仕組み

アプリケーションはOSに対し、自分の状態を「UserActivity」という単位で投げます。
OSはそのアプリ毎の「UserActivity」を時系列に並べて表示します。それが「Windows Timeline」です。

ユーザーがWindows Timeline 上のタイルをクリックすると、OS はUserActivity内のプロパティ ActivateUri をパラメータにしてアプリを起動又はアクティベートします。

UserActivityを「どのタイミングで」OSに投げるかはアプリ設計者に任されています。Webブラウザなら新しいタブを開いた、Officeならドキュメントを開いた、という操作の節目でUserActivityを発行するものが多いようです。

OSは、この投げられたUserActivity を一台のローカルマシンだけではなく同じMicrosoft Account でログインしている複数のシステムで共有します。この同期、Project Rome と呼ばれる Microsoft Graph ベースの仕組みを使っているようです。このため、Microsoft Graph に対してRESTで直接叩く事により、プラットフォーム非依存で使う事が可能…というように見えます（ただ、Timeline の「表示」自体は別にアプリが必要でしょう。Android ならば Microsoft Launcher あたりが適任っぽいですが。また、Rome系のAPIはGraph上だとBeta扱いのが多いので使っていいのか少し微妙）。

UserActivity 

UserActivity、色々プロパティはついているのですが、まずは一発表示してみたい時に必須なのは以下二つです。

• UserActivity.ActivationUri … Appをアクティベートするときに使うUri
• UserActivity.VisualElements.Title　名前　表示・検索に使われます（後述のAdaptiveCardを使う場合表示はそちらになる）

ActivationUri は一番大事なもので、ユーザーがTimeline 上のタイルをクリックするとOSはこれを使ってAppを起動します。

UWP Appでは、App 毎に独自のActivation Protocol をOSに登録することが出来ます。
例えばF10 が入っている環境ですと、Win+Rの名前をつけて実行、で

ddlgf10://a.4cdn.org/a/thread/166549698.json&view=post

とするとF10が起動し、そのスレが開きます。
これは、

1. OSは ddlgf10:// をプロトコルとして認識し、（AppxManifestで指定する）
2. パラメータをF10に渡し、
3. F10 はOnActivate でそれを受け取り処理する（というコードを自分で書く）

という仕組みになっています。Windows Timeline はこのActivationUriを含むオブジェクトUserActivity を折々のタイミングでOSが記憶し、リストとして表示するという仕掛けになります。

Timeline への向き・不向き

上で説明したように、このTimeline の核は

• アプリの状態…アプリが使うリソースも含めて…が、一行のUri で示される

事にあります。これが出来ないアプリの場合、あまり役に立てる事ができないです。

例を挙げると、

・F10 の場合… これはブラウザアプリです。Web上の画像掲示板のスレッドを取得し、XAMLでレンダリングします。
このため、アプリの状態は「表示するスレのURL」＋「F10上の表示形式オプション」で完全に記述することが可能です。
そしてこれは、システムユニークでは無く…どのシステムでも共通に（ネットに繋がれば）使用可能です。リソースはネット上のスレだからです。

・画像ブラウザの場合
例えばピクチャライブラリ上の画像 hoge.jpg を表示する場合を考えます。これをURLとして持ち、UserActivityとして登録する事は可能でしょう。ただ、このリソースはローカル…このデバイス上でのみ参照可能であるため、他のデバイス上でUserActivity をWindows Timeline に表示する意味がありません。
こういう場合、Timeline 上に表示するActivity としては不適切かもしれません。
逆にリソースがクラウド上にある場合…例えば画像がOneDrive上にある場合はTimelineで扱うにはピッタリでしょう。
他にもブックリーダー等、OneDriveとTimelineとの食い合わせはかなり良いです。OneDrive上の本のUri＋リーダーでの読書位置、を合わせた物をUriとしてUserActivityに入れれば、かなり良い感じになりそうです。

・ゲーム
ゲームの場合、状態をマシンAからBにポンと渡して引き続き遊べるのは魅力かもしれません。ただ、状態の区切りをどこに置くかという問題と、状態をUriとして一本にシリアライズできるのかという。Uri が長さどれくらいまで行けるのかはわかりませんが、あまり無理はしない方がいい気はします。

次の記事では、F10 を Windows Timeline 対応させた実作業の様子をコード例を挙げて書いてみます。

App を Windows Timeline に対応させる 2/2

Microsoft Docs を寄ってたかって直す

UWP App を開発していると、UWP やWinRT API のドキュメントをMicrosoft のWebから検索し調べるのは必須の作業になります。そのドキュメントが腐っていてつい舌打ちしてしまう事は無いでしょうか？ﾁｯ……僕は良くあります。

しかし今では、名も知らぬ誰かを呪う前に有効な選択肢があります。GitHub でPull Requestを送り、自分でドキュメントを修正する事が可能になってきています。
最近この修正を行う機会があり、案外ラクにできたので…その手順を簡単に説明する事で、Microsoft Docs を直す人が増えるとｲｲﾅｰという趣旨の記事です。

はじめに

Microsoft Docs へのContribution についてのドキュメントは
https://docs.microsoft.com/ja-jp/contribute/
に完備されています。判らない事は全部こちらに載っているはずです。ただ完全過ぎて全部読むのも大変なので、適度に端折っているのが今回の記事になります。

• 最初に、GitHub のアカウントが必要です。
• やり取りは英語になります。

※この記事、以降GitHub に慣れている人には今更な話が多いです。

Microsoft Docs の文書を表示する

この1年程で、これまでMSDN Documents として整備されていた文書の大部分は新サイト Microsoft Docs に移行しています。

Microsoft Docs トップページ

コンテンツ自体はMarkdown（のGitHub拡張）で記述されており、GitHubで管理されています。そして、一部の文書についてはユーザーがPull Request（以降PR、変更要求）を送ることが可能になっています。

そういった文書は、画面の右カラムに「Edit」ボタンがついています。文書によっては右カラムでは無く、真ん中のコンテンツエリアのセクション毎に「Edit」ボタンがついている物もあります。

このEdit ボタンをクリックすると、GitHub上の当該コンテンツのページに飛びます（ボタンの名前に反して、この時点では表示だけで編集は始まりません。気軽にポチっていいです）。このボタンが表示されていない場合、現在の所その文書にPRを送ることはできません。後で触れます。

Edit ボタンが右カラムに表示されている例
ちなみにウィンドウをもう少し狭くすると左上に移動します
Acrylic material

セクション毎にEdit ボタンが表示される例
Windows.ApplicationModel.Core.CoreApplication

GitHub 上での作業

ソースの表示

Microsoft Docs 上の文書に対応する、GitHub 上のソースが表示されます。

GitHub 上の Acrylic ソース

編集

編集を始めるには、右上の鉛筆アイコンをクリックします。
GitHubのMarkdown エディタが表示され、編集が可能になります。
画面上部に説明が出ているように、この編集作業は作業者（あなた）のリポジトリの中に作成されるブランチ（この画像の例ではMicrosoft/windows-uwp）に対して行われます。
プレビューで確認しつつポチポチ書きましょう。

Markdown エディタ
タブ切り替えでプレビューを表示できます

編集が終わったら画面の一番下までスクロールします。
Propose file change のフォームに変更のタイトルと説明を書きます。ボタンをクリックすると、Create Pull Request の画面に飛びます。

ファイル変更の提案
簡潔なタイトルと内容の説明を書きます

Pull Request の作成

先ほど行った編集前・後の比較が表示されます。諸々確認の上で覚悟が出来たらCreate Pull Request ボタンを押して作成です。
このタイミングで、

• 自動的に自分のリポジトリ内にブランチが作成（フォーク）され、
• そこで編集が反映され、
• その差分がPull RequestとしてMicrosoft側に送信

と物事が一気に進みます。今迄は基本自分の中だけでの作業でしたが、ここでポチっとした以降は担当者に通知が飛び、他の人との共同作業になります。

なお、簡単な編集・修正では、基本的にはこのリポジトリ上での自動フォークを使ってほしいようです。普通にローカルにブランチ作って編集してSyncして…というのはまだあんまりのようです。

Pull Request作成画面

Pull Request の処理

以降は、処理が進む様子をPull Request のページで確認します。

基本的には、

• 共通のレビュー担当者がPRの書式等をざっくり確認し、
• 次にそのドキュメントの担当が中身を確認し、
• OKならマージされて完了！

という流れです。大体数日から１週間～１０日くらいで終わる感じです。また、マージされてから実際のMicrosoft Docs のWeb側に反映されるにはさらに数時間掛かります。

PRの処理フロー
これは以前に私が上げた、Acrylicのページのカラーブラシの名前間違ってるから直したよというPRです

編集できる文書・できない文書

上でも触れましたが、Edit ボタンが表示されていない文書にPR を送ることはできません。
2017年11月現在では、UWP App、WinRT APIについてはen-us 、英語ページはほぼ全てEdit ボタンがあり、PRを送ることができます。しかし日本語ページは全て未対応です。

これは文書のジャンルによって状況が違います。例えば .NET や Outlook では、日本語に対する修正も可能になっています。


Outlook では日本語直してキャンペーン中だそうです。
https://www.facebook.com/MVPAwardProgram.JP/posts/1476999755669677

日本語のちゃんとした説明もあります。人力翻訳には温かみがある…
https://github.com/OfficeDev/outlook-dev-docs.ja-jp/blob/live/CONTRIBUTING.md


なお、編集できる・できないについて特にまとまったディレクトリ等があるわけでは無く、その文書にEdit ボタンがあるかどうかで判断して下さい、という事のようです。

Fall CU - スプラッシュスクリーンをすっとばして起動速度を上げる

意識低めのFall Creators Update ガイド二つ目です。
FCUから、スプラッシュスクリーンの表示設定にAttirbute「optional」が追加になりました。

Windows Platform Uservoice の意見が採用された（貴重な）例でもあります。

Splash screen for UWP apps should be optional
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/9333255-splash-screen-for-uwp-apps-should-be-optional

使い方はとても簡単で、Package.appxmanifest のスプラッシュスクリーン定義でOptional="true"とするだけです。
参考のために、Package.appxmanifest の例を下に示します。24行目がそれです。

丁寧に言うと、

1. AppのMinVersion を 16299(FCU)以降に設定する
2. Package.appxmanifest のPackage Element にネームスペース xmlns:uap5="http://schemas.microsoft.com/appx/manifest/uap/windows10/5"　を追加する
3. エレメント uap:SplashScreen に 属性 Optional="true" を追加する

です。

Optional="true" の効果

注意したいのは、これは「スプラッシュスクリーンをOFFにする」機能では無いことです。スプラッシュスクリーンを「Optional に」するよ！という機能です。
どういうことかというと…
アプリケーションの初期化が終わった時点でスプラッシュスクリーンが即閉じる、という動作になります（なのでスプラッシュスクリーンは「オプショナルな」動作だという事なのでしょう）。
このため、optional="true"であっても…アプリの初期化自体がモタモタしていると結局スプラッシュスクリーンはたっぷり表示されてしまいます。

「初期化」とはどのフェーズを言うのか…経験的には、「このスプラッシュスクリーンの扱いに関しては」App.xaml.csのアプリケーションクラスを抜けてページ表示に行った所で終わり、という感じに見えます（仕様で出ているかもしれませんが調べきれていないです、すみません）。一旦ページ表示まで行くと、例えばPage の OnNavigatedTo で幾ら時間がかかったところで今回のスプラッシュスクリーン表示には影響しません。

実例を動画で示します。

このアプリはVisual Studio 2017 のUWP Blankテンプレートほぼそのままです。
左から

1. UWP App 既定（optional=false)
2. optional=true
3. optional=true, ただしApp.xaml.cs のOnLaunchedでディレイ1秒追加

です。
1) 一番左は、おそらくWindows 標準の電卓と同じ動作に見えます。Blank テンプレートそのままで初期化に時間大してかかっていないので、この状態でもスプラッシュスクリーン表示は一瞬で終わります。
2) は今回のoptional=true の場合です。即App画面に行っているのが分かります。
3) はtrueだけどウェイト1秒入っている場合です。この場合スプラッシュスクリーンはきっちりその分表示され続けるため、optional=trueの意味が全く無いという悲しい結果になっています。


※ 動画は TechSmith Camtasia で作っています。Microsoft MVP 特典として使わせてもらっています。こういった説明、チュートリアル用のスクリーンキャプチャからの動画作成には超便利です。ｱﾘｶﾞﾄｳ(*´▽｀*)

Fall CU - コマンドライン・Win+R からのUWP App 起動

Windows 10 Fall Creators Update （以下FCU）から、UWP App 側に少し変更を入れることでコンソールからUWP App の起動が可能になりました。
Package.appxmanifest で定義するエイリアス名での起動、またパラメータ・カレントディレクトリのパスの取得ができます。

コンソールから起動と言われても…そんなに使わないんじゃん？僕らヤングはGUI世代じゃん？と思われるかもですが、実は「ファイル名を指定して実行」でも使う事が可能です。
Win+R、で名前入れればApp一発起動！というのは割と魅力と思うのですがどうでしょう？
あそこは履歴も残るので個人的にはスタートメニュー本体より使用頻度が高いです。

みんな大好きWin+R
ちなみにdevmgmt.mscはデバイスマネージャ、
appwiz.cplはアプリケーションの追加と削除

使い方

ここでは、 Visual Studio 2017 でUWP App をBlank テンプレートから作り始めた想定でコンソールからの起動を追加してみます。

1 プロジェクトのMinVersion を16299以上に設定する

 今回の機能はFall CU以降のみで使える機能です。MinVersionをFCU, 16299 に設定する必要があります。

2 Package.appxmanifest でアプリケーションのエイリアス名・エントリポイントを設定する

※今回の内容はVisual Studio のマニフェスト デザイナからは設定できません。ソリューション エクスプローラー上で Pacakge.appxmanifest を右クリック → 「コードを表示」 からXML を直で編集します。

Package.appxmanifest を全部貼りました。一部切り出されてもエレメントの関係が分かりづらいので。
まず、一番上のPacakge エレメントにネームスペースuap5 を追加します。 xmlns:uap5="http://schemas.microsoft.com/appx/manifest/uap/windows10/5" です。
次、下の方のApplication エレメント を探します。この子要素にExtensions を追加し、その中に今回のuap5:Extension Category="windows.appExecutionAlias" を追加します。26～37行です。

• Executable は、このアプリの実行ファイル名…普通はプロジェクトのアセンブリ名です。
• EntryPoint は、このアプリのアプリケーションクラス名です。テンプレそのままだと大体「アプリ名.app」ですね。
• uap5:AppExecutionAlias Alias は エイリアス名です。ここで「App1.exe」とすると、Win+Rやコンソールでは「App1」で起動します。また、このエイリアス名はuap:AppExecutionAlias の中で複数指定できます。

3 App.xaml.cs にコマンドライン起動の受けを追加

ここまでで、「起動」はするようになります。ただ、スプラッシュスクリーンで止まってしまいます。
これは、まだコンソール起動時のハンドラを書いていないためです。



App.xaml.cs に、この OnActivated を追加します。
UWP App ではApp起動時 OnLaunched にまず飛んでくるのはご存知と思います。ただこれは「通常起動」…スタートメニューからポチっと起動した場合の話です。

そうでは無い各種起動はOnActivated で扱います。今回のCommandlineやCortanaのVoiceCommandのような別口…裏口？起動は全部こちらに書きます。

上のコードにあるように、

• Arguments ... 起動時に渡されたパラメータ文字列
• CurrentDirectoryPath ... 起動時のカレントディレクトリ（後述）
• ExitCode ... 呼び側に渡す終了コード

等を使用・設定できます。
Arguments は、そのとおりパラメータなのですが…一つ注意として、おしりに必ずスペースが一つ入ります。"abc" と渡すと、Argumentsに入ってくるのは"abc "です。
ExitCode は呼び側に即返ります。以下のスクリーンキャプチャは、上のExitCodeのコメントを外した上で.cmd から起動し、ErrorLevelを表示している例です。

最後に、渡されたパラメータを表示するためにMain.Xaml と Main.xaml.cs をちょっと弄りましょう。


これで完成です(*´▽｀*)！
コマンドラインやWin+Rから起動してみてください。
また、すでに起動している所にもう一度実行しても表示が更新されるはずです。OnActivated は起動・アクティベートどちらでも通り、どちらもOnNavigatedToを通すのでこうなっています。

古の%ErrorLevel%とかそういう世界

「カレントディレクトリ」？

少し気を付けたいのは、取得できる「カレントディレクトリ」のパス名です。
例えばコンソールでc:\hogehoge に居る場合にアプリを起動すると「c:\hogehoge」が返ります。
じゃあそのディレクトリ内のファイルをFindFirstで列挙して云々、とついやりたくなるのが人情ですが…
UWP App の場合、それは基本出来ません。

UWP App の場合、Appがアクセスできるのは

• App固有のフォルダ
• ユーザーがFolderPickerで指定したフォルダ
• その他Manifestで指定された特定のフォルダ

のみである！という鉄の掟があります。App Container のサンドボックスですね。
このため、文字列でフォルダの名前を渡されてもあんまり使いどころがありません。
他のWin32 Appにパススルーで渡すとかその程度でしょうか。

F10 今後の Windows 10 Mobile への対応について

（2017年11月追記…後で気づいたのですが、16299向けのビルドはそもそも15xxxで止まっているWin10Mには入りませんでした。結果は変わりませんが、実は選択肢があるわけでも無かったという話でした。）

F10 v1.5.x (Fall Creators Update 向け） から、Windows 10 Mobile への展開を終了する事にしました。
今後は以下のようになります。

F10 のバージョン	Win10 のバージョン	展開対象の Win10 デバイスファミリ *1	更新する？
1.5 (11月頃リリース予定)	Fall Creators Update (Fall CU)or later	PC, Xbox	更新
1.4 *2	Creators Update (CU)	PC, Mobile, Xbox	更新
1.3	Anniversary Update (AU)	PC, Mobile, Xbox	更新停止
1.2	November Update	PC, Mobile	更新停止
1.1	(Win10 GM)	PC, Mobile	更新停止

*1) その他HoloLens, Surface Hub等でも動きますが省略
*2) 1.5がストアに載るまでは 1.4が Fall CUでも使われます


F10では、おおよそ「現行＋ひとつ前」の二バージョンを維持する形で更新しています。これまでの経験上、Win10 の新しいバージョンが出た時点で「そのひとつ前」の使用率が9割を超えていることが判っているためです。例えば今回の場合、使用率はCUが既に9割を超えています。残りがFall CU、次がAUで数%です。

この二つの内、新しいほうのv1.5, Fall CU向けF10からWin10 Mobile への展開を外します。
理由は大きく分けて二つあります。

1. Win10 Mobile の Fall CU は、F10がアプリとして対応する意味があまり無い

CU の頃から顕著になっているのですが、Win10 Mobile に対しては OS Core の更新は行われるものの、機能・UI等ユーザーの目に触れる部分での新機能は展開されない・されても実質あまり意味が無いことが多くなっています*3。このため、アプリ側でも改めて「対応」する意味が薄くなっています。

「対応する意味が無い」とはどういう事なのか、F10 での例で説明します。今回のFall CU に対して F10 に入れる予定の変更は主に以下二つです。

1. Fluent Design 対応
2. App Model の更新 - Commandline Support, その他

Fluent Design 自体はWin10 Mobile でも使う事ができます。
しかし、Mobile がタッチ操作であるのに対し、Fluent Designの要素であるReveal Effect はマウス操作が前提として作られているため、Mobileでは使いようがありません。また、Acrylic Effect、半透明のアクリル板のような効果も、アプリの裏に背景画像の無いMobile では効果がありません（アプリ内で透かすことは出来るにしても）。
コマンドライン もMobileでは用がありません。

つまり、「 Fall CU向けF10」をWin10 Mobile で動かしたとしても、その機能・操作感は現行の「CU向けF10」とほぼそのまま変わらないという事になります。そして今後Win10 Mobile 自体に大きな更新が望めない以上、この傾向は変わらないでしょう。

これらの事から、Win10 Mobile に対しては既に存在する「CU向けF10」で充分であると考えています。

*3) Coreの部分では.NET Standard 2.0対応等大規模な更新がMobileでも行われています。ただF10では特に使う予定が無いです。

2. 自分でWin10 Mobile 機を使っていない事による弊害

そうは言っても、現在のコードベースでもリリースすればWin10 Mobileでおそらく動くことは動くはずです。UWP ですから。今迄通りWin10 Mobile 向けにリリースを続けるという選択肢もあります。

ただ個人的には既にWin10 Mobile 機の普段使いを止めているので…テストは以前に比べどうしても甘くなっています。動かないものをうっかりMobile向けにお出ししてしまう可能性は急激に上がっています。
現在の「動作実績のある」CU向けF10 を使っていただいた方が安全です。

UWP App 開発で頼りになるコミュニティ・サービス一覧

UWP App 等、Microsoft のプラットフォーム上で開発する上で助かる・頼りになるのが各種オンライン フォーラム・コミュニティです。
ただ、Microsoft はご存知の通り太陽系で最大のソフト屋さんですので…こういうフォーラム・窓口もやたら多いですし、目的・使い方もまた色々です。

そこで、私が出入りしている所を中心に「役割別に」整理してみようというのがこの記事です。基本MSのものですが、一部MSとは関係の無い運営主体も含んでいます。

• 質問…こういうコード書いたけど動かないです助けて、と的を絞った質問
• 相談…こういう機能を実現するにはどうしたもんだろう、どんなライブラリがいいだろう的なふんわりした相談
• 報告…こんな問題があります、これが動いていません、と責任者（MS）に伝える
• 提案…こんな機能、APIが欲しいです、と伝える

StackOverflow	質問
MSDN Forum	質問・相談
Reddit WPDev	質問・相談
Windows Platform Uservoice	提案
Developers Community VisualStudio	報告
フィードバック Hub	提案（一般）・報告（開発）

※なお、今回の記事は基本的にUWP App 開発 を行う上での対象である

• UWP(WinRT) API
• OS
• Visual Studio

に主眼を置いています。その他の分野…Xamarin, Desktop App, Azure, Office, また一般向けサイト(Microsoft Answers) 等は考慮に入れていません。

また今回のカテゴリ分けは基本私が今迄見てきたベースで勝手にやっているので、運営者の意図とは異なる部分もあるかと思います。ご了承下さい。

StackOverflow

https://stackoverflow.com/questions/tagged/uwp

運営	StackOverflow
対象	よろず　UWPの場合はタグ「UWP」が使われます
カテゴリ	質問
レポート形式	Markdown形式 コード貼り付け・画像添付可能　ファイル添付不可
通知	有り
言語	英語　日本語版のja.StackOverflow もあります（UWPの話題は少ないです）

• Responseはここが一番早いかもしれないです。
• MSの人が数名面倒見ているようでマメに回答しています。
• ふわっとした相談、挨拶、自己紹介、その他質問と関係のないものは基本歓迎されません。他のフォーラムでも基本同じですが、SOの場合はHi, Hello, best regardsだの書くと自動的にその部分だけ削除されるという徹底ぶりです。
• どんなライブラリがお勧め？とかも実はSOでは御法度なのでDownvote不可避です。
• 聞きたいことを絞って、具体的なソースを貼って聞くのがコツです。
• UWPの質問に、WPFやWinForm時代の知識で答えちゃう人がわりといるのが残念。

MSDN forum

英語
https://social.msdn.microsoft.com/Forums/windowsapps/en-US/home?forum=wpdevelop
日本語
https://social.msdn.microsoft.com/Forums/ja-JP/home?forum=winstoreapp

運営	Microsoft
対象	Microsoft 製品・サービス一般
カテゴリ	質問・相談
レポート形式	リッチテキスト コード貼り付け・画像添付可能　ファイル添付不可コードサンプルを上げたい場合はZipを自分のOneDriveに置いて公開設定にする人が多いようです
通知	有り 投稿時に「アラートを送信する」チェックボックスをオンにすると、投稿にコメントがつく・評価される等のタイミングでメールが来る
言語	英語・日本語別にフォーラムが設置されています

• Moderatorがおり、ジャンル違いの質問については適切なForumに移動されます。
• やりとりの過程でOSの不具合だねとなった場合は開発に回してくれる（こともある）又はFeedback Hubに送れと言われる（こともある）
• MS側・ユーザー側回答者共に層は厚いです。
• 放置気味のForumもあるので注意が必要です。返答０の質問が多数放置されている所は用心したほうがいいです。

Reddit - Windows Platform Development

https://www.reddit.com/r/WPDev/

運営	Reddit
対象	UWP App 開発の話題が中心
カテゴリ	質問・相談
レポート形式	Markdown形式  コード貼り付け可能　画像・ファイル添付不可
通知	有り
言語	英語のみ

• 単に仕様やAPI に詳しい人というよりは、実際にStore にApp 出している人が多い気がします。例えばStackOverflow だと、UWP Appの質問にWinFormやWPF時代の知識で答えてしまっている人をそこそこ見かけるのですが、Reddit WPDevではまずありません。そういう意味で専門性はSOより高い印象があります。
• 流量は比較的少なめ…週に数通程度ですが、Postがあると反応は早いです。
• SOでは聞きづらいライブラリ話等も許容されるので、実は貴重な場所かもしれません。
• 質問・相談以外にも、自分のBlogにこんな技術系Postを書いたよという通知記事もあります。面白い。

Windows Developer Feedback

https://wpdev.uservoice.com/

運営	Microsoft
対象	Edge, UWP, Dev Center, Windows Store
カテゴリ	提案
レポート形式	プレーンテキストのみ 画像貼り付け・コード添付等は無し　画像を貼りたい人は各自imgur等の画像アップロードサービスを使う場合が多いようです
通知	有り
言語	メインは英語　日本語はたまに見かける程度　ただやり取りは回っているようなので自動翻訳等使っているのかもしれません
その他	仕組み自体はUservoice社のサービスを使用

• 開発者から製品・API等への機能追加等の提案・要望を出すのはこちら、とガイドされています。
• 製品・サービスについてここで要望を聞き、選択・プライオリティ付け、プランニングの参考にするという位置づけのようです。ここで提案されたものが最終的に製品に反映されることもありますし、投票を多数集めても全く一顧だにされない事もまた多いです。
• 参加者には投票権が与えられ、「自分もそう思う」という提案については賛成票を投じることができるUservoiceのシステムです。
• Windows 以外にも、VisualStudio等他のMS製品でも同様のUservoiceを使ったフィードバックサイトが存在しています。

Developer Community

https://developercommunity.visualstudio.com/spaces/8/index.html

運営	Microsoft
対象	Visual Studio, Visual Studio for Mac, Team Foundation Server, Team Services
カテゴリ	報告
レポート形式	リッチテキスト コード貼り付け・画像添付可能　ファイル添付可能　公開範囲を指定可能（レポートは全員、ファイルはMSのみ等） 投稿後の編集可能
通知	有り 既定の設定で、投稿した問題にコメントが付いた・トリアージされた等のタイミングでメールが来る
言語	メインは英語　日本語はたまに見かける程度　ただやり取りは回っているようなので自動翻訳等使っているのかもしれません
その他	トリアージ（問題の重要性の評価）・同じ問題のグルーピング等は管理側でマメに行われている

• VSのインストールが途中で止まる、IDEが固まる、コンパイラのオプションおかしくねえか、ライブラリ変、Store向けbuildの度に毎回毎回ObjDirectoryを手動削除しないとエラーが出て死にたくなる、MobileにDeploy出来ない、Win10 IP何某で動きが変、その他諸々VS開発環境系の話は全てここです。
• 逆に、OSやAPIのような「VSの外」の世界はお門違いになります。
• 開発系でねっとりと濃い為、詳しいユーザーさんが回避策を教えてくれる事も多いです。
• 最近のVisual Studio では必ずウィンドウ右上についている Feedback Buttonを押すと飛ばされるのがここです。
• Triage等のTag付け、Duplicate処理等はMS側でかなり手間をかけて運用されているようで、システム・運用共にこの記事で紹介している中では一番良く出来ていると思います。…次に紹介するフィードバックHubがこのシステムだったらいいのになと思う事しばしばです。
• 開発系の問題報告サービスとしては、長い間使われている「Microsoft Connect」というサービスもあります。性格はこちらと似ているのですが、特にどちらかに一本化という訳でもないようでConnect 側もまだ活発に問題がPostされています。（2018年2月追記：2018年を以ってConnect は正式に閉鎖されたようです。 アクセスすると以下のクッションページに飛ばされます。 Microsoft Connect Has Been Retired  ）

Feedback Hub

Windows 10 アプリ 「Win+F」で起動します

運営	Microsoft
対象	Windows
カテゴリ	提案・報告（一般）、報告（開発）
レポート形式	プレーンテキストのみ　画像・フィードバックHubアプリが取得するデバッグ情報の添付は可能だが、閲覧できるのはMSの人のみ 投稿後の編集不可
通知	無し
言語	OSの設定言語
その他	Webブラウザでの閲覧は不可能　専用のフィードバックHub アプリでのみ投稿・閲覧可能 　またWin10 Mobileでの問題はWin10 MobileのフィードバックHub アプリで報告する必要がある

（一般向けの「フィードバック」機能、アプリ開発者が自アプリ向けのフィードバックを受け付ける機能については本稿では省き、問題報告についてのみ述べます）

• OSの機能に問題があるのでMSに伝えたい （ここバグってません？等）
• Insider Previewを入れたらここが動かなくなったのでMSに伝えたい （IPビルド何某にあげたら今迄動いてたAPI の動作が変！等）

等がこちらになります。カテゴリの「開発者向けプラットフォーム」を選びます。

現状、OSの機能についての問題報告窓口はここだけであるようです。
窓口自体はMSDN Forum、VisualStudioCommunity、またMicrosoft Support 等ありますが、各所で「これはOSの問題だね」となったところで「じゃあFeedback Hubに入れてね」という扱いになる事が多いです（そういう共通運用がされているように見えます）。

使い方のコツ

問題報告はできるのですが、それを受けて問題が直ったかどうか教えてくれる…という事は開発者向けプラットフォーム カテゴリでは少ないです。基本意味のある返答は無いと思ったほうがいいようです。やりがいの無い場ではあります。
ただ、ここで報告しないことには何も始まらないのもまた事実です。
ここは堪えて問題を粛々と報告しましょう。

書き方ですが、

• タイトルには問題を簡潔に1行で　個人的には、フィードバックハブのユーザーに伝わりやすいようにIPの場合はビルド番号を入れるようにしています。ただ、MS側にはOSのバージョン情報等はデータとして送信された物が見えるので、そこまで詳しく書かなくてもいいようです。
• 再現手順を箇条書きで順に示す　こつは、読む相手が「Windowsの事はすべて知っているが、あなたのアプリ・問題は全く知らない人」と仮定し、その人が「こう順に手を動かせば何が見え、そして最後にあなたの見ている問題が現れる」ように書くことです。ここが一番重要です。一般に、開発側で再現できない問題は直らないです。
• どれが問題なのかを明確にする　「この返り値が問題」「この表示が問題」と明示します。
• その問題があなたのアプリに及ぼす影響を明確にする　先ほど仮定したように、相手はあなたのアプリを全く知らないので、この問題があなたのアプリに与える影響が全く分かりません。説明が必要です。全く起動しない？アプリの価値にかかわる重要な機能が動作しない？それほどではない？回避策がある？無い？
• 機械翻訳されるので、難しい言い回しは使わない　あれを何したらどうなった、これが動かないのが問題、式の子供のような文章を心がけると翻訳の通りが良くなります。仮定、時制の変化、比喩、感想、その他諸々は翻訳の品質を下げます。

📱📱📱

一般に…社内開発等のバグ報告のプロセスですと、開発側が報告を読み、分からないところがあればテスト側…PA Group等に問い合わせる、意味を聞く等が可能です。

ですが、このFeedback Hubはそういう優しいプロセスがほぼ無いです。一発勝負のプレゼンみたいなものです。相手は他にも見るべきFeedback Itemを山ほど抱えています。簡潔に必要な事だけを並べ、あなたの問題が修正されるべき重要なものである事を納得してもらうために出来る事をする必要があるでしょう。
問題への投票数も重要な要素です。あなたの問題が一般的、他のアプリにも関わる問題でしたら、Twitter等で短縮URLを貼って共有するのも充分に意味があります。

逆に…Feedbackのコメント中でグチる、不愉快さを表明する、怒る、同じフィードバックを何度も提出するなどは…それをMSの担当者が見たところで…問題が取り上げられる助けになるとは考えにくいですよね。

ただ、こういった不毛なコメントはシステム・運用上のこなれていない部分があるが故の裏返しなのかもしれません。この記事でフィードバックHubだけ記述量が多いのも、それだけ使う側が気にしないといけない部分が多いという事でもあります。ここまで各種コミュニティサービスを並べてきましたが、このフィードバックHubはマイルドに言ってもシステム・運用共に問題が多いと感じます。US本社でのReddit AMA、日本支社でのInsiders Meeting 開催等、改善への取り組みは始まっているようなので今後に期待したいです。

今回紹介していない所

• Teratail あまり見れていないです。
• 2ch ウチのプロバイダから書き込みできないので見てないです。コメントできない掲示板ほど空しいものも無いので。
• Microsoft Support   コミュニティ要素が一切無いので今回紹介していませんが、Dashboard でのアプリ公開にまつわるトラブル等、明らかにMS側の問題であり、対応してくれないとどうにもならないものも多いです。この場合はオンラインコミュニティで相談するよりはさっさとサポートに連絡して直してもらったほうが話が早いです。ダッシュボード 右上の「？」アイコンから手続きに進みます。
• GitHub 　最近はProject Rome や Windows Template Studio のように、開発中のプロダクトもGitHub上で全公開で進められるものが増えています。この場合、GitHub のissue で問題や要望について直で送ることが可能で、話がとても早いです。