2018/11/25

MicrosoftストアとPrivacy Policy

先月、Microsoftストアの管理用のダッシュボードで、Monitorianの更新のサブミッションを出そうとしたとき、Propertiesの項が前回から変えていないのにIncompleteになって、サブミッションの提出ができないことがあった。

何かと思ってPropertiesの項を開いてみると、個人情報の取扱いについてNoを選択していたら、そのせいで設定が完了していないことになっていた。

大前提としてMonitorianは個人情報に触らないので、ここは最初のサブミッションからNoを選択してきた。前回のサブミッションが通過したのが10月10日、この時が10月17日だったので、この間に何らかの変更があったのか、その前の変更の影響がこのタイミングで現れたのか、その辺は不明。

いずれにせよ、Privacy policy URLの入力が必要なのはYesを選択したときだけのはずで、ダッシュボードの動作としておかしいので、インシデントとして報告した。

過去の他の経験から、まず問題をサポートに理解してもらうのが手間かなと思っていたら、サポートの反応は迅速で、かつ、一発で問題を正確に理解していたので少し驚いた。前回と変えていないのに引っ掛かったことについて調査してもらった結果、以下のことが判明。
  • アプリのCapabilityとしてrunFullTrustを宣言しているので、このCapabilityの場合は、アプリの実際の動作にかかわらず、Privacy policyが必要。
  • 前回までこの問題が出なかった理由は不明だが、いずれにせよ現在は必要。
このrunFullTrust(Full Trust Permission Level)はDesktop Bridgeを利用する場合にはそう指定することになっているので、開発者に選択肢はないが、確かにかなり強いCapabilityなので、Privacy policyを要求するのは分からなくもない。というか、その可能性はあるだろうと思ってはいた。一方、弱いCapabilityでも個人情報を扱うことはあり得るので、本質的には別次元の問題。

ともあれ、このアプリは個人情報を取得しないという一文であっても、Microsoftストアのシステム上必要なのであれば書くが、Yesを選択すると事実と異なる虚偽の記載となって、後でペナルティ等はないのかと質問したところ(しつこく聞こえるかもしれないが、虚偽の記載は何であれ後で不利に利用されかねない)、以下の回答。
  • ここでYesを選択することによって、ペナルティを課されることはない。
ということで、確認はしたので、Privacy policyを作成してサブミッションを通過させた。

以上、デスクトップアプリをMicrosoftストアに出すにはDesktop Bridgeが必要、Desktop BridgeはrunFullTrustが必要、MicrosoftストアはrunFullTrustだとPrivacy policyが必要、よって、導き出される結論は、デスクトップアプリをMicrosoftストアに出すにはPrivacy policyが必要ということになる。

その後、ダッシュボードは修正されて、11月25日現在、以下のようになっている(Wifinianのもの)。

CapabilitiesとPrivacy policyの関係が明示されたので、その点は分かりやすくなった。

2018/09/08

Desktop App Converterの完全削除

Desktop App Converter(DAC)を使ったことがあれば知ってのとおり、DACは対象アプリのインストーラをコンテナ技術を使って実行するので、DACを実行するOSと同じバージョンのBaseImageを必要とします。

このため、DACを使うには初めに、
  1. MicrosoftストアからDACをインストールする。
  2. OSに合ったBaseImageをダウンロードし、DACでSetupする。
という手順が必要となります。

さて、DACによる対象アプリのAppxパッケージ化が完了し、不要となったDACを削除するときは逆に、
  1. DACをアンインストールする(ストアアプリなので簡単)。
  2. BaseImageを削除する。
で終了かといえば、実はそんなことはありません。

というのも、DACをSetupしたときにBaseImageから展開されたファイル群はDACをアンインストールしても削除されないので。具体的には以下のパスに存在します。
C:\ProgramData\Microsoft\Windows\Images
これらのファイルは現在のBuild 17134のもので約1.5GBありますが、アクセス権限の関係で簡単には削除できません。これを美しく消す方法はないかと調べてみたら、ちゃんと公式にありました。
このCleanupオプションを使えば、全部きれいに消すには以下のコマンドとなります。
DesktopAppConverter.exe -Cleanup All

これは当然にDACをアンインストール前に行う必要があるので、手順を改めれば以下のようになります。
  1. DACでCleanupする。
  2. DACをアンインストールする。
  3. BaseImageを削除する。
ちなみに、BaseImageはSetup後はなくてもConvertは可能なので、Setupした時点でもう不要かもしれません。

