ユニバーサル Windows アプリ

[アーティクル]
11/04/2014

ユニバーサル Windows アプリによるコード資産の再利用

2013 年 7 月号のコラム「Windows 8 と Windows Phone 8 向けアプリのビルド」(msdn.microsoft.com/magazine/dn296517) を執筆してからいろいろなことが変わりました。現在では、Windows 8.1 向けアプリをビルドしている開発者は、Windows Phone 8.1 向けに新しいエクスペリエンスをビルドする際、コードの再利用と資産の共有が可能になっています。同様に、Windows Phone 8 の開発者は、Windows Phone 8.1 をターゲットにする際、同じコードベースを最大限に活用できます。Visual Studio 2013 と統一 Windows ランタイムを併用すると、1 つの Visual Studio ソリューションで Windows Phone 8.1 と他の Windows デバイスをターゲットにするアプリを開発できるようになります。こうした新しいアプローチのおかげで、開発者はコードを最大限に再利用しながら、アプリのユーザーベースを大きく広げることができます。

今回は、Visual Studio 2013 の新しいユニバーサル Windows アプリ機能 (テンプレート、言語、API、コンパイラ) と、さまざまなコード共有アプローチを紹介し、プラットフォーム固有のアプリをユニバーサル Windows アプリに更新する際の考慮事項について説明します。

図 1 は、ユニバーサル Windows アプリのテンプレート、アプリソリューション、およびコンパイル出力パッケージの関係を示しています。

図 1 ユニバーサル Windows アプリのテンプレート、ソリューション、および出力パッケージ

Visual Studio に含まれるテンプレート (ハブアプリケーションプロジェクトテンプレートなど) を使用すると、プラットフォームごとに分かれた複数のプロジェクトと、共有を目的とした特別なプロジェクトを許容するように構造化されたソリューションを作成できます。共有部分では、PC、タブレット、Windows Phone をターゲットとするアプリで再利用するコードを定義します。この構造により、各アプリに固有の要素がすべて適切なプロジェクトに含まれるようになります。ビルドプロセスでは、それぞれに固有のアプリパッケージが作成され、共有プロジェクトに含まれる依存関係がすべて統合されます。ショッピングアプリ、ニュースアプリ、スポーツアプリ、およびメディアアプリをビルドする場合は、ハブアプリケーションテンプレートが優れた出発点になります。

図 2 は、[新しいプロジェクト] ダイアログボックスに表示されるユニバーサルアプリの C# 用のハブアプリケーションテンプレートを示しています。

Visual Studio Update 2 からは、コードを最大限に再利用するユニバーサル Windows アプリのビルドを容易にするために必要なすべてのサポートが含まれます。

図 2 [新しいプロジェクト] ダイアログボックスに表示されるユニバーサル Windows アプリ用のハブアプリケーションテンプレート

アプリプロジェクトのサポート

開発者が Windows 8.1 と Windows Phone 8.1 の両方をターゲットにする一般的なシナリオでは、ソリューションエクスプローラーに次の 3 つの異なるプロジェクトが表示されます (図 3 参照)。

Windows プロジェクト (Windows 8.1): Windows 向けの XAML ページと固有のコード用。
Windows Phone プロジェクト (Windows Phone 8.1): Windows Phone 向けの XAML ページと固有のコード用。
共有プロジェクト: ターゲットアプリ間で共有する資産 (.cs、.xml、.png、.resw、その他の項目など) 用。共有プロジェクトは、ビルドプロセス中に各プラットフォームプロジェクトに自動的にインポートされます。

図 3 ソリューションエクスプローラーのユニバーサル Windows アプリプロジェクト

既存のソリューションの場合は、プロジェクトのコンテキストメニューから [Windows Phone 8.1 の追加] または [Windows 8.1 の追加] を使用します。

言語のサポート

コードの共有は、設計が XAML、HTML、DirectX のどれに関係しているかに応じて、C++、C#、または JavaScript を使用して行います。Visual Basic の場合は、最新の更新プログラムを使用すれば、Windows ランタイム (WinRT) API を呼び出すことができます。また、XAML のサポートと、ポータブルクラスライブラリ (PCL) の assets フォルダーが含まれます。F# の開発者は、Microsoft .NET Framework と Windows Store のレガシアプリと新しいアプリの両方に向けた共有コードを作成できます。

