Begin / commitAnimations vs block animation

Question

I still don't understand why Apple shrugs off the old method of creating animations and instead says use blocks.

I mean, how can you really stop using the old way? Is it just iOS> 4.0 blocks? Is it supposed to fill in the code with if and execute two different implementations based on the current version of the device system? And why so, because the old method works fine? In addition, the base implementation should be the same, right? Are there any considerations behind this, other than the fact that begin / commit produces ugly code?

Answer 1

I still don't understand why Apple is discouraged by the old animation method and instead says that blocks should be used.

Apple wants you to use the latest and greatest methods. Apple is optimizing all new iOS releases for block-based animations and is likely to add new features only for block-based animations. That's why Apple is pushing you for block-based animations.

I mean, how can you really stop using the old way? Is it just iOS> 4.0 blocks?

Yes, only iOS blocks> 4.0. Therefore, if your application is designed for iOS 4.0+, you can use block-based animation. Or you can check for blocks and add specific animations only for iOS 4.0+ devices.

Completely stop animating the old way realistically if you abandon iOS 3 support.

Is it supposed to fill in the ifs code and make two different implementations based on the current version of the device system? And why so, because the old method works fine? In addition, the base implementation should be the same, right? Are there any considerations behind this, other than the fact that begin / commit produces ugly code?

Well, if the old method is suitable for you, and you want to support older (iOS 3) devices. Just use the old animation method. There is nothing wrong with this; do not put unnecessary if-statements in your code. This only complicates the situation, and you do not gain anything by doing this.

If your iOS 4 application comes with blocks, it is shorter and somewhat cleaned up. It should also be easier to maintain, because Apple will not update the old way of animation.

(You can always add if-statements somewhere in the future if there are animations that you can only do with blocks, and then return to another less complex animation with old methods. But this is something in the future.)

Answer 2

The old method works fine, but I think that with blocks you have the option of having a completion block. Where, as in the old way, the animation begins, and the code immediately resumes execution. So, something like the following sets the alpha of the view only after the animation to complete the frame has completed (in this case, the nested animation blocks). As soon as the alpha animation ends, it removes the view from the supervisor.

 [UIView animateWithDuration:0.3 delay:0 options:UIViewAnimationCurveEaseOut animations:^(void) { CGRect frame = self.actionView.frame; self.actionView.frame = CGRectMake(frame.origin.x, 370, frame.size.width, frame.size.height); } completion:^(BOOL finished) { [UIView animateWithDuration:0.2 delay:0 options:0 animations:^(void) { [self.blockingView setAlpha:0]; } completion:^(BOOL finished) { [self.actionView removeFromSuperview]; [self.blockingView removeFromSuperview]; }]; }]; 

you will need to use [responsesToSelector] to determine if the UIView supports the block method if it doesn’t use the old method, and you will probably have to be creative with moments to play nested animations.