WPF は死んだのか?

list このエントリーをはてなブックマークに追加

というか、Microsoft としては WPF をどうする気なのか?が気になるところです。by #comuplus ですね。表向きとしては、Windows DNA の頃(最初に XAML が発表された頃)と同じで「XAMLを学んでおくと、Windows Phoneでの開発がやりやすくなる」だと思うのですが、日本ではいまだにWindows Phoneが発売されない変な状況と、欧米諸外国の反応をかんがみれば、日本と日本以外のアプローチはかなり違っています…が、求めるところは同じところかな、とは思われるんですがね。

デスクトップでの WPF アプリケーションとしては、提督業も忙しい! を代表として、結構「綺麗な」アプリケーションができることがわかっています。もともと、ぐらばくさんがビデオ操作アプリ(でしたっけ?)の UI に特化していたのもあって「WFP で何が作れるのか?どこまでいけるのか?」の実験的な雰囲気もありました。あの、Visual Studio の光る影を作るところからスタートなハズです。で、Windows フォームでは作りづらかった(Visual Studio の 光る影は、がりがりに Widnows API なんですけど)綺麗な画面が、WPF で手軽に作れるところが最初の売りだったのです。従来の Windows Forms で作ると、テキストボックスの背景に色をつけるとか、コンボボックスのサイズを自由に変更して画像を入れ込むとか、が大変だったのです、DrawItem を使わないといけませんでしたから。コンポーネントを組んで発売したのが、例の旧文化オリエントで、COM の前身の VBX の頃からリッチなコンポーネントを販売していました(実は旧文化オリエントが作っていたのではなくて、イスラエル?だっけ?から買っているコンポーネントです。現在は、インドで作っていますね)。このあたりの、VBX → COM の流れを探ってみると、先の comuplus の話が分かりやすいのですが。そうそう、VBX 自体は、C++ でしか書けなくて、VB のコンポーネントを C++ で書くという言語差がありました。それを OCX とすることで、VB 自体でもコンポーネントを作れるようにしたんですよね。そのあたりが、従来の IUnknown とアパートメントの歴史になります。VB のほうは名前付けですからね。

さて「綺麗な画面」を形作るのは、実は WEB ブラウザで HTML 形式によるアプリケーションが出てきたのと無関係ではありません。当時、HTML で作ったブラウザアプリが画像を使って華やかになってくる、さらに Shockwave, Flash などを使ってアニメーション効果などが入った頃に、かたやデスクトップ環境の Windows フォームアプリは相変わらずの「灰色な画面」が標準的だったのです。一方で、DHTML を使ったアプリを IE 上で動かそうとしたり、あれこれと Web 業界に踏み込んだ Microsoft なのですが、やっぱり Apache に勝てなかった…んですよね。今はどうかわかりませんが、いや、Azure に LAMP 環境を乗せるという形で共存の道を選んでいます。

そのなかで、「統合」という形で、デスクトップの画面を HTML 形式風に扱えるようにしたのが、WPF です。かつ、Sliverlight ですね。この両方とも XAML という書式を扱っているのがミソで、デスクトップ環境でも動く、ブラウザ環境でも動く、ってのが最大のメリットでした。それ以前の UI の構築方式は、

  • VB6.0 のように独自の書式をつかう。
  • VC++ のようにリソースとして埋め込む。
  • tcl/tk のようにコードで構築する。

というスタイルが標準だったのです。そこで、HTMLかつXMLという標準的なフォーマットが生まれ、XLST などの派生ツールができたあたりで(これは死んでるのかな?)、標準フォーマットに XML を使おうといいうスタイルが生まれてきたわけですね。最初の、WPF1.0 や Silverlight が貧弱すぎてイベントまわりがひどかったので、SVG との差別化が難しかったのですが、バックグラウンドに .NET フレームワークと直結させたところに、WPF(XAML)のメリットがあります。

さて、当時「なぜ XAML を学ぶのか?」の質問に対して Microsoft は常に「統合されたときにあらゆるところで XAML が使えるようになるから、学んで損はない」という回答でした。これが、広告的なものだったのか、本音だったのかは定かではありませんが、今となって(非常に遅い登場ではありましたが)、Windows Store アプリと Windows Phone アプリでほぼ共通の XAML が使えるようになったことが、それを示しています。

