iPhoneアプリ開発、その(198) 提案、支持ビューのテーブルにも実装

　200回記念アプリは、ようやく説明書の下準備が終わって、明日にはウェブにアップロードできそう。これが終わったらAppleにいよいよ申請。

　テーブルビュー矩形より内容部の矩形の方が大きい場合なら、前回やったようなフッタービューの底辺の座標変数triggerTailは有効なわけですが



　内容部の矩形の方が小さい場合、テーブルビュー矩形は最初からtriggerTailをオーバーしちゃってるんですな。



　これじゃ、いつでも引っ張りだされてる状態が成り立っちゃうわけで…
　この場合は、フッタービューの底辺とではなくテーブルビュー矩形の底辺と比較する必要があるわけです。

　ということはUpdateTriggerクラスのscrollViewDidScrollメソッドのtableTailとtriggerTailを比較する前に、以下のチェックを入れることで対応できるはず。

- (void)scrollViewDidScroll:(UIScrollView *)scrollView {
・
・
if (triggerTail < tableView.bounds.size.height) {
// 全項目の高さがテーブルの高さを下回るので、triggerTailを
// tableView.bounds.size.heightに変更する。
triggerTail = tableView.bounds.size.height;
}
・
if ((tableTail > triggerTail + 20) && (footerOn == NO)) {
・
・
}

　でまあ、これできっちり動くようになったので、DetailViewController、CoDetailViewControllerクラスにも前回と同じ要領でUpdateTriggerインスタンスを実装します。

　機能をUpdateTriggerクラスにまとめたんで、コピペも簡単。

- (void)viewDidLoad {
・
updateTrigger = [[UpdateTrigger alloc] init];
[updateTrigger adapteTrigger:self.tableView];
updateTrigger.delegte = self;
・

　↑こいつと

- (void)scrollViewWillBeginDragging:(UIScrollView *)scrollView {
[updateTrigger scrollViewWillBeginDragging:scrollView];
}
- (void)scrollViewDidScroll:(UIScrollView *)scrollView {
[updateTrigger scrollViewDidScroll:scrollView];
}
- (void)scrollViewDidEndDragging:(UIScrollView *)scrollView willDecelerate:(BOOL)decelerate {
[updateTrigger scrollViewDidEndDragging:scrollView willDecelerate:decelerate];
}

　↑こいつは単純にコピペでOK。

　UpdateTriggerDelegateのupdate: メソッドだけは、更新するデータが違うので別にしなくちゃならない。DetailViewControllerは提案なのでdbに投げるメッセージは提案用の

[db connectForSuggestion:contributeID suggestion:ID forword:NO];

　を使い。CoDetailViewControllerは支持なのでdbに投げるメッセージは支持用の

[db connectForVote:contributeID suggestion:sugestionID vote:ID forword:NO];

　を使うことになる。
　
　ま、こうやるだけで全テーブルに更新機能がついたわけですが、CoDetailViewController側のフッターでまたまた問題発生。


DetailViewControllerはどっちもOK


CoDetailViewControllerのヘッダーはOK


CoDetailViewControllerのフッターは表示された時点で「手を離すと更新します」状態に…

　て、なんんでじゃあああ、直したはずやんけ～と世界の中心で叫んだんですが、冷静に考えるとテーブルビュー矩形より内容部の矩形の方が大きいんで、今回の対応とはまた別の問題らしいんですな。
　結論から言うと、この不具合はUpdateTriggerクラスは無実で、CoDetailViewControllerのUITableViewの作り方に問題がありました。

　遥か昔の銀河のはての話になるけどその(165)で「Interface BuilderではUIView一枚貼っておいて、残りのビューをプログラム上で作成する」という実験をしてたわけね。
　テーブル作るのにXIB使ってないのよ。
　で、XIBだと自動的に設定される親ビューの矩形変更に連動してテーブルの矩形を変更する指定をしてなかった。

　どういう事かというと、viewDidLoadの時点ではテーブルの親viewにタブバーが付いていないので、そこにピッタリとテーブルビューを貼付けていると後でタブバーが追加された時点でテーブルビューの下の部分がタブバーの下に隠されちゃうんですな。



　で、この対応のためにテーブルの親viewの高さはタブバーの表示に合わせて少し縮むようになとるわけで、XIBでテーブルを設定してる場合、この親viewの収縮にあわせてテーブルの高さも変わるように自動的に設定してくれてるんでDetailViewControllerの方は問題がなかったんですな。

　CoDetailViewControllerの実験的にプログラム上で作ったテーブルにはその親viewの矩形変化に連動する（正確にはどう連動するかの）指定がなかったわけです。
　
　結果、タブバーにテーブルが潜り込んでしまってる形になってしまい、



　フッターが画面上に引き出された時点では、十分に引っ張られきった状態になってたわけです。
　これを解決するにはCoDetailViewControllerクラスのviewDidLoadメソッドで作成したUITableViewインスタンスのtviewのプロパティautoresizingMaskにUIViewAutoresizingFlexibleHeightを設定するだけです。

tview.autoresizingMask = UIViewAutoresizingFlexibleHeight;

　こいつが親viewの矩形が変わるさいには、高さを調整して対応してねという指定になるわけですな。
　解決しました。

　ヘッダーフッターの見栄えがいまいちだけど、まあ、習作だからOK牧場。
　

　しかし、これだとスクロールバーがめり込むんだよね。やっぱ、王道のviewDidAppearで、tableViewの高さを調整するのが吉か？
2011.6.16

------------
サンプルプロジェクト：konohana_test22.zip