ようやく具体的な開発のステップに入ってまいりました。
「iOS開発におけるパターンによるオートマティズム」
で、今回読む章は…
第2章【アプリ設計のパターン】
最初の「パターン」は、アプリ設計についてです。
そして、「パターン」の名が示す通り、
使い回せる「型」としての設計のやり方が記してある章です。
なお、具体的なサンプルとして、
RSSリーダーを作成する場合の設計を取り上げています。
2.1 アプリの設計
設計は３つのフェーズに分ける。
・機能設計
・ユーザインタフェース設計
・クラス設計
３つのフェーズは、それぞれ異なる視点を持つ。
・機能設計
→アプリの機能を定義
→全体的な視点
・ユーザインタフェース設計
→画面遷移とレイアウト
→ユーザの視点
・クラス設計
→ソースコード
→プログラマの視点
2.2 機能設計
2.2.1. 機能設計とは
機能設計とは、アプリで何ができるのかを決めること。
その際、機能をできるだけ細かく、具体的に決める。
サンプルであるRSSリーダアプリを例にとって、説明。
基本である「RSSの記事をダウンロードして読む」を取っ掛かりに、
詳細かつ具体的に機能を洗い出し、定義して行く。
RSSとは何なのか？
RSSの記事とは何なのか？
RSSはどうやって入手するのか？
RSSを入手するタイミングはいつか？
…etc.
2.2.2. 技術仕様の調査
・仕様を調べること。
・仕様の選択。
・しんどくても仕様の原典をあたること。
・用語は仕様から。
2.2.3. RSSリーダの機能設計
具体例を元にした、機能設計の内容例。
・仕様の調査と選定。
・用語の定義と整理。
・盛り込む機能のリストアップ。
・各機能の詳細。
・盛り込まない機能も決める。
2.3 ユーザインタフェース設計
2.3.1. ユーザインタフェース設計とは
実際に表示される画面を決め、
それぞれのデザインを行い、
画面間の遷移を決める。
コツは真似ること。
良いアプリのユーザインタフェースをよく観察する。
パクるのではなく、機能的な部分を真似る。
iOSに共通する挙動を裏切らない。
iOS Human Interface Guidlines をよく読む。
独自性は最後。
2.3.2. ペーパープロトタイピング
アプリ画面を紙に描く。
紙に描いた画面を使って、実際の操作をシミュレートする。
上手くつながらない部分があれば直す。
できれば操作は設計者以外が良い。
2.3.3. ユーザインタフェースの設計パターン
２つの基本パターン＋２
１）ツールバー
・画面下部にあるツールバーに機能ボタンを配置。
・機能が充分に絞れている時に使用する。
・ユーザの機能へのアクセスが簡単。
・例：Safari、メールなど。
２）タブ
・画面下部にタブを配置。
・タブごとに画面を切り替えられる。
・タブに占められて、標準のツールバーが使えないので工夫がいる。
・例：iTunes、Youtubeなど。
タブもツールバーもボタンの数は５個まで。
画面遷移は左から右へ、詳細になって行く。（ドリルダウン）
３）モーダルビュー
・ツールバー、タブ、を問わず使える画面。
・通常とは別の「モード」にある画面。
・例：Safariのブックマーク画面など。
・「キャンセル」「完了」など、何らかのケリを付けないと抜けられない。
・２回以上モーダルが続く画面遷移は避ける。
４）ナビゲーションボタンの配置
・画面上部のナビゲーションバーに配置されるボタン。
・基本は左右の端。
・左端は「戻る」ボタンに使われる場合が多い。
・残る右端が自由に使えるボタン。
・機能が足りない場合は、右端のボタンを機能メニューへのアクセスボタンにする。
2.3.4. RSSリーダのユーザインタフェース設計
実際にRSSリーダの各画面をペーパープロトタイピングする。
各ボタンや画面機能に説明書きを書き加える。
画面遷移図を作成する。
2.4 クラス設計
2.4.1. クラス設計とは
ソースコードを実際に書く時の基準。
プログラミングの知識が必須。
アプリの開発期間は、ここの出来次第。
仕様の変更が一番の大敵。
2.4.2. MVCによるクラス設計
まず理解しておくべき内容。
MとVとCの依存関係を理解する。
１）Model は、他のレイヤから独立している。
２）View は、Model に依存し、Controller から独立している。
３）Controller は、Model とView の両方に依存している。
具体的に「依存」とは？
→あるクラスのヘッダファイルをインポートしていれば、そのクラスに依存している。
１）Model は他のクラスのヘッダファイルをインポートしない。
２）View はModel のヘッダファイルをインポートするが、
Controller のヘッダファイルをインポートしない。
３）Controller はModel とView 両方のヘッダファイルをインポートする。
モデルからビューやコントローラに何らかの操作を行いたい場合は、
「通知」と言うテクニックを使う。（第７章で学ぶ）
MVCの依存関係を守ることがクラス設計の最も重要な点。
2.4.3. 命名規則
Object-C には幾つかの慣例的な命名規則があるので、それに準拠すること。
2.4.4. モデルレイヤの設計
クラスの設計はモデルレイヤを基に行う。
→データが決まれば、ビューやコントローラは必然的に決まるから。
クラス分割の基準はどこか？
→データが１対１の関係ならば、同クラス
→データが１対多の関係ならば、別クラス
RSSで言えば、
RSSフィード、RSSドキュメント、チャンネルまでが１つのクラス。
アイテム、コンテンツが１つのクラス。
これらクラスの実装に関する内容は第３章で。
2.4.5. コントローラレイヤの設計
２種類のコントローラ
１）画面コントローラ
・１画面に１コントローラ。
→各画面を制御する。
→画面の種類だけコントローラクラスを用意する。
コントローラクラスは全てUIViewControllerクラスを継承する。
２）アプリコントローラ
・アプリ全体を制御するコントローラ
→アプリ起動時の初期化、終了時の保存処理などを行う。
→アプリに１つだけ。
2.4.6. アプリコントローラのパターン
アプリコントローラクラスの具体的な形。
ソースコードを添えて解説してある。
１）NSObjectを継承する。
２）UIApplicationのデリゲートになる。
３）アプリ起動時にインスタンス化を行う。
４）他のコントローラが参照を取得できるクラスメソッドを用意。
５）初期化と終了の処理はUIApplicationDelegateのメソッドを実装。
アプリコントローラは、プロジェクトを作ったら、真っ先に登録する。
全てのエントリーポイントになるため。
2.4.7. ビューレイヤの設計
基本的にUIViewクラスを継承。
設計のパターン化が難しい。
アプリの仕様によって、画面が大きく変わるから。
例外的にテーブルビューセルはパターン化しやすい。
テーブルビューの詳細は第６章で学ぶ。
【おまけ】
今回は全く余裕なし。
読んだ内容をまとめるので、いっぱい×２でした。
次回から、もうちょっと小分けに読み解いていく予定。
これじゃあ薄くなるばかり。
回数増えちゃうけどね。orz
