デスクトップアプリは、一周回ってWPFでいいじゃんと思った話

aroundthedistance.hatenadiary.jp

これは、2016年になってから前職の内製したWindowsフォームの密結合過ぎるデスクトップアプリを、WPFで刷新している時に書いた記事です。画面がレスポンシブじゃないのを除けば別にWPFやる必要なくねって書いていました。できること同じじゃん、っていう。

が、この時から1年半。もう1回WPF(with Prism)に向き合ってみると、PrismのようなMVVMライブラリを活用できなかった自分がアホやっただけなのでは、という気持ちがドンドン大きくなってきました。

Windowsフォーム→WPFに焼き直すメリットがあまり無いのも事実でしょうが、新規アプリでWindowsフォームを採用するメリットも特に無いわけです。

レイアウトを作るのはWPFの圧勝

改めて思いました。XAMLで画面デザインできることに慣れると、Windowsフォームはだるくてしょうがない。

Windowsフォームは絶対配置が基本ですが、TableLayout的なコントロールを使えば相対配置が可能です。でも、カラムに置くことができるコントロールが１個しか無い。この時点でかなりきつい。Dock/Anchorを活用すれば画面サイズの変更に伴って要素のサイズも変動できるけど、ちまちますべての要素にそれを設定するのはだるすぎた。

XAMLやリソース定義したスタイル設定、強力なGridLayoutやPanelコントロールになれてしまうと、戻れないですね... UI回りのカスタマイズが本当にやりやすくなっている。

MVVM、やっぱりイイ...

１年半前はPrismよくわかんないで素のMVVMやってたけれど、挙動が安定しなかった。Prismを勉強(GitHubのサンプルレポジトリの写経)してみると、思いの外簡単だった。DIでViewModelをインジェクションしてくれるの、すげー楽。ライフサイクルの管理もしなくて良いので、大変助かる。

MVVMで業務系アプリ作っていて、問題となるのはこの辺だと思う。

• キーイベントとCommand対応
• 親画面⇔子画面連携
• 画面遷移
• ViewModelの共存

KeyBindingsって機構があればキーイベントに対してコマンドが実行できる事を知った。これが上手くできれば、コードビハインドを書く必要が全くといいほど無い。残りの３つは、Prismがサポートしてくれる。ViewModelにViewの状態を集約できれば、似たような画面が多い業務系のアプリでは再利用性が高くなるので、MVVMを活用しない手は全く無い。

WindowsフォームもMVVMできるんだろうけど、データバインディングはWPFに軍配が上がる。

フォーカス制御だけはどうしようもない

これはWPF/Windowsフォームどっちも一緒。フォーカスが正しく制御されるUIに慣れてしまった人は、もうマウスクリックには戻りたくはない。そら、そうやね。入力はマウスレスが理想。検索・集計・出力系は、右クリックメニューが活躍するので、マウスレスはそこまで必要とされていない感触。

フォーカス制御する場合は、画面のコンポーネントの名前解決ができないといけないので、Region/Moduleと言った疎結合を実現するPrismの恩恵に預かることは困難だけど、それ以外はすごく楽。画面遷移や遷移時の値の引き継ぎも簡単にできる。Prism、いいっすね～。はじめから使っていればと悔やまれる。

結論: WPF悪くない

WPFはMVVMを簡素化してくれるライブラリを活用すれば、Windowsフォームにはない快適さがあることも事実でした。年内一杯、WPFでデスクトップアプリ作りまーす。

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を差し替えるアーキテクチャが最適化されている香りがする。

github.com
github.com

ViewModelの所もかなり簡単で、規則に沿ってViewModelを作れば勝手にDataContextに該当のViewModelがインジェクションされる。MVVMやるのが簡単になってるね。

Reactiveにどこまできるのか

ReactiveProgrammingを加速するライブラリもあるそうだ。最大の課題は、DataGridViewにバインドしたObservableCollectionの中身のオブジェクトの変更を検知する仕組み。Prismではないと思うから、その辺りに実績のあるライブラリ無いかな。RxJava的な。

Funcition Key 対応

これは絶対言われる気がするので、ちょっと考える。

WindowsFomで作るのめんどくさすぎる

レスポンシブに対応しようとして、TableLayoutなどを使ってみたはいいけど、やっぱり絶対配置文化なのでだるすぎる。TableLayoutのカラムは1つのアイテムしか登録できないと知って、諦めました。ボタンのUIを変えるのもWPFよりすごく面倒。Windowsフォームの弱点をWPFが解決しているのは確かなので、しっかり勉強し直して作り直すぞ〜。

tax_queryの検索が上手くいかない

