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

http://ufcpp.net/

Posts Tagged ‘WPF

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 , ,

開発者にとってのWindows 8

with 4 comments

Windows 8 上の開発環境について、ようやくきれいに整理された情報が。

といっても、公式アナウンスではなくて、リークした Windows 8 (もちろんβにも満たない開発途上版)の解析結果から得られた知見。

少々私見も込みで、要約:

.NET がもたらしたもの

まず少々歴史の振り返りを。

.NET Framework 登場以前、90年代に置いて Windows 開発がどういう状況だったかというと、「C++ と VB のパリティ(あっちを立てればこっちが立たず的な偶奇性)」という深刻な問題がありました。

Windows の機能を最大限使いたければ Win32 API を使う必要があって、それは VB では難しかった。あと、パフォーマンスの問題もあり、大規模で応答性のよいアプリを書くには C++ しか選択肢がなかった。

一方で、C++ はとにかく大変。特に、データベースアクセスと GUI 開発の効率は VB とは雲泥の差で、業務アプリなんかを書くなら VB 一択だった。

私見でいうと、VB と C++ の間のギャップっていうのも非常に問題だったと思います。「初心者は VB から」という一方で、深くプログラミングに関わるならいずれ「C++ への以降」が必要だった。そして、その間にある深い溝を超えるのは非常に大変。こういうギャップを作るというのは、「初心者から抜けるな」と言っているようなもので。

.NET や C# が、1.0 当初、「VB の生産性と C++ の性能を併せ持つ」として売り出されていたのも、こういうパリティやギャップの問題を解決したいという思いがあります。実際、(6 以前のクラシックな) VB とは違い、.NET は Win32 API へのアクセスが容易になっていて、パフォーマンスもそれなりによく作られています。もちろん、データベースアクセスや GUI 開発の効率の良さはそのままで。

Longhorn

かつて1度、.NET を中心に添えた Windows 作り(コードネーム Longhorn)というのが試みられていたわけですが…

結局ボツったというか、単なるライブラリ提供(.NET Framework 3.0)となり、OS 的には Win32 のままでリリース(Windows Vista)されました。

WPF(Windows Presentation Foundation、.NET 3.0 の一部)もこの一環だったわけです。元々 Win32 API の置き換えを狙っていただけあって、さすがに多機能。ベクター画像ベース、解像度独立、ハードウェア アクセラレーションありな新 GUI API。また、WPF も、取り扱うメディアごとに使うライブラリが異なることに起因するパリティの解消が目的の1つです。

パリティ問題再び

Longhorn がお蔵入りしたことで、再び .NET vs Native なパリティ構造が増していたり。

Windows の API はまず C++ 向けの Native API として提供されます。.NET からの利用(P/Invoke)は出来はするものの、そこそこ面倒な作業が必要です。一方で、.NET 向けのラッパー API の提供を待っていると、機能公開から1テンポ遅れることになります。

WinDiv(Windows 開発部門)とDevDiv(開発ツール部門)があまり仲良しじゃないというのが問題に拍車を掛けているそうで。WinDiv は C++ 推し、DevDiv は .NET 推しで、両者の間にかい離があるとか。

あと、これも個人的な意見ですが、昨今の Web 標準 vs プラットフォーム固有 の対立(HTML5 vs { Java on Android, Objective-C on iOS, Silverlight })の構図、かつての VB vs C++ と同じに見えてしょうがないんですよね。パリティもギャップも大きく。

そして Windows 8

現状(リークしたコードの解析によれば)、Windows 8 の目指すところはどうも、再びこのパリティの解消にあるようです。Longhorn で果たせなかった夢の再開とも。

