it's the first time I'm seriously using autolayout so I'm sure I'm missing something obvious.
I have a very simple view embedded in a UINavigationController. There are three subviews: a UIWebView, a UIToolbar (which in turn contains three UIBarButtons) and a UIActivityIndicatorView. It's just a basic browser view, basically.
I managed to have everything appear as it should even on rotation, except for the toolbar: if the view is first loaded in vertical orientation, going landscape will not resize the toolbar from 44 to 32 points. Originally, before I wiped everything out, it did resize the toolbar BUT the built-in UIBarButtonItems appeared lower and cut off, as if the toolbar was still 44 points tall but pushed 16 points out of the screen.
If the view is first loaded horizonttaly, the bar is 32 points high but the built-in UIBarButtonItems appear still like that, and rotating to vertical will keep it at 32 points.
I honestly have no idea how to make this work as expected (ie. resize properly when rotated, with the buttons showing properly!), so if anyone could point me in the right direction -- pun intended -- I would be really grateful.
The activity indicator is right in the middle of the frame, with these constraints:
Align Center X to Superview
Align Center Y to Superview
The web view is set to use all available space from the top of the view (including the navbar) up to the top of the toolbar, and has these contraints:
Top Space to Superview
Bottom Space to Toolbar
Align Trailing to Toolbar
Bottom Space to Toolbar (it's actually listed twice)
Align Leading to Toolbar
The toolbar is a mess. It has:
Bottom space to Superview
Align Center X to Superview
Top Space to Web View
Align Trailing to Web View
Top Space to Web View (listed twice)
Leading Space to Superview
Align Leading to Web View
Bottom Space to Bottom Layout Guide
The problem is that by not adding any constraints at all, the web view is much bigger than it should be, and the toolbar doesn't even show.
I mostly set these constraints using the horizontal and vertical red bars (similar to springs and strouts) in the 'pin' popover for autolayout, but I'm starting to think that's not the most appropriate approach.
Note that I'm not trying to use autolayout within the toolbar, I read that it wouldn't work and I'm just using the built-in buttons plus a couple of labelled ones (those 'arrows' are really unicode characters, I may change them to prettier images at some point.)
Thank you in advance. :-)
Related
I understand the old Struts and Springs method of aligning, sizing and distributing views in Interface Builder. However, I cannot seem to figure out how to evenly distribute views using auto layout with Xcode 5. There was a way to do it using Xcode 4, but that option is gone.
I have 7 buttons arranged in a vertical stack. On a 3.5" layout, it looks great. When I preview the screen in the 4" layout, all of the buttons remain tightly packed and there is a large amount of space below the last button.
I want them to stay the same height, but I want the space between them to be able flex so they can spread out across the screen.
I've been able to get the height of the buttons to flex and fill the space, but that is not my desired behavior. I would like to learn how to use Auto Layout to replace my old Springs behavior, but I can't seem to find any way to do it through Interface Builder.
I'm ok with the top button either being a fixed space from the top edge or a proportional space from the top edge, likewise for the bottom button and the bottom edge. Those are less important to me, I'm good with either.
But I really need to figure out how to evenly distribute the extra space between each of the items in the view.
EDIT Note that in iOS 9 this technique will become unnecessary, because a UIStackView will perform distribution automatically. I'll add another answer explaining how that works.
How to Perform Even Distribution Using Autolayout
The simplest way to do this in Interface Builder alone (rather than constructing constraints in code) is to use "spacer" views:
Position the top and bottom buttons absolutely.
Place spacer views between all the buttons. Use constraints to position them horizontally (centering them horizontally is simplest) and to set their widths.
Make constraints between each button and the spacer view above and below it, with a Constant of 0.
Now select all the spacer views and set their heights to be equal.
The first screen shot shows me setting this up in IB:
I have deliberately not corrected for the "misplaced views" because I want you to see what it looks like while I'm designing the constraints. Here's the result on both a 4 inch and a 3.5 inch screen:
I have left the spacer views black, just to show you how this technique works, but of course in real life you would make them transparent and hence invisible! So the user sees just your buttons, evenly distributed on either height of screen.
The reason for the use of this technique is that although the notion of equality performs the distribution of values you are asking for, constraints can apply equality only between aspects of views; thus we need the extra views (the spacer views) so that we have things we can make equal to other things (here, the heights of the spacer views).
Other Approaches
Obviously, a more flexible approach is to assign the constraints in code. This may sound daunting, but there's a lot of third-party code out there to help you, such as this sort of thing.
For example, if we have a (possibly invisible) superview whose height acts as a boundary to dictate maximum vertical distribution of our four buttons, we can pin their tops to the vertical center of that superview with a constant of 0 but a multiplier of 0.000001, 0.666667, 1.33333, and 2.0 respectively (if we have four buttons); now the buttons will stay vertically distributed even as the superview changes size in response to screen height or whatever. [In Xcode 5.1, it will be possible to set that up in Interface Builder, but in earlier versions of Xcode it is not possible.]
In iOS 9 / Xcode 7 this problem will be trivially solved in IB. Simply select the buttons (or whatever it is you want to distribute vertically) and choose Editor > Embed In > Stack View. Then you simply configure the stack view:
Provide constraints that position and size the stack view itself. For example, pin the four edges of the stack view to the four edges of its superview.
Set the stack view's attributes. In this case we want Vertical axis, Fill alignment, Equal Spacing distribution.
That's all! However, you may be curious about how this works, because it is still possible to do the same thing manually in code. A stack view performs distribution, not by inserting spacer views, but by inserting spacer guides. A guide (a UILayoutGuide) is a lightweight object that behaves like a view for purposes of layout constraints, but is not a view and therefore doesn't have to be made invisible and doesn't carry any of the overhead of a view.
To illustrate, I'll do in code what the stack view is doing. Presume we have four views to distribute vertically. We assign them constraints for everything but their distribution:
They all have absolute height constraints
Their left is pinned to the superview's left, and their right is pinned to the superview's right
The top view's top is pinned to the superview's top, and the bottom view's bottom is pinned to the superview's bottom
Now, presume we have references to the four views as views, an array. Then:
let guides = [UILayoutGuide(), UILayoutGuide(), UILayoutGuide()]
for guide in guides {
self.view.addLayoutGuide(guide)
}
NSLayoutConstraint.activateConstraints([
// guide heights are equal
guides[1].heightAnchor.constraintEqualToAnchor(guides[0].heightAnchor),
guides[2].heightAnchor.constraintEqualToAnchor(guides[0].heightAnchor),
// guide widths are arbitrary, let's say 10
guides[0].widthAnchor.constraintEqualToConstant(10),
guides[1].widthAnchor.constraintEqualToConstant(10),
guides[2].widthAnchor.constraintEqualToConstant(10),
// guide left is arbitrary, let's say superview margin
guides[0].leftAnchor.constraintEqualToAnchor(self.view.leftAnchor),
guides[1].leftAnchor.constraintEqualToAnchor(self.view.leftAnchor),
guides[2].leftAnchor.constraintEqualToAnchor(self.view.leftAnchor),
// bottom of each view is top of following guide
views[0].bottomAnchor.constraintEqualToAnchor(guides[0].topAnchor),
views[1].bottomAnchor.constraintEqualToAnchor(guides[1].topAnchor),
views[2].bottomAnchor.constraintEqualToAnchor(guides[2].topAnchor),
// top of each view is bottom of preceding guide
views[1].topAnchor.constraintEqualToAnchor(guides[0].bottomAnchor),
views[2].topAnchor.constraintEqualToAnchor(guides[1].bottomAnchor),
views[3].topAnchor.constraintEqualToAnchor(guides[2].bottomAnchor)
])
(Obviously I could make that code cuter and shorter using loops, but I have deliberately unrolled the loops for clarity, so that you can see the pattern and the technique.)
If an insane client had asked for this functionality, I would have told him it was impossible.
Yet here I have your everyday UITableView inside a UIScrollView, setup in Interface Builder. The scroll view has vertical scrolling enabled, but not horizontal. So what the heck is THIS:
Note the bottom right -- that capsule is the visible scroll thumb in a horizontal orientation. If you scroll the table view up and down, that thumb moves left and right... INSIDE THE VERTICAL SCROLL TRACK. The width of the track is the complete representation of the height of the scroll view's contents; I scroll to the top of the table view, and the thumb moves to the left, so I can just see the right side of that capsule shape.
This has to be some kind of weird bug, right? Any ideas how to shake this loose?
Looks like I posted too soon. I deleted the table view in IB and re-created it. The problem went away. Must have been some glitch in Interface Builder.
I've read a lot of documentation but still don't really understand how that UIScrollView works.
I have an example where I use an UINavigationViewController with the status bar (little top bar with wifi, battery, etc., icons) and a navigation bar (with the "back" button).
As the first subview of the UINavigatioViewController's main view I have a UIScrollView. Inside it I have created several subviews that make it's contents size to be 500 points.
In the "viewDidLoad" method I set the scroll view's "contentSize" equals to 500. But it doens't completely scroll down to show the last subview.
I read that I should add some points to the "contentInset" because of the "bars". I don't really know why. Isn't the scroll view inside the main view that is correctly framed? Why does it need to take the "bars" into account?
Anyway, I read that it should be like 64 points (44 navigation bar + 20 status bar). But it doesn't work.
The "magic" number (at least for me) is 84 points. I must add that quantity to the content size (584) or use it as:
self.scrollView.contentInset=UIEdgeInsetsMake(0.0,0.0,84.0,0.0); // AT THE BOTTOM!!
I'm really confused about this. Could anyone give a hand on understanding it?
Thanks.
self.scrollView.contentInset=UIEdgeInsetsMake(0.0,0.0,84.0,0.0);
UPDATE
I have seen that because I made my ScrollView size bigger in Interface Builder in order to add new elements beyond the normal small visible size, it had a "frame" size near to 500 points.
I set it frame size to 416 (just to fit and cover all the visible space) and now with a content size of 500 points (without any additional inset values) it scrolls perfectly.
But I still don't understand the previous behavior...
Couldn't find anything on the net about this and wondered if anyone on SO has a solution.
I have an NSView with several subviews that are centered by removing the left and right anchor points. When I resize my view, programatically or with the mouse, to a smaller width than the subviews: it pushes them off center. Has anyone come across this before and do you have a solution?
EDIT: I want to be able to resize my view to a zero width. The reason being, the view is actually part of a split view and I have hooked up a button to 'collapse' it. When it collapses all of the subviews are pushed off-center and aren't re-centered when the view is resized, effectively un-collapsing it.
I have solved my problem now and thought I would share incase anyone comes across this issue in the future.
No amount of playing with autosizing options or view layouts in Interface Builder seemed to stop my subviews from getting moved off center. I did manage to find this link here and from this page, the advice:
Springs and struts, as currently
implemented, are really no good for
anything but keeping either one or
both sides of a view "stuck" to the
nearest edge. Any sort of centering
behavior, division of gained/lost area
between multiple views, etc. has to be
done by hand.
Based on this I overrode my view's setFrame: method and manually laid out my subviews using their setFrame: method. This works great and gives me the results I'm looking for.
There is the same issue using NSSplitView, resizing here one Subview to be smaller than the Subview Subviews makes sense,e.g. having small charts in the upper subview, and an rss reader in the lower subview.
If you want to show only the rss reader in the lower subview, you can "hide" the upper subview, but after resizing the upper subview the NSImageView are not layed out the same as in the beginning. Check this nib/xCode Project and the following screenshot to see this behaviour.
Only workaroung is to override the resize function to stop getting smaller.
I've added an NSSegmentedControl to a pane on an horizontal split view on a normal window. I thought that adjusting the springs would make the segmented control centre itself automatically, but it doesn't. How can keep it centred?
I was told to add an observer for when the parent view's frame changes, and manually adjust the position of the centered view, but I've no idea how to go about that.
Any ideas are very welcome.
The layout you describe sounds totally plausible in IB.
Just testing it out, I dropped a segmented control in one of the views in a split view, and it stays centered, so I'm sure there's just a configuration issue.
Be sure that:
Your split view is set to stay centered and resize appropriately with the window as appropriate (just to make sure the behaviour you're seeing is not related to the segmented control's container not resizing properly).
You position your segmented control dead centre, and then leave all 3 horizontal "springs" unclicked (ie: no left anchoring, no right anchoring, no horizontal growing).
I don't know if it's been "fixed" in recent OS versions, but if I recall correctly, NSSegmentedControl does a -sizeToFit each time segments change. If the control isn't changing at all, Jarrett's instructions should work.