The iOS 9 readableContentGuide is a UILayoutGuide (essentially, a thing you can pin constraints to) that all UIViews have. The idea is to keep subviews with text from being too wide on iPad in landscape.
It's easy to configure this in code (v1 is the subview, v is its superview):
NSLayoutConstraint.activateConstraints([
v1.topAnchor.constraintEqualToAnchor(v.readableContentGuide.topAnchor),
v1.bottomAnchor.constraintEqualToAnchor(v.readableContentGuide.bottomAnchor),
v1.rightAnchor.constraintEqualToAnchor(v.readableContentGuide.rightAnchor),
v1.leftAnchor.constraintEqualToAnchor(v.readableContentGuide.leftAnchor)
])
Now then. So far so good. However... In two different WWDC videos, it is claimed quite explicitly that you can configure pinning a subview to its superview's readableContentGuide in Interface Builder.
But they don't explain how you do that.
So my question is: How do you do it?
Pin the subview's edges to the superview's margins as usual.
Now, in the superview's Size inspector, check the Follow Readable Width checkbox:
Related
So I've followed all the best practices with respect to having a scrollable content view that works with autolayout (first have one direct subview of UIScrollView, add all the pin constraints, etc), especially when you have a UITextView (i.e. disable scrollingEnabled on the text view)
for example here, or just googling UIScrollView and Autolayout you'll find a lot of tutorials that rehash the same thing.
I've done all this, but am noticing that the scrollView is calculating a contentSize that does not match the contentView's height. I have no idea why this is:
I expect moderators to point out other questions. I looked around and nothing really matched what I'm seeing...
For completeness, it was DonMag's comment that solved it. Unknowingly, the constant was not set to 0, which explains why the contentSize.height WAS 680pt larger than the content.
Think before you answer because this question may be deeper than it appears.
Do we really need autolayout and constraints for an OSX app that has a fixed interface size?
The only reason for constraints and autolayout on iOS is the different sizes when you rotate the application or between devices but on OSX the reason may be scaling the interface, because there is no rotation. In this specific case the interface has a fixed size.
You interface is really fixed? No resizable windows or anything? If so, nope, you totally don't need autolayout. Just disable the "Use Auto Layout" checkbox in the File Inspector for your xib. That will allow you to use the old-fashioned Autoresizing masks, which, if your app truly has a fixed interface size, you don't even need that.
Layout your interface in IB however you like, and you're done.
I'm not sure if I thought deep enough or onderstand the interface builder enough, but I found out that the buttons keep the size I want them to if I use the constraints. Without constraints and word wrap on, your (my) buttons resize to fit around the text.
Also when you need to resize subviews to fit the content they're showing and you don't have constraints set, you tend to get a messy interface inside your window. My experience is that constraints not only help you when your window resizes. It keeps your interface objects placed correctly in position of one another and with the right size even when content in the different view objects change.
I'm using Xcode 6 beta 5 at the moment, eager to try out the cool self-sizing collection view cells functionality introduced in iOS 8. It was introduced in the WWDC 2014 session 226: "What's New In Table Views and Collection Views". Links:
https://developer.apple.com/videos/wwdc/2014/
http://asciiwwdc.com/2014/sessions/226
http://blog.indragie.com/
All you gotta do, they said, is that you have to set auto-layout constraints on the contentView of your collection view cell or implement sizeThatFits:. The former sounds easier, so I definitely want to use auto-layout.
When got into Storyboard editor (or IB) though, it appears that you you cannot access the contentView property of a prototype collection view cell. Is this true?
I did set a few constraints between a label (direct subview of the prototype cell) — I pinned its four edges to the cell's bounds itself, hoping that the label's intrinsicSize would provide the needed width for the cell. No avail: I verified that none of these pinning constraints were applied onto the contentView:
- (void)awakeFromNib
NSLog(#"%s... contentView.constrants == %#", sel_getName(_cmd), self.contentView.constraints);
}
... prints out...
awakeFromNib... contentView.constrants == (
)
... no matter what constraints I set in Storyboard.
Am I missing something or must I do this auto-layout in code?
I'm having trouble getting a UIScrollView to respect the constraints I put in interface builder.
All I need to be able to do is set the content size of the scroll view from within IB.
The UIScrollView contains a single UIView.
Constraints on the UIScrollView:
Constraints on the UIView:
I've read through the documentation, and so have set things up as follows:
the UIScrollView has constraints pinning it to its superview, thus defining its size from outside
the UIView (content) has a fixed size (through width and height constraints)
the UIView is pinned to the UIScrollView, thus defining the content size
However, IB won't let me enter these constraints. If I change the 'Bottom Space' constraint between the view and the scroll view, shown in the image as -2196, to 0 (thus pinning the lower edge of the scroll view), then the 'Top Space' constraint resets to a non-zero value. The same happens in reverse. (I haven't yet tried in Xcode 5, which has a far saner approach to invalid constraints in that it doesn't just throw yours away when it feels like it.)
What am I missing?
Every time I've tried to do something even mildly sophisticated with constraints in Xcode 4's Interface Builder, I've eventually given up and either written the constraints in code or switched back to springs'n'struts and layoutSubviews (usually after crashing Xcode a few times).
That said, there is another approach to laying out a scroll view with content in IB. Just make the scroll view as big as its content size, and rely on the view controller (or some containing view controller) to resize the scroll view (or its superview) and let the constraints shrink down the scroll view's frame at runtime. The window's root view controller will always set its view's frame to the screen size, regardless of its size in the nib or storyboard, and that resizing flows down the view hierarchy.
I described this approach in more detail in this answer.
If your scroll view's content size is really supposed to be 2196 points tall, this probably won't work so well. I don't have anything better to suggest in that case.
I'm trying to create a scrollable area in the middle of the screen - above it are a few non-scrolling labels, and below it are some non-scrolling buttons, so I only placed the UIScrollView in interface Builder in the middle of the window. I set the outline of the UIScrollView to be the full width of the iPad, 768 pixels, and about 700 pixels high.
I can place other UI elements within the UIScrollView as children of it, and I can scroll those by setting (in the view controller):
#define SCROLL_AREA_VERTICAL_HEIGHT 1200
...
[myScrollView setContentSize:CGSizeMake(768, SCROLL_AREA_VERTICAL_HEIGHT)];
[myScrollView setNeedsDisplay];
When I look at this in Interface builder, it seems to work, I can see only the UI elements that happen to fit with in the 700-pixel or so frame of the UIScrollView as set in Interface Builder. When I actually run it, though, I can see the UI elements that should be hidden below the lower boundary of the UIScrollView frame, and when I scroll up, the elements at the top don't become hidden by the top edge, but rather move up and over the labels on the top that are supposed to be static. In other words the boundary of the scroll area isn't actually hiding the elements that scroll off of it. What am I doing wrong?
Well i had a problem that was a bit like yours, don't know if it would work for you but try selecting the view in interface builder, and in the atributes inspector there is a box with a checkmark that sais clip subviews, check it and try. That was the solution for me. Hope it helps.