徹底予習！ Windows 10のユニバーサルアプリ開発：特集：次期Visual Studioの全貌を探る（6/6 ページ）

[山本康彦，BluewaterSoft／Microsoft MVP for Windows Platform Development]

4. アプリ間連携の強化

　UIコントロール以外のAPIも、大幅に追加された。逆に、FileOpenPickerクラス（Windows.Storage.Pickers名前空間）のPickSingleFileAndContinueメソッドのように、Obsolete属性を付けられたものもある*14。

　ただし、全てのAPIが確定しているわけではなさそうである。Windows 10 TPの新しいビルドが出てくるたびに、かなりの量のAPIが改廃されているのだ。APIの確定は「Go-live」ライセンスの提供まで待たねばならない。

*14　Obsoleteになったのは、Windows 10 for phonesでもPickSingleFileAsyncメソッドが使えるようになったからだ。Windows Phone 8.1ではPickSingleFileAndContinueメソッドを使うしかなかったが、それがどれほど面倒だったかは「WinRT／Metro TIPS：アプリからファイルを開くには？［ユニバーサルWindowsアプリ開発］」を参照。

　新しく追加されたAPIの中で特筆すべきは、アプリ間の連携が強化されたことだ。

　Windowsランタイムアプリでは、セキュリティ確保のために、アプリ間の直接的な通信（プロセス間通信など）が禁じられている。その代わりとしてアプリ間の連携を取る仕組みはこれまでもあったのだが、十分とはいいにくいものだった。「共有に送る」機能やプロトコルアクティベーションによるアプリの起動など、いわば「投げっぱなし」であって、処理結果を受け取ることはできなかったのである。

　Windows 10のLauncherクラス（Windows.System名前空間）を使ったプロトコルアクティベーションでは、LaunchUriForResultsAsyncメソッドなどが追加された。これにより、アプリを指定して起動し、処理結果を受け取れるようになる。また、アプリを起動するときにファイルを渡すことも可能だ。

　ApplicationDataクラス（Windows.Storage名前空間）には、GetPublisherCacheFolderメソッドなどが新設された。これにより、同じパブリッシャーのアプリ同士に限られるが、アプリ間でフォルダーを共有できる。

　そして、AppServiceConnectionクラス（Windows.ApplicationModel.AppService名前空間）によって、「アプリサービス」の作成が可能になった。あるアプリがサービスとして登録しておいたバックグラウンドタスクを、別のアプリから呼び出して利用できるのである。Windowsランタイムアプリ間でクライアント／サーバーシステムを組むイメージだ。すでに、Windows 10 TPの「マップ」アプリなどで使われている。

　アプリ間連携の他にも多くの改良がある。それらの概要は「Windows 10 Developer Preview の新機能」をご覧いただきたい。

5. 多彩なセンサーAPI

　Windows 10は、IoT（＝Internet of Things、モノのインターネット）にも対応する。そのためであろう、センサー系のAPIも豊富に追加されている。

　Windows.Devices.Sensors名前空間を、Visual Studio 2015のオブジェクトブラウザーで表示させてみると（次の画像）、把握しきれないほどのセンサーAPIが並んでいる。従来からのものも含めていくつか拾っておくと、Accelerometer（加速度）／Altimeter（高度）／Barometer（気圧）／Compass（方位）／LightSensor（環境光の明るさ）などである。

Windows.Devices.Sensors名前空間をオブジェクトブラウザーで見る（Visual Studio 2015 CTP 6）
これでも、ほんの一部だけの表示だ。

　全てを確かめたわけではないが、これらのセンサーAPIのDevice familyはUniversalである。IoTデバイスに限らず、デバイスドライバーさえ提供されれば、PCなどでも利用できそうだ。これらセンサーAPIのサンプルコードは「Windows-universal-samples」（URLはMapControlコントロールの脚注*13を参照）に多数掲載されている。

　また、通信用のAPIも強化されている。名前空間で示すと、Windows.Devices.Gpio（GPIO）／Windows.Devices.HumanInterfaceDevice（HID）／Windows.Devices.SerialCommunication（USB接続のRS-232C）／Windows.Devices.Usb（USB）／Windows.Devices.WiFiDirectなどがある。

既存アプリの対応

　ここまで見てきたように、Windows 10ではWindowsランタイムアプリの作り方がずいぶんと変わる。既存のアプリはどうしたらよいだろうか？

1. ゼロから作り直す

　UXの設計から根本的に見直して作り直す。エンドユーザーにとっては恐らく最も適切な対応だが、開発は大変だ。

2. マイグレーション

