[UITableViewController scrollToRowAtIndexPath:atScrollPosition:animated:] の挙動まとめ

UITableViewController の scrollToRowAtIndexPath:atScrollPosition:animated: メソッドは、対象のテーブルビューのセクションにヘッダ・フッタが付いている場合挙動が変化する事がわかったので、ちょっと調査してまとめてみました。具体的には以下のような動きをするようです。

• このメソッドは自分で呼び出すか、またはテーブルビューのセルの中に UITextField のようなフォーカスを取るコントロールを配置して、それが選択されたときに呼び出される
• このメソッドで指定した indexPath の section に Header View or Header Text / Footer View or Footer Text が指定されているとき、このメソッドは選択された indexPath の row だけではなく、それらのヘッダやフッタも同時に表示される位置にスクロールしようとする
• ということであんまり長い Section Header / Section Footer を作ると scrollToRowAtIndexPath:atScrollPosition:animated: の挙動がおかしくなる
• Table View Header / Table View Footer については全然無関係なので長くしても大丈夫

画像にすると以下のような感じになります。

初期状態

section３つ、row３つ、合計９行のtable viewを作って、それぞれにsection header / section footerを追加しました。このテーブルビューを使って実験を行います。

UITableViewScrollPositionTopを指定してスクロール

section0, row0		section0, row1		section0, row2
section1, row0

UITableViewScrollPositionTopを指定すると、sectionの一番上のrowが指定された場合のみ、そのsectionのsection headerの高さを考慮してスクロールするようになります。

UITableViewScrollPositionMiddleを指定してスクロール

section0, row0		section0, row1		section0, row2
section1, row0		section1, row1		section1, row2

UITableViewScrollPositionMiddleの場合は特にsection header / section footer関係なく、中央に選択された行が来るようにスクロールするようです。

UITableViewScrollPositionBottomを指定してスクロール

section0, row0		section0, row1		section0, row2
section1, row0		section1, row1		section1, row2

UITableViewScrollPositionBottomを指定すると、sectionの一番下のrowが指定された場合のみ、そのsectionのsection footerの高さを考慮してスクロールするようになります。

自分流 View Controllerの作り方 その2

その1はこちら

ぼくのかんがえたさいきょうのせっけいです
主に以下の書籍に影響受けまくりであります

Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series (Fowler)) Martin Fowler Addison-Wesley Professional 2002-11-05 by G-Tools

レガシーコード改善ガイド (Object Oriented SELECTION) マイケル・C・フェザーズ ウルシステムズ株式会社 翔泳社 2009-07-14 by G-Tools

---

図を適当に補足
ViewWrapperは既存のすでにあるどうしようもない設計のViewを何とか救いたいときに非常に便利、Wraper / Decoratorパターンを適用してボタンのタップを奪い取ってViewHelperに流すみたいな役目をする
ViewHelperは簡単に言うならUITableViewControllerのdelegate, datasourceだけを担うオブジェクトみたいな感じ。要するにView専用のドメインロジックを書くオブジェクト
Viewの表示を制御するドメインロジックが途方もなく大きくてViewControllerに納めるのが不可能になってしまったときに超便利

Serviceは準ドメインロジックだと思っている、たいていの場合セミシングルトンみたいにする（通信が絡むので複数画面をまたいで使うことがほとんど）
Androidの場合はここ、普通にServiceクラスでいいんじゃないでしょうかね

Managerはドメインロジックというよりもプロセス外へのリソースアクセスを行うためのクラスというイメージ、個人的にはゲートウェイみたいな感じ

• NSFileManager
• NSUserDefaults
• KeychainAccessManager
• InAppPurchaseManager
• APIConnectionManager

Modelはドメインモデルです、ほとんどの場合はCoreDataのNSManagedObject。用がないときでもCoreData使っておけ（超便利）
と思ってましたがCoreDataのモデルは特にN:N関係を正しく扱わないと簡単に問題が発生してしまいますので、安易に採用すると危険かも。

