I have applied a CABasicAnimation to a layer. The animation modifies the "position.y" layer property to create a gentle bouncing effect; it is set to autoreverse and repeat.
I use the From and To values to position the animation in the bottom right quadrant of the screen. It works quite nicely until I change the orientation of the device. The problem is the animation is positioned relative to the top of the screen. So when the orientation changes it is no longer positioned in the correct place.
The autoresizingMask for the View itself is correctly set in interface builder, but the animation doesn't seem to take any notice of that. I guess because the animation is assigning an absolute value to the layers position.
I'm a bit stumped, thanks in advance.
Can you place your animation in a seperate view so it is self contained and then adjust that view with the rotation?
Related
I want to flip the whole view to support right to left languages. The problem is my project doesn't use autolayout so I need to perform this flip manually.
In the same time I can't simply flip the parent view because it mirror all the labels and make them unreadable. So I need to flip parent view and some of its subviews. And in the same time I can't flip these subviews because by default they are flipped around their own centers and break the layout.
How to solve this issue?
I'm using Constraints within my app and have have a reasonable level of success so far; everything visual object in the gif below is Constrained.
The issue is that when selected, tiles leap to another location before animating to the final, correct destination.
From a code perspective, on a tile click, higher priority positioning Constraints are applied to the tile, the tile is added as a subview to the blue area, then animation is performed.
Can anyone shed a little light on what's happening here?
Thanks
Based on the behavior I'm seeing in your gif, I would guess that when you move the tile views between superviews (the blue area vs. the larger white area), the view jumps to it's current frame position (within the coordinate system of the old superview), but now in the coordinate system of the new superview.
The solution, I think, would be to translate the final position in the new superview to a position in the current superview, perform the animation, and only when the animation completes would you move the view to it's new superview.
Does that make sense?
I am trying to apply a simple CGAffineTransform to an imageView by scaling to 0, but for some reason the frame of the imageView is getting screwed up just before the animation starts. It appears as though autolayout is applying to the shrunken view. I don't want that at all. I want the view to remain "relatively" where it was and just visually shrink to its center, but because the view is tied to the top and right of its containing view, it is being moved.
What I want is for it to shrink into its center and disappear, but just before it starts, the frame of the imageView is jumping to the top-right of its container (it seems as though iOS is calculating its size after the animation and using that to reposition it before the animation starts). After it jumps there, the animation works properly with respect to itself, with the view shrinking relative to its center, but I want to avoid it moving in the first place.
This is all taking place inside a UITableViewCell that is managed by autolayout, so I'm guessing this has something to do with autolayout and <understatement> would not be the first time autolayout has gotten in my way </understatement>.
Is there any way to prevent autolayout from affecting the transform?
I have two views that flip based on a button press within the view. The view has two CAGradientLayers as sublayers. If I flip immediately after the action method fires, the button is in the process of changing the opacity of the gradients and so you see stuttering (the UIVIew flip animation is having to accommodate the button that is itself changing.)
I can hack a solution by doing a performWithSelection:withObject:afterDelay:0.1f, but it feels like such a hack. I tried setting the layer's needsDisplay property and testing for when it was clears, but probably this is insufficient to tell me the screen itself has redrawn.
Dav
In the end this has no solution. I have since found that when animating a view there are severe performance implication if you also try to animate the super views. You can see this in many iOS apps where the app animates an image in a scrolling list - the scrolling stumbles.
So what I learned is either animate something, or it's view, but not both!
iPad app; I'm trying to resize my view when the keyboard appears. It amounts to calling this code at appropriate times:
CGRect adjustedFrame = self.frame;
adjustedFrame.size.height -= keyboardFrame.size.height;
[self setFrame:adjustedFrame];
Using this technique for a view contained in a uisplitview-based app works in all 4 orientations, but I've since discovered that a vanilla uiview-based app does not work.
What happens is that apparently the uisplitview is smart enough to convert the coordinates of its subviews (their frame) such that the origin is in the "viewer's top left" regardless of the orientation. However, a uiview is not able to correctly report these coordinates. Though the origin is reported as (0,0) in all orientations, the view's effective origin is always as if the ipad were upright.
What is weird about this is that the view correctly rotates and draws, but it always originates in the literal device top left. How can I get the view to correctly make its origin the "top left" to the viewer, not the device's fixed top left? What am I missing? Please, for something so trivial I've spent about 6 hours on this already with every brute force technique and research angle I could think of.
This is the original source which doesn't work in this case:
move up UIToolbar
OK, I don't know what the ACTUAL answer is to the original question, but I can say with certainty that one way to resolve the issue is to always ensure that you don't manipulate a viewController's view directly. Always wrap your view inside a container view inside the main "view", then have that container view adjust its position etc as needed. Works exactly as the splitview does, probably because in both cases now the view in question is a subview of the main "view". What a relief!