SilverlightでのXMLシリアライズ

どうもJudaです。

dobon.net

かずきのBlogさん

MSDN　＋ MSDNライブラリ

waりとnaはてな日記

すまないが、XMLの書き出し、読み込みをもうちょっと簡単にしたい。

System.Runtime.Serialization.DataContractSerializer

をつかえば、なんとかなる。というか、なんとかできる。

でも正しい使い方なのかわからない。

とりあえずSilverlightでXMLを読み書きするときには、便利なクラス。

というか、XMLの解析をガチでやらせようと思うと、めんどくさくてくさくて、仕方がないです。

ありがとう、XMLの簡単な読み書き機能を作ってくれた開発者の方。

それにしてもXMLにある潜在的なセキュリティーホールとか怖いなぁ。まぁ、全ての入力はすべからく怖いのか。

Silverlightとインターフェイスの話

どうもJudaです。
XAMLの技術とInterfaceの親和性についての話。
XAMLで記述して、事前にデータバインディングのターゲットを固定させて、そこへのアクセスを確率できるようなInterfaceを公開することは有益なのだろうかと言う問から端を発しました。
試作段階に置いてXAMLで表示したいものと表示の形式がある程度固まると、そのバックエンドとなる部分で調整になると思います。その時に、もっとも合致する機能はInterfaceではないのかという思いつきですが、そこそこ有益だと思います。
Interfaceなら実装を保証させるので、それによってバインディングエラーを減らすことができます。ここで注意したいのは、XAMLのほうでTwoWayを採用するなら、Interfaceに必ずSetterを書いておく方が混乱が少ないのですが、それ以外のOneTime、OneWayの場合には、それはInterfaceで規約するのではなく、実装側の裁量に任せる方がいいとおもう。また、OneWay、TwoWayの場合にはINotifyPropertyChangedの継承が実装側で最終的に必要になるので、それも検討しておきたい。
別の話にはなるが、INotifyPropertyChangedでプロパティの変更を検知する処理を組み込んで、Setterなりを修正するのだけれども、この場合には、自作でSnippet、もしくはマクロを組むことが有効であると思う。大半のコードが同一になるので、これをおすすめしたい。しかしながら、簡易でPropertyを書いた場合、つまり　get;set;のプロパティへの変更検知機能の追加はめんどくさい。なんとかならないのかと思っている。
話は戻るが、Interfaceの基本的な考え方とXAMLでのバインディングの記述の間にある程度の親和性があり、これを再利用出来る形で提供すると面白いのではないかと思う。しかしこれでは何が問題になるってくるのか、まではまだちゃんと確認出来ていない。Interfaceがそういう具体性を求めているのではないとすれば、この考え方はあまり良くないと思うが、個別の開発でフロントエンドとバックエンドを分離して開発するときには、いちいち名称の確認をとらなくてもよくなって、個人的にはいいと考えた。

Silverlightとの戦い

どうもJudaです。
Silverlightと最近は格闘中ですが、面白いです。TemplateやBindingはパワフルで使い出のあるアドバンテージです。これらの機能を使いこなすことでコーディング量を劇的に減らすこともできますし、自分の中のデータとビューの関係性を捉え直す機会もくれます。実に取り組みがいのある技術です。この先には、まだまだ多くの発展技術がいることを考えると、挫けそうですが。
それはそうとSilverlight4RCがきましたが、まだ確認をしていません。それよりなによりVerUpの頻度が多い気がします。それ自体は悪いことではないですが、技術書が出揃わないうちにVerUpされると出版側が手を出しにくくなって、困ります。ただでさえ、少ないのに。
ブログなどもいくつも見ていますが、重要なのは基本的な機能に十分習熟することと、Bindingをコード側からも理解することがかなり重要ですね。特にとっつきづらいのはCanvasとGridの実際的な制約事項。
Canvasは自由配置できるのですが、Grid内に配置しても自由に配置を出来ること。Gridのみの場合には、自由配置が全くできないので、XAML側での構造の構築には気を使わなければなりません。あとはDrag&Drop機能を使おうと思うときには、構造をよくよく見れば明白ですが、ListBotのListBoxItemはListBoxの外ではそのまま使えないので、取り出したあとなんらかのコンテナを必要とする点や、データ自体の受け渡しのみならば、別のItemSoruceをもつものとも融通がきくことなど。
実際にコードを触らないとあまりに些末で考えなければならないことが多いです。

SilverLightの特徴まとめ

どうもJudaです。

SilverLightのどういう点が特徴的であるのか、ちょっとまとめる。

• XAML（XMLの拡張）でUIを記述する。
• C#、VBもしくはJavaScript、Iron Python、Iron Rubyでロジックを記述する。
• デザインとロジックを分離できる。
• 動画再生にAdv.がある。
• 疑似３DやエフェクトをSilverLight3からサポート。
• WPFのサブセットという位置づけであるので、Desktop Applicationとしても使える。
• DeepZoomやPhotoSynthいう機能が他のRIAとは異なる。

DeepZoomはこちらで確認できる。

Photosynthはこちらで確認できる。

マルチメディア系のアプリケーションをつくるのにはいろいろ楽しい感じになっている。

SilverLightことはじめ

どうもJudaです。

とりあえずSilverLightのことはじめ。

VisualStudio2008で始めるには、とりあえずSP１が当たっていること、.net Framework3.5がはいっていること。これらはWindowsのDownloadページで手にいれることができるのでこれを用意します。Visual Studio 2008 Service Pack 1 および .NET Framework 3.5 Service Pack 1

つぎにVisualStudio上でSilverLightを快適に開発するために、SilverLight Toolをいれる。Visual Studio 2008 SP1 用 MicrosoftR Silverlight（TM） 3 Tools

ほかにも便利なToolなどが存在するが、それらはCodePlexで探せばよい。

たぶん開始してProject作成をしてすぐに文字列を表示したいと思う。その際に注意がある。XAMLファイルの編集は癖があるので、注意。文字列はTextBlockを使う。ここにしか文字を書き込めない。Buttonにすらだ。つまりLabel的なものの動作はこれが請け負っている。これだけわかればあまりイライラせずに開始できるとおもう。この落とし穴に関しては解説サイトでもなんかスルーされている気がする。

開始して30分で気がつく落とし穴はそれぐらい。

WPFって？

どうもJudaです。

今さらですが、
Windows® Presentation Foundation - Microsoft
Windows Presentation Foundation - Wiki
まぁSliverLightの基礎的なフレームワークなんですけど、
これは既存のWindowsのFrameworkから脱却する目的で開発されているので、MFCとは違いますし、.net Frameworkとも違います。まぁ.netとはとても近いですけどね。
重要なのはこれがまぁ新しいフレームワークで、なおかつDesktopとWebをそれほど区別しない点、UIとLogicの分離をフレームワーク的に強制するところです。

これによってMVCのような粗な結合を作ることが推奨されますし、これによってOOP、テストの導入などがしやすくなると考えられます。しかしこれは、ある程度以上の興味と技術をもっていないと上手くいかないので、学習コストをそれなりに払う必要があると思います。
もっとも悲しい事例をあげるなら、すべてが無理やり結合されている。もしくはそれに近い状態におかれることでしょう。例えるなら果物ナイフで巨木を切り倒すようなことにならないように、適宜道具の吟味とその使用法を確認する必要があります。
WPFはC#とVBから利用できる点も特筆しておきたいです。