可変高さのカスタムテーブルセルを持つUITableViewを構築しています。その高さは、含まれている複数行のUILabelのサイズによって決まります。私はtableView:heightForRowAtIndexPath:
デリゲートメソッドを結んで、最終的な高さを正しく計算することをsizeWithFont:constrainedToSize:
で行っています。UITableViewCellのフレームの高さが一致しないtableView:heightForRowAtIndexPath:
データソースメソッドtableView:cellForRowAtIndexPath:
が呼び出された時点で、正しい行単位の高さは既に説明したとおりに決定されていますが、セルのフレームはその高さに一致しません。代わりに、セルのframe.size.height
プロパティは、テーブルビューのデフォルトのセルの高さです(Interface Builderで設定した86pxのように、含まれているUILabelが1行のテキストしかない場合は正しい高さになります)。高さはtableView:heightForRowAtIndexPath:
で、その索引パスが正しいと判断されます。
私はデキューを使用してcellForRowAtIndexPath:
で細胞を産生しています、それは、
// Using storyboards, this never returns nil, no need to check for it
CustomCell *cell = (CustomCell *)[tableView dequeueReusableCellWithIdentifier:@"SomeIdentifier"];
NSLog(@"%f", cell.frame.size.height); // 86, not correct if the cell contains a multi-line UILabel
ある何のiOSが舞台裏でやっていること、そして、そうです、デキューは、セルの枠プロパティを設定されていません計算された高さと一致させる。これ自体は、驚くべきことではありません。セルインスタンスのジオメトリではなく、デキューに関する懸念自体です。ただし、セルは正しくレンダリングされるため、高さプロパティはのどこかのに設定されますが、cellForRowAtIndexPath:
の後に発生します。
So:最初にテーブルビューに値を入力すると、リストを下にスクロールしたときに最初に表示されるすべてのセルについてcell.frame.size.height
が86になります。正しいジオメトリは、表示される前に各行の最初のcellForRowAtIndexPath:
の後に設定されるため、スクロールバックすると、高さプロパティは再利用後に表示されるセルごとに正しくなります。
これ以降、テーブルビューを自由に前後にスクロールすることができ、高さプロパティは、そのポイントの各セルに対して正しいままです。
デキューベースの再利用が行われる前に、正しいセルの高さを最初に取得する正しい方法は何ですか?私はテーブルのセルのサブビューのビットを再配置するためにこれを必要とします。 cellForRowAtIndexPath:
に手作業でheightForRowAtIndexPath:
を呼び出して、新しく作成したCustomCellインスタンスのフレームをその高さに手動で設定する必要がありますか?これは重複しているように見えますが、この冗長性を避けるために後で正しいフレームの高さからデキューされたときに、不正なフレームの高さでセルが初めて作成されたときを検出するメカニズムを作成する必要があります。
誰かが論理がこの背後にあることにいくつかの光を当てはめることができたら、私はそれを感謝します。
最初の質問は本当に良いですが、この回答はあまり良くありません。あなたが問題をどのように修正したかを分かち合いましょう。 – botbot