Autolayout, constraint and autosizing relationship in iOS - ios

I've been following 6 or 7 tutorials already about table view cells, and they have been behaving seriously wrong (for example: as I click a row, the imageview resizes and covers the whole cell).
Since I'm new to iOS I have only read about things like constraints and auto-layout, and understand them theoretically. Given the fact that I have not set up anything related to auto layout or constraint, my storyboard prototype cell have only drag-n-dropped labels and imageviews and the Use autolayout checkbox is checked.
Up to this point, I have the theory that since use autolayout is checked, and no constraint is set up whatsoever, that is the cause of the strange behavior.
Also, in the Size inspector each view (imageview, label, other label) has different autosizing definition.
My question would be what is the relationship between autolayout, constraint, and autosizing

Related

Design Self-Sizing UITableViewCell using .xib, cell doesn't adjust itself in interface builder

I'm trying to use .xib file to design a self-sizing UITableViewCell. However, the cell doesn't adjust it's height according to it's content subviews. I have to adjust cell manually. If the cell is too large, a subview will be stretched to fill the cell. And if the cell is too small, there will be some constraint error alert by interface builder.
The UI is correct when running, but is broken when designing.
When using a .storyboard file to design a self-sizing cell, it works great. The cell can grow or shrink automatically.
Is this a limitation of the .xib file? Or did I miss something?
If you set constraints properly, the UILabel will be set its height and width as per the set constrains and its content.
All you need to do is...
For the first label you need to set Leading, top and trailing constraint
For the second label you need to set Leading, top constraint with the bottom of first constraint, and finally trailing and bottom constraint to the superview.
Do not forgot to set the number of line equal to zero & Line break mode to Word Wrap in the Attribute Inspector.
Also need to set the following
We could consider it a "limitation" ... but it's more a matter of "by design."
When laying out UI elements in Storyboard (including a Prototype Cell), Interface Builder (IB) does a lot of additional work. For an obvious example, you can change the Orientation and your prototype cell will automatically expand its width.
When developing a XIB, though, IB doesn't change your root view's size on its own. Think of it as IB saying "you're designing a XIB, you know what you're doing and you know exactly what you want."
While it's generally a good idea to follow IB's advice and get rid of any "constraint error alerts" it's not required.
There are legitimate instances when designing a cell (or other view) in a XIB where you cannot eliminate all constraint warnings. For example, if I put a UIScrollView in my cell XIB, but the scroll view will not have any content until run-time, IB will tell me it has "Ambiguous scrollable content size." In this case, I know my constraints are correct, and I know the content size won't be defined until I add and constrain subviews at run-time... so I can ignore the warning.
If you find it a hassle to manually resize the cell, but not see constraint warnings, you can (for this example) if your bottom-most constraint is Zero, give it a Priority of 999, or set it to >= 0 ... or, change the Ambiguity option to either:
or:
First set top, left, right constraints of first label and bottom, top, right, left constraints of second label with cell.
Set Lines of labels to 0 then it will work as you are expecting.

How to make UIStackView with yours SubViews with different sizes?

I wants create a ViewController with UIScrollView, UIStackView (Vertical), UILabel and UITableView. But my problem is that I can't set different height sizes to my Views. I did tried write in the field, but XCode erases and set back value. I did tried all options of distribuitions, but I think that my option is "Equal Spacing".
I've added two UIView to test.
I did can make my screen, but this not works on iPhone device and XCode says that it's impossible adjust constraints automatically. This is my objective:
Some fields needs different height sizes. Some labels need 3 lines, other 1 line.
You need to set a height constraint in order for your view to have a specific height within the stack view. Apple's Documentation
If you add constraints to all subviews i.e. top and bottom it will work correctly. Make sure you set translatesAutoResizingMaskIntoConstraints to false

iOS and interface builder: misplaced view (e.g. UITableViewCell)

