Prismに慣れてきた。これがMS標準だったらなぁ・・・
WPFアプリ構築の敷居もグッと下がったと思う。このライブラリがMicrosoft標準でないというのが、WPFの悲劇なのでは。
Prismを使ってWindowsのデスクトップアプリを作っているのですが、だいぶ慣れてきた。かずきさんのレポジトリを見て写経すればまずOK。MVVMのやり方と画面遷移のあり方が書いてあるので、その2つがあれば生きていける。Prismはよく出来ているライブラリですわ。
XAMLが好きになってきた
最初はなんだよこのハイパー拡張HTMLはと思いましたが、XAMLに慣れてしまうとWindowsフォームで画面を作るのは無茶苦茶だるくなりました。テキストで全部が表現されているのは正義だ。似たような画面作るのすごい楽。ViewModelのインスタンスはDIしてくれるのも楽なんだよな〜
画面遷移が便利すぎて感動
Region機能を使わないでPrismでアプリを使うことはありえない。今回、こいつがすごく便利でびっくりしている。
HTMLのコーディングと一緒で、MainWindowにヘッダーとフッターだけは共通化して定義。あとは「Contents」みたいな感じにして、そこだけPrismからユーザーコントロールを当て込む。これだけで生きていけるようだ。
かずきさんのレポジトリにあるように、PrismのUnityBootstraperの機能で画面とViewModelが予め全て初期化された状態でアプリが起動してくれるので、画面遷移した時は遷移前の状態が残る。残ったほうが便利なんだよね、間違いないんだよね。
ダイアログを起動してコールバックをするというのは、IntercationRequestなるものを使えばいける。YES/Noも取れるし、画面を起動する時にその都度パラメーターを与えてバインドさせることもできる。任意の型のパラメーターを受け渡すことができる。
ダイアログではなく、Contentsページの切り替えも簡単にできる。当該画面が画面遷移によって表示される時と、当該画面が遷移によって消える時の両方にコールバック関数を定義することができるし、任意の型のパラメーターの受け渡しもいける。
RegionManagerクラスのインスタンスは、任意のViewModelのプロパティにDIすることができる。親画面のメニューをクリックして画面遷移、データグリッドをEnterひっぱたいて画面遷移の2パターン等が多いと思いますが、この2つは別のViewModelですよね。でも、PrismがDIしてくれることで、同じインスタンスがSingletonで引き回せるため、どのVMからも画面操作が可能。これは便利。
5年ぐらい前のWindowsフォームで作ったシステムのように、PanelにAddControl/RemoveControlしていた原始的なやり方に比べると、近代的で大変すばらしい。
コードビハインドからのVM
DataContextプロパティをDIされたViewModelにキャストすれば、どうとでもなる。
ただ、ほとんど使わない。Commandプロパティにバインドできるし、KeyイベントもInputBindingsを使えばどうとでもバインドできる。コードビハインドを余儀なくされたのは、任意の画面のコンポーネントにフォーカスを移す時。それ以外は殆どCommandをバインドすればいけるんじゃないかな。ViewModelを継承すると、更に便利。イベントは一緒だけど処理が違う(コマンドの中身が違う)という差分だけ実装すれば、生きていける。
DataGridの編集可能カラムで発生するキーイベントについては、コードビハインドで書いた。ViewModelとは関係なく任意のロジックを持っているクラスに処理を投げたかったので。
引き続き頑張ります
まだ5画面ぐらいしか作ってない。本番では60画面ぐらいになる予定なので、重くないかどうかはとても気になっている。でも、Prism+WPFの組み合わせは最高に便利だし、生産性も高い。引き続き頑張るぞい。
デスクトップアプリは、一周回ってWPFでいいじゃんと思った話
aroundthedistance.hatenadiary.jp
これは、2016年になってから前職の内製したWindowsフォームの密結合過ぎるデスクトップアプリを、WPFで刷新している時に書いた記事です。画面がレスポンシブじゃないのを除けば別にWPFやる必要なくねって書いていました。できること同じじゃん、っていう。
が、この時から1年半。もう1回WPF(with Prism)に向き合ってみると、PrismのようなMVVMライブラリを活用できなかった自分がアホやっただけなのでは、という気持ちがドンドン大きくなってきました。
Windowsフォーム→WPFに焼き直すメリットがあまり無いのも事実でしょうが、新規アプリでWindowsフォームを採用するメリットも特に無いわけです。
レイアウトを作るのはWPFの圧勝
改めて思いました。XAMLで画面デザインできることに慣れると、Windowsフォームはだるくてしょうがない。
Windowsフォームは絶対配置が基本ですが、TableLayout的なコントロールを使えば相対配置が可能です。でも、カラムに置くことができるコントロールが1個しか無い。この時点でかなりきつい。Dock/Anchorを活用すれば画面サイズの変更に伴って要素のサイズも変動できるけど、ちまちますべての要素にそれを設定するのはだるすぎた。
XAMLやリソース定義したスタイル設定、強力なGridLayoutやPanelコントロールになれてしまうと、戻れないですね... UI回りのカスタマイズが本当にやりやすくなっている。
MVVM、やっぱりイイ...
1年半前はPrismよくわかんないで素のMVVMやってたけれど、挙動が安定しなかった。Prismを勉強(GitHubのサンプルレポジトリの写経)してみると、思いの外簡単だった。DIでViewModelをインジェクションしてくれるの、すげー楽。ライフサイクルの管理もしなくて良いので、大変助かる。
MVVMで業務系アプリ作っていて、問題となるのはこの辺だと思う。
- キーイベントとCommand対応
- 親画面⇔子画面連携
- 画面遷移
- ViewModelの共存
KeyBindingsって機構があればキーイベントに対してコマンドが実行できる事を知った。これが上手くできれば、コードビハインドを書く必要が全くといいほど無い。残りの3つは、Prismがサポートしてくれる。ViewModelにViewの状態を集約できれば、似たような画面が多い業務系のアプリでは再利用性が高くなるので、MVVMを活用しない手は全く無い。
フォーカス制御だけはどうしようもない
これはWPF/Windowsフォームどっちも一緒。フォーカスが正しく制御されるUIに慣れてしまった人は、もうマウスクリックには戻りたくはない。そら、そうやね。入力はマウスレスが理想。検索・集計・出力系は、右クリックメニューが活躍するので、マウスレスはそこまで必要とされていない感触。
フォーカス制御する場合は、画面のコンポーネントの名前解決ができないといけないので、Region/Moduleと言った疎結合を実現するPrismの恩恵に預かることは困難だけど、それ以外はすごく楽。画面遷移や遷移時の値の引き継ぎも簡単にできる。Prism、いいっすね~。はじめから使っていればと悔やまれる。
WPF with Prism6に挑戦
販売管理システムのデモを求められており、昔に作ってお蔵入りしたWPFベースのアプリを元にPrismを使って移植手術することにした。Windowsフォームで新しいアプリを作る気になれなかったし、WPFはMVVMと画面遷移がピタッとハマれば作りやすいと感じた。
オレオレ実装で死んだあの日
昔に作ったのは確か2年以上前。オレオレ実装で適当にやったことで、以下の問題が発生した。
- ビューがめっちゃ重い
- Core 2 Duoでカツカツ
- Celeron? 知らない子ですね
- MVVMの挙動が一致しない
- フレームワークを使わなかった
- Viewの状態がリフレッシュされず、変な挙動があった
キーイベントを包括的に拾えるっぽい
オレが不勉強だった。WPFにはビヘイビアという機能があり、UIEement(例えばTextBox)に共通のキーイベント等の処理をフックすることができる。これがあればUIのコンポーネント化が加速でき、同じTextBoxだけど何らかの分類をすることで、ビヘイビアの有無を切り替えることもできると思われる。それだけでいいんです。マジで。
オレオレMVVMはやらない
Prismがよくわからなくて、ViewModelの作り方やコードビハインドからの呼び出し方、画面遷移等の設計がGDGDだった。MVVMもオレオレでやってしまった。今回は画面構成・遷移・MVVMを全てPrismのアーキテクチャに乗っけて作ってみることにする。
Prismのサンプルプロジェクトやかずきさんの自習レポジトリを見てみると、おおよその流れはわかった。クラスライブラリとしてViewをインジェクションできるModuleという機能を使うとDDLで組み込めるらしいので、プレコンパイル済のJSPのような感じで画面のロードが速くなってくれたら嬉しい。動的にViewを差し替えるアーキテクチャが最適化されている香りがする。
ViewModelの所もかなり簡単で、規則に沿ってViewModelを作れば勝手にDataContextに該当のViewModelがインジェクションされる。MVVMやるのが簡単になってるね。
Reactiveにどこまできるのか
ReactiveProgrammingを加速するライブラリもあるそうだ。最大の課題は、DataGridViewにバインドしたObservableCollectionの中身のオブジェクトの変更を検知する仕組み。Prismではないと思うから、その辺りに実績のあるライブラリ無いかな。RxJava的な。
Funcition Key 対応
これは絶対言われる気がするので、ちょっと考える。
tax_queryの検索が上手くいかない
配列をネストする必要がありました。これやからPHPは(ry
<?php //アカンやつ 'tax_query' => array( 'taxonomy' => 'XXXX', 'field' => 'slug', 'terms' => 'YYYY', ) //いけるやつ 'tax_query' => array( array( 'taxonomy' => 'XXXX', 'field' => 'slug', 'terms' => 'YYYY', ) )
「好きなこと」と「得意なこと」
どっちを仕事にしたほうが良いかって考えると、絶対に「得意なこと」だよなって思う。
得意なことっていうのは、ある作業や成果物を作るのに同じ時間をかけた場合、他人が自分の倍以上の時間がかかったり、半分以下の成果物しか提供できないもの。他人より短い時間でより良い成果が出せるものが、得意なこと。好きかどうかは関係なくて。
その意味で言うと、僕はコードを書くのは好きだけど、得意じゃない。だから仕事としてコードを書くことは辞めてしまった。自分で作りたいモノ以外でコードを書くことはしない。
教えるのは好きじゃないけど得意だし、文章を書くのは好きだし、得意。他人に何かを伝えて説明するのも、得意。
得意なことをやって、まずは会社の足固めをしないよね。
情シスメディア「ジョーシス」が2017年7月末で閉鎖
数少ない情シス向けのメディアで、個人的には最大手の1つだったのではと思っていたジョーシスさんが閉鎖。情シス向けのメディアの難しさを思い知らされます。
色々思うことはありますが、中小企業の情シスをWebメディアで集客するなんてことは可能なのかなぁ... 販社が足で稼いでいる所に入っていくのは大変だし...うーん..