そもそも、MicrosoftがWindows 10の細かなバージョン向けのBaseImageを継続的に提供しなくなっているので(歯抜け状態)、DAC自体が使い物にならなくなってきていますが。

2018/08/08

FlashAir W-04の速度

遅ればせながら、W-03が一杯になって容量をやり繰りするのが面倒になってきたので、W-04を買ってきた。これで4世代のFlashAirが揃ったことになる。

かなり速くなった(特に無線LAN)らしいので、早速W-03と比較してみた。
PC側はThinkPad X230で、FlashAirからアンテナまでは約30cmの至近距離。なお、無線LANの速度はその時々の電波環境でかなり変わるので、あくまで参考値。

Snowyで759枚のJPGファイル(合計3GB)を転送するのにかかった時間は、W-03の場合は2033秒(約34分)。平均速度は1.515MiB/sとなる。

対して、W-04の場合は573秒(約10分)だった。平均速度は5.376MiB/sとなる。

つまり、W-04は約3.5倍の速さを発揮したことになる。

これは条件のよいときの速度だと思うので、出先で電波が飛び交うような環境ではもっと下がるだろうが、今時イベントで写真を撮ると1GBぐらいはすぐ行ってしまうので、それでも(条件がよければ)3~4分で転送が終わるとなれば、写真を撮った後の工程に大きく影響する。という意味では買う価値はあると思う。

2018/03/21

MonitorianとWifinian

しばらく前にMonitarianWifinianをWindowsストアでリリースしました。どちらもWindows用で、OSの機能で行けてないところ(モニターの明るさ調整、Wi-Fi設定)を補完するものです。中身的にはC#によるWPFアプリ(ただし、Win32を多用)で、Desktop Bridgeを利用してストアに出しています。これらの使い方自体は、そんなに難しくないと思うので、開発について簡単に説明しておきます。

1. Monitorian


以前の環境光センサーに関するエントリで、Windows 10のアップデートでアクションセンターにモニターの明るさ調整のスライダーが入るらしいと書きましたが、これまでのところは入っていません。
Monitorianの設定中の「調整後の明るさを表示する」は、このエントリで触れた問題に対応するもので、(環境光センサーがある場合に)設定値に加えて実際の調整後の値も表示することで、設定を多少やりやすくします。

内部的には、モニターの明るさに関して利用可能なWin32、WMIの機能をほぼ全て動員し、Device Instance IDをキーに使って統合して利用しています。少々面倒なことに、それぞれに含まれる機能が断片的なので、統合しないと必要な機能が揃わないのですよね。

外部モニターについては、DDC/CIが有効であることが条件ですが、これはモニターとその設定によるので、開発側としてはどうしようもありません。この問題に引っ掛かったらしきレビューが付いてますが、必要条件には初めから書いてあるので。一応、それと直接表示する機能を追加しました。

名前については、昔アプリには機能が分かりやすい名前を付けるべしという話を読んだことがあって、それを考慮していたこともありますが、そんなお行儀に囚われる必要などないと悟ったので、造語しています。

2. Wifinian


Native Wifiのマネージド実装であるManaged Native Wifiを利用するアプリから機能を強化・リファインの上、改名したものです。
機能としては、前のアプリと比べて、Wi-Fiの状態変化に応じて自動的に更新するようにした、Auto ConnectとAuto Switchの設定に合わせて自動的に介入して接続先を切り変える機能(Engage)を付けた、というのが主な違いです。後者はWindows 7まではOS標準であった機能が、Windows 8以降で簡略化されたものを、再び使えるようにしたことになります。

この辺はMicrosoftのデザイン上の判断で、「Wi-Fiセンサー」の顛末も見るに、ユーザーはWi-Fiに繋がりさえすれば何だって気にしないだろうという判断があったものと想像しますが、まあ実際そうかもとは思いつつ、ユーザーの意図で決めたい場合もあるので。

内部的には、このためにManaged Native Wifiを強化し、WlanClientを保持してWi-Fiの状態変化を監視できるようにしています。引き続きReactivePropertyを使わせていただいてます。その点で再確認した注意事項は、ReactiveCommandに繋げる前にはUIスレッドに戻しておけということです。

名前については、同上。Wifiの後は語感です。

3. ScreenFrame


タスクバーの通知領域にアイコンを出しつつ、タスクバーに引っ付いたウィンドウと通知領域アイコンに重なるウィンドウを(NotifyIconのContextMenuと同じ位置に)出すためのライブラリです。Wifinianの前のアプリで開発したものをベースに、Monitorian用に開発し、後にWifinian用に拡充しています。Wifinianではウィンドウのタスクバーからの脱着ができるようになっています。