配列をネストする必要がありました。これやからPHPは(ry

<?php

//アカンやつ
'tax_query' => array(
	'taxonomy' => 'XXXX',
	'field'    => 'slug',
	'terms'    => 'YYYY',
)

//いけるやつ
'tax_query' => array(
	array(
		'taxonomy' => 'XXXX',
		'field'    => 'slug',
		'terms'    => 'YYYY',
	)
)

俺達はビジネスマンだろ？

ダーティー桜塚さん、ええこと言うわ。グラゼニ13巻より。このためにKindle本買った。

ビジネスは浮いている葉っぱをつかむようなもの

ほぼ個人事業なんですけどまがりなりビジネスをやってみて、改めて思います。

基本的にふわふわと浮いていて、つかみどころがない。つかんでみるしか無い。

掴んでみたけども、握ってみたら葉っぱが既に枯れていた。

掴んだと思ったら手からすり抜けて、追いかけて掴みに行ったら事故って怪我した。

大きく見える葉っぱをつかんでみたら、ビリっと破けてえらく小さくなった。

でも、保証されている金を掴む為の努力は、したくなかったんだな〜。

自分でつかみとることに意味がある。

「好きなこと」と「得意なこと」

どっちを仕事にしたほうが良いかって考えると、絶対に「得意なこと」だよなって思う。

得意なことっていうのは、ある作業や成果物を作るのに同じ時間をかけた場合、他人が自分の倍以上の時間がかかったり、半分以下の成果物しか提供できないもの。他人より短い時間でより良い成果が出せるものが、得意なこと。好きかどうかは関係なくて。

その意味で言うと、僕はコードを書くのは好きだけど、得意じゃない。だから仕事としてコードを書くことは辞めてしまった。自分で作りたいモノ以外でコードを書くことはしない。

教えるのは好きじゃないけど得意だし、文章を書くのは好きだし、得意。他人に何かを伝えて説明するのも、得意。

得意なことをやって、まずは会社の足固めをしないよね。

情シスメディア「ジョーシス」が2017年7月末で閉鎖

www.josys.jp

数少ない情シス向けのメディアで、個人的には最大手の１つだったのではと思っていたジョーシスさんが閉鎖。情シス向けのメディアの難しさを思い知らされます。

色々思うことはありますが、中小企業の情シスをWebメディアで集客するなんてことは可能なのかなぁ... 販社が足で稼いでいる所に入っていくのは大変だし...うーん..

夢に進むことも重要だけど、塁に出る努力も大事

note.mu

頂いている色んなお仕事に邁進している内に、自分が最もやりたいと思っていたそう簡単にお金にならない仕事をする時間がなくなってしまった、というもの。フリーランス、あるあるじゃないかな〜。エンジニアだとサービスを開発して云々的なものに近い。

目の前のお仕事をやれば必ず報酬があるのだから、そういったものがドンドン後回しになるのは自然なこと。でも、それだけになってしまうと何のために独立したのかわからない。

まずは塁に出る

独立して間もないころに、最所さんもご存知である我らがビープラウドの治夫さんから頂いた金言をシェアします。

「ござ先輩、ホームラン狙いで見逃し三振してはダメです。まずは塁に出ましょう。チャンスメイクしてくれたら、あとはチームで野球ができます。点が入るかどうかはわからないけど、塁に出ないと何も始まらないですよ。」

野球に例えると何でもよく分かる。この金言は、独立後の僕の行動指針となっています。

頂いている仕事が自分の最もやりたい内容と条件にド真ん中で来る(ホームランボールが来る)ことは、早々ありません。インサイドにズバッとくるようなクロスファイヤーなお話だったり、ボールゾーンに落ちるフォークのような拾うのが難しい話だったりします。

そういった時に「これは自分の待っているボール(条件や内容その他諸々)じゃないんで、手を出さずに見逃し三振」ではなく、塁に出る(次に繋げる)ための努力をやらないのはまずい、ということ。

自分が動くのが難しい話でも、向こうはお話をしてくれたわけだから少なからずお困りになっている。「その話だったらXXさんだったらよく知ってると思うので、ちょっと聞いてみます」とか「XXはやったことないけど、YYという立ち位置なら協力できます」とか。何かしら自分がお役に立てる為の努力をして、進塁打を打つ事を目指す。

もちろん、単なる犠牲じゃ意味がない。点が取れるか(売上になるか)どうかは別問題。でも、打点を上げるのは自分じゃなくても良い。他の人でいい。得点圏までランナーを進めたことが重要で、打線がつながるように努力すれば良い。

最もやりたいことが出来る土壌を作るためにも、お互いに、塁に出る努力をがんばりましょう。