++C++; // 未確認飛行 C ブログ

http://ufcpp.net/

Posts Tagged ‘WinRT’

DevSumi2012 OpenJam codeseek – Metro アプリ

with one comment

Developers Summit 2012 にて、codeseek 枠で OpenJam セッションしてきました。

事前告知すっかり忘れていて、当日、直前くらいに twitter でつぶやいた程度、本セッションがたくさんある裏でのセッションだったわけですが。その割に、常時20名超、延べだと40名程度お越しいただけたようです。ありがとうございました。

OpenJam 運営の方の手により、録画＆YouTube 公開されています。

DevSumi2012 OpenJam codeseek – Metro アプリ (1/2)
DevSumi2012 OpenJam codeseek – Metro アプリ (2/2)

スライドも、SkyDrive にアップロードしました。

https://skydrive.live.com/#!/view.aspx?cid=5C622397E11C979D&resid=5C622397E11C979D%214035

ちなみに、「100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊」にも寄稿していたりします。ほんとに名著が並ぶ中、自著（を書くにあたって込めた思いをつづっただけ）だったりしますが…

Written by ufcpp

2012年2月22日 at 11:40

カテゴリー: .NET, C#, Windows

Tagged with , , ,

Windows 8時代のGUI開発/Windows 8時代の.NET

with 2 comments

金曜日に、@ITで以下のような記事が公開されました。

そして、Silverlightを囲む会で以下のような発表をしてきました。

https://r.office.microsoft.com/r/rlidPowerPointEmbed?p1=1&p2=1&p3=SD5C622397E11C979D!3402&p4=&ak=!AFg49XomaSVgLM4&kip=1&authkey=!AFg49XomaSVgLM4

1万字程度の原稿に加えて、25分間のプレゼン発表って、何この学術発表スタイル。

公約数 VS プラットフォーム固有？

さて、お気づきかもしれませんが、実はこの話には落とし穴が一つありまして。公約数VSプラットフォーム固有という構図でお話しましたが、ここはほんとに対立すべきかという点。

原理的には、公約数な.NETがあってもいいと思うし、プラットフォーム固有なHTML5があってもいいはずなんです。それが、政治的な理由で分断されている。

プラットフォーム固有なら、Silverlightはまだまだ現役です。しかし、世の中の多くは公約数で十分というのも事実。

ギャップ問題

問題は、この2者の間に大きなギャップがあることなんですよねぇ。まさに、90年代のVB VS C＋＋の構図そっくり。大半の案件はVBで十分だけど、あるラインを境にVBは破綻する。しかし、ギャップがある故にC＋＋への移行はムリ。

開発者はVBの方が多く、案件も徐々にVBが増える。しかし、製作単価は据え置きで、破たんするラインを越えても同じ安いお値段で使われる。

そんな時代がありました。

製作単価安いから

そこに来て、こんなブログ記事もあるわけですよ。

比較項目の一番下、代理店の利益のところ。「製作単価が安いから」という理由で○が付いています。HTMLの方が開発者の単価安くてお得だと。つまるところ、ギャップを越えれない人を安く使う構図。破たんするライン（Canvas 使って高度なグラフィック表現してとか、WebGLを使って3D作ってとか）を超えてもお値段据え置きになりそうな恐怖。

時代はどこまでも繰り返すのか。

繰り返すのか…

かつて、VBを少しC++に寄せてC#を作ったように、HTML5をXAMLに寄せたような世界が来るんですかねぇ。

そしてそれは、標準ベースであり得るのか。

WinRTで、C++や.NETで作ったコンポーネントをJavaScriptから参照できるようにしてあるのは、1つの解決策ではあるんでしょうけども。

Written by ufcpp

2011年12月3日 at 14:06

カテゴリー: .NET, C#

Tagged with , ,

WinRT に関する誤解

with one comment

まあ、ます先に、ダウンロード リンク一覧を

で、やっぱいろいろと誤解されてるなぁ。