その中で、MVVM パターンという View と Model の作成パターンの含めて(これは戦略的なものだったのか?少なくと WPF1.0 の頃にはなかったものですし、MVC を広めた後に、MVVM ですから、「幸運」かもしれません)、XAML の価値は MVVM とワンセットになって広がります。

独自形式であった Xcode の xib が storyboard になり XML 形式になって扱いやすくなったり、Android の UI が AXML 形式であったりする(これは単純に XML 形式です)したところから、「UI を XML 形式で分離させる良い」という風潮が広まり、同時に MvvmCross のような MVVM パターンを組み入れたライブラリが、Microsoft 以外にも広まるようになりました。

そうなると、XAML という Microsoft 独自形式ではなくても、XML で扱えば何かと UI が便利である、ことがわかってきます。静的に UI のプロパティは struts や ASP.NET で行われているので、それと同じように、静的にマッピングする方法を XAML が行い、それに storyboard や axml も追随しています。動的ローディングのほうはどうなのか?という話ですが、実は、XAML が発表される以前に、MyXaml で実現されています。と言いますか、もともと XAML は動的ロードになる予定だったのが、いつの頃なのか、静的ロードになったんですよね。ちなみに、Xamarin.Forms は静的ロードですが、(訂正)XAMLは動的ロードされています。Xamarin.Forms もリソースから動的ロードですよね。ただし、イベントのバインドとかも自動で行われる XamlReader を使って読み込まれます。ただ、これに癖があってイベントのバインドとか自動で行ってしまうのでバインド先がないとエラーになっちゃうのです。うまくやれば、HTTP プロトコルでネットからダウンロードして表示ってことも可能です。なので、 自前の Xamarin.Forms のプレビューアは別途動的ロードになっています。考えてみれば、ブラウザで表示される HTML のロードは動的ロードなので、静的に(ビルド時に)マッピングしなければいけない理由はないのです。当時、CPU パワーが遅かったので、初期表示時のロードを避けたのですが、いまとなっては結構なスピードで動きます。

そんな訳で、初期の頃には、WPF は XAML として孤立してた(XAML自体が孤立していた)のですが、今に至ると WPF は XAML の仲間となっています。Windows Store App や Windows Phone 8.1 アプリに XAML が使われると同様に、WPF でも XAML を使えます。それぞれのプラットフォームの違いにより使えるライブラリやコンポーネントの違いはありますが、基本的なところはほとんどかわりませんし、インターフェース自体(状況依存プロパティやイベントの作り)は変わらないので、UI ライブラリを移植するのはそれほど難しい作業ではありません(DirectX 絡みのところは大変でしょうが)。

というわけで、UI を XML 形式で作る、そして MVVM パターンを使ってプロパティとイベントを連結させる(ここの分離は Rx を使っても同じ、あるいは直接コードビハイドでも同じ)パターンとしては、

  • Windows Store App を XAML で書く。
  • Windows Phone 8.1 アプリを XAML で書く。
  • Xcode で iPhone/iPad アプリを Storyboard で書く。
  • Android で axml で書く。
  • Xamarin.iOS/Android で、storyboard, axml で書く。
  • Xamarin.Forms で、Xamarin製XAMLで書く。
  • WPF で XAML で書く。
  • Siverlight を XAML で書く。

という広がりまでできてます。そういう中で、Windows デスクトップアプリとして WPF を使った書くこと(書いておくこと)は、他のプラットフォームの移植しやすいという利点があります。惜しむらくは、このなかに Linux が含まれていないことと、ブラウザ環境が含まれていないことですよね。本来は Silverlight がそれを担っていたのですが、およそ死んでいます。XAML → HTML コンバータ、あるいは XAML を解釈するスタイルで、ブラウザのほうに XAML 形式を持っていければ(MVVM パターンも込みで)結構いいところまでいけるんじゃないんですかね?と期待はしているのですが → http://xaml.jp/

カテゴリー: 雑談 パーマリンク

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*