I applied flexible height & width to my UILabel and now I want to use that type of functionality by using Auto Layout.
I am able to increase height and width of UILabel as Device width and height, but X and Y is not changed according to Device width and Height.
Ex:-
Device :- iPhone 7
UILabel :-
X : 20
Y : 120
Width : 300
Height : 30
Device :- iPhone SE
UILabel :-
X : 20
Y : 120
Width : 245
Height : 25
Now problem is that Size of UILabel decrease with aspect ratio but X & Y coordinate was not changed.
According to flexible height & width that will set like 17 & 102, but in auto layout it was not change.
Constraint :
Constraint Image
You have fixed X and Y Position for your label (Which is not device specific)
If you need to achieve this you need to set X and Y according to Centre of your view
I have create to set centre X (For Y Pos )
And How I have set centre of Y Pos
EXPLAINATION
The centre of UIView according to self.view is 318.5 and required space from top is 20 so final multiplier is 20:318.5
as every view has different centre
For Iphone SE centre would be around 17
Don't Forgot to set First Item to Label.Top as we need 20 from TOP
OUTPUT:
Hope it is clear to you :)
I have attach a image to make a label height dynamically. Select trailing constraint and change relation from "Equal" to "Greater Than Equal". Make sure number of line of label should should be "0".
I would like bar width equal to 30 pixels.
barData.barWidth let me change it but this is proportional to chart width and number of bars to display, which display a big bar on iPad for only one element.
Do you have an idea?
Thanks.
You Can not fix BarSize directly in ios-charts but you can change the default ratio width of the bar.
By default barWidth ratio is 0.85 so based on this it will cover 85% area of the chart if you have only 1 Bar on the chart and if you have 2 it will calculate the ratio based on Bar count so you can set approximate bar width with this property.
Default value:
/// **default**: 0.85
open var barWidth = Double(0.85)
You can set:
let chartData = BarChartData(dataSet: chartDataSet)
chartData.barWidth = Double(0.01)
chartData.barWidth = Double(0.10)
chartData.barWidth = Double(0.25)
chartData.barWidth = Double(0.30)
chartData.barWidth = Double(0.50)
like that you will achieve your fix width between 0.01 to 1.00.
Hope this will helps!
Assuming chart width is fixed:
step 1: find the ratio for required width in scenario where there is only one element on x-axis (for me it was 0.05)
step 2: set the bar width to this ratio multiplied by element count on x-axis
data.barWidth = 0.05 * Double(xArray.count)
This will work because max width for a single bar is inversely proportional to number of elements on x-axis
For variable chart width you will need an additional factor for bar width correction: (original chart width/current chart width)
You can add a chartView to the scrollView, then set the chartView.widthand scrollView.contentsize
width = values.count * fixedWidth
chartView.width = width
and
scrollView.contentSize = {width,scrollView.height}
I'm trying to find out what the values of the left and right views in a constraint equation are.
Currently this is how I see it.
The origin-point (0,0) in the coordinate system is at the top left.
Therefore views.attribute that are closer to the top and left are smaller.
In the image posted above.
RedView.Leading has a higher value than BlueView.trailing.
The equation is satisfied because 8 is added to BlueView.trailing.
The same would apply to the circled constraint in the image below.
superView.top is less than greyView.top because superView.top is on origin.x .
My question is are the values relative to the origin point ?
Theory of Relativity in Auto Layout
Short answer:
Yes and no. Actually more no. But most importantly: It's irrelevant!
Detailed answer:
Layout attributes are abstract descriptions of a view's position and size.
Position attributes:
top
bottom
leading
trailing
...
Size attributes:
width
height
While size attributes can describe an absolute value (e.g. view.height = 20.0) position attributes are always relative to another position attribute. That's why Apple only shows two views in their example, without any coordinate system. The equation
RedView.leading = 1.0 × BlueView.trailing + 8.0
states that RedView's leading edge is always 8.0 points to the right of BlueView's trailing edge. The origin of the underlying coordinate system doesn't matter!
Let's say we have a coordinate system ∑1 with an origin O1 and let's assume that BlueView's trailing edge is at x = 100 with respect to that origin. This would mean:
BlueView.trailing = 100
RedView.leading = 1.0 × 100 + 8.0 = 108
Now we look at a different coordinate system ∑2 with an origin O2 that's shifted by 20 points to the left, so
O2.x = O1.x – 20
O2.y = O1.y
In this coordinate system BlueView's trailing edge is at x = 120. So we get:
BlueView.trailing = 120
RedView.leading = 1.0 × 120 + 8.0 = 128
As you can see the values for the layout attributes BlueView.trailing and RedView.leading are different in ∑1 and ∑2. However, the horizontal spacing between the views is the same
RedView.leading – BlueView.trailing = 8
in both coordinate systems.
And that's the whole point of Auto Layout:
To describe the positions and sizes of views relative to each other, rather than using absolute values with respect to a particular coordinate system.
When I tell you to park your car behind your neighbor's car and leave a 1 meter gap in between, you know what to do, right? Without knowing where the road begins!
It's not important.
However – and I guess that's what made you ask the question – the system will need to "tell" the display at some point which pixels to draw for a particular view. And the pixel grid does have an absolute origin and a fixed coordinate system.
So eventually, the system will substitute the layout attributes for the outermost view (the window) before solving all the constraint equations. At that point in time your layout attributes will be relative to a particular origin (most likely the window's origin in the upper left corner, yes) but it's simply irrelevant!
Apple may choose any coordinate system they want (even a coordinate system whose origin is 50 points above the screen) and regardless of that particular system your layout will still look the same with the same set of constraints.
No, values are not relative to origin point. Forget about this.
To position them there must be some additional constraints applied to such attributes of views as:
left, right, top, bottom, leading, trailing, width, height, centerX, centerY, lastBaseline, firstBaseline, leftMargin, rightMargin, topMargin, bottomMargin, leadingMargin, trailingMargin, centerXWithinMargins, centerYWithinMargins.
Also in iOS 9 there were added diffrent kind of anchorPoints to make adding constraints easier.
Also Autolayout added localized leading and trailing attributes which position (leading is at left or right side of view) depends on Device Locale.
I would suggest the following equations:
redView.width = 0 + 1 * blueView.width
redView.height = 0 + 1 * blueView.height
redView.leading = 20 + superView.leading
blueView.trailing = -20 + superView.trailing
redView.bottom - blueView.bottom
redView.bottom = superview.bottom - 20
So it does not matter where origin is.
Everything you are asking requires knowledge of Auto Layout.
Leading, Trailing, Top, Bottom and other several constraints are applied w.r.t to the views.
Example:
RedView.leading = 1.0 x BlueView.trailing + 8.0
here, the leading constraint of RedView is applied w.r.t the BlueConstraint trailing whatever it is. i.e. RedView is placed 8 points farther than BlueView in horizontal direction.
https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/AutolayoutPG/index.html
provides a good knowledge of the auto layout constraints, in what context they are applied and the how the views layout according to them.
Also there are top layout guide, bottom layout guide, margins with respect to which you apply constraints to a view.
Read more about auto layout to get a clear understanding.
Edit:
Example:
BlueView frame: (x: 0, y: 0, width: 4, height: 2)
Now the BlueView trailing that we have is: 4
So now we are setting RedView leading as:
RedView.leading = 1.0 x BlueView.trailing + 8.0
i.e. RedView.leading = 1.0 x 4 + 8.0 = 12.0
So now the frame of RedView is: (x: 12, y: 0, width: 4, height: 2)
Also from above equation,
BlueView.trailing = RedView.leading - 8.0
i.e., BlueView.trailing = 12.0 - 8.0 = 4.0
So, the equation is valid for both RedView and BlueView.
I have a helper view with dynamic height in my storyboard, this is a common practice to make layout responsive.
However, something strange happens when I introduce multipliers.
The blue button is aligned center y to the white view on the left:
Changing multiplier value into 0.5 should align the button to center of first half of the white view, at least it works this way when aligning to superview.
Instead I end up with sth like this:
The blue button height is equal to 0.05 times th height of the superview. The white view height is equal to 4 timees the height of the blue button
I have no idea what is the problem here that causes this weird alignment. I suspected it might be something with dynamic height value, so I tried setting explicit height value but the result was exactly the same.
You said that if button is Center Y with multiplier 0.5, than it should be positioned at the 1/4 of that white view.. No thats not worked like that .. lets check it with equation
multiplier works with this equation
FirstItem.Attribute1 = (SecondItem.Attribute2 * Multiplier) + Constant
Your constraint is Button.Center Y = BlankView.center Y .. so this is how equation filled up
Button.Center Y = (BlankView.center Y * 1) + 0
So the question is what is the value of BlankView.Center Y ...
answer is
BlankView.Center Y = HeightOfSuperviewOFBlankView - (Y positionOFBlankView + (BlankViewHeight / 2))
// in your case it would be 603 - (483 +(120/ 2)) = 543
Now move to Your equation Center Y with multiplier 0.5
Button.Center Y = (543 * 0.5) + 0 // 271.5
because of that your button position with Center Y is placed at
Button.Center Y = 271.5 - (buttonHeight / 2)
// if we take buttonHeight = 30 than it should be 257.5 (approx 257)
I hope now you understand how center Y with multiplier works...
I have the following bit of lua code. I am not sure what it is doing
width = aspectRatio > 1.5 and 320 or math.ceil( 480 / aspectRatio )
is it a short circuit?
It is indeed a short circuit. It's equivalence in c would be:
width = aspectRatio > 1.5 ? 320 : math.ceil( 480 / aspectRatio )
Or in english: if the aspect ratio is greater than 1.5, set the width to 320, otherwise set the width to the smallest integral value that is greater than or equal to the division of 480 and the aspect ratio.
Reference
http://www.lua.org/pil/3.3.html