I've been trying to make a short animation that reverses halfway through with a static method that can be called by my view controllers. This works fine.
But I need it to perform a selector when the reverse takes place, essentially in the middle of the animation. The method setAnimationDidStopSelector only fires when the entire animation is completed, not in the middle.
So I split the animation into two blocks. However, when I do this, the first animation is instantly completed, then the second one happens. I suspect it's because the animation is on the same view. Perhaps there can't be two separate animation blocks for the same view?
I've set up the second block with a different animation name, and with the appropriate delay, and even tried setAnimationBeginsFromCurrentState (even though it's discouraged in OS 4), but none seem to solve the problem.
Here's some sample code to get an idea of one of the ways I've tried. 'selector' is the method I need called halfway through (once the alpha is transparent).
[UIView beginAnimations:name context:view];
[UIView setAnimationDuration:(duration/2)];
[UIView setAnimationDelegate:delegate];
[UIView setAnimationDidStopSelector:selector];
[view setAlpha:0.0];
[UIView commitAnimations];
name = [name stringByAppendingString:#"_reverse"];
[UIView beginAnimations:name context:view];
[UIView setAnimationDelay:(duration/2)];
[UIView setAnimationDuration:(duration/2)];
[UIView setAnimationDelegate:delegate];
[UIView setAnimationDidStopSelector:selector];
[view setAlpha:1.0];
[UIView commitAnimations];
Edit: I want to avoid animation 'blocks' as I'd like the code to be compatible with pre-OS4. I'd also like to keep the method static so I can use it as a library method.
Have you tried putting the second part of the animation into a method, and use a NSTimer or performSelector: withObject: afterDelay:?
I don't know if these work or not, but UIView animations and drawing stuff tend to have weird interactions when a lot of stuff is done concurrently. For example, you set a couple animations to go off one after another in a single method. Spacing them out so that the first animation has no knowledge of the upcoming one might help. I do realize that you do set a delay on the second one, but UIViews are weird in that way.
Edit: Just tried it out, works like a charm.
Related
I want to fade-out a view as it is scrolling inside a parent UIScrollview. When the fade-out animation begins, the scroll view stops scrolling. It jumps to the correct position when the fade is complete.
My fade-out is achieved with animateWithDuration and block objects, triggered upon a page-change I detect in scrollViewWillBeginDragging.
Does anyone know how to make them both happen simultaneously? Just to be clear, I am not 'animating' the UIScrollView scrolling - rather it is happening via user interaction of swiping.
EDIT:
Here is the code I'm using to fade the UIView. This code is in a UIViewController derived class, which is the delegate for a UIScrollView. When the user starts dragging his finger, I want to fade out the subView. But when the user starts draggin a finger, the subview fades and the scrolling stops. After the subView has completely faded out, the the scroll view will then snap to the location where the user's finger is.
-(void)scrollViewWillBeginDragging:(UIScrollView*)scrollView
{
[UIView animateWithDuration:0.5
animations:^
{
self.subView.alpha = 0.0f;
}
completion:^(BOOL finished) { }];
}
A little late, but if you want to keep using blocks, you can use:
animateWithDuration:delay:options:animation:complete:
add "UIViewAnimationOptionAllowUserInteraction" to options to allow interaction while scrolling.
I'm sure that you will still have the lag problem. Here's the best way I can explain it. Please forgive me in advance since I'm probably using the wrong terms. All animations must run on the main thread. When you call an animation, iOS first *P*rocesses then it *R*enders before it generates *F*rames. It looks like this.
PPPPRRRRFFFFFFFFFFFFFFFFFF
But since ScrollViews don't know how long your animation is going to be or when it will end, it has to perform the animation like this.
PRFPRFPRFPRFPRFPRFPRFPRF
My theory is that the lag you are experiencing has to do with these two calls colliding on the main thread at the same time. I'm not sure how you would solve this problem other than with a faster chip. I've that you could push one animation to the CPU and one to the GPU, but I'm not that advanced at programming yet.
very interesting ... I've checked this out, and yes, i have the same effect ... Well, it seems that the animateWithDuration somehow blocks the main thread ... which is not logical, and the documentation doesn't say anything about it either ..
However there is an easy workaround, something similar to this: (i've set the animation duration to 3 so i can see that it's working while i'm moving my scroll view :) ...)
[UIView beginAnimations:#"FadeAnimations" context:nil];
[UIView setAnimationDuration:3];
self.subview.alpha = 0.0f;
[UIView commitAnimations];
I would suggest, since the opacity is based on the user's finger's movements in the UIScrollView, using the delegate method scrollViewDidScroll:. The scrollView passed as a parameter can be used to check the contentOffset which is simply a CGPoint indicating how far into the content view of the UIScrollView the user has scrolled. Something like this can be used to relate the scroll position to the opacity of a given view in a paginated UIScrollView:
- (void)scrollViewDidScroll:(UIScrollView *)scrollView {
// The case where I used this, the x-coordinate was relevant. You may be concerned with the y-coordinate--I'm not sure
CGFloat percent = ((int)(scrollView.contentOffset.x) % (int)(scrollView.frame.size.width)) / scrollView.frame.size.width;
if (percent > 0.0 && percent < 1.0) { // Of course, you can specify your own range of alpha values
relevantView.alpha = percent; // You could also create a mathematical function that maps contentOffset to opacity in a different way than this
}
}
According to information that is still not supposed to be widely released, all iOS 4.x versions completely block user interaction while the animation is in progress.
Isn't it interesting, though, that you're UITouches are obviously still registered during the animation? Hmm... maybe that HINTS that something NEW is coming in a yet-to-be-released version!
I.e., If you can, read the iOS 5 Beta documentation on UIView class methods.
I have a UIView with a bunch of subviews, all positioned using layoutSubviews. When the view is resized, the relative positions all change. I'd like these re-calculations to happen during an animated resize (using +[UIView beginAnimations:] calls). This doesn't seem to be happening. Any ideas?
Assumption: You want to have multiple animation steps (i.e. position doesn't change linearly with frame size).
This isn't possible with a single "standard" UIView animations. Why? The frame/bounds is only set once.
Core Animation has three "layer trees":
The model tree is where your app thinks things are.
The presentation tree is approximately what's being displayed on screen.
The render tree is approximately what Core Animation is compositing.
UIView is a (somewhat thin) wrapper around the model layer. During a UIView animation, Core Animation updates the presentation/render tree — the model tree represents the endpoint of animations. The upshot is that your code can (for the most part) treat animations as instantaneous — moving a view from A to B instantly moves it to B; the change just happens to be animated to the user.
There are more complicated things you can do with CALayer/CAAnimation directly, but I haven't investigated this much.
You could chain multiple animations together using -[UIView setAnimationDidStopSelector:]. (You could also try using multiple animations together with setAnimationDelay:, but I'm not sure what happens with multiple animations on the same property; you might have luck with setAnimationBeginsFromCurrentState:.)
If you want really fine-grained control, CADisplayLink (OS 3.1+) is a timer that fires after each screen refresh. A fallback option (for 3.0 support) is to use an NSTimer at 30/60 Hz or so.
I know this is an old question, but this code works for me very well (suited for your example of changing frame).
-(void)layoutSubviews{
[super layoutSubviews];
// layout your subviews here, or whatever
}
-(void)someMethod{
double duration=...;
[UIView animateWithDuration:duration animations:^{
self.frame = ...;
[self layoutIfNeeded];
}];
}
Of course you can call this method from another object. The "trick" is to call layoutIfNeeded (or layoutSubviews directly - same thing, if You change the frame the setNeedsLayout is called).
As tc. nicely explained the "layer trees", You just force the presentation layer to display the final stage of model layer with animation.
The advantage of this method is in possibility to control when the frame/bounds change is animated and when it's instant.
Hope this helps someone:).
Completing #GrizzlyNetch's anwer, you can set the UIViewAnimationOptionLayoutSubviews animation option, so you don't need to call layoutIfNeeded:
-(void)someMethod{
double duration = ...;
[UIView animateWithDuration:duration delay:0 options:UIViewAnimationOptionLayoutSubviews animations:^{
self.frame = ...;
} completion:nil];
}
Posting for completeness. Thanks to tc. for explaining that what I want to do, exactly, is not supported by Core Animation.
I eventually came up with a reasonable solution. Rather then layout my subviews in -layoutSubviews, I do so in -setBounds:. Then, when I wrap a -setBounds: call in a UIView +beginAnimations: block, those positioning calls are also animated, and the end result is everything properly animating to where it should god.
I have an animation which I kick off like this:
[UIView beginAnimations:#"doThis" context:self];
[UIView setAnimationDuration:1.5f];
[UIView setAnimationDelay:2.5f];
Now, the problem is that this animation is told to start in 2.5 seconds. But in the meantime, something may happen and I don't want the animation anymore. However, CA will just animate that thing after 2.5 seconds, no matter what happens. How could I say "no, thank you, don't animate"?
I have other animations going on in different context and animationID, so I don't want to just remove all animations from the app. What's the most clean way of achieving this? Just running another nonsense-animation with same context and animationID and old targets?
If you re-set the properties that are currently animating, that should kill the animation. If you have an animation delegate/didStopSelector set, the method will be called with kCFBooleanFalse as the "finished" parameter in this case.
There is another related question here:
Cancel a UIView animation?
One other thing you could do is to put your animation code in a method and then use:
[self performSelector:#selector(animateMethod) withObject:nil afterDelay:2.5];
Then you can add a check in the beginning of "animateMethod" to see if the animation should still be performed. This however does not help if you want to cancel the animation while it is running.
I'm writing a drawing application that shows a tools view controller when the user clicks an item in a toolbar. However, several of my beta testers have reported that the tools palate opens too slowly. I'm using the standard presentModalViewController:animated: call to display the tools, and I've tried wrapping it in a code block like this to speed it up:
[UIView beginAnimations:nil context:nil];
[UIView setAnimationDuration: 0.1];
[self presentModalViewController:settings animated:YES];
[UIView commitAnimations];
Unfortunately, that doesn't work. If you say animated:NO it works better, but the underlying drawing canvas view is removed immediately (since the controller thinks it is no longer visible), and so the animation occurs over a white background.
Has anyone done this before that would be willing to offer some advice? I'd appreciate it!
Edited: added another option with controller containment for iOS 5 and later.
Another solution is to set the layer's time space.
This is done through the speed property of CALayer. To slow the animation down, one could use:
MytransparentVCViewController *vc = [[MytransparentVCViewController alloc] initWithNibName:#"MytransparentVCViewController" bundle:nil];
// Makes all animations 10 times slower
// To speed it up, set it to multiples of 1: 2 is 2 times faster, 3 is 3 times faster etc
vc.view.layer.speed = 0.1;
[self presentModalViewController:vc animated:YES];
Note that the proposed solution in the linked post will not work if your objective is to change the animation speed of the modal view controller you are about to present (for example if you use UIModalTransitionStyleCoverVertical).
The layer's speed is not an absolute value but a function of that layer's parent time space (unless the layer is in the root of the layer hierarchy of course). For example, when you set a layer's speed to 2, its animations will run twice as fast in comparison to that layer parent's animations.
Yet another option is to use view controller containment. (iOS 5 and later only)
http://developer.apple.com/library/ios/DOCUMENTATION/UIKit/Reference/UIViewController_Class/Reference/Reference.html#//apple_ref/doc/uid/TP40006926-CH3-SW81.
You have full control over the animation with UIViewController's transitionFromViewController:toViewController:duration:options:animations:completion:.
A similar question is asked here.
You can also change the speed using this technique, but in my experimentation, it does so over a blank background, as you've suggested.
I was wondering how animations work in Cocoa Touch. For example:
[UIView beginAnimations:nil context:nil];
[UIView setAnimationDuration:1.0];
view1.alpha = 1.0;
view2.frame.origin.x += 100;
[UIView commitAnimations];
How does UIView tracks the changes to the properties of the two views?
I suspect that KVO is used, but does it really observe the changes to every views between the beginAnimations and commitAnimations calls?
Any insight would be appreciated!
A simplified explanation:
All animations for all views are handled on a single stack, beginAnimations:context: will push a new active CAAnimationGroup on the stack, and commitAnimations will pop the current active animation group.
If there is an active animation group on the stack, then all setters for animatable properties will create CAAnimation subclass instances to handle that property and add then to the active animation group.
When the last animation is popped, it is replayed.
I believe it is just a wrapper over the old CoreAnimation calls. Look into the CoreGraphics API, you can see that there are multiple keys that you must set into a dictionary, while providing beginning and ending values for these keys.