WindowsデスクトップアプリケーションをXAML Islandsで最新化する

もしインターネットが唯一の情報源ならば、Windowsデスクトップ開発はもはや終わりだという印象を持っているかも知れない。しかしながら、Visual Studioのテレメトリーデータによると、デスクトップアプリケーション開発に積極的に携わっている開発者の数は約240万人で、20か月前に比べて50％増加している(2018年5月現在)。この大規模なコミュニティをサポートするため、Microsoftは、これら資産のWindows 10への統合を支援する方法を検討している。

XAML Islands

Microsoft Windows開発における最大の不満のひとつは、WinformsおよびWPFへの投資の不足である。Windows 10で公開されている新機能の大部分は、UWP向けに構築されており、実際には.NET FrameworkからUWP APIを呼び出すことが可能になっているにも関わらず、UIが関与していない場合にのみ機能する。

この問題に対処するための新たなコントロールとして、WinForms XAML HostとWPF XAML Hostの2つが新たに開発された。これにより、UWP用に作成されたUIを、既存のWinForms/WPFアプリケーションに組み込むことが可能になる。

ラップされたUWPとWindows 7フォールバック

WinFormsあるいはWPFを引き続き使用する理由のひとつとして、Windows 7のサポートがある。その結果として、新たなXAML Islandsの要件は、アプリケーションがWindows 10で実行されない場合に正しく機能することになる。

ひとつの例が、現在提供中のWebViewだ。アプリケーションがWindows 10で実行されている場合、WebViewはEdgeブラウザをホストするが、Windows 7で動作する場合には、IEブラウザコントロールがロードされる。

その他の現在計画中のコントロールとしては、MediaPlayer、InkCanvas/InkToolBar、Map、SwapChainPanelなどがある。

Airspace

これまでWinFormsとWPFを混在させる必要のあった開発者ならば、同じウインドウ内の異なるUIフレームワークによるコントロール重複の問題を扱う、“Aitspace”と呼ばれる概念に詳しいはずだ。

Win32の開発では、画面上の各オブジェクトは、OSレベルで登録された独自のウィンドウハンドル(HWND)を取得する。このHWNDは、オブジェクトがコンテンツをレンダリング可能な画面上の矩形(Rectangle)に関連付けられている。一般的に、WinFormsのコントロールがそれぞれ独自のHWNDを取得するのに対して、大部分のWPFコントロールはウィンドウ全体でひとつのHWNDを共有する。

XAML Islands(WinFormsおよびWPF)では、UWPコントロールで使用するためにHWNDが生成される。これは自明ではない、いくつかの悪影響を及ぼす可能性がある。例えば、UWPコントロールを回転させても、HWNDは回転しない。従って、回転するUWPコントロールを格納できるように、HWNDを大きくしておく必要があるのだ。

ポップアップコンテキストメニューは、特に扱いが難しい。これらは通常、独自のHWNDを持つが、そのHWNDがXAML IslandsのHWNDに必ずしも正しくスタックされていないため、他のコントロールの背後にメニューが表示される場合があるのだ。

スレッディングモデル

現在のUWPでは、各トップレベルウィンドウが専用のUIスレッドを所持する必要がある。ここで、例えば、詳細ビューがUWPで記述されたマスタ詳細ビューがあるとする。これを実装するには、いくつかの方法が考えられる。

• 詳細ビューがマスタビューのウィンドウを共有する – 問題はない。
• 詳細ビューが自身のトップレベルウィンドウを持ち、オブジェクトを共有しない – 問題はない。
• 詳細ビューが独自のトップレベルウィンドウを持つが、マスタビューとオブジェクトを共有する – レースコンディションや、UIのクロススレッディングなどの可能性がある。

最終的にこの問題は、軽量ウィンドウを導入することで解決される予定である。