2013-11-10 5 views
6

カスタムUITableViewCellsの1つがtableViewによって描画されるたびに:cellForRowAtIndexPath:コンソールはNSLayoutConstraintの不一致の束を吐き出します。私はこれらのほとんどを理解しています:カスタムUITableViewCellでレイアウトに影響を与えていない、奇妙なNSLayoutConstraintエラーを修正する方法

Unable to simultaneously satisfy constraints. ...boring stuff.. 

"<NSLayoutConstraint:0x8b0eb60 V:|-(NSSpace(20))-[UILabel:0x8b0cb30] (Names: '|':UITableViewCellContentView:0x8bd7d40)>", 
"<NSLayoutConstraint:0x8b0db70 V:[UILabel:0x8b0cb30]-(NSSpace(8))-[UITextView:0x91dba00]>", 
"<NSLayoutConstraint:0x8b0dba0 V:[UITextView:0x91dba00]-(NSSpace(20))-| (Names: '|':UITableViewCellContentView:0x8bd7d40)>", 
"<NSLayoutConstraint:0x8b0d5a0 V:[UITextView:0x91dba00(1000)]>", 
"<NSAutoresizingMaskLayoutConstraint:0x8b00330 h=--& v=--& V:[UITableViewCellContentView:0x8bd7d40(44)]>" 
) 

Will attempt to recover by breaking constraint 
<NSLayoutConstraint:0x8b0db70 V:[UILabel:0x8b0cb30]-(NSSpace(8))-[UITextView:0x91dba00]> 

または少なくとも私はそう思います。本当に困惑しているのは、私のUITableViewCellが動作しており、制約が壊れていないようです。私は、エラーに記載されているいくつかの制約、特に最後の制約は、システムによって追加された制約だと思います。 .xibsを使用せず、コードに制約を追加しただけの場合は可能ですか?エラーの最後の行は、特に私が各コードの高さを動的に生成しているので私にはっきりと出ていますが、そこにある44のセルの高さに気付きました。

たとえば、[super updateConstraints]に電話をかけたときのように、これらの制約の一部がデフォルトで追加されていますか?これらのエラーを解決する方法や、どこから来たのかを知る方法はありますか?

私はUITextView + Auto LayoutソリューションよりもCore Textにディッピングが優れていることを理解しています。今のところ私はセルの高さをキャッシュすることに取り組んでいます。しかし、これらのレイアウトエラーは、スクロール中にラグを引き起こす可能性がありますか、それとも単に画面上に表示されるように自動レイアウトを使って各セルの高さを計算しているためですか?

誰かがダウンロードして自分自身のために奇妙なことを体験したいと思ったら、私はthe project in which these errors are occurring on Githubを投稿しました。

+0

これらの制約は、UITableViewCellの高さがデフォルトの高さである44である場合にはすべて満たされません。 '20 + 8 + 20 + 1000 +あなたのラベルの本質的な内容の大きさの高さ 'より大きいデフォルトの高さを手動で指定することによって、これらのエラーを取り除くことができます。また、身長を手動で計算してから表示されない場合は、無視することもできます。 –

+0

ちなみに、autolayoutはUITableViewCellで使用しないでください。これは、スクロールのパフォーマンスが低い(不安定になる)一般的な原因であるためです。 –

+0

@AaronBrager私はそれを動作させましたが、セルのcontentView.frame.heightをinitWithStyle:およびprepareForReuse:の大きな定数に設定しました。ご協力いただきありがとうございます! –

答えて

2

Aaronの提案によれば、セルレイアウトが初期化されたときにセルの高さを手動で変更するので、オートレイアウトがその計算を行うときに制約が適用されます。コンテンツフレームを最初に設定することなく、デフォルトフレームは{0, 0, 320, 44}です。これは小さすぎるため、制約を満たすことができず、コンソールにエラーが表示されます。

同様に、セルを再利用する場合、古いレイアウトのcontentView.frame(自動レイアウトで計算された)が使用されます。同じ量のテキストを使用している場合、これは問題ありません。新しいセルにさらに多くのテキスト(したがって、より大きなcontentView.frame)が必要な場合、同じ問題が発生した場合、contentView.frameは小さすぎます制約を満たすことができない。

私のカスタムUITableViewCellでは、contentweb.content.heightをinitWithStyle:prepareForReuse:に手動で設定して、一定の大きさのテキスト(App.netポストと余分なヘッドルームがあれば十分です)に対応できます。これにより、自動レイアウトで計算が行われるときにエラーが発生しなくなります。

iOS 7のダイナミックテキストに対応するために、この値を多少高く設定することもダイナミックに設定することも考えられます。スクロールでは、エラーが発生しても、スクロールが不安定になることはありません。レイアウト計算(私は思う)。次のステップは、viewDidAppear:が呼び出されたときにセルの高さを計算することです。

+0

"次のステップは、' viewDidAppear: 'が呼び出されたときにセルの高さを計算することです。... ...データ(テキスト)がサーバーから到着したときにセルの高さを計算し、結果を格納することができます。そして、セルを表示する必要があるときは、計算を行う必要はありません。 –

+0

私は、セルの高さからUITextViewの高さを引いたものを計算する方法を考え出したので、heightForRowAtIndexPathではUITextViewに必要な高さを計算します。スクロールはスムーズで、キャッシングを実装する必要もありません。私はデータが到着したときに計算を行うことを考えましたが、今は完成したモデルオブジェクト、ローカルでランダムに生成されたコンテンツなしで作業しています。私はそれを心に留めておきます。また、私のソリューションは現在Githubに公開されています。 –

+0

私は、initWithStyle:とprepareForReuse:でcontentViewの高さを設定することが良い解決策であることを確認できます。あなた自身の質問に対するあなた自身の答えであっても、この回答を受け入れたものとしてマークしたいかもしれません。 –

関連する問題