iOSアンチパターン

メモリの手動管理

1. 目的:メモリの最適化
 Objective-Cでは、C言語と同様に生成したオブジェクトは手動で管理しなくてはいけません。メモリーリークを回避するために、必ずautoreleaseかreleaseを行わなければいけません。メモリを適切に管理することによって、消費電力を抑えたり、高速化ができる。
 しかし、メモリーリークの危険が発生します。これは必要以上に神経を使う作業です。そのためのテストを大量にしないといけないでしょう。参照数のチェックのためにコードが増えるというのもあります。
2. アンチパターンを用いていい場合
 極限まで拘束したい場合は必要かもしれません。
3. 解決策:ARCを使う
 IOS5からは、コンパイラが自動的にreleaseを挿入してくれるようになったので、メモリを管理したい場合は、自動的にreleaseが挿入される位置を予想してコードを書くのが適切だと思われます。それでも、消費電力を抑えたり、高速化したい場合はC言語で書いたほうがいいかもしれません。

全部Objective-C

1. 目的:UIを生成する
2. アンチパターンを用いていい場合
 動的なUIを生成する場合。ユーザーが自由に配置できたり、常に全く異なるUIに作り変えたり、アニメーションを使うなど。
3. 解決策:Interface Builderを使う
 静的なUIとViewの遷移についてはほぼすべてStoryboardを使って作ることができます。ただ複数人で開発を行う場合コンフリクトが起こりやすいです。作業を分担する、Storyboardを分割する、xibを用いることで回避できる。

とりあえずNSUserDefaults

1. 目的:データを保存したい
 日付ごとにデータを配列で保存するなど。正規表現でしか表現できないようなキーの保存
2. アンチパターンを用いていい場合
 保存する件数がたかだか数件の場合。
3. 解決策:CoreDataを使う
 Databaseの設計を学ぶか、詳しい人に設計してもらいましょう。CoreDataが使いづらい場合は、MagicalRecordを使うか、sqliteを直接叩くという方法もあります。

神ViewController

1. 目的:とにかく実装する
 単純に書いていくと長くなるのは、分かります。ですがViewControllerが100行超えてるのは、レッドサインです。設計し直すのをお勧めします。
2. アンチパターンを用いていい場合
3. 解決策:Classを分ける
 ViewControllerはViewの変更とViewからの通知を処理するためのクラスです。それ以外の処理は他のクラスに任せましょう。
  解決策2:カテゴリを用いる
 Viewの変更については長くなりがちです。Viewの変更部分だけカテゴリで他のクラスに分けることで、見通しが効きやすくなります。

ジャングルライブラリ

1. 目的:ライブラリを管理する
2. アンチパターンを用いていい場合
3. 解決策:CocoaPodsを使う
 自分で作った。ライブラリも管理できる

警告無視

細切れStoryboard

1. 目的:機能ごとにStoryboardを分けたい
 Storyboardごと他のアプリに使いまわしたい場合があります。そのとき、Storyboardを分けることができますが、分け過ぎると大変なことになるので気をつけましょう。
 1.1 ナビゲーションバーとタブバーのviewDidLoadのときに反映されていない
 ナビゲーションバーとタブバーがない状態で、viewが計算されるのでバグの原因になります。viewDidLoadときに動的にviewを追加した場合ずれてしまう可能性があります。あった。
 1.2 遷移の情報が失われる。
 分ければ分けるほど、Storyboardの利点である。遷移の情報が失われます。利点をなくしてまで再利用性を上げれるれません。
2. アンチパターンを用いていい場合
3. 解決策:必要になったときに分ける
 解決策2:xibを使う
 完全に分けてしまえば、viewの再利用性は上がります。遷移の情報がコードを見なければいけませんが、その部分だけ変えれば良いとも言えるでしょう。
 解決策3:分けない
 大体はコピーできるので分けないのもひとつの手だと思います