Unexpected UIImageView Auto Layout Behavior - iOS 8 - ios

I've been trying to make a screen look like this:
But when i run it it keeps appearing like this:
So far I've tryed to debug the View Hierarchy but debugger shows the actual expected view:
I've come up with a workaround, putting the UIImageView before the top bar in the View Hierarchy so when it extends it goes under the top bar instead of on top.
EDIT:
The bottom white box is not a blank space, is actually a view intended to host 2 buttons.
My constraints are set as follow:
Top banner:
height: 50
vertical spacing to Top Layout Guide: 0
leading and trailing spacing to superview: 0
Image:
vertical spacing to Top banner: 0
leading and trailing spacing to superview: 0
Bottom view (white box):
vertical spacing to Image: 0
leading and trailing spacing to superview: 0
proportional height to Image: 1:3
There are no other views in the hierarchy and no other constraints.

You need to place a vertical spacing between the top banner ("Amigo invesa app" written image) and the middle image (image with unknown green fruit/vegetable). But there is an unclear point, which is following
Exactly how many spacing do you want bottom of the middle image view
For example you want a 64px distance between middle image and the bottom of the view controller's view, then don't forget to put an vertical spacing with spacing 64px.
According to your second editing::
all the Constraint you have listed in the bottom. But there are some missing constraint which is
Height of the top banner, but you may want to resize the banner in bigger screen, that's why you need to specify other component's height (explicitly or implicitly). Here explicitly, I mean hard-coded specify the height of the middle image & the bottom white view's height & implicitly means by ratio between both of them as you mention proportional height to Image: 1:3. In the implicit case, you middle image height is not specified so the bottom white view's height can't be specified by the autolayout. Its an ambiguity situation for autolayout.
My advise will be please specify a explicit height for both top banner & bottom white view & remove the ratio constraint. That should do what you want.
Happy gui designing.

I found both the problem and the solution to this problem.
The UIImageView is actually behaving as expected, but the image it contains is spilling out of the view as stated in this answer.
The solution, explained in detail in the referenced answer, is as simple as to set imageView.clipsToBounds = true.

Related

How to implement constraints for 2 labels between 2 images for xib file

Edit: PLEASE LEAVE A COMMENT IF YOU'RE GOING TO DISLIKE SO I CAN IMPROVE MY QUESTION
I'm trying to recreate a custom table view cell in my xib file as shown below. The company's square image is on the left. The company's name and company's booth (2 UI Labels) are to the right of the company's image. The star button is to the right of the text and is a square image. I guesstimated that the company's image and favorites button should be about 8px from the top and edge.
I tried to create 4 constraints for the top, bottom, left, and right of every element (image, 2 UI labels, and button). I also added 1:1 aspect ratio constraint to the image and button to make sure the image would be square. Then I aligned the left edge of the 2 UI labels. I vertically centered the image and the button. However, it came out with no star button and the location and title switched. How do I create this design using constraints?
Their is no difficulty with that.
First if we talk about your left UIImageView, Set following constraints,
Leading constraint
Fixed Height
Fixed Width
Centre Vertically
After that the UIImageView on left, set following constraints,
Trailing space from superview
Fixed Height
Fixed Width
Centre Vertically
Now for both Labels, put them in a UIView and give that UIView following constraints,
Leading space from left image view.
trailing space from right image view.
top space from superview
bottom space from superview
Now for upper UILabel, Set following constraints,
Leading space
Trailing space
top space
Now for lower UILabel, Set following constraints,
Leading space
Trailing space
top space from upper UILabel
bottom space
After all this, i think that this will work for you.
You can use the constraints in the image below. It will work for all screen size and for any height of row.

Need help to set autolayout