API のサポート

共通 Windows ランタイムにより、Windows 8.1 (PC とタブレット向け) と Windows Phone 8.1 の両方のプラットフォームでサポートされる API の統一が大きく進みます。クロスプラットフォーム開発を簡単かつ強力にするには、このような統一が重要です。ユニバーサル Windows アプリは同じ Windows ランタイム上で実行されるため、開発者は広範な Windows デバイス向けのアプリを設計およびビルドする共通の方法を手に入れることになります。この共通の方法は、中断と再開の処理やバックグラウンド処理の実行から、アプリ内のセキュリティの管理に至るまで多岐に渡ります。実際、Windows 8.1 SDK と Windows Phone 8.1 SDK は、主要言語要素に関して 566 個のクラス、119 個の構造体、および 57 個のインターフェイスを共有します。ただし、API によっては、Windows Phone でしか利用できないものもあります。

コンパイラのサポート

ビルドプロセスでは各プロジェクトに関連付けられている XAML、コード、および資産が必ずインポートされますが、共有プロジェクト内のプラットフォーム固有のコードは手動で含めることが必要になる場合があります。コードがどのプラットフォームをターゲットにしているかを示すには、条件付きコンパイルディレクティブの #if と #endif を使用します。プリプロセッサコンパイルシンボルは、C# では WINDOWS_APP と WINDOWS_PHONE_APP、C++ では WINAPI_FAMILY_PC_APP と WINAPI_FAMILY_PHONE_APP です。

次の C# の例は、開発者が App.xaml ファイルを共有プロジェクトに移動する場合の条件付きコンパイルを示しています (この例は、共有プロジェクト内で定義されたスタイルが他の種類のアプリで利用できるリソースを使用することを想定しています)。

#if WINDOWS_APP
  if (!rootFrame.Navigate(typeof(HubPage)))
#endif
#if WINDOWS_PHONE_APP
  if (!rootFrame.Navigate(typeof(WindowsPhoneStartPage)))
#endif
  // ...throw exception
Here’s the equivalent C++ conditional compilation:
#if WINAPI_FAMILY==WINAPI_FAMILY_PHONE_APP
  if (!rootFrame->Navigate(WindowsPhoneStartPage::typeid, e->Arguments))
#else
  if (!rootFrame->Navigate(HubPage::typeid, e->Arguments))
#endif
  // ...throw exception

コードと XAML エディターのサポート

Visual Studio には、ユニバーサルアプリの開発を容易にするための多くのサポートが用意されています。IntelliSense はコードを監視して、サポートされない API がユニバーサルアプリプロジェクトで使用されないようにします。プロジェクトのビルド時にも、対応するエラーメッセージによって不適切な API が特定されます (図 4 参照)。

図 4 API の使用エラーを示す IntelliSense

ナビゲーションバーでは、プロジェクトのコンテキストを切り替えることができます。これは、ソリューションエクスプローラー内の 1 つのプロジェクトのみに専念する場合に便利です。プロジェクトのコンテキスト (Windows Phone または Windows 8) によって、エディターとデザイナーの IntelliSense エクスペリエンスが変わります。

デバッグ中、F5 キーの既定のスタートアッププロジェクトを指定したい場合があります。Visual Studio では、デバッグターゲットのドロップダウンを使用して、[スタートアッププロジェクト] で必要なプロジェクトを選択すると、この操作を簡単に行うことができます。この機能は両方のストアでサポートされていて、ソリューションに複数のアプリケーションプロジェクトが含まれている場合に有効になります。

デバイスパネル (図 5 参照) では、アプリがすべてのターゲットデバイスで想定どおりに動作することを確認できます。このパネルは、さまざまなディスプレイ解像度、向き、アクセント、テーマなどを使用してアプリをテストできるようにします。

図 5 デバイスパネル

コード共有の方針

ユニバーサル Windows アプリをビルドするときは、複数のアプリが共有できるアプリアーティファクトを最大限に活用するようにします。これまで開発者は、複数のプロジェクトでコードを共有する際リンクファイルを利用してきました。Visual Studio 2013 では、この機能が強化され、共有プロジェクトと PCL という、コード共有を可能にする 2 つの関連するアーティファクトを提供します。

