その2はこちら
以前勉強会の際に発表した View Controller の作り方のメモをまとめてみました。あくまでメモなので中身はうまくまとまっていませんが、何かのご参考になればと思います。
通信が絡んでくると、たいていの人がやりがちな問題（実例）
- API通信のレスポンスを処理するコードがViewControllerの中に入っている
- API通信が3種類必要で、Aを実行したあとにBとCを実行しなければならないとか
- ABCのレスポンスJSONのパースまでViewControllerでやっている
- というかAPIの呼び出しの組み立てだとかURLの指定だとか自体がIBActionの中に入っていたりする
それに対する対応策。そもそもなぜこのような問題が発生するのか？
- Outletの生成・更新・レイアウトが分離されていない
- そのため複数回画面が更新されるタイミングが発生するととたんに破綻する
- 大変よく見かける初心者コードが"drawXXX"という名前のOutletを生成してデータをセットしてframeまでセットして画面に配置するコード
- Outletを描画コードと勘違いしている。Outletはペンやブラシに相当するものであって、実際に線を書くコードではない
- この初心者コードでも動く唯一の理由は画面が一回（viewWillAppear時）しか更新されないから
- 通信という（比較的大きくなりがちな）ドメインロジックがViewControllerに混入している
- Outletを生成する
- preload（一度に生成する方法）
- lazy load（必要になったら生成し、必要でなくなったら捨てる方法）
- Outletのプロパティを更新する
- Outletをレイアウトする
- loadView
- Outletをpreloadする場合はコレで全く問題ない。このとき、self.viewとここで作られたOutletの生存期間は等しくなる
- Outletをlazy loadする場合はOutletを生成するコードと削除するコードを用意しておいて、必要なタイミングで呼び出すとかする
- なし
- プロパティを更新するために、たとえばupdateOutletsみたいなメソッドを自分で用意してやる
- 各種willRotate...系メソッド
- willRotateほげほげの中にレイアウトコードを入れておくと自動的に画面の回転にも対応できて超便利
- 自動的に必要なタイミングで適切に呼び出ししてくれて超便利
- そういうのが嫌いな人はlayoutOutletsForInterfaceOrientation:みたいなメソッドでも作ればいいんじゃないでしょうか
決してViewControllerの中にドメインロジックを混入させないのが大事
→混入するとドメインロジックとビューナビゲーションロジックが混ざって大爆発する
→さらにドメインロジック自身も複雑な通信が必要になると大爆発する
それとは別にイベントを受け取ってViewの状態を制御する大事なお仕事をする必要がある
- ボタンタップしたり
- 画面をタップしたりパンしたり
- スクロールが発生したり
- APIコールが完了したり
- In App Purchaseが完了したり
