Metroアプリ

デモとして作っていたMetroアプリが一応形になったので。

1. Raidar Metro Demo

Windows 8 RP上のVisual Studio 2012 RCで作ったが、もうWindows 8もVisual Studio 2012もRTMが一般の開発者向けに出る直前で、RTMでまた動作に変更がある可能性があるが……。言語はC#とXAML。

機能的にはNAS Herderのモニター機能のサブセットで、ロジック部分はVisual BasicからC#に大体そのまま移植。このメインページと設定ページの構成で、この間のページ遷移は本来スワイプで出すNavigationBarかAppBarを使うべきだが、とりあえずAppBar用のSettingsのアイコンを置いている。

対象のNASを指定する方法はHost NameかIP Addressの選択式。Scanで見つかったNASを表示する部分はGridViewで、唯一Metroらしい見た目。トースト通知はStatusにWarningが出た場合か温度が閾値を上回った場合に出るが、音声設定がうまく行かないのでデフォルト音声のまま。

これらの設定項目は、変更がある度にApplicationData.LocalSettingsに保存するようにしているので、このアプリのサスペンド時には何もしない。

Metro特有の要求の一つが4つのレイアウト（デフォルトの全画面横長のFullScreenLandscape、Snappedになった別のアプリが横に入って幅が狭まったFilled、全画面縦長のFullScreenPortrait、横に寄せたSnapped）への対応だが、とくにSnappedは要素の配置を大きく変える必要がある。

ちなみに、このレイアウト遷移をアニメーションと呼んでいるが、実際にはアニメーションするわけでも何でもなく、ただ配置が切り替わるだけ（XAMLのアニメーション機能で、いきなり最終値に変えるメソッドを待ち時間0で実行）という。

メインページを左側にSnappedにすると、こうなる。右側はデスクトップ。

やっていることは、

• タイトルのアイコンを非表示にする。
• Ping NASのButtonの列は、各要素を入れたGridをStackPanelに入れているが、この配置方向を横にしていたものから縦にし、サイズも合わせて変える。
• Settingsのアイコンを非表示にする。
• StatusのTextBoxの位置を下げる。
• CPUなどの各項目は、各要素を3つに分けて入れたGridをStackPanelに入れているが、これも配置方向を横から縦にし、サイズを変えて位置を下げる。
• WarningのTextBoxのサイズを変えて位置を下げる。
• 一番下のRaw responseのTextBoxを非表示にする。

なお、このページは基本ページ（Basic Page）のテンプレートから作ったもので、タイトルのフォントが小さくなっているのはテンプレートによるもの。また、タイトルのアイコンの位置に、元のページに戻るbackButtonのアイコンが要素として存在する。これは最初のページの場合は実際には表示されないが、不要かといえばそうでもなく、ページ履歴の管理に関係しているようで、削ってしまうとSnapped状態のときにこのページに戻れなくなる。

ついでに、デスクトップの壁紙を見ていて気づいたが、Filled状態になったデスクトップは、アイコンは移動しても壁紙は移動しないらしい。

次にSnapped状態の設定ページ。Snappedになったら自動的にメインページに遷移することも考えたが、一応用意した。

やっていることは、

• Scan NASのButtonの列も、同じくStackPanelの配置方向を横から縦にし、サイズを変える。
• 見つかったNASを表示するGridViewは、実は同じ内容のListViewも要素として存在していて、このGridViewを表示にしてListViewを非表示にしていたものを逆にする。
• Ping Intervalなどの各項目も、同じくStackPanelの配置方向を横から縦にし、サイズと位置を変える。
• 一番下のRaw responseのTextBoxを非表示にする。

このGridViewとListViewを両方持っていて切り替えるという方法は、非効率な気もするが、Grid AppとSplit Appのテンプレートでやっている方法なので。なお、これらの中のGridはItemTemplateでサイズを指定しているが、実際に表示されるサイズは外のGridViewとListViewのサイズにも影響される模様。

以上、このプロジェクトファイルはNAS Herderのプロジェクトサイトに置いてある。ただし、Microsoftの審査は受けてないので開発者ライセンスのあるPCでしか実行できない。そもそも常駐できない監視アプリに何の意味があるのか、という致命的問題があるが……。

2. プロジェクトのテンプレート

アプリを作り始めるのに、どのテンプレートをベースにするのがいいのか、ということを調べるのに時間を食ったので、そのメモ。

新しいプロジェクトをWindows Metro styleで作成するときは、Blank App、Grid App、Split Appのテンプレートから選ぶわけだが、アプリの内容的にGrid AppでもSplit AppでもないとなるとBlank Appになる。ただ、Blank AppにはMetroアプリとして必須のレイアウト切り替え機能なども入ってないので、あまりベースとして使えない。

