構成について 結論
これまでのことを考えると、InterfaceとView寄りControllerとModel寄りControllerってあった方が良いですよねという感じなんですけども。
実はInterfaceの方も二種類ありますよね、というところ。
ViewとControllerの方でも軽く触れましたけど、アプリ側/OS側とUser側のInterfaceですね。
これも、完全に別物にすべきだと思ってます。
というのも、UI操作というのがViewに紐付いた形になる場合が多いから。
というか人間の操作というのはどうしても表示部分に対する操作になってくる事情があってViewというのが半Interfaceの性質を持った状態の言語というのも多いです。
さらにいうと、Application/OSに対するInterfaceとUserに対するInterfaceだと当然ながら期待する動作も変わってきます。
OS側なら多少Queueしても確実に動作するなら良いけど、User側なら即座にレスポンスを返さないと場合によってはバグに見えますしね。
そしてUser側は動作のブレもある程度想定して許容しないといけない。
そう考えると、そもそも同じInterfaceと言っても別物なんですよね、と。
もっと言えばOS側は表示が一切なくてもsymbolなりAPIなりが存在してれば良いもののUser側は確実に目に見える必要がある。
目に見えないと操作できないですからね。
特にスマホとかだと。
キーボードとか外部接続の操作用デバイスでもあるなら隠しコマンド的なものもつっこめなくはないですが、いやそれいつの時代のゲームだよということになってくる。
今の時代のアプリケーションは全てのユーザに全ての機能を十全に使いこなさせないといけない訳です。
使うか使わないかは置いておいて。
閑話休題。
まあ、そういういろいろを考えてみると最終的にこういう構成になってくるんじゃないかな、というのを。
Application（Project）
- Interface（OS側）
- ViewController
- View（UserInterface）
- LayoutUtility(Colorとか)
- ModelController
- Model
- ModelUtility(Queue関連とか)
InterfaceからViewControllerに起動画面/ホーム画面表示の通知を送る。
ViewControllerからはInterfaceに表示中のControllerを通知する。
そしてViewに応じた必要なModelControllerを動作させる。
操作はViewからViewControllerに通知されて、動作を確定する。
動作を確定したViewControllerからModelControllerに処理実行を通知して、Modelに実行要求を送る。
ページ遷移する場合には動作中のViewCotrollerから別のViewControllerを初期化してView生成が完了した通知を受け取って画面遷移を実行する。
画面遷移を実行するときにはInterfaceに画面遷移を通知する。
大まかな流れでいうとこんな感じですかね。
特にページ遷移というのは繋がりがあって、基本的に特定ページには特定ページからしか遷移できないだろうという前提で語ってます。
もし全ての画面からModalに表示したい場合だとかはViewControllerのBaseクラスでも作ってそっちに突っ込めば良いかな、と。
ただBase作るなら可能な限りModelとは切り離した方が無難だと思います。
要するに見えにくい処理の一つになってきますからね、Baseの動作って。
まあ、そんな方法で開く画面なんてのは設定画面くらいかな、とは思いますけど。
という形で、今現在私が思うアプリの構成というのはだいたいこういう感じです。
他にExtraとかResourceとかそういうディレクトリはあっても良いと思いますけどね。
というか一定規模を超えてくると普通に入れざるを得ない感じになると思いますけどね。