Am new to iOS & am facing it very difficult to set autolayout. Watched many videos to learn, but all of them giving solution to a specific problem. No video covers all base rules to set an UI object into it's place & with proper flow.
I came from Corona Background & used to set UI programatically very well. Am thinking here same way, but I think apple made it so difficult or people are not able to explain me properly.
Please see 2 images attached in this question & tell me rules to apply to achieve this UI. I request you people to please explain in the general manner so that my other screen can be completed using same rules.
Image 1: http://i.stack.imgur.com/MPE47.png
Image 2: http://i.stack.imgur.com/qEiCm.jpg
A really helpful guideline is
Every element should be able to figure out its position (x and y) and size (width and height).
Ensure that every element only has one way to figure out its position and size.
Remember that the autolayout of all the elements can influence each other.
The most used layout constraints are:
Top The space between the top of the view to another view.
Trailing The space between the right edge of the view to another view.
Leading The space between the left edge of the view to another
Bottom The space between the bottom edge of the view and another view
Width Assign a fix width to a view (Note that it can also be a percentage - aspect ratio)
Height Assign a fix width to a view (Can also be a percentage)
Center Horizontally Always align the view relative to the horizontal center of another view
Center Vertically Always align the view relative the the vertical center of another view
For example in your second image, say the yellow bar is a UIView called titleView.
Set the position of titleView by setting the top layout constraint to the container view. y position is set.
Set the leading constraint to the container view. x position is set.
Set the trailing constraint to the container view. The view's width will now stretch with the screen size. Thus width can now be determined.
Set height to 50. Height is set.
Now... If you also set the width of this view, it will cause the layoutConstraints to break, because you have redefined the width constraint. Some of the constraints will then be ignored.
Another example of how layoutConstraints might influence each other. Lets look at determining the y positions of the second image.
Say titleView has a top constraint to the container + height of 50.
currentCampaignView has a top constraint to the bottom of titleView. (Use vertical spacing) + equal height to titleView. (y + height can be calculated)
the 5 buttons have equal heights. Top buttons have Top space to Bottom of currentCampaignView. Centre buttons have Top space to bottom of top buttons. Bottom button have Top space to bottom of centre buttons.
startCampaignView has equal height to currentCampaignView. Top constraint to bottom of bottom button and Bottom constraint to container view.
Note that because views and buttons have equal heights, all are considered when determining the height. Thus it is very important that they are all interlinked and that the entire height that can be used is specified. In this case it is specified by the first element titleView that has a Top Constraint to the Container view (of which the height should be known) and the last element, startCampaignView, that has a Bottom constraint to the Container view. Because all the views in between are linked on y position and height, the view can work out what each view's height and y position should be.
One more example. (Your first image)
topLeftButton Set the top constraint to Superview. (y), Set the leading constraint to Superview (x), Set height = 100 (height), Set equal width to topRightButton (Note that we do not quite have the width yet, because the width of topRightButton can not be determined)
topRightButton Set the top constraint to Superview. (y), leading constraint to topLeftButton (will be used for x), Set trailing constraint to superview. Now the width of both buttons can be determined, because we have an external startX + endX and we know the two buttons touches each other and are equal widths. Thus the available space will be split to get the width of the two buttons.

iOS Auto Layout >> View is not Changing its Size

I have a design for a screen that should look like this (other things will be added later, but I cannot seem to resolve the basis...):
I have added Constraints to determine the following:
Both Labels are Constraint in spacing to the screen edges.
Middle View is Horizontally and Vertically Constraint to the Middle of the Background View Center.
I have added 4 Constraints to express Minimum and Maximum Vertical Spacing between the Middle View and the Labels (Current spacing as Maximum and Standard spacing as Minimum).
I have also added 2 Constraints to the Middle View to define Spacings from the Screen right and left edges.
I thought that it should be enough, but in reality, when switching between Retina 3.5 and 4 the Bottom Label disappears and the Middle View is cut in the middle:
I have tried lowering the Middle View Content Hugging and Content Compression Priorities, and still no good.
Here are the Warnings I get:
Any idea how to resolve this?
Or alternatively, how to approach it differently (preferably, still using Auto Layout)?
Add Equal Width & Equal Height constraints as well & It will work
Add TopSpaceToContainer constraint for Top Label. Then add width and height constraints for your yellow view at the middle. Remove the multiple vertical spacing constraints given to the Top Label and Bottom Label.

Using AutoLayout and ensuring bounds of parent view to fit subviews when resized

