numberOfRowsInSectionを呼び出す：heightForRowAtIndexPathから

Question

UITableViewクラスで非常に奇妙で予期しない動作が検出されました。私は私のセクションの最後の表のセルが他のセルと異なる高さである必要があり、私は基本的にこれをやっている：

- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath 
{ 
    if (indexPath.row == [tableView numberOfRowsInSection:indexPath.section] - 1) 
     return 44; 
    else 
     return 88; //double size for all but the last row 
} 

はかなりストレートなようだが、私はそれを実行したとき、私は無限を取得しますループし、クラッシュします。 numberOfRowsInSection:と呼ぶと、データソースのtableView: numberOfRowsInSection:メソッドが呼び出されます。これはテーブルビューのメソッドがデータソース値のキャッシュされたバージョンを返すので理にかなっているので、最初にデータソースから値を取得する必要があります。しかし、それはheightForRowAtIndexPathを呼び出し、indexPath [0、0]をもう一度渡します！そして、これはノンストップです。

私の代わりに（代わりにtableViewの方法の私のデータソースメソッドを呼び出す）

[self tableView:tableView numberOfRowsInSection:indexPath.section] 

を使用して、それを回避することができました。それがなぜこれを行うのか誰もが知っていますか？これは定義された動作ですか？またはAppleのTableViewフレームワークのバグ？

Answer 1

問題は、UITableViewがデータソースにデータの入力を要求していて、それがデータに依存しているということです。はキャッシュされていません。

あなたは、AppleがそのコントロールをベースにしているM-V-Cレイアウトを誤解しています。行の高さに対する答えは、ビュークラスへのコールバックではなく、モデルから来るべきです。これにより、ビュークラスは再帰呼び出しのセットを開始する詳細情報（内部キャッシュを構築するための情報）を要求します。

すべてのデータソースデリゲートメソッドがモデルからのデータを返し、何かをキャッシュしているビューに依存しないことを確認してください。任意のデータソースベースのビューをデバッグすると、UITableViewが何回データを要求するのか驚くでしょう。しかしそれがAppleがコード化した方法です。