さて、２ヶ月毎日更新を目標に掲げて早々。
僅か３日目にして更新が途切れましたが、 *01自分のダメっぷりに涙が出そうです。恥ずかしい。 企画は進めます。
前回、「How to 本の実践レビューを書く」と宣言し、
読み進める本も決めました。
これです。
で、今回読む章は…
目次です。
【目次】
「目次を読む」と言うよりは、
「目次をチェックする」の方が正確かもしれません。
私は、プログラムについての本を買う時に、必ず目次をチェックします。
目次は、その本の輪郭です。
ここに目を通すと、自分にとってその本がどんな位置付けになるか判ります。
先行投資と利回り回収
もし、目次をざっと見て、さっぱり内容や展開がわからない場合。
その本は、自分にはまだ難しい本です。
「難しいから読むな」と言うわけではありません。
自分にはまだ難しいはずの本。
これを背伸びして読むと、将来その領域に手が届きだしたときに、
個々の知識が綺麗に繋がっていくことに驚くでしょう。
これは、読んだ時には飛び石的に入っていただけの知識が、
その後の成長においては、行く先を示す目印となってくれるからです。
将来の成長を見越して、知識の種を仕込む。
つまり先行投資のための本と言えます。
逆に、目次から内容や詳細な展開が想像出来てしまった場合。
その本は、自分には簡単な本です。
これも「簡単すぎるから読む価値は無い」と言うわけではありません。
自分には簡単であったはずの本。
これを改めて読んでみると、以前は無かった理解を得られて驚くはずです。
これは、習得した時には借り物であった知識が、
その後の経験と改めて結び付く事で「自分の知識」になるからです。
過去に得た知識を見直すことで、新たな理解を得る。
つまり利回り回収のための本と言えます。
今回はどっち?
で、これから読み進めていく本、
「iOS開発におけるパターンによるオートマティズム」はどっちか？
ですが、「先行投資７割、利回り回収３割」という感触でした。
先行投資的な本と言うことになりますね。
せっかくなので、普段やらないことを
と、ここまで目次について、ご大層な話をしましたが、
内容が難しめであろうと簡単であろうと、
その後の行動には、全く影響がありませんでした。
「難しいめだなー」「簡単だなー」と判別するだけ。
その後の行動に活かされなかったわけです。 *02「欲しいなー」って思っちゃえば、難しかろうが簡単だろうが買っちゃいますよね。
これまで、簡単だろうが難しかろうが、
関係なく正面から突撃して行くだけだったのですが、
せっかくブログに書くので、いろいろと試してみたくなりました。
目次を見て、知らない単語があればリストアップして調べる
目次はその本の輪郭であると、冒頭に書きました。
つまり、目次をざっと見て内容に検討がつかない見出しがあれば、
その部分は実際に読み進めても理解が大変な場所だと言えます。
目次をざっとチェックして、よく知らない単語があればメモ。
で、後でそれらの単語を調べてみる。
という事をやってみました。
目次を使った予習です。
ちなみに、私が調べた単語は以下になります。
脚注として目次に埋め込んでみました。
調べた単語の横にある脚注数字にカーソルを合わせると、
私がリストしたメモが読めます。 *03こんな感じですね。
「何を言っているの？これ？」なメモばかりですが、
私自身がわかれば良いメモなので、その点はご容赦ください。
目次を見て、わからない単語を調べることで予習をしておく。
と言うのが、今回の趣旨になります。
「iOS開発におけるパターンによるオートマティズム」目次
■目次
本書の目的
パターン *04【パターン】 プログラミングにおいて「パターン」と言えば「デザイン・パターン」を指す場合がほとんどだが、この本での「パターン」はそれとは異なる。詳細は本の中で説かれるので、よく読んで理解すること。 の目次第１章 パターンとはなにか
1.1 パターンによるアプリの作成
1.1.1. フレームワークではないパターン
1.1.2. パターンとは
1.1.3. パターンは汎用化しない
1.1.4. アプリ開発のオートマティズム *05【オートマティスム】 オートマティスム（Automatism、Automatic writing）とは、心理学用語で「自動筆記」「自動記述」という意。あたかも、何か別の存在に憑依されて肉体を支配されているかのように、自分の意識とは無関係に動作を行ってしまう現象などを指す。 [Wikipedia]
1.2 7つのパターン
1.2.1. 7つのパターンの概要
1.2.2. パターンは絶対ではない
1.3 本書の構成第２章 アプリ設計のパターン
2.1 アプリの設計
2.2 機能設計
2.2.1. 機能設計とは
2.2.2. 技術仕様の調査
2.2.3. RSSリーダの機能設計
2.3 ユーザインタフェース設計
2.3.1. ユーザインタフェース設計とは
2.3.2. ペーパープロトタイピング
2.3.3. ユーザインタフェース設計のパターン
2.3.4. RSSリーダのユーザインタフェース設計
2.4 クラス設計
2.4.1. クラス設計とは
2.4.2. MVC *06【Model View Controller（モデル・ビュー・コントローラ; MVC）】 Wikipediaの説明を読んだが、「３層構造システム」との使い分けがよくわからなかった。注意して読むこと。 によるクラス設計
2.4.3. 命名規則
2.4.4. モデルレイヤ *07データを扱う層だが、３層構造システムで言う「データベース層」とは異なる様だ。 の設計
2.4.5. コントローラレイヤ *08ユーザーインターフェイスであるビューとデータを取り扱うモデルを仲介する層。３層構造システムで言う「アプリケーション層」と似ている。 の設計
2.4.6. アプリコントローラ *09「コントローラレイヤがアプリケーション層的な存在だとすると、「アプリコントローラ」と言う名前の項目が別に示される理由があるはず。その点に注意して読むこと。 のパターン
2.4.7. ビューレイヤ *10その名の通り、見た目に関する部分を取り扱う層。３層構造システムで言う「プレゼンテーション層」と同じと考えて良さそうだが、他の２つが３層構造システムの内容を微妙に異なることから考えて、異なる意味を持つ可能性は十分にある。注意。 の設計第３章 モデルのパターン
3.1 モデルの設計
3.1.1. モデルに求められるもの
3.1.2. Core Data *11【Core Data】 モデル層がデータを扱う際のフレームワーク。 を使うか否か
3.2 モデルオブジェクトクラスとモデルマネージャクラス *12モデル層がデータを扱う層である点から推測すると、データクラスとクラス管理クラスか？
3.2.1. 2つのクラス
3.2.2. モデルオブジェクトクラス
3.2.3. モデルマネージャクラス
3.2.4. サンプルで使われるモデルクラス
3.3 モデルオブジェクトクラスのパターン
3.3.1. 情報保持のためのインスタンス変数
3.3.2. アクセッサ
3.3.3. 保存と読み込み
3.3.4. オブジェクトの破棄 *13ガベージコレクションの有無に関わらず、iOSでのメモリ節約を考えれば、オブジェクトスコープの管理はタイトに行った方が良さそう。
3.4 モデルマネージャクラスのパターン
3.4.1. モデルマネージャへの参照
3.4.2. モデルインスタンスの管理
3.4.3. モデルへのアクセス
3.4.4. 保存と読み込み
3.5 Core Dataによるモデルオブジェクトのパターン
3.5.1. Core Dataでのモデルオブジェクトのモデリング
3.5.2. エンティティを表すクラス *14「エンティティ」という単語とモデル層に関する章なので、データベースに関する内容かとも考えられるが、それにしては取り扱いが小さい。
3.6 Core Dataマネージャのパターン
3.6.1. Core Data関連クラスの作成
3.6.2. Core Dataマネージャへの参照
3.6.3. 管理対象オブジェクトの作成
3.6.4. 管理対象オブジェクトの取得
3.6.5. 保存第４章 メモリ管理のパターン
4.1 Cocoa touchのメモリ管理 *15フレームワークであるにも関わらず、わざわざメモリ管理について言及されている。何かクセがあるか？注意。
4.2 メモリ管理のパターン
4.2.1. 参照カウンタによるメモリ管理
4.2.2. インスタンス変数とオーナーシップ
4.2.3. setterのパターン *16「setter」がCocoa touch に用意されたクラスなのか、この本で独自に提唱されるフレームワーク拡張の名前なのか注意。
4.2.4. releaseのパターン *17「release」がCocoa touch に用意されたクラスなのか、この本で独自に提唱されるフレームワーク拡張の名前なのか注意。
4.2.5. deallocのパターン *18「dealloc」がCocoa touch に用意されたクラスなのか、この本で独自に提唱されるフレームワーク拡張の名前なのか注意。第５章 ビューコントローラのパターン
5.1 ビューコントローラとは
5.2 ビューコントローラのライフサイクル
5.2.1. 初期化
5.2.2. nibファイル *19【.nib ファイル（NeXT Interface Builder の略）】Xcodeのリソースエディタで使用される。ボタンやメニュー、ウィンドウなどのGUIコンポーネントを生成する。単なる構造定義ファイルではなく論理層も含んでいるらしい。それはMVC的にはOKなの？ の読み込み
5.2.3. ビューコントローラの表示
5.2.4. ビューコントローラの隠蔽
5.2.5. viewの解放
5.3 ビューコントローラの配置の仕方
5.3.1. ナビゲーションコントローラに入れる
5.3.2. モーダルビューとして表示する
5.3.3. 手動で配置する
5.4 ナビゲーションアイテム
5.4.1. UIBarButtonItem *20その名のとおり、ユーザーインターフェイスにボタンを配置したバーを用意する。 の作成と更新
5.4.2. 編集ボタンとeditingプロパティ
5.4.3. キャンセルと保存
5.5 ツールバー
5.5.1. ツールバーの更新第６章 テーブルのパターン
6.1 テーブルとは *21「テーブル」と言うとデータベースのテーブルを思い浮かべるが、iOS開発における「テーブル」とは、ビューの基本的なスタイルと言って良い。まるまる１章を割いていることからも、かなり気合を入れて取り組む必要がありそう。
6.1.1. テーブルはiOSの中心
6.1.2. UITableViewとUITableViewCell
6.1.3. テーブルのMVC
6.2 セルのパターン
6.2.1. 標準のセル
6.2.2. contentViewとbackgroundView *22「backgroundView」とは、背景に関する内容を取り扱うビュー。 「バックグラウンドで動くビュー」ではないので注意。まあ、そんなことするなら「MVCとか言うな」って話になるわな。
6.2.3. サブビューの作成
6.2.4. コンテンツのためのアクセッサメソッド
6.2.5. サブビューのレイアウト
6.2.6. セルのハイライト／選択
6.3 データソースのパターン
6.3.1. データソースとは
6.3.2. データソースとしてのモデルマネージャクラス
6.4 表示更新のパターン
6.4.1. 表示更新のタイミング
6.4.2. セルの表示更新のパターン
6.4.3. reloadDataを呼ぶべきとき
6.5 編集のパターン
6.5.1. テーブルの編集モード
6.5.2. 行の削除
6.5.3. 行の並べ替え第７章 通知のパターン
7.1 通知とは
7.1.1. オブジェクト間の通知
7.1.2. 3種類の通知
7.2 デリゲート *23【デリゲート(delegate、デレゲート)】 delegateとは「委譲」という意味であり、あるオブジェクトに代わって別のオブジェクトがメッセージの処理を引き受ける。デリゲート先のオブジェクトはどんなオブジェクトでも構わない。デリゲートしないときはnilを指定してもよい。Objective-CはC++とは異なり実行時解決を採用しているので、デリゲート先に指定したオブジェクトが必要なメソッドを持っていなくてもコンパイルエラーにはならず、単に何も実行されないだけである。[Wikipedia] による通知
7.2.1. デリゲートとは
7.2.2. デリゲートメソッドの宣言
7.2.3. デリゲートオブジェクトの宣言
7.2.4. デリゲートメソッドの呼び出し
7.2.5. コントローラ間の通知のパターン
7.3 キー値監視による通知
7.3.1. キー値監視とは
7.3.2. 監視するオブジェクトの登録と解除
7.3.3. 通知の受信
7.3.4. 通知の発生
7.4 NSNotification *24名前から推察するに「通知」用のフレームワーククラスのひとつか？ による通知
7.4.1. NSNotificationとは
7.4.2. 通知の登録と解除
7.4.3. 通知の送信第８章 ネットワークのパターン
8.1 ネットワークプログラミング
8.1.1. ネットワークプログラミングの難しさ
8.1.2. レスポンスパーサとコネクタ
8.2 レスポンスパーサ
8.2.1. NSURLConnectionによる通信
8.2.2. レスポンスパーサのパターン
8.2.3. 非同期通信のためのパターン
8.2.4. 同期通信のためのパターン
8.2.5. XMLパース *25フレームワークにXMLパーサーを持っていると楽なのだが。注意。 のパターン
8.3 コネクタ
8.3.1. コネクタクラスの宣言とネットワークアクセス状況
8.3.2. コネクタの操作
8.3.3. コネクタからの通知
8.3.4. ネットワークパターンのさらなる拡張第９章 iPadへの対応 *26MVC構造の真価が試されそう。
9.1 複数のiOSデバイスへの対応
9.2 iPad版の仕様策定
9.2.1. 機能は同じでユーザインタフェースが異なる
9.2.2. 画面のレイアウト
9.2.3. クラス設計の確認
9.3 iPad用コントローラの実装
9.3.1. メインnibファイル
9.3.2. RSSPadAppControllerの実装 *27わざわざ「実装」と書いてあるところを見ると、本書独自に定義するクラスか？
9.3.3. その他のコントローラの変更
9.3.4. 拡張可能なアーキテクチャ故にあとがき
索 引
【おまけ】 読書メモとi文庫HD/S
結局、これは「読書メモ」ってやつになるのですが、
実はこれまで読書メモってやつをほとんど取ったことがありませんでした。
i文庫HDを使うようになってから、Evernoteに直接メモを取れるようになり、
ようやく読書メモの効果に目覚め始めたところです。
積極的に読書メモを取り始めると、
i文庫HD/Sのメモ機能だと使い辛い面も出てきました。
メモエリアがフロートでないので、
メモを取るときに見たい本文を隠してしまい、それが不便なのです。
これから読み進めていく時もメモは必須になりそうですが、
今のところ「これ！」というやり方には辿り着けていません。
とりあえず、今度 @nagisawks さんにお会いできたら、
メモ機能の強化についてねだってみようと考えています。 *28おっさんに頼まれても聞いてもらえないかもしれませんが。何か良い袖の下ないかな。光蟲99匹とかじゃ駄目かしら。
脚注
| ↩01 | 自分のダメっぷりに涙が出そうです。恥ずかしい。 |
|---|---|
| ↩02 | 「欲しいなー」って思っちゃえば、難しかろうが簡単だろうが買っちゃいますよね。 |
| ↩03 | こんな感じですね。 |
| ↩04 | 【パターン】 プログラミングにおいて「パターン」と言えば「デザイン・パターン」を指す場合がほとんどだが、この本での「パターン」はそれとは異なる。詳細は本の中で説かれるので、よく読んで理解すること。 |
| ↩05 | 【オートマティスム】 オートマティスム（Automatism、Automatic writing）とは、心理学用語で「自動筆記」「自動記述」という意。あたかも、何か別の存在に憑依されて肉体を支配されているかのように、自分の意識とは無関係に動作を行ってしまう現象などを指す。 [Wikipedia] |
| ↩06 | 【Model View Controller（モデル・ビュー・コントローラ; MVC）】 Wikipediaの説明を読んだが、「３層構造システム」との使い分けがよくわからなかった。注意して読むこと。 |
| ↩07 | データを扱う層だが、３層構造システムで言う「データベース層」とは異なる様だ。 |
| ↩08 | ユーザーインターフェイスであるビューとデータを取り扱うモデルを仲介する層。３層構造システムで言う「アプリケーション層」と似ている。 |
| ↩09 | 「コントローラレイヤがアプリケーション層的な存在だとすると、「アプリコントローラ」と言う名前の項目が別に示される理由があるはず。その点に注意して読むこと。 |
| ↩10 | その名の通り、見た目に関する部分を取り扱う層。３層構造システムで言う「プレゼンテーション層」と同じと考えて良さそうだが、他の２つが３層構造システムの内容を微妙に異なることから考えて、異なる意味を持つ可能性は十分にある。注意。 |
| ↩11 | 【Core Data】 モデル層がデータを扱う際のフレームワーク。 |
| ↩12 | モデル層がデータを扱う層である点から推測すると、データクラスとクラス管理クラスか？ |
| ↩13 | ガベージコレクションの有無に関わらず、iOSでのメモリ節約を考えれば、オブジェクトスコープの管理はタイトに行った方が良さそう。 |
| ↩14 | 「エンティティ」という単語とモデル層に関する章なので、データベースに関する内容かとも考えられるが、それにしては取り扱いが小さい。 |
| ↩15 | フレームワークであるにも関わらず、わざわざメモリ管理について言及されている。何かクセがあるか？注意。 |
| ↩16 | 「setter」がCocoa touch に用意されたクラスなのか、この本で独自に提唱されるフレームワーク拡張の名前なのか注意。 |
| ↩17 | 「release」がCocoa touch に用意されたクラスなのか、この本で独自に提唱されるフレームワーク拡張の名前なのか注意。 |
| ↩18 | 「dealloc」がCocoa touch に用意されたクラスなのか、この本で独自に提唱されるフレームワーク拡張の名前なのか注意。 |
| ↩19 | 【.nib ファイル（NeXT Interface Builder の略）】Xcodeのリソースエディタで使用される。ボタンやメニュー、ウィンドウなどのGUIコンポーネントを生成する。単なる構造定義ファイルではなく論理層も含んでいるらしい。それはMVC的にはOKなの？ |
| ↩20 | その名のとおり、ユーザーインターフェイスにボタンを配置したバーを用意する。 |
| ↩21 | 「テーブル」と言うとデータベースのテーブルを思い浮かべるが、iOS開発における「テーブル」とは、ビューの基本的なスタイルと言って良い。まるまる１章を割いていることからも、かなり気合を入れて取り組む必要がありそう。 |
| ↩22 | 「backgroundView」とは、背景に関する内容を取り扱うビュー。 「バックグラウンドで動くビュー」ではないので注意。まあ、そんなことするなら「MVCとか言うな」って話になるわな。 |
| ↩23 | 【デリゲート(delegate、デレゲート)】 delegateとは「委譲」という意味であり、あるオブジェクトに代わって別のオブジェクトがメッセージの処理を引き受ける。デリゲート先のオブジェクトはどんなオブジェクトでも構わない。デリゲートしないときはnilを指定してもよい。Objective-CはC++とは異なり実行時解決を採用しているので、デリゲート先に指定したオブジェクトが必要なメソッドを持っていなくてもコンパイルエラーにはならず、単に何も実行されないだけである。[Wikipedia] |
| ↩24 | 名前から推察するに「通知」用のフレームワーククラスのひとつか？ |
| ↩25 | フレームワークにXMLパーサーを持っていると楽なのだが。注意。 |
| ↩26 | MVC構造の真価が試されそう。 |
| ↩27 | わざわざ「実装」と書いてあるところを見ると、本書独自に定義するクラスか？ |
| ↩28 | おっさんに頼まれても聞いてもらえないかもしれませんが。何か良い袖の下ないかな。光蟲99匹とかじゃ駄目かしら。 |