Silverlight
●最近の仕事
昨年後半から、仕事でSilverlight(2のβからやっていて、もう3が出てしまった)のアプリケーション開発に携わっている。
●役目
役目は、Silverlightで作成する業務アプリケーションのフレームワークを設計・開発することで、業務要件のヒアリングと要件定義も行っている。
今回は業務アプリケーションとはいえ、社外の人に見せながら使うこともあるため、見た目や操作性が重要視され、Windows以外のOSからも利用するということで、FlashとSilverlightが候補だった。
抱えている開発者が.NETに習熟していることで、.NETで開発できるSilverlightが採用された(本当はもっといろいろ比較していた様子)。
●やりがい
仕事をしながらSilverlightのスキルが身に付くため、技術者としてうれしい仕事で、やりがいがある。
以前からの仕事で技術力とパフォーマンスを認めてもらっているからこそ、この仕事を任されたので、期待を裏切らないためにここでもパフォーマンスを出す必要がある。
●要件
要件として大きいのは、なるべくコードを書かないですむようにしたいというものだ。その理由はいくつかある。
技術的に難しい部分を共通部品としてあらかじめ提供し、技術的なリスクを抑えるという目的が1つ。
もう1つは、開発者にあまり自由に作ってもらうと、業務的に残したいログや、絶対に行いたい処理などが漏れてしまう可能性があるということ。また、同じような機能を複数の開発者が作成するという非行率的なことが起こり、プログラムをよけいに書く分だけテストもバグも多くなる。動けばいいということでは、パフォーマンスも心配とのこと。
業務アプリケーションの開発者にとっては楽しくないだろうが、なるべくソースコードを書かないでアプリケーションを開発できるようにする。
例えば、業務ロジックの半分くらいは、専用のツール(フレームワークチームが作成)を使ってXMLを出力し、その定義をフレームワークが読み込んで動作する。そのため、ツールの想定していないようなおかしな設定は行えず、バグも作り込まれない。
また、業務上よく使うコントロールは、共通コントロールとしてかなりの種類を用意する。これは見た目を統一する意味もあり、スタイルの設定ミスなどがないように、開発者はスタイルを設定しないで用意された部品を張り付けることで画面を開発する。
また、こうすることで共通コントロールに処理を埋め込めるようになる。
Silverlightでは、Webサービスの呼び出しが非同期であり、サービスの返り値はイベントハンドラーに渡される。サービスの実行中にも画面の操作ができるが、これが困ることもある。サービスの実行中に画面にあるコントロールを無効化したいこともある。これはいちいち画面単位で行わず、サービス開始時にフレームワークからコントロールを無効化したり、サービス完了時に有効化したりできるように対処する。
また、サービスの実行中に画面を無効化するのであれば、ダイアログでスプラッシュ画面を表示したい。これもフレームワークで行う。
今回は利用者がモバイルPCで無線アクセスすることもあるため、回線が細いことも考慮する必要がある。アセンブリのサイズをなるべく小さくすることや、全体に影響しない一部の変更によって、アセンブリをすべてダウンロードし直すということのないように、アセンブリを分割し、必要に応じてフレームワークがダウンロードして使う。
業務のページや、共通部品、フレームワークは、それぞれ更新頻度が違うので、アセンブリを分けて、更新する必要のあるものだけをダウンロードさせたい。どこか1カ所の変更で、大きなアセンブリをダウンロードさせたくない。
●まとめ
今までやったことは、
- 業務的に必要で、Silverlightに含まれていないコントロールを設計、開発
- Validationの仕組みを設計、開発(WPFにあるValidationRuleがない。それがあっても今回の業務要件は満たせない)
- フレームワークから各UIコントロールを制御する(値の設定/取得、状態の設定)仕組みを設計、開発
- 業務アプリのページとなるユーザーコントロールの基底クラスを設計、開発
- 画面遷移やアセンブリのダウンロード＆動的ローディングなどの共通部品を設計、開発
- コントロールのスタイル統一についてや、コーディング、テストのガイドを作成
実際には設計時に、実現可能性の調査も行っている。
Silverlightは、画面周りはXamlの知識が必要となるが、ロジックに関してはC#やVB.NETのスキルが利用できるため、以前から（ASP.NETやWinFormなどで）ビジネスロジックを.NETで開発している場合には、設計者、開発者の確保がしやすい。
フレームワークの開発では画面よりもロジックを組むことが多いので、特にSilverlightを意識する部分は全体の半分くらいで済んだ印象がある。
●困ったこと
- IME制御不可：半角カナにしたりできない。IME機能をOffにすることはできる
- バグ多し：Tabナビゲーションで特に困る
- OSやブラウザーなどの動作条件が複雑：Windows2000やMacでもテストしなくちゃいけない
- 勝手にバージョンアップされる：SilverlightランタイムがMicrosoftUpdateで自動アップデートされる。SL2でテストしてたのにSL3が出たらそっちでもやらなくちゃ。互換とか言いつつ細かい動きが変わっている。バグフィックスなんだろうけど。
●最後に
Silverlightのテスティングフレームワークが公開されており、かなり高機能だが、分かりやすい解説がないため次回の記事でまとめてみたい。C#の解説は多少あるので、VB.NETで解説する予定。テスティングフレームワークで、機能的にもうひとつ気がきいていないところがあるので、その拡張についてもやっていきたい。