I am using interface builder to create a masterview details application. However
when I run the app the cell gets misaligned.
Here is how it looks both on the simulator and on interace builder:
Any suggestion on how to fix this?
I have noticed that this happens also in the detail view controller that's why I choose the title of "misplaced view":
The problem in the first screen shot seems to be that you are not supplying a tall enough height for the cell. Thus some of the views on one cell are actually appearing on top of the cell below it. You need to fix your table view's rowHeight.
In the second screen shot, it looks like you are using auto layout but you are not doing auto layout (you have no constraints). You need to position these interface elements with constraints.
Check your constraints in interface builder first and make sure that your UITableViewDelegate is returning the correct heightForRowAtIndexPath:, then report back.
In Interface Builder, if you select one of these views that is not sized correct and then select the "size inspector" tab on the panel on the right (option+command+5), if you have no constraints defined, IB will warn you:
The selected views have no constraints. At build time, explicit left, top, width, and height constraints will be generated for the view.
If you don't see that sort of message, your screen snapshots suggest that you likely have constraints defined for the view which are tantamount to the same thing, left/top/width/height constraints.
The problem is that when you transition to a real device with different width, the layout of the view will not be correct.
If, however, you defined your own constraints (for example, notably using trailing constraint instead of width constraint, using bottom constraint rather than height constraint), you'll find the views will be better adjusted for the device's actual dimensions.
In your first example, iOS 8 will automatically adjust the row height of the cell if you had defined constraints. Something like:
V:|-[nameLabel]-[artistLabel]-[categoryLabel]-[priceLabel]-|
V:|-[imageView]-|
H:|-[imageView(100)]-[nameLabel]-|
H:[imageView]-[artistLabel]-|
H:[imageView]-[categoryLabel]-|
H:[imageView]-[priceLabel]-|
I'm showing it to you in VFL, but you can define it in IB, too. The key point is add constraints so that the vertical height is now unambiguous (i.e. the cell height will be adjusted to fit the labels) and the width is not hard coded, but rather the labels will expand/contract to fill it depending upon the device size.
Conceptually the exact same problem occurs in your second example, that you don't have leading and trailing constraints, but rather IB has defaulted to using leading and width constraints, which will not work as you go from device to device. For example, if you just want the text view, but have it adjust for the size of the device's screen, you might have constraints equivalent to the following VFL.
H:|-[textView]-|
V:|-[textView]-|

Self Sizing UITableViewCells with UITextViews

I am using sizing classes to make two separate layouts for a UITableViewCell. I am using IB to create all of the constraints. I have four UILabels and one UITextView in the cell. The wAny, hAny class works perfectly.
The hCompact, wRegular class was getting a broken vertical constraint, which I fixed by giving the vertical spacing constraint from the UITextView to the content view a 999 priority instead of 1000.
An issue still exists that causes the UITextView to collapse all the way (or the cell to be sized such that it covers the UITextView completely) when the cells are first presented. All out-of-view cells render fine when they come into view, and the original cells also render appropriately when they come back into view after going out of view.
I want to be able to use self-sizing cells and have the UITextView render correctly upon load. It would also be nice to know why I had to set the priority of the constraint to 999 to fix that layout warning at run-time.
This is only occurring on my hCompact, wRegular class which, in my opinion, has a less vertically complex set of constraints set up than the other sizing class. I have included an image of the UITextView selected and showing the constraints on the right. I gave the UITextView a lime background for debugging. As you can see, it looks rather odd in IB. I will provide any other info as requested.

Resizing a UITextView in UIScrollView using Auto Layout issue

I really hate to ask here because I usually try to figure things out on my own. But on this one I've stuck for days and can't find a solution anywhere online.
I have a ScrollView containing multiple subviews. I've got an image view and two labels at the top with fixed heights. Then there is a UITextView and another ImageView (see pictures).
I add the text to the text view programmatically so it should have a dynamic height and the ImageView should move to the bottom so you can scroll. I don't want the TextView to be scrollable in itself but I want all the subviews to move as well.
I know I should be able to solve this issue using constraints. But I feel like I've tried everything and nothing worked yet. It worked when I disabled auto layout and moved the views manually. I'm wondering if there is a better way though.
As you can see I pinned the TextView to the ImageView above with a 1,000 priority and to the ImageView below with a 1,000 priority. The height constraint can not be deleted so I set it to the lowest possible priority. The ImageView on the bottom is pinned to the bottom of the superview with an absolute height. Its height constraint also has low priority. (I can post an image of the ImageView's constraints, if it helps)
I also tried adapting the frame programmatically but this is not working well in combination with auto layout. (If it helps I can of course post the code)
What am I doing wrong? Shall I just disable auto layout and do it manually? This seems unclean to me. Is it even possible to do?
I really appreciate your help :)
Greets,
Jan
Make sure the Scrolling Enabled attribute on the UITextView is unchecked in Interface Builder. I believe that the Auto Layout system takes that into account when it calculates the intrinsic content size.
If somebody is struggling with a similar problem: This is what I ended up doing:
Remove all subviews from the ScrollView in IB
Programmatically add a single UIView to the ScrollView.
Add all the views to the UIView as subviews (move them using setFrame)
Set the Frame of the UIView appropriately to the subviews
Set the ScrollView's contentSize to the size of the UIView.
A little more work but it finally works. This follows Apple's mixed approach guidelines that can be seen here (look for UIScrollView): http://developer.apple.com/library/ios/#releasenotes/General/RN-iOSSDK-6_0/index.html
The problem is the height setting. You somehow have to try to delete it. If you have added other constraints that are "sufficient", it should become deletable.
At the moment you have one user constraint for the height that is "Greater or equal" and an "Equals" constraint as well. Clearly, those are not working well together.
Maybe there is a conceptual error as well. The lower image view should not be fixed in position, so the distance to the lower image view will not be a "sufficient" constraint to let you delete the fixed height.
I think it should work if
the lower image view has a fixed height and
a fixed distance to the text view above, and
the text view has a minimum height as well as
a fixed distance to the image view above
(which should be fixed in relation to the superview).

Resources