1

Say you have (for example) a table cell layout with more than one dynamic flexible-height items,

They are linked vertically one to the other in the obvious way.

enter image description here

It seems very difficult to make this work, and very undocumented.

You'd expect that: you set the compression resistance of all the expandable items to 751. But that doesn't work.

After random experimentation, it seems to me that surprisingly you have to do something like this:

have the compression/hugging of the overall view on 250 and 750,

enter image description here

then strangely enough, for the three text views in the example, the priorities have to

...sequentially increase...

enter image description here

And, I think you have to make one of them "one lower" than the overall view - in the example one of them would be 749.

It's difficult/impossible to find the exact "formula" to make it work consistently.

What the heck is the logic of this? Is it just a pure bug in iOS?

Has anyone found the "correct formula" for making a number of expandables work in a cell?

  • priorities for the three text views

  • priorities for the overall holder view

cheers

Community
  • 1
  • 1
Fattie
  • 27,874
  • 70
  • 431
  • 719
  • 1
    Tried a stack view? I guess I am a little confused on your layout, Can you post a screenshot of what you are laying out exactly? – Siriss Jun 29 '17 at 17:22
  • 2
    I haven't voted yet, but: "It is very annoying if you have 6 or 7 in a line!" 6 or 7 of what?! ||| "Just go ahead and try it, set them all the same to +1 as you'd expect " <-- what? You mean set 750,751,752? ||| "What the heck is the logic of this"? Is not the proper language spoke on SO... – mfaani Jun 29 '17 at 18:20
  • 1
    I do understand the downvotes because the question is not very clear to me either. If I understood you correctly, it's a valid and legitimate question but it's really not that precise: What's an "expandable" for example? What do you mean by "Just go ahead and try it, set them all the same to +1 as you'd expect"? etc. You could really make it a hell of a lot easier to other SO users to understand your question quickly by adding a screenshot of your setup and making your descriptions more precise. – Mischa Jun 29 '17 at 22:27
  • @Fattie , can you please post ScreenShot , or i want to ask one thing , are you looking for the Contraints which will autometic Height on tableCell , ???? or somthing else little bit confusing question .... please elaborate – Dhiru Jun 30 '17 at 12:02
  • see if that's any better, dudes :) – Fattie Jun 30 '17 at 12:29

2 Answers2

4

Your question is not very clear to me. However, here's a good recipe to stack text views (whether or not you use a stack view for constraining them doesn't matter):

1. Disable scrolling for all your UITextViews:

Disable scrolling in Identity Inspector

Reason: If scrolling is enabled, a UITextView does not have a defined intrinsicContentSize. See this answer. Without an instrinsic content size, the content hugging and compression resistance ("CHCR") priorities have no meaning or effect.

2. Give each view along one axis a different priority for CHCR:

More precisely: Give all views that are connected with constraints along one axis a different CHCR priority that are not constrained in size along that axis (i.e. that don't have a fixed width / height constraint).

In your particular example, your setup shown in the screenshots is a correct solution: Each of the three text views has a different content hugging and a different compression resistance priority. As a general rule you should start with the default values (750 / 250) and only slightly increase or decrease them as you did.

In case you use a table view with self-sizing cells (by setting its estimatedItemSize), the CHCR priorities won't matter at runtime because the cell will automatically resize to accommodate enough space for all three text views. You just need to set those priorities to "silence" Interface Builder.

If you use fixed-height table view cells however, the CHCR priorities are quite important because they determine

  • which of the views will shrink first if there's not enough space inside the cell (it's the view with the lowest compression resistance priority) and
  • which of the views will expand if there's more space inside the cell than the subviews actually need (it's the view with the lowest content hugging priority).

The CHCR priorities of the superview ("MV") is irrelevant as it's usually just a container view that does not have a defined intrinsicContentSize either. Its size is defined by the inner and outer constraints you add.

For more information on the CHCR priorities, see the chapter Intrinsic Content Size in the Auto Layout Guide.

Mischa
  • 15,816
  • 8
  • 59
  • 117
  • Ahhhhhhhhhhhhh - who the hell knew point "2". Thanks so much, I'll go investigate. I sort of "stumbled on" to a halfass version of that ruleset you know? I'll go experiment ......................... totally awesome – Fattie Jun 29 '17 at 22:40
  • Thanks for the trick with disabled scrolling. Didn't know that (maybe I will use it for some scenario in future). Intrinsic Content Size is definitely the most obvious solution, though. – Silmaril Jul 06 '17 at 13:48
  • In which software did you make the image? – Rubén Ruíz Jul 06 '17 at 16:07
  • thanks again @Mischa don't spend that bounty all in one place! :) You know, this topic raises more specific detailed questions which I must pose at a later time. – Fattie Jul 06 '17 at 17:18
  • Hmm, I was just about to buy a new house... ;) Hope you'll get all these things resolved. – Mischa Jul 09 '17 at 12:26
-1

When I am playing with cells that have a variable height I use:

tableView.estimatedRowHeight = 20.0
tableView.rowHieght = UITableViewAutomaticDimension

These two cause the table view render its cells with the appropriate height. In order for the height to be computed though you should set the cell's data in tableView(cellForRowAt)

gkaimakas
  • 574
  • 3
  • 17