共有プロジェクト (共有フォルダー) には、app.xaml などの XAML ファイル、コードファイル、イメージ、XML/JSON、.resw ファイルを含むすべての共有コードと資産、および共通テンプレートや DataModel テンプレートといったテンプレートを格納するシンプルな構造が編成され、用意されます。共有プロジェクト内の参照は、コンパイラエラーを発生させないように解決しておく必要があります。

PCL はユニバーサル Windows アプリでも優れたサポートを提供します。たとえば、開発者は WinRT API と移植可能な XAML ユーザーコントロールの呼び出しと作成が可能になります。プロジェクトのターゲットを変更して別のプラットフォームを含めると、コンパイラは、すべてのターゲットで動作することが保証される 1 つのバイナリを生成します。また、他のターゲットを削除して、PCL のターゲットを特定のプラットフォームにすることもできます。このような状況に応じた変換は、PCL、Windows Store 8.1、および Windows Phone 8.1 の間でのみサポートされます。

PCL のバイナリはサードパーティにも配布できるため、ライブラリを PCL に移植するクロスプラットフォーム開発者のコミュニティが拡がっています。そのため、Visual Studio Express の開発者などは、他のプラットフォームをターゲットにする際に豊富なライブラリ機能を利用できるようになります。マイクロソフトは、MS Open Tech を通じてさまざまなオープンソースコミュニティと連携し、よく使用されるフレームワークにコードを提供して Windows デバイス向けに最適化しています。たとえば、JQuery は Windows ランタイムを完全にサポートするため、開発者は既存のコードとスキルを再利用して、Windows 8.1 アプリをビルドできます。

共有プロジェクトと PCL の選択方法

共有プロジェクトと PCL のどちらかを選択するかを簡単に決めるには、プラットフォームの特異性を考えます。

プロジェクトがサードパーティの配布をターゲットにしていなければ、共有プロジェクトを選択すると最高のエクスペリエンスが得られます。
プロジェクトがサードパーティへの配布をターゲットにしていれば、PCL が適切な選択肢になります。

図 6 に、各アプローチの長所と短所の一部を示します。

図 6 共有プロジェクトとポータブルクラスライブラリの比較

長所

短所

共有プロジェクト

• #if を使用してプラットフォーム固有の API を使用できる。

• API が異なる名前空間に含まれる場合のように、ソースに互換性があってもバイナリには互換性がない状況に対処できる。

• ソースまたは複数のバイナリのいずれかを共有する必要がある。複雑な部分は利用者に委ねられる。

• コードのメンテナンスが難しくならないように、異なる API の処理を一元化する規約や規律が必要になる。

ポータブルクラスライブラリ

• 配置と共有モデルが非常にシンプルである。

• サードパーティまたは複数のプログラミング言語が関連する複数のソリューションを必要とする非常に大規模なシステムにスケール変換できる。

• ターゲットにまとまった API があるかどうかに大きく左右される。

• 異なる API を処理するには、依存関係注入コンテナーや制御の反転コンテナーなど、高レベルの抽象化の使用が必要になる。

コード共有に関するその他の考慮事項

リンクファイル: 共有ファイルと同様、Visual Studio の [リンクとして追加] 機能によって、コンパイラ条件を使用して複数のプラットフォーム間で共有するという、従来の明示的なファイル共有手法が提供されます。

フロントエンドでのコード共有: Windows Store 8.1 と Windows Phone 8.1 はどちらも、同じ WinRT XAML スタックを共有します。これにより、開発者は UI も共有のターゲットにできるようになります。UI は、XAML デザイナーを使用するなど、PCL を介して共有します。

バックエンドでのコード共有: ユニバーサル Windows アプリは、バックエンド処理コードの共有に注目すると、大きなメリットを得られます。さらに、クラウドとの依存関係を利用する共有データモデルを実装すれば完璧です。特に Microsoft Azure Mobile Services は強力なバックエンドコンポーネントの優れた例です。ユニバーサル Windows アプリでは、複数のアプリやデバイスで、このサービスの通知などの機能にアクセスすることができます。このサービスを利用すると、Windows ストアアプリでも Windows Phone アプリでも、同レベルのデータセキュリティ、アプリの可用性、スケーラビリティを実現できます。