.NET と Native を同列に扱う仕組み。そして、そこにさらに HTML5 ベースのアプリが加わるという。

  • WinRT (Windows Runtime): Win32 に変わる新 Windows API
    • 20年前の C 言語スタイルではなく、モダンな C++ 向けの設計に置き換わるとか
  • WinMD (WinMetaData): .NET のメタデータ(共通型システムの型情報)部分を、Native でも定義/利用できる
  • DirectUI: (おそらくは WinRT の一部で)WPF/Silverlight 的なプレゼンテーション層を Native 実装
    • 現状の WPF/Silverlight の基礎部分みたいな作りになっているとか
    • そして、XAML ベースで書く(WinMD と合わせて考えると、Native な GUI も XAML ベースで構築することに)
    • DirectUI として提供されるのはおそらく基礎中の基礎な部分のみで、WPF なんかはその上に Managed な層を重ねて再構築されるものと思われる
  • コードネーム Jupiter: どうも、Silverlight 6 にあたるものではないかと。WP7 のマーケットプレース(AppHub)にあたるものを Windows 8 にも導入するはずで、それ用の、Win8 向け Silverlight かな?

Native でも共通型システムにアクセス可能(WinMD)という部分が非常に重要。Native で書かれたライブラリが即座に .NET でも利用可能。逆もまたしかりで、「WPF でないとベクター画像ベース、GPU アクセラレーションありのアプリが書けない」という状況が解消されるということに。

先日物議を醸しだした「Windows 8 では HTML5 + JavaScript でアプリ開発」というやつも、WinMD を介した Native/.NET との相互運用が肝になりそうな予感。

つまるところ、「これからは HTML5 になる」じゃなくて、「これからは Native/.NET/HTML5 の垣根が解消される」が正しかったと。

(もちろんこれは Windows 8 上での話でしかないので、引き続き、Web 標準 vs プラットフォーム固有 の対立はなんら解消されることなく続くと思いますが…)

BUILD を待て

これらはあくまでリークした非正規な情報を元に語られているもので、正式には、「BUILD(今年9月開催)まで待ってくれ」となっているわけです。

ひょっとすると、やってることが Longhorn で果たせなかった夢の再来なので慎重になっているのかもなぁという感じが。最初のビジョン(Longhorn という新 OS、新 API)から徐々に妥協的(WinFX というライブラリ、.NET Framework 3.0 の一部)になっていったのを見て、それなりに皆落胆したもので。

Written by ufcpp

2011年6月24日 at 06:45

カテゴリー: .NET

Tagged with , ,

WPF の {Binding Path=/}

leave a comment »

昨晩、こんな話が:

コレ クションをバインドした時に何が起きているか

WPFのBindingのPathの解決は結構複雑なことをしております。何のせいでそんなに複雑になるかというと、「マスター詳細シナリオ」とか言う概念のせいだったりします。

マスター詳細シナリオ

以下のページ参照:

DataContextに何かコレクションを与えた上で、選択項目の詳細を見たいという場合があります。こういう状況を指して「マスター詳細シナリオ」と呼んでいるようです。

データ バインディングでは、以下のように、Path=/ と書くことで、「コレクションの選択項目を参照しろ」という意味になります。

<ListBox ItemsSource=”{Binding}” IsSynchronizedWithCurrentItem=”True” />
<ContentControl Content=”{Binding Path=/}” />

この例では、ListBox側で選択された行の要素がContentControlに表示されます。

あるいは、DataContext自信ではなく、その子要素のコレクション(例えばItemsプロパティとしましょう)をバインディングする場合には以下のように書きます。

<ListBox
ItemsSource=”{Binding Items}” IsSynchronizedWithCurrentItem=”True” />
<ContentControl Content=”{Binding Path=Items/}” />

さらに、以下のように、Path=/Name と書くことで、選択項目のNameプロパティを参照できます。

<ListBox ItemsSource=”{Binding}” IsSynchronizedWithCurrentItem=”True” />
<ContentControl Content=”{Binding Path=/Name}” />

Path=/ の省略

