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.
Related
suppose I have this layout:
I would like to set contraint from trailing of the color view to the superview in such a way that when the label expands, it will push the colored view to the right, but not exceeding the screen.
So, what I understand is, setting trailing of the colored view to superview with less than or equal relationship will do the trick. But it does not.
So, what is really the use of greater than or equal and less than or equal anyway?
set color view's trailing constraint to greater than or equal to some constant! And it will manage space equal to that constant!
Your label should be self sizing, I mean should increase width with content and you should give fixed width to your color view!
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.
I can not understand why following setup gives me the Inequality constraint ambiguity error. The general idea (although simplified in this question) is to pin the View to the top and left, give it fixed height and variable width. Thus, 4 constraints have been added: 3 with equal values (for top, left and height) and 1 with less than or equal. And it gives me that error. Finally, what I am trying to achieve, is to put other new to the right of this View, and specify the spacing between them. So, whenever Left view changes the width, the right View will change the X.
It is ambiguous because your width constraint is ambiguous: a less than or equal constraint is not constraining enough. What you probably want, if I can infer what you are doing correctly, is to set the width constraint to a fixed value that you want initially, and then create an IBOutlet for that constraint, as well as for the Right View's X constraint, and change those programmatically when needed. This way you can programmatically change the width of your Left View, and at the same time update the Right View's X position.
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).
I want to have the bottom view be at least 20 away from both the image and the label above it. The label is multiline, so it can be taller or shorter than the image view, depending on how much text there is. When I add two "distance to nearest neighbour >= 20" constraints like shown in the screenshot, Xcode tells me constraints are ambiguous.
How do I fix it?
I think you can do it like this, if I understand your requirements:
The image view has a fixed width and height, and constraints to the left side and top, as well as a constraint to the bottom view of =20 with a priority of 700. That's crucial -- that will set the y position of that bottom view (which has fixed height and constraints to the two sides), but will allow it to move lower if another constraint with higher priority makes it. That constraint with higher priority is the constraint to the label -- it's >=20 with priority of 1000 (the label also has constraints to the top, right side, and trailing edge of the image view).