メディア

Windows 10はPCとスマホで同じアプリがなぜ動く？――「UWP」の理想と現実：鈴木淳也の「Windowsフロントライン」（1/4 ページ）

PCとスマホで同一アプリを利用、スマホに外部ディスプレイ＋キーボード＋マウスをつないでデスクトップPC的に作業、外部ストレージにアプリ導入など、ユーザーの利便性を高めるWindows 10世代のアプリ基盤「UWP」は、どのような仕組みなのだろうか？

※本ページはアフィリエイトプログラムによる収益を得ています

Windows 10成功の鍵を握る「UWP」

　「Windows 10」の世界では、PCでもタブレットでもスマートフォンでも、さらにゲーム機の「Xbox One」やヘッドマウントディスプレイの「HoloLens」でも、果てはIoT（Internet of Things）の名称で呼ばれる小型の組み込み機器でも、同一のアプリパッケージが動作する。

　これを「Universal Windows Platform（UWP）」と呼び、ここで動作するアプリ群を「Universal Windowsアプリ」や「UWPアプリ」などの名称で呼んでいる。言うまでもなく、UWPはWindows 10における重要な鍵だが、これはどのような仕組みで成り立っているのだろうか。今回はこの辺りをチェックしていく。

ウィンドウサイズの変更で“ビュー”を切り替える

　UWPでは、画面サイズやハードウェア機能（タッチ機能の有無や接続インタフェースの種類）など、デバイスごとのUIの差異を吸収すべく「Adaptive UX」という概念を導入している。基本的には、以前に掲出した『Windows 10の「ユニバーサルアプリ」でWindowsストアは巻き返すか？』という記事の内容に沿っているので、併せてご覧いただきたい。

　Adaptive UXがどういうものかは、端的な例があるので、まずはスクリーンショットを参照してほしい。

同じアプリ「Sports」のウィンドウを拡大していったところ。同じコンテンツだが、表示方法が変化していく様子が分かる

　これらはWindows 10のデスクトップ上でアプリのウィンドウをリサイズした様子だ。コンテンツの内容はまったく一緒ながら、リサイズしただけで表示方法が大きく変わっている。これがデバイスやスクリーンサイズごとのUIの最適化である「Adaptive UX」だ。3枚の画像で上が状態が「スマートフォン向け」の画面だとすれば、中央は複数ウィンドウを同時表示した場合の「中サイズ」、下はフルスクリーンの「大サイズ」だと考えるといいだろう。

　つまり、Adaptive UXにおけるデバイスごとのUI最適化方法の1つは、ウィンドウサイズによって表示方法を適時変更していくことにポイントがある。言い換えれば、ウィンドウサイズが、このUIを“切り替える”ための「トリガー」となっているのだ。具体的には、「ウィンドウの幅」に応じてあらかじめ用意してある「View（ビュー）」を適時切り替えて最適化が行われている（この切り替えは「ViewStateManager」が行っている）。

　例えば、アプリ開発者はウィンドウの横幅が768ピクセル以内であれば「スマートフォン向けのビュー」が設定され、ウィンドウがそれ以上のサイズになった場合は「デスクトップ向け（あるいは大画面向け）のビュー」に切り替えれるよう設定すればいい。

「ビュー」を切り替える“スイッチ”として、ウィンドウの横幅が一定数値を境にスマートフォンと大画面ディスプレイで2種類のビューを選ぶよう設定しておく

　基本的に、スマートフォンの場合は後述の「Continuum（コンティニューム）」を使わない限りは画面サイズが不変のため、ウィンドウのリサイズによるビューの切り替えは発生しない。

　ただし、画面を傾けて縦画面から横画面モードへと移行した場合には「ウィンドウサイズ変更のトリガー」が発生し、もし横画面モード向けのビューが存在する場合には、ビューの切り替えが行われる。PCでもスマートフォンでもタブレットでも、画面のUI管理の仕組みは一緒で、単に「最適化されたビュー」が用意されているかが重要というわけだ。

　Windows 10ではWindows 8.1におけるユニバーサルアプリの時代とは異なり、UIに利用されるコントロール部品や基本的なUIテンプレートなどがすべて共通化されている。重要なのは、画面サイズや環境（タッチ対応かどうか）によってスムーズにUIを切り替える仕組みだ。

　例えば下の2枚の画像が典型的だが、複数ペインに分割されたコンテンツを「％」の比率でリサイズしていった場合、あるサイズまでは問題ないが、小さくしすぎることで可読性が損なわれてしまう。そこで、あるサイズ以下に到達した段階でペイン（部品）の配置を変更し、可読性を可能な限り損なわないようにする。

画面のペイン分割比率を「％」で指定しておくことで、ウィンドウをリサイズしてもスムーズに画面が変化するようになる

ただし、リサイズの幅によっては画面がかえって見にくくなるため、このタイミングで部品要素を組み替えた「別のビュー」を用意しておいて、適時切り替えることで対応する

　このような工夫を施すことで、スマートフォンの狭い画面でも必要な要素を詰め込みつつ、操作感がそれほど悪くないUWPアプリや、あるいは大画面表示であっても隙間が多すぎず、かつ画面操作における指やマウスカーソルの移動量がそれほどなくても必要な操作が行えるUWPアプリが、共通のパッケージで配信可能となる。

　悩みどころは、どういったUIの表示方式を選択するかだが、UWPにおける基本的な画面パターンとしてMicrosoftでは5種類を提案している。1つは写真アルバムのように要素をずらっと一覧表示させる「Hub」、2つめは畳まれたメニューを適時展開する「Hamburger」、3つめはWindows Phoneで主に利用されているタブ表示方式に似た「Pivots」、4つめはリスト一覧から詳細表示へと遷移する「Master-Details」、5つめがWebブラウザでおなじみの「Tabs」となる。開発者はアプリの特性に応じて最適な方法を選びつつ、違和感なくスムーズに画面が切り替えられるよう工夫できる。

Microsoftが提案するAdaptive UXにおける5種類の基本UI

「Hamburger」は畳まれているメニューを展開するタイプのUIだが、その名前は画面左上にある「≡」マークの形状に由来する

　「同じコードがどのデバイスでも動く」というと「言うは易し」だが、実際に作る側にとっては「行うは難し」だろう。その理由はシンプルで、本来はデバイスごとに最適化した形でアプリを作成しているにもかかわらず、「すべてで共通して動作するアプリ」を作るとなると、相応の手間がかかるからだ。

　「どのデバイスで動かしてもあまり大差がないようなアプリ」であったり、「デバイスごとの最適化を最小限度にとどめる」ならば話は別だが、実際には開発からテストまでを含め、対応範囲を広げれば広げるほど開発者の負担は増えることになる。もちろんスクラッチからデバイスごとに開発し直すよりははるかに楽だが、「UWPの光と影」ということで、この辺りは留意しておきたい。