さて、ここからが問題。BindingのPathは、実は色々と省略が効きます。Bindingマークアップ拡張が内部で「そっちがダメならこっちをバインディング」みたいな頑張り方を結構しています。例えば、以下のように、/Name から / を取ってみましょう。

<ListBox ItemsSource=”{Binding}” IsSynchronizedWithCurrentItem=”True” />
<ContentControl Content=”{Binding Path=Name}” />

この場合にBindingがどういう挙動をするかというと、

  • DataContextに指定したコレクションがNameプロパティを持っている場合、そのNameプロパティをバインディング。
  • なければ、/Name と同じ挙動をする。すなわち、選択項目のNameプロパティをバインディング。

という判定を内部的に行っているようです。

この挙動に悩まされることはそう多くないとは思いますが、例えば、少々恣意的ですが、以下のようなデータをバインディングに使ってしまうと変なことが起こります。

public class SampleData
{
    public string Name { getset; }
    public int X { getset; }

    // Y は、SampleData にだけ持つ。
    // X 
 Name  SampleList に同名のプロパティを作ってしまう。
    public int Y { getset; }
}

//
こんなことわざわざする人がいるかどうかわからないけども、
//
要素の方と同じプロパティを持つ謎のコレクションを作成。
public class SampleList<T> : List<T>
{
    public string Name { getset; }
    public int X { getset; }
}

Bindingマークアップ拡張は内部で、動的な型(GetType() で得られる型)を見てデータ バインディングしているようなので、IListをDataContextに渡したつもりが、その実体の動的な型はNameプロパティを持っていて…ということも、原理的には起こりえます。

実例

ということで、1つ実例を:

実行結果のスクリーンショットを3枚ほど:

結果を見るに、正直なところ、Path=/ の省略はおすすめできないです。省略した場合には、以下のような挙動を起こします。

  • データ テンプレートの暗黙的な適用(リソース中でDataTemplateにDataType属性を付ける)ができない。
  • コレクション自信と要素に同名のプロパティがあったりなかったりするときの挙動が悩ましい(意図しない挙動になりかねない)。

問題

ドキュメント不足

でも、MSDNのサンプルの多くは、この Path=/ を省略していたりします。そのせいで、/ で「選択項目の参照」ができることを知らない人も多かったりします。

その割に、この辺りの挙動(/ を省略した場合、まずコレクション自信を調べて、なければ選択項目を調べる)に関する説明は自分の知る限り見たことがないんですよね。そりゃ、調べればわかりますけども。

.NET文化に合うのか

XAMLは、どうもHTML+JavaScriptとかXPathとかを意識して作られてるんじゃないかと思っているんですが、「知ってると便利だけども知らないとはまる」って感じの「便利な省略」が多いんですよね。かなりルーズ。

.NET文化的には、もっときっちり書きたいって思う人が多いはず(それが静的な型付けを使う意義なわけで)なので、このルーズさはあまりよくないのではないかと。

Written by ufcpp

2011年1月28日 at 19:47

カテゴリー: C#

Tagged with ,

非同期 C# サンプル動画

leave a comment »

動画ブログ。

完成品: ソースコード一式(zip 書庫)

  • WPF プロジェクトを作って、AsyncCtpLibrary.dll を参照しただけの状態からスタート。
  • うちの C# 入門の記事タイトル一覧を取得して、ListBox に表示する簡単なプログラム。
  • 5分弱。
  • キー入力の履歴表示付き(まだちょっとバグありで、括弧の表示がおかしいけども)

参考:

Written by ufcpp

2010年12月12日 at 23:00

カテゴリー: .NET, C#

Tagged with , , ,

第60回codeseek勉強会・第2回日本C#ユーザー会勉強会 開催決定

with 4 comments

ということで、開催日決まりました。

  • 第60回codeseek勉強会・第2回日本C#ユーザー会勉強会
    • テーマ「MVVM パターン(WPF/Silverlight)」
  • 日時:2010年11月6日 (土曜日) 13:00-18:00
  • 場所:マイクロソフト新宿オフィス(OST)5FセミナールームA&B