【×】 HTML5＋JavaScript で書かなきゃいけないのかな

今現在、.NET のスキルを持っている人が HTML5 で Metro アプリを書くメリットはほとんどないと思います。

逆に、今現在、HTML5 のスキルを持っている人なら、HTML5 で書く。

「両方できるけどしいて言うなら？」と聞かれたなら、まあ…

Anders Hejlsberg の Future directions for C# and Visual Basic で、Anders が、「JavaScript にあってうれしいものは、全部 C# にもあってうれしいよ」みたいなことを言った瞬間、会場が大喝采。

そして、WinRT は非同期 API だらけになります。処理に50ミリ秒以上かかる（可能性のある）ものは、基本的に非同期 API しか提供されないそうです。そのタイミングで、C# 5.0 の async が来る。.NET にだけ強いアドバンテージがあります。

【×】 Metro 版 IE でプラグインが使えないのは Adobe 排除だ

Adobe とマイクロソフト、密にやり取りして、Metro 版 AIR を作ってるんですって。

ブラウザー プラグインの時代は終わった（実際に終わるのはだいぶ先のことだと思いますが）ってことですかねぇ。

デスクトップ版の Silverlgiht も、どんどん Out of Browser 方面で強化されてますし。要は、デプロイが楽な Windows デスクトップ アプリ扱い。

ちなみに、デスクトップ版の IE は今までどおりです。ある日突然ブラウザー プラグインがなくなることはありえないです。

余談になりますけど、Youtube は普通に HTML5 video タグで動画が見えるみたいですねぇ。

【×】 C++/CLI かよ。WinRT は CLR か？

違うよ、全然違うよ。

WinRT はネイティブです。

.NET 側/ JavaScript 側から見て

.NET 側から見ると、普通に .NET のクラスに見えるネイティブです。

今までの P/Invoke とか、COM の ref Type.Missing 地獄がないのがいいところ。

なんかところどころ、規約ベースの暗黙的な型の置き換えやってますねぇ。WinRT 側だと IVector っていうインターフェイスが、.NET 側からは .NET 標準の IList に見えたり。

.NET 側で作ったクラスを C++ や JavaScript 側から使いたければ、いくつかのルール守れとか。ちなみに、ルールは例えば、

  • public なクラスは sealed にしろ
  • public なプロパティ、メソッドなどで使う型は WinRT 上で定義されているもの（と、それに暗黙的に変換できるもの）だけにしろ
  • 構造体使うなら、public なフィールドだけにしろ

等々。

C++/CX

C++ 側、パッと見、C++/CLI に見えるデモ コード、実は C++ Component Extension （C++/CX）っていうらしい。

仕組み的には、ビルド時に標準 C++ なコードを生成するような感じで、WinRT の呼び出しコストはほとんどない（単に仮想関数呼ぶだけというレベル）とか。

TOOL-690: Under the covers with C++ for Metro style apps を参照:

image

ほぼ C++/CLI だけど微妙に“似て非なる”感あるのが嫌すぎるものの、.NET のクラスを呼び出すようなコストがかからない点は素敵。

WPF とはなんだったのか

ずっと WPF やってきた人間からすると、WPF で苦しみもがいて頑張ってたことが、ようやく実を結びそうだなぁという感慨深い気持ちなわけですが。

知らない人から見たら、「また既存技術捨てて新しいもん作るのかよ」にしか見えないのかなぁ。残念。

Windows 8 でしか動かないんだったら WinRT なんて流行るわけないよ

そんないきなりの置き換えを狙ってるわけないし。

各社 HTML5 推しだけど、IE6 がいまだ数％現役なのと一緒で、「WinRT 推しだけど、延々と Win32 が残る」みたいなもんだと思えば。

つくづく、iPhone の良さは、Mac 低迷期に既存のしがらみ捨てて作り直されてるとこだなぁと思う。

Written by ufcpp

