Aufruf von numberOfRowsInSection: from heightForRowAtIndexPath

Question

Gerade ein sehr seltsames und unerwartetes Verhalten in der UITableView-Klasse gefunden. Ich brauche die letzte Tabellenzelle in meinem Abschnitt eine unterschiedliche Höhe von den anderen Zellen zu sein, also ich mache im Grunde diese:

- (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 
} 

scheint ziemlich geradlinig, aber wenn ich es laufen lasse, erhalte ich eine unendliche Schleife und es stürzt ab. Ich habe festgestellt, dass, wenn ich numberOfRowsInSection: aufrufen, ruft es die tableView: numberOfRowsInSection: Methode meiner Datenquelle. Dies ist sinnvoll, da die Methode der tableView eine zwischengespeicherte Version des Datenquellenwerts zurückgibt, sodass sie den Wert aus der Datenquelle zum ersten Mal abrufen muss. Aber dann ruft es heightForRowAtIndexPath auf und übergibt es indexPath [0, 0] erneut! Und es macht das non-stop.

ich war in der Lage, um es zu erhalten, indem

[self tableView:tableView numberOfRowsInSection:indexPath.section] 

statt mit (anstelle des Verfahrens der Tableview meine Datenquelle Methode aufrufen). Jeder hat eine Idee, warum es das tut? Ist das definiertes Verhalten? Oder ein Fehler in Apples TableView-Framework?

Answer 1

Das Problem ist, dass das UITableView fragt Ihre Datenquelle nach Daten, und Sie sagen, dass die Antwort hängt von Daten, die es möglicherweise kann nicht zwischengespeichert haben.

Sie missverstehen das M-V-C-Layout, auf dem Apple seine Steuerelemente basiert. Die Antwort auf die Höhe einer Zeile sollte von Ihrem Modell stammen, NICHT von einem Aufruf an die Ansichtsklasse. Dies führt dazu, dass die Ansichtsklasse nach weiteren Informationen fragt (um ihren internen Cache zu erstellen), was eine Reihe von rekursiven Aufrufen startet.

Stellen Sie sicher, dass alle Datenquellen-Delegatmethoden Daten aus Ihrem Modell zurückgeben und nicht darauf angewiesen sind, dass die Ansicht irgendetwas zwischenspeichert. Wenn Sie eine datenquellenbasierte Ansicht debuggen, werden Sie überrascht sein, wie oft ein UITableView nach Daten fragt. Aber so hat es Apple codiert.