iOSアプリの開発の話題は、ライブラリやツール、APIの使い方に始終しがちなので、ちょっと違った方向から書いてみる試み。
意図的に発散させてみようと思ったら、思った以上にまとまりがないのですが、まあそれはそれで。
私見です。
iOS SDKをよく知る
標準のAPIを呼べば一発のところを、自力でなんとかしようとして死亡みたいなことがありがちです。
API Diffを読む。ドキュメントを読む。ヘッダファイルを読む。
ライブラリも使うだけでなくて、コードを読むと勉強になります
状態の数とスコープを抑える
GUIのアプリケーションは増え続ける状態との戦いです
- 前提を作らない。B画面はA画面から呼び出されているはず、など
- 例えば、Promise系のライブラリやReactiveCocoaを使う
- 成功/失敗/未解決を一つのオブジェクトで表現できる
- UIコンポーネントはアニメーションを意識しなくても雑に使えるようにする
- そんなに頭がよくないので、一度にたくさんのことを考えられません
もっとうまく説明できる人がいるはず
データの流れは一方向に
Viewの状態に依存してViewを更新するなどすると、ある日突然想定外の不具合に遭遇する羽目になります
データの流れが常に一方向であれば、アプリケーションの挙動を変えるとき、変更するべき箇所が明確になる
多少、記述量が多くなっても、データの流れを保ったほうが最終的には楽
コンテキストに依存する処理は呼び出し側に
A画面からC画面を呼んだ場合と、B画面からC画面を呼んだ場合の挙動が異なる時、
C画面にフラグを持たせるのではなくて、delegateで振り分けよう、とかそんな感じのこと
あるいは、タスクが完了した後の処理をカスタマイズするのに、フラグを渡すのではなくてPromiseのチェーンに後の処理を付け加えよう、とかそんな感じ
あれ、すごく当たり前のことを書いていますね
後半はUIの話を書きます
UIコンポーネントを作り込む
例えば、自前のUIコンポーネントなんかは、作り込んでおくと何かと便利です
IBDesignable対応は必須
開発が長くなると、昔作ったコンポーネントの存在を忘れがちなので、UIカタログ的なものを作ると大変便利です
壊しやすく、作り直しやすく
UIコンポーネントを作り込む一方、画面のレイアウトはよく変わる部分なので、
StoryBoard & AutoLayoutでカジュアルに実装する
大きな変更があったら、また作り直すくらいでちょうど良いです
画面を作り直すのが苦にならないくらいに、UIコンポーネントを作り込んでおく
意味のあるViewControllerの階層を保つ
ViewControllerの階層が論理的に破綻していると、実装とデバッグが辛い感じになりがち
ありがちな例。
例えば、ログインが必要なA画面があるとします
A画面を開こうとする
状態1:A画面(データなし)
ログインしていなかったので、ログイン画面を開く
状態2:A画面 > ログイン画面
ログインできたのでログイン画面を閉じてA画面を表示する
状態3:A画面
ログイン画面はA画面の下層というわけではないので、状態2が論理的に破綻していて、
状態3でA画面を正しく表示するのに苦労するというパターンをよく見ます
アプリケーションの状態によって、時にはViewControllerの階層を根元から差し替えることもあります
スタイルガイドとユーティリティー
色とか文字のスタイルなんかは、適当に始めると収拾がつかなくなって大変なので、
プロジェクトが始まるタイミングで、デザイナーを巻き込んでスタイルガイドと、それに対応したユーティリティーを実装しておく
人は易きに流れるので、便利なユーティリティーを作ると、全体として統一感が出るということになります