そこで、プロジェクト作成後に追加できる基本ページ（Basic Page）のテンプレートにはこれらの機能が入っているので、最初のページをこれに差し替える手順。に、プロジェクト作成時に入る、XAMLのテンプレートの大元たるStandardStyles.xamlには後々にBlendで開いたときにエラーを出す問題があるので、これをMSDNのサンプルのものに差し替えることを含めた手順が以下。

1. Visual Studioで、ファイル -> 新規作成 -> プロジェクト -> テンプレート -> Visual C# -> Windows Metro style -> Blank App (XAML) を選び、プロジェクトを作成したら一旦終了。
2. 作成されたプロジェクトフォルダーのCommonフォルダーを開き、StandardStyles.xamlを、MSDNのいずれかのサンプルにある同名ファイルで上書き。
3. Visual Studioでこのプロジェクトを開き、プロジェクト -> 新しい項目の追加 -> Visual C# -> Windows Metro style -> 基本ページ を選び、追加（名前はここではBasicPage1.xamlとする）。
4. App.xamlのコードの表示を開き（C#）、 if (!rootFrame.Navigate(typeof(MainPage))) 中の MainPage を BasicPage1 に修正し、ビルドして最初にBasicPage1が表示されることを確認。（ファイルの差し替えまでしない場合は、ここまで。）
5. ソリューションエクスプローラーで（元の）MainPage.xamlを削除。
6. BasicPage1.xamlのデザイナーの表示を開き（XAML）、 x:Class="[名前空間名].BasicPage1" 中の BasicPage1 を MainPage に修正。
7. 同じくBasicPage1.xamlのコードの表示を開き（C#）、 public sealed partial class BasicPage1 中の BasicPage1 を MainPage に修正し、 public BasicPage1() 中の BasicPage1 も MainPage に修正。
8. ソリューションエクスプローラーでBasicPage1.xamlの名前をMainPage.xamlに変更。

ただ、Visual Studio 2012もRTMで変わるだろうから、この手順もたぶん変わる。

3. よしなしごと

本格的にXAMLを使ったアプリは初めてで、最初は「何かややこしいことしてるな」という印象だったが、慣れてくるとこれはこれで合理的で面白い。スタイルやテンプレートのかけ方は、CSSを多重にかけたウェブページに似ている。

一方で、Metroアプリ作成のガイドラインなど改めて読んでいると、Metroはやはりタブレット向けのUIとの印象を強くした。その辺り、Microsoftの偉い人が話すことと、実際のMetroにはズレがある感じがする。

Metroでは比較的狭いタブレット画面でタッチ操作するために色々なガイドラインがあって、一言でいうと画面が窮屈になりがちだが、そこを（タッチ操作を駆使して）使いやすいUIにデザインすることが求められる。

また、Metroアプリの重要な方針として、「Content not Chrome」がある。つまり、従来のウィンドウの枠部分（Chrome）は表示せず（必要なときだけ出す）、ユーザーを内容（Content）に集中させよ、というものだが、これにはそもそもの前提として窮屈になりがちな画面の有効活用という要求があると思う。

これは見方を変えると、ユーザーに（OSの存在を意識させず）シングルタスクをさせろ、ということでもある。Metroではユーザーが同時に見られるアプリは基本的に1つで、Snappedで他のアプリも出しておけば一応2つになるが、まあシングルタスク＋のUIといえる。

で、従来どおりのPCでは当然にウィンドウを幾つも開いてマルチタスクで使えるわけで（大型化するディスプレイを使えばなおさら）、それをシングルタスク＋で使えと言われても無理がある。例えば、よく例に出る旅行サイトを使うアプリの場合、1つのアプリで見るより、色々な会社の旅行サイトを開いて見比べたり、Google Street Viewで現地の写真を見たり、交通の便を確かめたり、他の人の体験を読んだり、そういうことが同時にできた方が効率がいい。

いや、そんなことは当然で、リラックスしながらタブレットで見られることに価値がある、という言い方もできる。実際、従来はPCでやっていたがタブレットでも可能で、むしろそちらの方が便利という作業はあって、そこはタブレットが伸していくのだと思う。

ただ、そうすると対立軸はデスクトップかMetroかではなく、従来のPCかタブレットかになると思うので、それはつまり、従来のPCではデスクトップを使い、タブレットではMetroを使えばいい、という面白くも何ともない話に落ち着く。一周回って「元々そういう話だったのでは」という地点に戻るというか。

したがって、使う人、使う場面を考えて、タブレットがよければMetroアプリで行き、従来のPCがよければデスクトップアプリで行く、ということでいいのではないか、と改めて思う。