ユニバーサルWindowsアプリ開発の勧め：特集：Windowsストアアプリ開発最新情報（Build 2014より）（4/4 ページ）

WindowsとPhoneの使い分け

　実際に開発していくに当たっては、WindowsとPhoneの使い分けが必要な場面が出てくる。気が付いた点をいくつか挙げておこう。

編集コンテキスト

　上で作ったユニバーサルプロジェクトの「App.xaml.cs」ファイルを開いてみる。共有プロジェクトに入っているファイルだから、Windows用にコンパイルされたりPhone用にコンパイルされたりする。編集しているときには、どちらのコンテキストで見えているのだろうか？ エディターの上にドロップダウンが追加されていて、現在のコンテキストはそこに表示されており、簡単に切り替えられる（次の画像）。

編集コンテキストのドロップダウン

#ifディレクティブ

　テンプレートでは共有プロジェクトに「Common」フォルダーがあるが、果たしてWindowsとPhoneでは完全に同じにできるものなのだろうか？ 例えば「Common」フォルダーの「NavigationHelper.cs」ファイルを開いてみよう。そのコンストラクターには次のような記述がある（次の画像とコード）。

NavigationHelperクラスに見る#ifディレクティブ（VS 2013）
WindowsとPhoneの違いをカバーするために、Phoneのプロジェクトには「WINDOWS_PHONE_APP」という条件付きコンパイルシンボルが定義されている。

　Phoneのプロジェクトには「WINDOWS_PHONE_APP」という条件付きコンパイルシンボルが定義されていて、#ifディレクティブを使ってPhoneに特有のコードとWindowsに特有のコードとを切り分けている。ちなみに上のコードでは、Phoneの場合だけ、Windows Phoneの［戻る］ハードウェアボタンのイベントハンドラーを設定している。

generic.xaml

　上の話から、「なるほど、それなら」と思うだろう。「画面のXAMLファイルをWindows用のプロジェクトから共有プロジェクトに持っていっても、［戻る］ボタンはちゃんと切り分けできるはずだ」と。

　ところが実際にやってみると、［戻る］ボタンのスタイル定義がPhoneのプロジェクトには存在せず、ランタイムエラーになってしまう。これは、「generic.xaml」ファイルがWindowsとPhoneで別々に定義されているためだ*13。

　また、「generic.xaml」ファイルの相違を克服したとしても、やはりWindowsとPhoneではUIのデザインが違ってくる（特に画面のヘッダー部分）。そういったことから、画面のXAMLファイルを共有プロジェクトに置くのはお勧めできない。開発上の戦略としては、画面定義はWindowsとPhoneに置くが、できるだけロジックを含めない「薄い」UI層にすること。そして、WindowsとPhoneでほとんど変わらない画面は、ヘッダー部分を除いた部分をユーザーコントロールとして共有プロジェクトに置くのがよいだろう。

パーシャルクラス

　#ifディレクティブによるソースコードの切り替えは手軽だが、その分コードが汚くなっていく。そこで、プラットフォームごとに異なるコードがある程度の量になったら、そのコードはメソッドとして切り出して、Windows用かPhone用のプロジェクトにパーシャルクラスとして配置するとよい。

クラウドのサポート

　最後に、マイクロソフトのクラウド側の対応を簡単に紹介しておく。クラウドのサポートがあって初めて、エンドユーザーにとってのユニバーサルWindowsアプリとなるのである。

ストア

　WindowsアプリとPhoneアプリでAppIDが同じものは、両方のストアで同じアプリとして扱われる。一方で購入すれば、他方でもその権利が有効となる。

　Buildの資料によれば、開発者がAppIDを同じにすればWindowsとPhoneのアプリが同一のアプリとして扱われるとのことなのだが、まだ実際に試せておらず詳細は不明である。今まではアプリの名前を登録した時点でAppIDが確定していたので、後からAppIDをそろえられるようになるのかどうか、定かではない。

　なお、ユニバーサルWindowsアプリとは関係ないが、エンドユーザーが記入してくれたレビューに対して開発者からレスポンスを書き込めるようになることがBuildの複数のセッションで発表されていた。

OneDrive

　これまで、Windowsストアアプリがローミング用のフォルダーに設定やデータを書き込むと、自動的にそのユーザーの全てのWindows 8.xデバイスにローミングされていた。これは、Windows 8.xとOneDrive協調によって実現している。

　Windows Phone 8.1もこのローミングの仕組みを備え、Windows Runtimeアプリからローミングが利用できるようになった。そしてAppIDを合わせておけば、WindowsとPhoneの間でローミングされるのだ（次の図）。

OneDriveを介したローミングの動作
セッション2-522「Dealing with Data: Storage, Backup, and Roaming」の資料p.15より。
左下のPhoneでローミング用のフォルダーに書き込んだデータが、Phoneによって自動的にOneDriveへアップロードされ、右下のWindowsはOneDriveからWNS（Windows Push Notification Services、Windowsプッシュ通知サービス）経由でプッシュ通知を受けて、ローミングデータをダウンロードする。この図ではAppIDが「PFN 12345」という架空のものになっている。

WNS（Windowsプッシュ通知サービス）

　プッシュ通知も同様だ。例えばライブタイルをプッシュ通知で更新しようとすると、これまではWindowsとPhoneでその作り方が違うだけでなく、通知自体もWindowsとPhoneとで別々に送信しなければならなかった。これもAppIDが同じなら、WindowsとPhoneで合わせて1回の通知を送るだけでよくなる。

まとめ〜ユニバーサルWindowsアプリ開発の勧め

　ユニバーサルWindowsアプリの特徴とその3要素について、駆け足で見てきた。

　最後に筆者の感想を述べさせてもらえば、「Windowsストアアプリの新規開発は、ユニバーサルWindowsアプリにしない理由がない」ということだ。

• WindowsとPhoneの、APIの互換性で悩むことは、もう無いだろう
• 画面とロジックを別のプロジェクトに分けるのは少々面倒だが、良い設計のためにはそもそもそうすべき
• Windowsストアアプリ開発時にはPhoneのプロジェクトは放っておいて、フルビルド時の互換性チェックだけを担ってもらおう
• Phoneのアプリ（国内は無くても国際化対応すれば海外には大市場がある）を後からリリースしようとなったら、画面まわりだけ作ればよい

　PhoneのWindows Runtimeアプリを新規開発するときも同じだ。未来に他方のアプリを開発する可能性がそれほど高くなくとも、ユニバーサルWindowsアプリにしておくコストはとても低いので、わずかな可能性であっても十分に見合うはずである。

　これからの新規開発はユニバーサルWindowsアプリで！

「特集：Windowsストアアプリ開発最新情報」