Task, Operationってのは非同期で実行されていく特別なドメインロジックのイメージ。要するにAPI通信みたいなもんです
API通信を複数束ねて使ったりとか並列実行したりとかの制御が絶対必要になるのでそういうときに使う via @monjudoh

// MyTaskが終わったらMySuperTaskを実行して、それが終わったらさらにMySuperDuperTaskを連続して実行したい
// 終わったらselfに通知させたい
Task *root = [[[MyTask alloc] init] autorelease];
root.nextTask = [[[MySuperTask alloc] init] autorelease];
root.nextTask.nextTask = [[[MySuperDuperTask alloc] initWithId:100] autorelease];
root.delegate = self;
[root start];

自分流 View Controllerの作り方 その1

その2はこちら

以前勉強会の際に発表した View Controller の作り方のメモをまとめてみました。あくまでメモなので中身はうまくまとまっていませんが、何かのご参考になればと思います。

---

通信が絡んでくると、たいていの人がやりがちな問題（実例）

• API通信のレスポンスを処理するコードがViewControllerの中に入っている
• API通信が3種類必要で、Aを実行したあとにBとCを実行しなければならないとか
• ABCのレスポンスJSONのパースまでViewControllerでやっている
• というかAPIの呼び出しの組み立てだとかURLの指定だとか自体がIBActionの中に入っていたりする

API通信だけじゃなくてIn App Purchaseなどでも同様の事例が見られる

それに対する対応策。そもそもなぜこのような問題が発生するのか？

1. Outletの生成・更新・レイアウトが分離されていない
   • そのため複数回画面が更新されるタイミングが発生するととたんに破綻する
   • 大変よく見かける初心者コードが"drawXXX"という名前のOutletを生成してデータをセットしてframeまでセットして画面に配置するコード
   • Outletを描画コードと勘違いしている。Outletはペンやブラシに相当するものであって、実際に線を書くコードではない
   • この初心者コードでも動く唯一の理由は画面が一回（viewWillAppear時）しか更新されないから
2. 通信という（比較的大きくなりがちな）ドメインロジックがViewControllerに混入している

そこで問題1.に対応するためにViewControllerの中でやる作業を以下のように分割する

• Outletを生成する
  • preload（一度に生成する方法）
  • lazy load（必要になったら生成し、必要でなくなったら捨てる方法）
• Outletのプロパティを更新する
• Outletをレイアウトする

これらはそれぞれ（基本的に）以下のようなUIViewControllerのメソッドが対応する

• loadView
  • Outletをpreloadする場合はコレで全く問題ない。このとき、self.viewとここで作られたOutletの生存期間は等しくなる
  • Outletをlazy loadする場合はOutletを生成するコードと削除するコードを用意しておいて、必要なタイミングで呼び出すとかする
• なし
  • プロパティを更新するために、たとえばupdateOutletsみたいなメソッドを自分で用意してやる
• 各種willRotate...系メソッド
  • willRotateほげほげの中にレイアウトコードを入れておくと自動的に画面の回転にも対応できて超便利
  • 自動的に必要なタイミングで適切に呼び出ししてくれて超便利
  • そういうのが嫌いな人はlayoutOutletsForInterfaceOrientation:みたいなメソッドでも作ればいいんじゃないでしょうか

次に問題2.に対応するためにAPIの呼び出しやファイルアクセスなどはService, Managerなどの層を作ってそちらに任せる
決してViewControllerの中にドメインロジックを混入させないのが大事
→混入するとドメインロジックとビューナビゲーションロジックが混ざって大爆発する
→さらにドメインロジック自身も複雑な通信が必要になると大爆発する

それとは別にイベントを受け取ってViewの状態を制御する大事なお仕事をする必要がある

• ボタンタップしたり
• 画面をタップしたりパンしたり
• スクロールが発生したり
• APIコールが完了したり
• In App Purchaseが完了したり

ここまでがView Controllerのお仕事。決してドメインロジックを混ぜないのがポイント