アプリの更新パス

開発者がいずれかのストア向けにアプリを作成している場合、他のストアをサポートするようにそのアプリを簡単に更新できるようになりました。すべての更新パスには、Windows 8.1 と Visual Studio 2013 をインストールしておく必要があります。

Windows Phone 8 アプリからユニバーサル Windows アプリへの更新: Windows Phone 8 アプリをユニバーサル Windows アプリにするように Windows ランタイムを更新する場合は、Windows XAML を使用して新しい UX を作成し、新しい Windows Phone 8.1 アクションセンターを最大限に活用する通知オプションのような機能を提供したうえで、まったく新しい機能をユーザーに提供するようにします。ユニバーサルアプリに更新すると、PC やタブレットの並列アプリと簡単にコードを共有できるようになります。

アプリを Windows Phone 8 から Windows Phone 8.1 に更新する場合、バックグラウンド処理、ファイルとストレージ、コントロール、およびその他のデバイス機能に関連する API 動作と機能の変更点 (https://msdn.microsoft.com/ja-jp/library/windows/apps/dn642486) がいくつかあるため、API サポートの違いについてのドキュメントを参照してください。

Windows ストアアプリからユニバーサル Windows アプリへの更新: ビルド済みの Windows 8.1 アプリを Windows Phone 8.1 ストアに公開すると、ユニバーサル Windows アプリのパターンも適用されます。Windows Phone 8.1 の場合と同様、移行プロセスに影響する可能性のある API 動作の変更点 (https://msdn.microsoft.com/ja-jp/library/windows/apps/dn596093) を理解しておくことが重要です。たとえば、アプリバー、ポップアップ、ハブなどのコントロールは、Windows Phone ではサポートされません。

Windows ストアアプリの更新と Windows Phone 8.1 の追加: コンパニオン Windows Phone 8.1 アプリを Windows ストアアプリに提供する操作は、ユニバーサル Windows アプリテンプレートによって簡単になります。このテンプレートを使用すると、新しい Windows Phone 8.1 プロジェクトを Windows ストアソリューションに簡単に追加できます。コードエディターとコンパイラが追加部分を認識して動作に適切な変更を加えるため、開発は必ず正常に行われます。

ストア認定

Windows アプリ認定キット (WACK) は、開発者がアプリをストアに提出する際の準備に使用するインストルメンタルツールです。このツールを使用すると、Windows Phone 8.1 アプリをテストすることもできます。ただし、Windows Phone 8 アプリはテストできません。WACK 3.3 は Windows 8.1 用 Windows SDK に含まれています。WACK の新しい要件についての詳細情報 (bit.ly/1qXPKmf) を確認してください。

まとめ

プラットフォームをまとめる作業は、実現までに長い時間がかかっています。まだ完璧とは言えませんが、これまでの進化により、プラットフォーム機能、ツール機能強化、UX 機能、幅広いアプリシナリオのサポートなど、開発者が利用できる機能は大きく改善されました。現状では、さまざまなデバイスでコードを十分実行できるとはいえません。UX では、アプリを実行するデバイス固有の特性を最大限に活かす必要があります。異なるデバイスで同等の機能をサポートすることも重要です。それがユーザーが期待することです。

今回は、PC やタブレットのプラットフォームと Windows Phone プラットフォームの両方をターゲットにするアプリを同時に開発できる主要機能について説明しました。こうした機能は、ソリューションをゼロから構築する場合にも、既存のソリューションを更新する場合にも対応します。ユニバーサル Windows アプリは、開発者がユーザーベースを広げながら、コードへの投資価値を向上させる優れた方法を提供します。

aka.ms/wasamples (英語) には Windows 8.1 と Windows Phone 8.1 の両方で実行できるさまざまなユニバーサル Windows アプリのサンプルがあり、aka.ms/uap (英語) には新しいユニバーサル Windows アプリテンプレートを使用する数多くの機能サンプルがあります。

Joel Reyes は、スタートアップ開発手法に重点を置くマイクロソフトの Developer Experience & Evangelism グループのシニアテクノロジエバンジェリストです。彼の連絡先は joel.reyes@microsoft.com (英語のみ) です。

この記事のレビューに協力してくれた技術スタッフの Lora Heiny に心より感謝いたします。

次の方法で共有