2011年9月17日 at 14:54

カテゴリー: .NET, C#

Tagged with ,

Windows 8、WinRT

with one comment

BUILD、まだ基調講演くらいしか見れていませんが、それだけでもなかなかに素敵。

そして、公開されて間もないWindows 8の開発者プレビュー、さっそく使ってみているわけですが。

WinRT

開発者的に気になっていたのは、うわさのWinRT。

コードネームとかじゃなく、正式名称的にもこの名前でよかったわけですが、実物見るとなかなかに楽しそう。

Metroアプリ vs 既存デスクトップ

開発スタイル的には全く別系統でした。いわば、Silverlight と WPF みたいなもの。

  • Metro アプリ
    • タブレット向け、タッチUI
    • たぶん、ARM版で快適に動かそうと思ったらこっち
    • App Storeで配布できるのはこっちだけ
    • WinRTを使って作る（ネイティブ、.NET、JavaScriptから使える）
    • 感覚的に、一番近いのはWindows Phone 7向けSilverlight（が、.NET 4.5相当のクラスいろいろ取り入れた感じ）
  • 既存デスクトップ
    • まんま、今まで通り
    • Win7タブレットを触ったことがある人なら、タッチに向かないことはご存じのとおり
    • OSのかなり低層に触れてない限り、XPとかのアプリもバイナリそのままで動くのではないかと
    • App Storeで配布できない（そもそもARM版で動くの？動くには動くみたいだけど、快適か？過去のアプリがどこまで互換性ある？）
    • .NET Framwork 4.5が出ました
      • WPFも強化されています

WinRTと.NET Core

さて、そもそもWinRTとは

  • Win32の置き換えで、COM（の焼き直し）なネイティブAPI
  • .NETから見ると、普通に単なる.NETのクラス ライブラリに見える（P/Invoke不要）
    • ちなみに、名前空間はWindowsから始まる
  • HTML5＋JavaScriptなMetroアプリからも呼べる（まあ、昔でいうActiveXみたいな状態）
  • クラスやメソッドの設計もかなりきれい。たとえばUI層なら、WPFを再設計した感じ
    • どのクラスがどの名前空間にあるかはかなり再整理されてる
    • たとえば、INotifyPropertyChangedはWindows.UI.Xaml.Data名前空間
  • UIはXAMLで記述
    • C++からもXAMLが使える
    • コピペで動くレベルでかなりSilverlightなXAML
  • サンドボックス化されてて、App Storeに登録するにあたって「このアプリはネットワークを使います」みたいなのが全部申告される

それで、ですよ。問題は、実は .NET Framework が2系統に分かれます。

  • .NET Core: WinRT、つまり、Metroアプリから使える .NET
    • パッと見た感じ、今現在 Portable Library で使える範囲（どこまで一緒かは要検証）
      • async/awaitは使える状態になってる
    • Metroアプリ ＝ .NET Core + WinRT なので、感覚的には非常に Silverlight for WP7 に近い
    • WinRTとの連携のために、メタデータの読み込み部分あたりに手が入ってるっぽい
  • .NET Framework 4.5: デスクトップ版。
    • 要するに、現在の .NET Framework の新バージョン
    • 仮想マシン的には .NET 4 のものと一緒。ライブラリの追加
      • async/awaitのための拡張（Task.GetAwaiterとか）
      • TPL Dataflow 追加
      • その他、WPF, WCF, WF なども色々更新あり

今の、Out-of-browser Silverlight VS WPF な構図とあまり変わらなかったり。

今から備えるMetroアプリ

WPFやSilverlightで、Portable Library使ってモデル書いてれば、かなり低コストで移行可能かと。

Windowsフォーム？てめぇはダメだ。（モデルに関してはそこまでダメでもないけども。）

Portable Libraryを使った開発については以下のスライド参照（Silverlightを囲む会で発表したもの）。

経験的には、コピペまで認めるなら、90％くらいコード共有可能。

