I've constrained a UILabel to leading, and trailing anchors, the intrinsicContentSize exceeds the anchors I've specified. Just to be sure, I added a widthAnchor as well, still no improvement.
Then I added these properties:
self.preferredMaxLayoutWidth = 356.25 // didn't hard code
self.invalidateIntrinsicContentSize()
Still the intrinsicContentSize is equal to 356.5, which is something I don't expect from my UILabel, is there anyway to fix this issue?
I'd have to go look up how preferredMaxLayoutWidth interacts with intrinsicContentSize, but assuming an interaction its likely the 356.25 is getting rounded up to 356.5 since .25 won't address a whole pixel.
But more specifically, what are you trying to use intrinsicContentSize here? Its not meant to be a way to measure a view size, or generally inspected by client code, but rather a way to signal values to auto layout that cannot be communicated via constraints (in this case, text measurement).
So even if your layout width is (for example) 350, the intrinsic content size can continue to return something bigger (such as 356.5) but the other constraints in your system ensure the view lays out as expected (at least in general). If you want to get a measurement of the label under specific conditions, you should instead call systemLayoutSizeFitting(), which allows you to specify specific size limitations.
Thanks for this: "356.25 is getting rounded up to 356.5 since .25 won't address a whole pixel.". Indeed, that was the case. This is how I was calculating that value: UIScreen.main.bounds.width * 0.95, that's how I was getting that value, what I did was: instead of UIScreen.main.bounds.width * 0.95, I used this ceil(UIScreen.main.bounds.width * 0.95), this rounds the value up and I get a value in whole number instead of a decimal value.
Thanks for the help :)
To add to my question here, I was using boundingRect to calculate the height, but, I realised that the intrinsicContentSize was taking up more space than I asked it to, which gave me an inaccurate height, so, basically I was trying to get the width equal to what I specified and not go over. I feel like the whole number thing really helped me out as Apple documentation doesn't really specify that constraints round up or not.
I'd have to go look up how preferredMaxLayoutWidth interacts with intrinsicContentSize, but assuming an interaction its likely the 356.25 is getting rounded up to 356.5 since .25 won't address a whole pixel.
But more specifically, what are you trying to use intrinsicContentSize here? Its not meant to be a way to measure a view size, or generally inspected by client code, but rather a way to signal values to auto layout that cannot be communicated via constraints (in this case, text measurement).
So even if your layout width is (for example) 350, the intrinsic content size can continue to return something bigger (such as 356.5) but the other constraints in your system ensure the view lays out as expected (at least in general). If you want to get a measurement of the label under specific conditions, you should instead call systemLayoutSizeFitting(), which allows you to specify specific size limitations.
Thanks for this: "356.25 is getting rounded up to 356.5 since .25 won't address a whole pixel.". Indeed, that was the case. This is how I was calculating that value: UIScreen.main.bounds.width * 0.95, that's how I was getting that value, what I did was: instead of UIScreen.main.bounds.width * 0.95, I used this ceil(UIScreen.main.bounds.width * 0.95), this rounds the value up and I get a value in whole number instead of a decimal value.
Thanks for the help :)
To add to my question here, I was using boundingRect to calculate the height, but, I realised that the intrinsicContentSize was taking up more space than I asked it to, which gave me an inaccurate height, so, basically I was trying to get the width equal to what I specified and not go over. I feel like the whole number thing really helped me out as Apple documentation doesn't really specify that constraints round up or not.
