iOS8のテーブルビューの素晴らしい新機能である自動行の高さの副作用が発生しています。
iOS 7では、固定サイズ(で設定tableView.rowHeight
)の行があるか、セルの高さを計算するコードを記述して、それをで返しますtableView:heightForRowAtIndexPath
。セルに多数のビューがあり、異なるフォントサイズで異なる高さを検討する場合、セルの高さを計算するためのコードの記述は非常に複雑になる可能性があります。動的タイプを追加すると、プロセスはお尻の痛みでした。
iOS 8でも上記のことを行うことができますが、自動レイアウトを使用してセルのコンテンツを構成した場合、行の高さをiOSで決定できるようになりました。これは、開発者にとって大きなメリットです。動的フォントサイズが変更されるか、ユーザーがユーザー補助設定を使用してテキストサイズを変更すると、UIは新しいサイズに適応できるからです。また、複数行のテキストを持つことができるUILabelがある場合、セルは必要に応じてそれらに合わせて拡大し、そうでない場合は縮小できるため、不要な空白がなくなります。
表示されている警告メッセージは、セルの高さをテーブルビューに通知するための自動レイアウトのための十分な制約がセルにないことを示しています。
動的なセルの高さを使用すると、他のポスターですでに言及されている手法と同様に、このメッセージが表示されなくなります。セルにUIアイテムをセルの上部と下部にバインドするための十分な制約があることを確認する必要があります。以前にAuto Layoutを使用したことがある場合は、おそらくTop + Leading制約の設定に慣れていますが、動的な行の高さには下部の制約も必要です。
レイアウトパスは次のように機能します。これは、セルが画面に表示される直前に、ジャストインタイムで行われます。
固有のサイズのコンテンツの寸法が計算されます。これには、UILabelsとUIImageViewsが含まれます。これらの寸法は、それぞれに含まれるテキストまたはUIImageに基づいています。これらのビューは両方とも、その幅を既知であると見なします(トレーリング/リーディングエッジに制約を設定したか、明示的な幅を設定したか、最終的に左右の幅を明らかにする水平制約を使用したため)。ラベルにテキストの段落があり(「行数」が0に設定されているため、自動折り返しが行われる)、ラベルの幅はわずか310ポイントなので、現在のフォントサイズでは高さが120 ptと決定されます。
UIは、配置の制約に従ってレイアウトされます。セルの下部マージンに接続するラベルの下部に制約があります。ラベルは120ポイントの高さに成長し、制約によってセルの下部にバインドされているため、「bottom of」という制約を満たすために、セルを「下」に押す(セルの高さを上げる)必要があります。ラベルは常にセルの下部からの標準距離です。
報告したエラーメッセージは、その下部の制約が欠落している場合に発生します。その場合、セルの上部からセルの下部を「プッシュ」するものはありません。これは、報告されているあいまいさです。上、セルが折りたたまれます。ただし、自動レイアウトもこれを検出し、標準の行の高さを使用するようにフォールバックします。
何に価値があるのか、ほとんどの場合丸められた答えを得るために、iOS 8の自動レイアウトベースの動的行の高さを実装する場合は、を実装する必要がありますtableView:estimatedHeightForRowAtIndexPath:
。その推定メソッドはセルに大まかな値を使用でき、テーブルビューが最初に読み込まれたときに呼び出されます。これは、UIKitがスクロールバーのようなものを描画するのに役立ちます。これは、テーブルビューがスクロールできるコンテンツの量を知らない限り描画できませんが、単なるスクロールバーなので、完全に正確なサイズは必要ありません。これにより、実際の行の高さの計算を、セルが必要になる瞬間まで延期することができます。これにより、計算負荷が軽減され、UITableViewがより速く表示されます。