iOSにおけるパターンによるオートマティズム
勉強になりすぎてなかなか読み進めないので、個人的に参考になりそうな部分をかいつまんでまとめていきます。
通知のパターン
- デリゲート
- 委譲元が移譲先の詳細を知らなくてよいことが特長
- 移譲先と委譲元に明確な親子関係がある時に適している
- デリゲートメソッドの第一引数には委譲元オブジェクトを指定するようにするとよい。1つの移譲先で、複数の委譲元からの通知に対応できるため。
- デリゲートはassignにしておくのが望ましい。retainにすると、委譲元が移譲先への参照を持つことになり、循環参照になってしまう。
- retainにしなければならない状況は、そもそもデリゲートを採用すべきでない。たとえば移譲先が委譲元より先に解放されてしまう場合は、互いが独立関係にあるということ、つまり親子関係ではない。
- NSNotification
- 通知元と通知先を結びつけるものは、通知の名前のみ。非常に弱い結びつきを実現するしくみ。
- モデル、ビュー、コントローラなどレイヤを気にすることなく使えるのも特長。
- addObserverは、コントローラであればviewWillAppearで行う。それ以外は、初期化時に行う。
- removeObesrverは、画面から消えるとき(viewWillDisappear)か、deallocで行う
- removeObserverを忘れると、クラッシュする可能性がある。なので安全のため、(viewWillDisappearなどで解除している場合でも)deallocでも解除を行うとよい
ネットワークのパターン
- ネットワークにアクセスすること自体は簡単だが、アプリとして様々なことを考慮する必要が出てくるため、ネットワークプログラミングは難しい
- 本書のおすすめパターンは、「レスポンスパーサ」と「コネクタ」の2種類のクラスを定義するパターン
- レスポンスパーサ
- サーバにリクエストを投げてレスポンスをパースするところまでを行う
- 通信の数だけインスタンスを作成する
- コネクタ
- レスポンスパーサを管理するシングルトンクラス
- コントローラ向けの口となる。アプリにおいて必要な操作をここで行う。
viewの解放
- viewDidUnloadでもアウトレットを解放する必要がある
- アウトレットの解放はrelease以外にnilの代入も必要?(要調査)
あとで読む
- モデルのパターン
- 表示更新のパターン