Autolayout Contraints for a View from XIB - swift

I am loading a view (shaped a circle) from a circle. I want to make sure, the circle's size adapts to various screen sizes. So far I tried placing the view inside another view, pinning the margins to the superview and then setting the superview's aspect ratio to 1:1. This gives me a circle. However, now, I want to change its size. Currently, the superview's size is specified by another subview in it, a label. Depending on the contents of the label, the superview's size changes (I have set the label's font size to Autoshrink). If I try to add a constant to the margin constraints it works, but looks the same size across different screen sizes. Also, I tried adding a multiplier, while the multiplier works for trailing and bottom margins, top and leading margins don't get affected by setting the multiplier. Below is a screenshot of the IB (Today View is the shape in the question).

You have a good start - aligning both center X & Y, 1:1 ratio. All you need to add is two sets of top/bottom and leading/trailing constraints with different priorities. Here's an example, which combined with the three constraints you have, would center a view in all orientations with a 10 point border along the narrower axis:
Priority == 750
Top == 10 points
Bottom == 10 Points
Leading == 10 points
Trailing == 10 points
Priority == 1000
Top >= 10 points
Bottom >= 10 Points
Leading >= 10 points
Trailing >= 10 points
You may see errors/warnings while doing this because IB doesn't know how to render it, but once you've completed this, you'll have what you need.
EDIT:
From memory, there are points and pixels. When and where possible, try to think in terms of points. About the only time you may wish to think in terms of pixels is with images. (There may be other measurements of graphics, but again, I'm writing from memory.)
Points should be consistent across device size - so if you have a 100x100 square in a 4 inch iPhone screen, it will be the same size on a 12.9 inch iPad Pro.
More importantly, the margins can be set the same using auto layout. A 25 point margin will be the same on both of those screen. So in my example above, you will get pretty much the largest rectangle possible across all devices since you are setting margins, not view size.
I did a dive into screen sizes last year, and these are the current screen sizes:
//iPad Pro 1366x1024
//iPad 1024x768
//iPad Mini 1024x468
//iPhone 6 Plus 736x414
//iPhone 6 677x375
//iPhone 5 568x320
//iPhone 4 480x320
So based on this the above constraints would yield a 300x300 square on an iPhone 4 (iPhone SE also) as the narrowest axis will be 320 less two 10 point margins. And on an iPad Pro 12.9 inch it will be a 1004x1004 square.
When you create constraints in code, you can also create a layoutMarginGuide with this code:
let margins = view.layoutMarginsGuide
This should be the same thing as keeping the "contain to margins" checkbox checked in IB. Essentially this is the recommended size of margins for each device. (I believe this should also include the status bar, tab and navigation bars, and even the iPhone "phone call top banner (sic)". But I've had some issues with this so YMMV.)
EDIT 2:
Putting this all together, what you are defining through "auto layout" is a very fluid way of maximizing the size of a square (or in your case, a square turned into a circle). By setting two sets of margins, one set equal to but with a high priority, you are letting auto layout know that it may break this over required constraints. The second set with greater than or equal to values is required.
Thus, in a 480x320 device, the top/bottom margin constraints that cannot be met ("equal to") can be broken, and in landscape the leading/trailing ones that cannot be met will be broken. Remember, you already set the center X/Y, so the view will be centered, and you set the 1:1 ratio so it will be square. (As long as you did not touch the priorities - the default is required.

Related

Is there a way to define a view's frame in terms of inches instead of points?

Given any screen resolution, is there a way that I can figure out the amount of points in an inch? For instance, if I wanted to create an NSView that was 8.5 inches by 11 inches (like a sheet of a paper), is there an algorithm that will allow me to obtain the correct point values for the frame across many different types of Macs and screen resolutions?
It's not straightforward. I'm not sure there's a good way. I can provide an approach, but I haven't confirmed that this works reliably:
First, you can use CGDisplayScreenSize() to get the screen's physical size in millimeters. You can obtain the CGDirectDisplayID for a screen from NSScreen, which you can, in turn, get from the window. Obtain the screen's deviceDescription and get the value for the "NSScreenNumber" key. That may need to be cast to CGDirectDisplayID.
The problem from there is that the display mode may not fill the screen. It could be letterboxed or pillarboxed. Or, it might be stretched. This should be fairly uncommon these days, but still possible. You can obtain the display mode using CGDisplayCopyDisplayMode(). To determine if it's stretched, you can examine its ioFlags to see if they contain the bitmask kDisplayModeStretchedFlag (declared in IOKit).
If it's stretched, the screen's frame will have to be mapped to its size in millimeters separately for the X and Y axes. You assume the screen's frame.width (in points) maps to the full physical width, and similarly for the height.
If the mode is not stretched, you'll have to check the aspect ratio of the frame and the screen physical size to see if it's letter- or pillarboxed. If the aspect ratios are very close, then it's presumably not. That case is similar to the stretched case, but the width and height mappings should be equivalent.
If the aspect ratios differ significantly, then you compare them. If the screen's physical aspect ratio is larger than the frame's, then the screen is physically wider than the mode is using (pillarboxed). So, you compute the mapping from points to millimeters from the two heights. If the physical aspect ratio is smaller than the logical one, then the mode is letterboxed and you use the widths to compute the mapping.

Stack view constraints changes top-layer's view width

I have a stack view holding 2 images.
One image's width to be lower or equal to 140 and 1:1 ratio
Stack view top constraint 20 and trailing constraint 5
When I want to set the stack view leading constraint to 5 (looking at the safe area leading) it enlarges the safe area to a width of 1920 and I have no idea why it does that.
It might have something to do with that the total width of the stack view (including the constraints) is smaller than the width of the safe area so it's ignoring the images width constraint and enlarging it to the default size (1920)? Because, when I change the stack view's distribution to fill proportionally instead of fill equally it does obey to the image's width constraint and the safe view's width stays normal.
If I am thinking correctly, how can I find a workaround for this?
Thanks in advance.
EDIT: I was trying to think logically and I found a solution by changing the image's width to GREATER or equal to instead of SMALLER or equal to. I was following a devslopes guide and in that Xcode version (Beta XCode9) it did work, it just gave a warning it wasn't obeying that constraint anymore (I think it was saying that, I just saw the width being red). So it works now, if anyone has this problem following their guide, just do what I said and it will work.

How to adapt the position of a UIButton to a background image for all iPhone sizes?

I just begin swift and I'm facing a simple problem:
I can't adapt a UIButton to an image in my storyboard for all iPhone sizes. I work with a storyboard with the size of an iPhone 6s Plus because I have one. When I run my test, all it's OK but when I run my test with iPhone 5 simulator, nothing is good.
This image shows the button is in the good place on iPhone 6 plus but no to other sizes.
I tried so many different constraints but nothing seem to work.
In summary: How can I set constraints to position a button at the circle in the background image (as shown in the linked drawing), regardless of phone size?
Try setting your constraints to a percentage.
Control-drag from your button to your view.
Shift-click to select Horizontal Spacing and Vertical Spacing.
Click Add Constraints.
Now, you should have 2 constraints for the button, relative to the superview.
In the Attributes Inspector for each constraint, check to ensure the button's X and Y are relative to the trailing edge and bottom of your superview. For example:
First Item: Button.Center X
Relation: Equal
Second Item: Superview.Trailing
First Item: Button.Center Y
Relation: Equal
Second Item: Superview.Bottom
In each constraint, set the constant value to zero.
Then, set the multiplier value to a percentage or fraction.
For example, if you want the button to be at the halfway point, regardless of device size, enter a multiplier of 50% (or 1/2 or .5 if it won't take the percent value - sometimes it won't accept one version of a value, but it will accept another expression of the same thing).
The percentage is multiplied by the superview's values. The superview's trailing edge is the max X value, and the superview's bottom edge is the max Y value.
Your button appears to be around a third of the way down the view, and about a quarter of the view on the left. So you might try setting the Button.Center X multiplier to 25% or 1/4 or .25, and the Y multiplier to 33% or 1/3 or .33
Note also that under a constraint's Second Item dropdown, you can select whether the value is relative to the margin. If that is not selected, the multiplier uses the full width or height of the superview. Selecting Relative to margin uses the width of the superview minus any trailing or bottom margin. That could throw off your percentages. I recommend leaving Relative to margin unselected when playing with your values.
Here are images for the end constraint values:
Note that the button doesn't seem to be centered until you look at the preview. Running the simulators for the different sized phones gave me the same results as shown in the preview: button correctly centered in the circle.

How to adjust multiple rows of labels in Xcode so that they occupy around 70 % of screen height?

I'm trying to build an app that has just a single portrait oriented view. There is a title on top and results label at the bottom of the view, these are locked to top and bottom and center, no problem here.
Now this is the tricky part. I have 9 rows of labels, most single row but couple span out to 2 rows. I want them to spread out evenly between the title and the result-label.
I lock the first label to top-left, lock the leading edges and then set equal vertical distance constraints between the labels. Otherwise ok but the last labels on 3.5 inch display overrun my results -label.
So I adjust either the fontsize or make vertical distance between labels smaller or both. 3.5 inch problem fixed but now there is a big empty gap between the last label and result. On iPhone 6 its really ugly.
I have tried all sorts of methods but can't just get this working.
So basically: how do I reserve 10 % of view height from top and 20 % from bottom and tell Xcode to use the rest 70 % (and all of it) for my 9 rows of label, evenly?
Thanks for help!
Would have posted an image but no rank for such things...
If I understand you right, you need several flexible spaces that will all be the same size. One space in-between each of the labels.
Create UIViews to put between each label, set them all to have equal widths or heights and anchor each one to the views it is supposed to sit between.
I got this idea from another SO question: Springs in Auto Layout: Distribute views evenly, with constraints, in Xcode 5

StretchableImageWithLeftCapWidth stretching wrong portions

I am trying to use a UIImage with stretchableImageWithLeftCapWidth to set the image in my UIImageView but am encountering a strange scaling bug. Basically picture my image as an oval that is 31 pixels wide. The left and right 15 pixels are the caps and the middle single pixel is the scaled portion.
This works fine if I set the left cap to 15. However, if I set it to, say, 4. I would expect to get a 'center' portion that is a bit curved as it spans the center while the ends are a little pinched.
What I get is the left cap seemingly correct, followed by a long middle portion that is as if I scaled the single pixel at pixel 5, then a portion at the right of the image where it expands and closes over a width about twice the width of the original image. The resulting image is like a thermometer bulb.
Has anyone seen odd behavior like this and might know what's going on?
Your observation is correct, Joey. StretchableImageWithLeftCapWidth does NOT expand the whole center of the image as you would expect. It only expands the pixel column just right of the left cap and the pixel row just below the top cap!
Use UIView's contentStretch property instead, and your problem will be solved. Another advantage to this is that contentStretch can also shrink a graphic properly, whereas stretchableImageWithLeftCapWidth only works when making the graphic larger.
Not sure if I got you right, but LeftCapWidth etc is made for rounded corners, with everything in the rectangle within the rounding radius is stretched to fit the space between the 'caps' on the destination button or such.
So if your oval is taller or wider than 4 x 2 = 8, whatever is in the middle rectangle will be stretched. And yours is, so it would at least look at bit ugly! But if it's not even symmetrical, something has affected the stretch. Maybe something to do with origin or frame, or when it's set, or maybe it's set twice, or you have two different stretched images on top of each other giving the thermometer look.
I once created two identical buttons in the same place, using the same retained object - of course throwing away the previous button. Then I wondered why the heck the button didn't disappear when I set alpha to 0... But it did, it's just that there was a 'dead' identical button beneath it :)