　既存のアプリを、Windows 10用に移植する。そのためにはWindows 10用のプロジェクトにしなければならないが、それには二通りの方法がある。

　まず、再ターゲットによる方法。Visual Studio 2015 CTP 6にはまだ実装されていないが、正式リリースまでには追加されると思われる。また、有志による「Windows 8.1 to Windows 10 Retargeting Extension」（英語）が公開されている（C#限定）。

　次は、プロジェクトを追加する方法だ。共有プロジェクトを使ったユニバーサルWindowsアプリのソリューションの場合、そこにWindows 10用のユニバーサルアプリのプロジェクトを追加する。そして、共有プロジェクトに対する参照を追加し、Windows 8.1／Windows Phone 8.1のプロジェクトから画面を移植するのだ（前述したXaml viewを使うと簡単になりそうだ）。

　Windows 10用のプロジェクトになったら、あとはコツコツと修正していく。「UXの変更」で述べたWindows自体の変化にも対応する必要がある。

　共有プロジェクトで、Windows 8.1／Windows Phone 8.1のサポートも継続するときには、Windows 10用のユニバーサルアプリのプロジェクトでは「WINDOWS_UAP」というコンパイル時定数が定義されているので、コードの切り分けを追加できる（ApiInformationクラスによる可用性チェックを忘れずに）。逆に、Windows 8.1／Windows Phone 8.1のサポートをしないのであれば、「#If」ディレクティブは削ってしまおう。

3. 既存アプリの改修

　Windows 8.x／Windows Phone 8.x用のアプリは、そのままでもWindows 10で動作する（Windows Phone 7.x用のアプリも）。

　従って、そのままにしておくこともできるが、Windows 8.x用のアプリでは「UXの変更」で述べたWindows自体の変化による影響だけはチェックしてもらいたい。ウィンドウの最小高さが小さくなったことで、全く利用できなくなってしまうアプリもあるかもしれないからだ。チャームやアプリバーに関しては、Windows 10に互換性のための機能があるので（次の画像）、致命的な問題にはならないはずである。

　また、使いにくくなってしまうのを補うために、ある程度のUI改修も検討してみてほしい。詳しくは次の「WinRT／Metro TIPS」を参考に。

• コードから設定チャームやアプリバーを開くには？
• アプリバーをタッチ操作で開きやすくするには？
• Windows 10のようにGridViewコントロールをスクロールさせるには？

Windows 8.1用アプリをWindows 10で動作させた例（Windows 10 TP）
Windows 8.x用のアプリには、互換性を維持するためWindows 10が自動的にハンバーガーボタンを付ける（赤丸内）。このハンバーガーボタンをタップすると赤枠で示すコマンドが表示される。［アプリ コマンド］はアプリバーを開く。［検索］／｢共有｣／［印刷］／［設定］は、チャームにあったそれぞれの機能を呼び出すものだ。タッチ操作でアプリバーを出す操作（ハンバーガーボタンをタップしてから［アプリ コマンド］をタップ）は、これまでより手間がかかる上に、タッチする部分が小さいためかなり苦痛である。

まとめ

　Windows 10ではWindowsランタイムが再構成され、そのユニバーサルアプリは1バイナリで複数デバイスに対応できる。Windows 10用のユニバーサルアプリ開発は、プロジェクトの構成からUIコントロール／APIに至るまで大きく変貌を遂げ、より多くのことをより簡単にできるという方向に進化している。

　Windows 10のUXは、Windows 8.1からずいぶん変わった。既存のアプリをWindows 10で動かすと操作に支障が出る可能性もあるので、チェックしてみてもらいたい。

　Windows 7／8.xからWindows 10へのバージョンアップは無償なので（一年間限定）、エンドユーザーの移行は早く進むだろう。また、2015年中にWindows Phoneの国内販売が始まるのはほぼ確実となり、今後はWindows 10 for phonesの国内普及も大いに期待できる。

　これまでより高機能なアプリをより簡単に開発できて、インストールベースの急成長が見込まれるWindows 10。その開発に興味があるなら、さっそく始めてみよう。プレビュー版の開発環境は、すでに入手可能なのだから*5。

　残念ながらプレビュー版の環境を作れない場合は、Visual Studio 2013を使ったWindows 8.1用のWindowsストアアプリ開発で、肩慣らしを始めよう。そのときはWindows 8.1専用のプロジェクトでよい。Visual Studio 2015が正式リリースされるときには、Windows 10向けユニバーサルアプリへの再ターゲットがメニューに追加されているはずだ。

「特集：次期Visual Studioの全貌を探る」