このコードの肝は、
  • WM_WINDOWPOSCHANGINGメッセージに引っ掛けてウィンドウのサイズ・位置調整をすること。これにより、ウィンドウのサイズ・位置変更を全て捕捉し、状態に応じてそのWINDOWPOSを改変することでサイズ・位置変更に自然に介入できる。

  • NotifyIcon中のNativeWindowへのWM_DPICHANGEDメッセージを監視することで、通知領域のあるスクリーンのDPI変化を捕捉すること。マルチモニター環境で通知領域アイコンのあるスクリーンのDPI変化をどう検知するかが課題になっていたが、これによりそのスクリーンにウィンドウがない場合でも検知できる。なお、NativeWindowへのウィンドウメッセージ監視は、そもそもNotifyIconがそうしていることに倣ったもの。
ちなみに、非公開メンバーにReflectionでアクセスしている部分がありますが、もはやほとんど開発は行われていないだろうし、実際上、気にする必要はないだろうと。NotifyIconがWinFormsだという点は、それを避けてWin32を直接使うよりマネージドの方がましです。

そういえば、先日、LGの42.5インチのモニターの実物を見てきましたが、広すぎてスクリーンの端に付いたタスクバーを起点とするUIにはもう無理があると感じました。既にこのサイズのモニターが普及価格帯に入っていますが、Microsoftはどうする気ですかね。

[追記]

後から気づきましたが、NotifyIcon中のNativeWindowはプライマリーモニターに存在する扱いになるようで、これではプライマリータスクバーのあるモニターのDPI変化を必ずしも検知できません。また、プライマリータスクバーはどのモニターにも移動できるので、これを完全に追いかけるのはほぼ無理です。

4. StartupAgency/StartupBridge


常駐アプリとして必要な自動起動のためのライブラリがStartupAgencyです。自動起動の方法は幾つかありますが、コード的に一番簡単なのはレジストリに登録することで、インストーラによるアンインストールで掃除できることを前提にすれば、それで十分なのでその方法を取っています。

ただし、Desktop Bridgeの場合はその方法ではダメで、UWPのStartupTaskを使う必要があるので、そのための別ライブラリがStartupBridgeという構成になっています。
問題は、これによる自動起動とユーザーによる手動起動をどう判別するかで(自動起動のときはウィンドウを出さないようにしたい)、自動起動のときにArgumentsを付けることができれば簡単ですが、StartupTaskでこれをやる方法が見つかりませんでした。

代替策として、完全な方法ではないですが、アプリの起動時間を記録するようにし、自動起動が有効な場合に、起動時に前回の起動時間とOSの起動時間(セッション開始時間)を比較して前者の方が前であれば自動起動と判断する方法を考えましたが、どこに記録するかという選択が残ります。

この記録には、ライブラリのモジュール性を高めたかったので、UWPのLocalSettingsを使うようにしました。Desktop Bridgeの場合は実はこの手が使えます。といっても、TaskIdはAppxManifest.xmlのものと一致する必要があるので、そこのアプリ本体への依存は避けられませんが。

[追記]

過去のStack OverflowでのMSFTの人の回答を見ても、Argumentsを付ける方法はないようです。

5. Desktop Bridge


Desktop Bridgeのパッケージ作成は今ではVisual Studioでも直接できますが、Desktop App Converterのやり方に慣れたので、そちらを使っています。面倒な画像作成を自動でやってくれます(ただし、サイズが妙に奇数なので、輪郭がぼける)。コマンドはメモしておいてPowerShellに張ればいいので、さほどには。

このパッケージ作成を14393より新しいバージョンでやりつつ(BaseImageのバージョンは実際のOSのバージョンと一致している必要がある)最低動作バージョンを14393としておくことは可能で、パッケージ作成のためだけに14393の環境を維持する必要はありません。一応、14393のときのISOで環境を作って動作確認はしましたが。

ちなみに、Desktop Bridgeでインストールしたアプリには、UWP同様に以下のパスに専用フォルダーが作成されるので、この中を探せばAppDataに作成したファイルを直接見ることは可能です。
[system drive]\Users\[user name]\AppData\Local\Packages

Windowsストアに出すことのメリットは、正直それだけで認知度が上がる感じではないですが、クラッシュ報告が自動的に集計されてくるのは参考になります。

なお、2018年2月現在で、Desktop Bridgeはまだ専用窓口から申し込んでMicrosoftの担当者とのやり取りを経てから通常のストア申請に移る方式でした。その担当者は現在は既に日本Microsoftの方になっています。