これからのXAMLアプリ？

さて、ここからは推測まじり。

WPFとSilverlightとWinRTとWindows Phone 7と。9割方コピペで作れるXAMLファミリーがまた増えました。

まあ、世の中いきなり移行できるものなら幸せですよ。

WinRT は今のところ、Metroアプリ専用、つまり、ターゲットはタッチ操作UI。

（今の開発者プレビューで、「今のままだとマウスで使えた代物じゃねーよ」ってフィードバックが入りまくって、製品版までには、マウスとキーボードでもMetroアプリを快適に使えるようになる可能性も高いですが。）

据え置きPC

当然、現状のPCはマウスとキーボードが前提で、タッチ操作に最適化されたアプリだとかえって使いにくい。

なので、当面、引き続き普通にデスクトップ アプリ（WPF とか、OoB Silverlight とか）を書くことになると思います。そして、WPFとSilverlight、どっちがいいの？という悩みも消えません。両方に対して、引き続き改善が入っています。

とはいえ、Metroアプリがあることによって、タッチ操作な新入力デバイスが流行ってくれるかも。それに、Kinectにも期待。

タブレットPC

Atom搭載なタブレットは、たぶん、Metroアプリもデスクトップ アプリも両方動きます。

ただし、デスクトップ アプリの場合、右クリックがない前提でアプリを書かないと、タブレットでの利用はきつい。マウスでも使えて、タッチでも使えるぎりぎりの妥協案はリボンUIかもしれない（リボン化された Explorer を見ていて）。

ARM版は、ひょっとしたら、Metroオンリーで考えたほうがいいのかな？

タブレットPCからリモート デスクトップ接続

今後、増えていきそうな利用方法として、外出時にはノートPC持たず、タブレットのみ持ち歩き、そのタブレットからリモート デスクトップ接続して仕事ってのが考えられます。

サーバーOSであるWindows Server 8にすらMetro UIが搭載される理由。

こういう利用方法を考えると、「据え置きPCがターゲットだから、マウス前提でいいや」とは言いづらくなると思います。上記のとおり、マウス前提なんだけども、ぎりぎりタッチ操作できるUIを考えなきゃいけないという極めて面倒な事態に…

携帯電話

今回の発表を見て一番不透明（言及なし）なのはこれ。

Metroアプリは、Windows Phone 7アプリを参考に作られてるっぽい雰囲気なので、Windows 8上で現状のWindows Phone 7アプリを動かすのもそんなに苦ではなさそうな。

マイクロソフトの出している求人情報によれば、今、Windows Phone 8 と Windows 8のアプリ開発モデルの統合を研究中だそうで、Windows Phone 8が出るころには本当に統合されるかも。

ちなみに、上記の WinRT の説明のとおり、Windows Phone 7 のアプリから WinRT への移植はかなり簡単だと思います。

Windows 7以前

WinRT、Windows 8の上に載っている形になっているので、Windows 7にも拡張ランタイムとして載せれそうなもの。というか、うわさだと載せる？

Visual Studio 11

で、Visual Studio も開発者プレビューが出たわけですが。

11って数字は内部バージョン番号ですね。2005→8、2008→9、2010→10。なので、次は11。2011年中に出るって意味ではないです。時期はいまだ名言されていないので、2012とも限らず。まあ、大方の予想では2012年の春から夏にかけてだと思われていますが。

VS11単体ダウンロードもできるみたいですね。MSDNサブスクライバー向けにはすでにダウンロード提供されていて、一般にも数日中に公開予定。

Windows 7にもインストール可能です。ただし、この場合はMetroアプリの開発はできないみたいです。WinRTを触ってみたければ、Windows 8でないとダメっぽい。

普通に、次期バージョンのC#（async/await）を試してみたいだけとかならWindows 7へのインストールでいいと思います。

Written by ufcpp

2011年9月15日 at 18:30

カテゴリー: .NET, C#

Tagged with ,