内容(敬称略、発表順):

スピーカー タイトル 概要
岩永 信之 (@ufcpp) なぜMVVMなのか MVVM パターン(に限らず、いわゆるビューとモデルの疎結合という考え方)などのアーキテクチャ パターンや、データ バインディング・値の変更通知・コマンドなどの仕組みがなぜ必要とされるのか、そもそもGUIアプリケーションに求められている機能要件のレベルから、その背景について説明していきます。
かるあ (@karuakun)

MVVM を使ったアプリケーション開発 -基本編-

MVVMってよく聞くけれど、実際どんなふうに実装すればいいんだろう。
このセッションでは、何も無い状態からMVVMパターンを適用する例と、MVVM Light Toolkitを使った実装例をステップ&ステップで解説していきます。

尾上 雅則 (@ugaya40) ViewModelからViewへのメッセージング手法

MVVMでの実装を行っていると、ダイアログはどうするのか、画面遷移はどうするのかといった問題にあたりがちです。

解決のために世界中で様々な実装が試みられてきました。様々な手法が編み出されましたが、すたれていった手法は何故すたれていったのか、今主流の手法は何か、何故それが今主流の手法なのか、今後標準的にどういった手法がとられていくのか、MVVMで問題にあたった際は何を基準に解決策を模索すれば良いのかについて説明します。

伊藤 達也 (@TatsuyaIto) T4 によるアプリケーション開発 T4 を使って MVVM パターンによる WPF アプリケーション開発を例に、コードの自動生成のコツとメリットについて考えてみたいと思います。

 

参加を希望される方は、codeseek の申し込み方法に合わせて、以下の内容で僕(連絡手段問いません。メールは ufcpp@live.jp)、または codeseek までご連絡ください。

  • メールタイトル:C# ユーザー会(codeseek 共催)勉強会参加希望
  • 名前(必須):
  • メールアドレス(必須):
  • 住所:
  • ハンドル:
  • 懇親会:参加する/未定/参加しない

いただいた情報はC# ユーザー会/codeseekの活動のためにしか使いません。

いただいた情報を会場にお知らせすることがあります。

登録なしでの参加はできません。

Written by ufcpp

2010年10月19日 at 12:48

extensionmethod.net、Mono 2.8、等々

leave a comment »

Written by ufcpp

2010年10月17日 at 13:07

カテゴリー: .NET

Tagged with , , , ,

C# ユーザー会 第2回(テーマ: MVVM パターン)計画中

leave a comment »

C# ユーザー会 第2回 勉強会に関して、期日も近づいてきたとこですし、そろそろ詳細詰め始めているところだったりします。

  • 候補日
    • 11月6日、11月13日(わんくまと被るので避けたい)、11月27日、10月30日
  • 場所
    • OST(マイクロソフト新宿オフィス)会議室、もしくは、新宿近辺の部屋借りれるお店
  • 予算等
    • OSTの会議室を借りれそうなら無料 + 懇親会まで参加されるなら懇親会費
    • その他どこか借りる場合は店が決まり次第、公開します(おそらく、懇親会込みで3,000円~)
  • テーマ概要:

  • MVVM パターンとは
    • モデルを INotifyPropertyChenged とコマンドを前提としてラッピング
    • View に状態を残さないよう、ViewModel 側に追いやる → テストの切り分け
  • 必要ではあるけども、ViewModel 作るの、定型的な割にコード量が多く、大変
    • 自動生成?
      • T4? コードスニペット利用? DSL Tools?
    • 動的プロキシ?
  • ViewModel から View へのメッセージングはどうすべき?
    • 用途: ナビゲーション、ダイアログボックスの表示、ウィンドウ閉じるなど
    • 方法は?

Written by ufcpp

2010年10月12日 at 08:39