I really wish I could get my head around auto layout. It seems that whenever I read an abstract description of how things are supposed to work it makes sense, but whenever I actually try and put it into practise it always causes massive headaches. So, apologies if there is already an answer out there for this but I couldn't find one.
The problem should be relatively simple. I have a container view, which contains two subviews, shown here in hideous colours for maximum readability :) :
The bottom (black) view, should remain at it's current size and maintain the spacing between it and the red view, and the spacing between itself and the bottom of yellow view.
The red view I want to be able to dynamically change its height, causing the black view to shift up/down accordingly whilst the yellow view resizes to fit both the red+black views.
For the black view, I've added constraints to:
Set the height to 94
Pin the leading and trailing space to superview
Set the top space to the red view at 51.
Set the bottom space to the yellow view at 20.
I am trying to understand what seemingly-mystical set of constraints I need to add in order that, when the red view is resized vertically, the black view stays its current distance from the red view and maintains its size, and the outer container view resizes accordingly so that it contains the red view + black view + vertical spacing between the views.
For the red view, I've added constraints to pin the top, left and right spacing to superview, but have had no luck working out the vertical constraints. Currently I've got a constraint pinning the height =114 with a priority of 999 and a constraint with height >=114 with a priority of 1000 thinking this would ensure the view is always at least 114 in height...
The fun starts when I try and manually set the height of the red view.... I've added a button on the view, and when the button is pressed, I manually set the bounds of the red view. (The red view's default height is 114):
CGRect bounds = self.redView.bounds;
bounds.size.height = 300;
self.redView.bounds = bounds;
When I run this and press the button, the view goes from this:
To this:
To me this makes no sense whatsoever. Why does this result in:
The Y origin of the red view changing? Particularly when there is a "required" constraint telling it to stay 20pts from the top of yellow view.
The spacing between the red and black views breaking down, even though the constraint on the spacing between them is "required"?
The vertical size of yellow view not changing. Again, despite the spacing between red+black, and me having tried just about every combination I can think of in terms of compression resistance and content hugging priority.....
I really want to understand this, so would be really grateful if someone can explain what additional constraints / changes to constants are required, but more importantly WHY they are required, because to me it doesn't seem clear at all how the layout system comes up with its answers....
Any clarification much appreciated.
Thanks in advance
(All code above is running on iOS 7 and built with Xcode 5.0.2).
You don't need any fancy constraints to do what you want here -- no inequalities or messing with the priorities. In addition to the constraints to the sides, the red view should have 20 to top, 51 to black view, and a height constraint of 114. The black view, has a 20 to the bottom and a height of 94. The superview (yellow) should have zero constraints to top, left and right -- no height. You should have an IBOutlet to the red view's height constraint. When you want to change its height, modify its constraint (don't set frames):
- (IBAction)resizeYellowView:(id)sender {
self.heightCon.constant = 300;
}
Everything is linked together from the top of the yellow view to the bottom with fixed values, so the only thing that can change when the height of the red view changes, is the height of the yellow view.

Views are Horizontally and Vertically Ambiguous with complex layout

I have a UIViewController on my storyboard that has 2 subviews side-to-side horizontally. I added constraints to fix the leading and trailing edges to a constant (20 pts), and another constraint to keep the widths equal. If I assume the following, it should be possible to calculate what the width of each subview will need to be:
the subviews do not overlap
there are no other views present (horizontally, at least)
the width of the screen (the superview) is known
However, XCode gives me a warning that my views are horizontally ambiguous. I'm guessing that means that XCode is not making one of these assumptions, but which one is it? And is there a way for me to instruct XCode to make that assumption?
EDIT: Okay, played with it a bit and got the warning to go away, but it looks like it's not making the first assumption - it's just setting each subview's width to superview.width - 40, and happily burying one view underneath the other. So the question is how to I stop them from overlapping?
EDIT 2: Okay, my actual screen is a lot more complicated than my simple example. Here's what I got:
So in this setup I have 4 views that are vertically and horizontally staggered.  I want the blue, red, and purple views to all be the same subview.frame.size.width = superview.width - 60. The blue and purple are lined up in the left column, and the red is alone in the right column, and all the gaps (between the two columns and between each column and it's nearest edge) are at a constant (20 pts). These 3 tables have a variable height, which I will be setting programmatically as described in James's answer here. At the bottom is a pink view that stretches the width of the screen (minus gaps), and sits at a constant 20 pts below either the purple or the red view, whichever is lower (which I'm attempting to do by giving it a spacing constraint of >= 20 to each view, and I hope that it will pick exactly 20 for one of them). Since all of the heights are dynamic and may not necessarily fit on the screen at the same time, I made their superview a UIScrollView instead of the normal UIView.
When all is said and done, I'm still getting a warning that all 4 of my views are horizontally ambiguous, and that the pink bar is vertically ambiguous. I think it's having trouble realizing what is supposed to go next to what, which is why it thinks it's horizontally ambiguous. And I think it's not picking to place the pink bar exactly 20 pts below either the purple or red views, which is why it thinks it's vertically ambiguous. Can anyone confirm or deny any of these suspicions? Or suggest a way around it? When I run it in the end, I just get this (I made the background of the scroll view yellow, which you can't tell in the storyboard screenshot):
Vertically Ambiguous
Okay, I think I've solved the vertical ambiguous part. I added two vertical constraints between the pink and purple views and two vertical constraints between the pink and red views. For each pair, the first constraint is that the spacing between them must be > 20 pts, and it has 1000 priority. The second constraint is that the spacing is = 20 pts, but it only has an 800 priority.
For example, if the bottom of the purple view ends up being lower than the bottom of the red view (as it is in my first screenshot), Xcode should try to set the vertical distance between the pink and red views = 20, but it will realize that that conflicts with condition that the space between the purple and pink being >= 20. Since the >= constraint has higher priority, the = constraint will be ignored. Now, when Xcode looks at the constraint that the spacing between the purple and pink views being = 20, it checks that against the constraint that the pink and red must be separated by at least 20. Since the bottom of the red view is higher than the bottom of the purple view, the >= 20 constraint between the red and the pink still passes.
So TL;DR, you can set up a view to have a spacing at a given value (x) from the most extreme of multiple views by giving it a >= x constraint with 1000 priority and giving it a = x constraint with <1000 priority for each view you are considering - and my vertical ambiguity problem has been solved. I do not yet have a solution for the horizontal ambiguity for all 4 of the views.
Horizontally Ambiguous
Okay, I got the horizontally ambiguous part fixed now as well. What it boils down to is that constraints in scroll views (and therefore table views) work differently than they do for any other kind of view. Here's what the step-by-step looks like.
Place the UIScrollView
Place a UIView into the UIScrollView to serve as a "contentView" for that scroll view
Add constraints to pin the contentView to all 4 corners of the scroll view AND pin it's width and height (so 6 constraints between the contentView and it's superview - 2 more than usual). Note that the width and the height can be pinned to something much larger than the normal screen size, which is probably why you are using a scroll view to begin with.
Add all of your other views you want in the UIScrollView (UIButtons, UILabels, etc. - I'm just going to assume UILabel from here on so I don't have to type as much, but any kind of UIView subclass will work) as subviews of the contentView, NOT directly as subviews of the UIScrollView
With this setup, the UILabels that are given constraints to their superview will constrain to the contentView, which has a defined size, so nothing is ambiguous.
Alternatively, if you want to fix the sizes of your UILabels (or dynamically calculate them, depending on the functionality of your app) and let the contentView expand to hold them:
Place the UIScrollView
Place a UIView into the UIScrollView to serve as a "contentView" for that scroll view
Add constraints to pin the contentView to all 4 corners of the scroll view AND pin it's width and height
create an outlet for the width constraints on the contentView (let's say we name it contentViewWidthConstraint)
place the UILabels
fix the sizes of the UILabels
create an outlet for the width constraints on the UILabels
Then in the code for viewWillLayoutSubviews
add up the widths of all of the UILabels and any gaps you want between them (as a CGFloat, which I'll call totalWidth)
set contentViewWidthConstraint.constant = totalWidth
And you're good to go! Note that I assumed you were setting the width in most of this example, but it should be just as applicable to height.
The problem is that many different widths of the two views will satisfy the constraints that you've set up. Here are two examples (I drew the shapes stacked vertically to make it easier to see the overlap example):
You can add a horizontal space constraint with a value of 0.

Resources