R・田中一郎さんトコとかおぎらわさんトコとかで言及されているスプラッシュスクリーン。
どんなものなのかはあちらを見て頂くことにして、俺は別の面から問題提起をしてみたい。
そもそも、スプラッシュスクリーンとは何のために表示するものだろうか？
これは、アプリケーションが時間のかかる初期化処理を行う必要があるために、起動してすぐにメインウィンドウを表示できない場合でも、とりあえず起動していることは示すためであると思われる。
では、時間のかかる初期化処理を行うのは誰なのか？
ここに、俺の認識と、Windowsフォームアプリケーションのアーキテクチャのズレがある。
個人的には、フォームとはMVCアーキテクチャのVであり、「見てくれ」を提供するものでしかないという感覚がある。
フォームありきのアプリケーションではないのだ。
フォームはユーザからの入力を受け付けて、裏にあるシステムに何らかの動作を要求するトリガとしても機能する。
だが、それはフォームがマンマシンインターフェイスとしてユーザの要求を仲介するからであり、ユーザの要求がないのに、フォームが能動的に何らかのアクションを起こすということは、基本的にないと思うわけだ。
長々と何を言いたいかと言うと、アプリケーションの初期化処理は、フォームが行うものではないということだ。
Form.Loadイベントでアプリ全体の初期化処理を走らせるような作りは嫌いなんだよ。
さて、じゃあ初期化処理はどこから呼ばれるべきか？ ということになるが、Formでないのなら当然、Main処理からということになる。
フォームの初期表示処理に時間がかかるのなら、フォームのコンストラクタなり何なりでスプラッシュスクリーンを出してもいいだろうが、フォームが表示される時には、既にアプリ全体としての処理は終わっているべきだと思うので、スプラッシュスクリーンはメインフォームが作られる前に出しておくべきだろう。
επιστημηさんトコでは、Programのコンストラクタの中で初期化処理を行っている。
コンストラクタとは、まさにクラスの初期化処理を行う場所であり、Programクラスとはプログラムそのものだとすれば、ここは確かにアプリ全体の初期化処理を行うのに適当な場所だ。
…スプラッシュスクリーンを表示しようとしなければ。
R・田中一郎さんのところで書かれているように、メッセージポンプについて心配をするなら、Applicarion.Runの実行が開始されるまではウィンドウを表示してはならない。
では、Application.Runの実行が開始された後、最初に何か処理を行う契機はどこか？ というと、メインフォームのLoadしかない。
ApplicationContextを引数に取るRunを使っても、憎たらしいことに終了を検出する方法は複数あるくせに、実行開始後にまず呼ばれるメソッドのようなものは無い。
ということは、スプラッシュスクリーンはメインフォームのLoadで出す以外になく、初期化処理も必然的にそこから開始するしかない、ということになってしまう。
Microsoftが考えているWindowsフォームアプリケーションのアーキテクチャとは、その名の通り「Windowsフォーム＝アプリケーション」だとすれば、Loadイベントでアプリの初期化処理をしてもいいのだが、俺的には「Windowsフォーム＝アプリケーション」にはならないのだよ。
偶然にも、επιστημηさんの上記のエントリからリンクされているさらに昔のエントリを見ていたら、R・田中一郎さんも同様のことを考えていることがわかった。
さあ問題だ。ここに書かれているスタートアップルーチンを.NETで書くとどうなる？