Up until iOS 8, Auto Layout used the transformed dimensions of a scaled view, and factored in that scale when laying out. So, say you have a 0.5x transform on a view, and set that view to use the same dimensions as another, unscaled view - Auto Layout keeps those views the same size. Good-o:
Since iOS 8 though, Auto Layout now seems to be ignoring transformed dimensions, which means that it's performing layout on the un-transformed coordinate system and making stuff look weird - now, with scaled-down views, I've got masses of whitespace:
So; I'm wondering if anyone has any ideas about how to get that original behaviour back? I'd like to override alignmentRectForFrame: and frameForAlignmentRect: and provide transformed values there, but they're never called.
Anyone got anything else?
Cheers!
(For reference, here's the little Xcode project demonstrating the issue)
Related
Briefly, I want to properly use autolayout (and maybe size classes) to get a column of UIViews to rotate in place when the orientation changes. I can get the correct before and after looks (see images) using a UIStackView, but the transition is not what I want: each little image-label combination should rotate individually. I have tried embedding the image-label pair in a wrapper view, setting constraints in various plausible and implausible combinations... going crazy. Would prefer to use IB as much as possible, but willing to go to programmatical if necessary.
It's so easy to visualize this that one thinks it should be comparably easy to implement. I know enough linear algebra to do it all by hand, but really can't I stand on some tall shoulders?
I need to draw a line on the screen. The designer tell me to set the height of line to 2.5 pt. I'm wondering if it's acceptable to use decimal here.
I know it will be better if we use integer as the size or position of a UIView. But I can't tell why. I didn't find any convincing document about it.
So could anyone explain it or find something for me?
The only problem I know is UILabel with decimal size will be blurry. Is there any other problem like performance problem would happen?
As per your case it's just about half point which in my opinion should be ok. I often find that in storyboards my frames get moved 0.5 point up or down when I have lot of UI elements and sometimes constraints just get confused.
Additionally: the easiest scenario when your frame could be positioned at "some 0.5 point" is if you use a constraint to centre your view in it's superview. In this case the default x or y frame position could easily end up being "some 0.5 point". So it can happen often times and could be done by Xcode itself, so that's why I think your view will be just fine.
As stated previous in comments those points are CGFloat. What we have now is 1x, 2x and 3x resolutions. So there will always be the need for some calculations for at least one of the devices.
You may also look at this Screen resolutions guide to see all the time when up sampling and downsampling occurs.
I am trying to think of a way to render a sub-hierarchy that is somewhat complex, and would look good (crisp) when drawn at multiple scales.
I would expect there to be some container view with a size, and this subview could be constrained within it and drawn properly.
If it helps think of a hierarchy like a calculator keypad or computer keyboard even:
You would have a keyContainer view, and a bunch of key views (or layers) of various sizes and positions.
Suppose I wanted this to be drawn in a container that was 320 x 320. I was thinking if I knew the ratio of w:h for each key and I knew the ratio of a key's width to the width of the whole container, then I could work out the sizes and positions for the key. I've found in practice the math seems to introduce a lot of rounding errors and you end up on off-pixel boundaries so the final rendering does not look great.
So how would you tackle a problem like this?
Thanks for any ideas.
I'm having a problem with scale transformation I have to apply to UIViews on Swift (but it's the same in objective-c too)
I'm applying a CGAffineTransformMakeScale() to multiples views during a gestureRecognizer.
It's like a loop for a cards deck. I remove the one on top and the X others behind scale up and a new one is added in the back.
The first iteration works as expected. But when I try to swipe the new front one, all the cards reset to their initial frame size because i'm trying to apply a new transform, which seems to cancel the previous one and reset the view to its initial state.
How can I apply definitely/commit the first transform change to be able to apply a new one after that based on the UIView resulting new size ?
I tried a UIView.commitAnimations() but no change.
EDIT :
Here's a simple example to understand what I try to do :
Imagine I have an initial UIView of 100x100
I have a shrink factor of 0.95, which means next views behind will be 95x95, then 90.25, then 85.73, etc
If I remove the top one (100x100), I want to scale up the others, so the 95x95 will become 100x100, etc
This is done by applying the inverse of the shrink factor, here 1.052631...
First time I apply the inverse factor, all views are correctly resized.
My problem is, when I trigger again by a swipe on the new front UIView a new resize of all views (So, for example, the 90.25x90.25 which became 95x95 should now scale to 100x100).
At this moment, the same CGAffineTransformMakeScale() is apply to all views, which all instantly reset to their original frame size (so the now 95x95 reset to 90.25x90.25, and then begin to apply the transformation on this old size).
As suggested here or elsewhere, using UIView.commitAnimations() in the end of each transformation don't change anything, and using a CGAffineTransformConcat() is like powering over and over the scaling by himself and of course views become insanely big...
I hope I made myself more clear, that's not easy to explain, don't hesitate to ask if something is wrong here.
After a lot of reading and consulting colleagues who know better than me about iOS programmation, here's my conclusion :
Applying a CGAffineTransformMakeScale() only modify visually a view but not its properties, and since it's difficult (and costly) to modify afterward the bounds and/or frame of a view, I should avoid to try to make a transform, update bounds, make another transform, etc.
Applying the same CGAffineTransformMakeScale() only reset the effect and not apply to the previous one.
Applying a CGAffineTransformScale() with the same values on top of the previous CGAffineTransformMakeScale() (or with a CGAffineTransformConcat()) has some unpredictable effect and will be very difficult to calculate precisely the new values to apply each time to get the effect I want.
The best way I can go with this is only applying one CGAffineTransformMakeScale() that I will keep updating scales values all along the view's life.
It implies now for me to rework all my implementation logic in reverse, but that's the easiest way to do this right.
Thanks all for your tips.
I'm really interested in this effect introduced in iOS 7 Camera app:
http://i41.tinypic.com/2a0hwk8.jpg
Notice, how "Pano" option is transformed - as if it is goes on a circular path to the right and dissappears. What kind of transformation can achieve this effect? Any help would be appreciated.
Thanks
It is probably a transform that is applied and adjusted when the view in question (the label) reaches a certain position (which would normally be done with KVO or similar).
However, a good place to start would be the iOS 7 picker view, which has a similar 3D effect, but in the vertical rather than the horizontal. They are probably achieved the same way, and the advantage with the picker is you can inspect its view hierarchy in your own apps.