構成について ModelとController編
例えば処理中かどうかで分岐する時、そのstateってどこで持つのかってその処理を管理してるところでやらないと話にならない訳で。
ということで構成について、第三弾です。
↑の話ですが、これをViewのController側で管理してしまうとページ遷移の必要が出てきた時とかどうするの？ とかいう話になってきます。
その度に必要なデータを次のControllerに渡すの？ と。
それって要するに渡し忘れたらバグりますよね。
そして処理によっては非同期で実行してたりする訳で、そういう作りになってると処理の状態の担保が難しくなっていきますよね、と。（場合によっては解放されたインスタンスにアクセスしに行こうとしてNullPointerとかBAD_ACCESSとかが発生したりしますし）
そんなことするくらいなら、Modelの処理を管理するためのControllerをシングルトンなインスタンスで作ってそっちを参照するようにすれば良い。
そうすればstateの管理をあっちでもこっちでもという感じにする必要がなくなりますしね。
ViewのControllerとは違うModelのControllerが必要……な、場合もありますというお話。
例えば通信処理みたいに普通に動作させても別スレッド管理しないとマズいヤツとか。
かといって複数のプロセスで通信しまくろうとしてもマズいから動作は止めたいという場合とかにそういう作りにすることがよくありますね。
というか、古臭い作りのアプリの動作を後付けで制御するために管理用のシングルトンインスタンス作ったりすることもあったりします。
ただ、それの管理というのをModelで持ってしまうとまた話が変わってくる。
そこを管理する役割ってModelが持つべきじゃないですよね、というところ。
通信するなら通信の実行だけを管理すべきで、通信が成功したか失敗したかをコールバックなりなんなりで通知するだけのクラスにしないといけない。
そのコールバックを受け取ってアラート出したりするのも、だいたいどんな言語でもできることだからその場でやりたくなるけどそれもあまり良くない。
例えばiOS6以前だと複数のアラート表示通知が来ると来た順番でアラートを出す作りになりますけど、iOS8以降だとアラート表示中に出力しようとしたアラートは握りつぶされたりしますからね。
内部的な動作が変わってるからそういう動作の違いが出てくるという話ですが。
ちなみにiOS7ではどっちだったか覚えてません。
とりあえずiOS8向けの動作にしておけばバグらないんで初めからそういう想定で作るんで。
話を戻すとして、つまり場合によっては、というか最近の事情で話すなら一部のOSではアラートの出力をqueueしたりする必要が出てくる。
そのあたりの管理もModelクラスに突っ込むか？ と言われると、仮にModelクラスに突っ込むとしても別処理の別Modelクラスに突っ込んだ方が良いですよね、という感じですけどね。
もっと言うとModelとしてSchedulerクラスでも作ってそこからViewとしてのAlertクラスに投げるのが正しい役割分担だと思う。
なぜかって、他のクラスでもアラートって出すでしょ？ というのが一つ、そもそも処理が違うというのとModelがViewを持つのも良くないという考えもありつつ。
そういう意味では、特に時間がかかる処理だとか中断要求の受け入れが必要な処理とかを作る場合にはControllerが必須なんです、本来は。
という訳で、ModelとControllerについてはだいたい書き終えたことにしつつ続きます。
あと、構成周りは次で最後です。
