NSLayoutConstraint breaks - ios

I have a custom UITableViewCell. The cell has three labels. The left most 'Amount' Label has the following constraint.
On the right side of the cell I have another label, 'Label Dollar Amount'. It has the following constraints:
The third label is right below 'Label Dollar Amount' is the 'Label Max Amount'. The constraints are as follows:
Nothing is done on the code. The table row height is calculated using UITableViewAutomaticDimension. The estimatedRowHeight is set to 100.
When the view is in landscape and the tableview is scrolled down, this particular cell is being dequeued since its out of the visible view. When the orientation is changed to portrait for the same state, the cell is expected to be visible.
I receive the following error:
Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)
(
NSLayoutConstraint:0x1607a770 H:[UILabel:0x160c1990'Amount'(150)],
NSLayoutConstraint:0x160c2b30 H:|-(18)-[UILabel:0x160c1990'Amount'] (Names: '|':UITableViewCellContentView:0x160c18c0 ),
NSLayoutConstraint:0x160c2b90 H:[UILabel:0x160c1990'Amount']-(0)-[UILabel:0x160c1c40'$45.61'],
NSLayoutConstraint:0x160c2bf0 UILabel:0x160c1ac0'(Max: $1,000.00)'.leading == UILabel:0x160c1c40'$45.61'.leading,
NSLayoutConstraint:0x160c2c80 H:[UILabel:0x160c1ac0'(Max: $1,000.00)']-(12)-| (Names: '|':UITableViewCellContentView:0x160c18c0 ),
NSLayoutConstraint:0x14e179e0 'UIView-Encapsulated-Layout-Width' H:[UITableViewCellContentView:0x160c18c0(72)]
)
Will attempt to recover by breaking constraint
NSLayoutConstraint:0x1607a770 H:[UILabel:0x160c1990'Amount'(150)]`
Note: Priorities are set to 1000 (Required) for all possible constraints seen here.
If I change the priority of the width constraint on Amount label to 999 it works. But the label disappears for longer text. Since zero spacing in the trailing constraint has a hight priority. Any suggestion on what could have gone wrong?

The table is setting a fixed width of 72 points on your cell view. This may just be temporary while it adjusts to the new orientation or layout, but you need to accommodate it:
NSLayoutConstraint:0x14e179e0 'UIView-Encapsulated-Layout-Width' H:[UITableViewCellContentView:0x160c18c0(72)]
So, you need to decide what should happen in your layout when its superview is only 72 points wide.
Currently, you have the following (edited a bit to make things clearer):
H:|-(18)-[UILabel:0x160c1990'Amount'] (Names: '|':UITableViewCellContentView:0x160c18c0 ),
H:[UILabel:0x160c1990'Amount'(150)],
H:[UILabel:0x160c1990'Amount']-(0)-[UILabel:0x160c1c40'$45.61'],
UILabel:0x160c1ac0'(Max: $1,000.00)'.leading == UILabel:0x160c1c40'$45.61'.leading,
H:[UILabel:0x160c1ac0'(Max: $1,000.00)']-(12)-| (Names: '|':UITableViewCellContentView:0x160c18c0 ),
Or:
H:|-(18)-[Amount(150)][Max]-(12)-|
So, even if every view which could be collapsed to 0 width were, you would still require 18 + 150 + 12 == 180 points of width between the edges of the superview. That conflicts with the 72 points available.
How would you like that to be resolved? One possibility is to reduce the priority of the width constraint on the Amount label, as you mention. Or you could even eliminate this constraint entirely and rely on the intrinsic width and the compression resistance priority. You say "the label disappears for longer text. Since zero spacing in the trailing constraint has a hight priority." I'm not entirely sure what you mean. Perhaps with longer text, the label is wrapping and words are on a second line which isn't visible? If so, you can set it to truncate (although that should be the default). If even truncation isn't acceptable, then what should happen?
You can try setting adjustsFontSizeToFitWidth and minimumScaleFactor to allow the text in the label to shrink, but eventually you still hit the limit (if the text is long enough and the cell width is narrow enough), so you still need to decide what you want to happen.
Another approach is to reduce the priority of the trailing constraint between Label Max Amount and the superview, so that that label moves off the right side. You may also need to reduce the priority of the trailing constraint of Label Dollar Amount, too, since it imposes the same requirement on the layout.
But, of course, that means that some of your content is off-screen. There's just no getting around the fact that you have to decide what should be lost when the width is too small to fit everything.
Once you decide what should happen, you set the priorities to achieve that. For example, if you want the Max Amount to truncate first, set its compression resistance lowest. If you want Dollar amount to truncate next, set its compression second lowest. If you want the Amount label to truncate after that, set its width constraint (or compression resistance, if you get rid of the width constraint) third lowest. And if you want things to be pushed off the right edge as a last resort, set the priority of the trailing-to-superview constraints to 999.

Related

iOS autolayout disregarding "trailing space" constraint, using width/content size instead?

I have a UILabel (the subtitle) that I want to have a static X origin, but extend to the edge of its nearest neighbor. There's a button ("Visit Link") that is optionally removed from the superview at runtime if not needed. The constraint from the label to the button has a priority of 1000, and the constraint from the label to the superview container has a priority of 250:
However, when I run the application removing the button (via .removeFromSuperview() in the viewDidLoad method), via the view debugging I see that the content size is setting the width of the label, taking priority over the constraint I have set.
I expect the label to extend to the edge of the view, but as you can see, the constraint is greyed out - I assume trumped by the (content size) constraint instead:
Does the (content size) constraint have a higher priority than my Trailing Space to: Superview constraint? And how can I change it, since it's not a constraint I've even defined?
When you remove the button from the view hierarchy, that also removes any constraints involving the button. So, all that's left is the trailing constraint to the superview at priority 250.
The label has an intrinsic width based on its content. That means that its horizontal content hugging and compression resistance priorities come into play. Its content hugging priority is 251.
That means that it's more important to the auto layout system that the view's width be no larger than necessary than it is to keep its trailing edge at 8 points from the superview's trailing edge.
You should probably increase the priority of the trailing constraint. You want it to be less than the trailing constraint to the button so that, in the case where the button is present, it doesn't conflict. You also want it less than the button's compression resistance priority, so that the button doesn't get squished to allow the label to be 8 points from the superview. But, other than that, you want it to be as high as possible. (In the hypothetical case where you simply got rid of the possibility of there being a button, you would normally make that trailing constraint required, right? So, it should be as close as possible to required without causing undesirable side effects.)
If you're targeting deployment to iOS 9.0 or later, you should consider using a UIStackView for this layout. It will take care of some things for you, like adding or removing the appropriate constraints when the button is hidden or shown.
The (content size) constraint, automatically installed by the system at runtime, seems to have a priority somewhere between 250 and 750. When I use 250 or 251 for my Trailing Space constraint, it does not work.
However, bumping the priority of my Trailing Space constraint up to the Xcode-titled High priority of 750, allows it to take precedence. So the defaults for the width of UILabel seem to fall "somewhere in the middle."
Autolayout, you silly.
From the second screenshot, it looks like everything is working as it is supposed to.
Two things I'd like to mention:
Always try to set up your layout so you have as few constraints as possible. Each constraint adds complexity.
Yes, content size of the label does indeed have a higher priority. That's why the label is not resized to the right-most edge, which is good. What you are seeing is the label's intrinsic size which means that UIKit knows how big the label is supposed to be drawn, depending on font, text, etc.
To make this layout a bit more robust, I'd change the Trailing space of the label so that it has priority 1000 but is >= 0.
This way, the layout will be valid with or without the Visit Link button and the content size of the label (it's intrinsic size) will resize it to whatever length it needs to be, but no more than the right edge of its superview.
Hope this helps!
UPDATE: Wrote a quick post on why this content size is appearing and why you should use it to your advantage.

How to set constraint in a reusable UITableViewCell

My xib layout likes under drawing
I have set the constraints from "a" to "b" to ..."e" besides the height constant of "c" so that can determine the height of the cell.
Sometimes the "c" will hidden because some reasons, I changed the height constant to zero and actual height by the label's content when it is visible.
--------------------------------------
UILabel(name-singleline) a
UILabel(title-Multi line) b
UIView(hidden or not) c (default height constant = 80)
-UILabel(content Multi line) d
UILabel(singleline) e
--------------------------------------
But there is a autolayout warning make me crazy
(
"<NSLayoutConstraint:0x15756760 V:[UILabel:0x15756650'XXXX'(15)]>",
"<NSLayoutConstraint:0x15757130 V:[UIView:0x15756ee0(80)]>",
"<NSLayoutConstraint:0x15758060 V:|-(21)-[UILabel:0x15756650'XXXX'] (Names: '|':UITableViewCellContentView:0x157563a0 )>",
"<NSLayoutConstraint:0x15758120 V:[UILabel:0x15756650'XXXX']-(14)-[Project.GWWLabel:0x157573d0'YYYY']>",
"<NSLayoutConstraint:0x157581e0 V:[Project.GWWLabel:0x157573d0'YYYY']-(3)-[UIView:0x15756ee0]>",
"<NSLayoutConstraint:0x15758210 V:[UIView:0x15756ee0]-(8)-[UILabel:0x157569e0'ZZZZ']>",
"<NSLayoutConstraint:0x15758270 V:[UILabel:0x157569e0'ZZZZ']-(18)-| (Names: '|':UITableViewCellContentView:0x157563a0 )>",
"<NSLayoutConstraint:0x1575d760 'UIView-Encapsulated-Layout-Height' V:[UITableViewCellContentView:0x157563a0(139.5)]>"
)
Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x15757130 V:[UIView:0x15756ee0(80)]>
I'm also deeply interested in understanding why this happens
Try this:
make the priority of height constrain 750 as shown below
it will work when you change height constant
The first golden rule of auto layout (specially when working on TableView's cells) is to be able to draw a line from top to bottom and from left to right and be able to determine the size of each element. To manage this you will need to be sure that each view has at least one constraint per side (unless it size could be inferred)
Also sometimes when testing the UI on different screen size the constraints might break. In does cases you should change the priority of the constraints or content hugging / compression resistance of the views to allow auto layout to break does constraints and change the constants to adapt the screen size. (Most of the cases it will only change in a few points, if it changes more you might need to change your constraints)
Is also important to mention that "Hidden views, even though they don't draw, still participate in Auto Layout and usually retain their frames, leaving other related views in their places." check this post
You may want to check this post or this one if you use swift

iOS auto-layout constraints

I'm unsure of how I should set up some constraints in my auto-layout storyboard in iOS.
I have a textbox and a button next to it, constrained to each other, and they're both constrained to the sides of their superview by 20. It works great for iPhones/iPods. Moving up to iPad, however, the textbox becomes too wide. Is there some way to set a "max width" on the text box in order to allow some growth, and allow the constrains to the superview grow after that point?
It feels like I'm approaching it all wrong, do I have the wrong approach?
The constraint
You can set a constraint for "width less than or equal to X" (whatever your value X is).
Then pair that with your "trailing edge space to the edge of the superview is equal 20".
The Conflict
This will not work as it is though as if the superview is too wide it will create a conflict.
Priorities
What you can do though is give the "edge space" constraint a priority of 1 less than the priority of the width constraint.
So if the width constraint has a priority of 750 (which is default) then give then space constraint a priority of 749.
This has the effect of telling AutoLayout. "If there is a conflict, then break gracefully by 'removing' the space constraint and keeping the width constraint".
You can set a width constraint and in the right side of the screen, instead of equal, select less than or equal (or something like this). This will add a maximum width to your UI element.
You can add width constraint which can be set the constant with the equal value, for example 100 or you can add equal greater than 100 or less equal...
you can use Ctrl+Drag with in a text field to set fix width.

ios8 cell constraints break when adding disclosure indicator

I have a problem with auto layout on IOS8, the simplest case I can recreate is a simple tableView. I setup a static cell and then simply add a label.
My aim is to have the label largely fill the space, so I have three constraints on the label...
Centre it vertically within the superview (I think this is fine)
Set the label trailing margin to 30 (relative to superview)
Set the label leading margin to 30 (relative to superview)
It's all absolutely fine and works perfectly with no major problems or warning (it does warn about zero height, but I don't think that so much of an issue for this)
Now ... if I add a disclosure indicator it all falls apart. It still looks ok, but I get the following:
2014-10-30 15:51:46.358 ContraintIssue[25572:1586028] Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want.
Try this:
(1) look at each constraint and try to figure out which you don't expect;
(2) find the code that added the unwanted constraint or constraints and fix it.
(Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand,
refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)
(
"<NSLayoutConstraint:0x7fd3f3d23390 UITableViewCellContentView:0x7fd3f3d226f0.trailingMargin == UILabel:0x7fd3f3d227e0'Label'.trailing + 30>",
"<NSLayoutConstraint:0x7fd3f3d235f0 UILabel:0x7fd3f3d227e0'Label'.leading == UITableViewCellContentView:0x7fd3f3d226f0.leadingMargin + 30>",
"<NSLayoutConstraint:0x7fd3f53b73b0 'fittingSizeHTarget' H:[UITableViewCellContentView:0x7fd3f3d226f0(38)]>"
)
Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x7fd3f3d23390 UITableViewCellContentView:0x7fd3f3d226f0.trailingMargin == UILabel:0x7fd3f3d227e0'Label'.trailing + 30>
I don't understand why adding an indicator would cause such a problem, it's nothing to do with the scale of the numbers, I've experimented quite a bit.
Any ideas?
The real world example a cell that has a label (the label) and then either another label or a text view that contains a value that can be set by following the disclosure. So the first label is a fixed size, the second ideally needs to be the max that it can be, but truncate the text if needed.
(See the 'ringtone' or 'vibration setting' within adding a contact for an example of what I'm trying to achieve)
Many thanks,
Lee.
I just had the same problem. I want to layout an image-view on the left hand with a label on its right which fills the space between the image-view and the right (or trailing) border of superview (which is the cell's content-view). Accessory view is set to disclosure indicator as well.
As in your case the conflicting constraints where all H-based and one I found in the logs where fittingSizeHTarget. I didn't found out what this means nor where this was coming from, but I found your post here.
The following did the trick for me:
Lower the priority of your label's trailing-to-superview constraint. (I chose 990).
I assume, that the layout system (with the disclosure indicator visible) for what ever reason can't satisfy all the constraints anymore, so it breaks one. But if you lower the priority, it still tries to satisfy the constraint, but doesn't break it as the conflicting constraint(s) have higher priority.
Hope this solves your problem as well.
Please pay attention to what Stephen says in the comment section of the upvoted answer. The upvoted answer is somewhat correct, but it's important to understand why it should only be used in certain scenarios.
Priorities are usually used in context where element A has a constraint saying height is equal or less/more than 300, and element B has one says height is equal or less/more than 500. Then autolayout can satisfy both conditions based on their priorities.
In this particular example, both constraints are set to specific value and lowering priority essentially tells to ignore that constraint if it's impossible to satisfy (there's no "partially ignore it"). However UILabel has an exception - default UILabel behaviour is to resize itself to fit the content unless it's constrained by additional margins (autosize constraint hides under fittingSizeHTarget name) and this behaviour sometimes shows false warnings. In reality this constraint will be ignored in the runtime, but before it becomes disabled internally it will file a warning. Therefore, even though we tell to ignore one of our constraints by lowering its priority (the one we set priority to 900), since autosize constraint will be ignored in runtime, our 900 priority will be applied and satisfied.
Raimunda's answer above explaining about the intrinsic size that happens on labels, buttons, etc being where this fittingSizeHTarget log is coming from was spot on. While you can leave it and let the system deal with it, it's a risky hack, because you're relying on the system to break an unwanted constraint...which it may not do in future releases. And in some cases, as in a view example I recently dealt with, lowering the priority of the trailing constraint to the outside safe area didn't prevent the label from overrunning (it did, however, fix the log warning lol).
For content issues like this, use the Content Hugging Priority and Content Compression Resistance Priority values. If you know that your label, for example, will want to increase in vertical height but constrain to a horizontal value, then make the vertical content hugging priority (Content hugging = the view resisting being made bigger) lower than the horizontal.
The Compression resistance is the opposite of this.
Then set your outside trailing constraint to a greater than or equal and you're good to go.
In the stack view below, the label titled Fake 4 actually overran and wanted to become two lines. That caused a conflict involving fittingSizeHTarget (the intrinsic content size wanted to stay on one line and overrun the view width). The key here was lowering the Horizontal Compression Resistance priority to lower than ALL of the other content priorities. This allowed me to lower the priority of the >= constraint on the trailing value, and everything behaves as expected.
Anyway, tweaking this stuff is annoying as heck, but those Hugging/Compression values, combined with some form of >= / <= are usually the answer.
Hope this helps.

Inequality Constraint Ambiguity

i've a problem in resizing a UIView with Autolayout and constraints.
I'd like to change the origin (less than or equal of original) and the width (greater than or equal of original) but I got this: Inequality Constraint Ambiguity
Do you have idea for solve this?
thanks
I tried to make more than 1 vertical spacing constraint shrink for 3.5" displays, so I had to make 2 constraints between components that I wanted to shrink on smaller screen. One constraint was inequality (greater or equal) where I specified minimum required size, with 1000 priority, other constraint was equality constraint with specific size that is suitable for 4" screen, but with lower priority of 250.
This way Xcode stopped complaining and layout repositioned properly on smaller screen.
Your view is horizontally ambiguous. You do not have enough horizontal constraint information for the system to come up with just one solution for your view heirarchy. In this instance, it can't determine what the view size or left margin needs to be based on the current constraint information.
You need to add a less-than-required-priority (<1000) constraint either to your view's width giving it a defined width or add an equality constraint to your left margin constraint. By making the new constraint a <1000 priority, it will enable the new constraint to properly mix with your existing inequality constraints (which are required constraints). Here is another question that is similar to yours relating to inequalities.
The view will size differently depending on if you add the new constraint to the view's width or the view's left margin. This all depends on how you want your layout to behave in response to changes.
This does not make sense to the compiler (and logically) because there is no way to know whether the program should change x or width. Making one of the two static will solve your problem.
First you have to know what you want to do with constraints, please remove greater-than-equal-to constraint that does not make scene with less-than-equal-to constraint. buz view need define width constraint. either apply priority to which constraint play role first (greater-than-equal-to constraint or less-than-equal-to constraint).

Resources