CODEWITHSUNDEEP
iphonecocoa-touch
ySgPjx
ySgPjx

Reputation: 10265

begin/commitAnimations vs block-based animations

I still don't get it why Apple discourages the old method of doing animations and instead says to use blocks.

I mean, how does one realistically stop using the old way? Aren't blocks iOS > 4.0 only? Is one supposed to fill the code with ifs and make two different implementations based on the current device's system version? And why do so since the old method works just fine? Plus the underlying implementation should be the same, right? Is there any reasoning behind this aside from the fact that begin/commit produces ugly code?

Upvotes: 4

Views: 2222

Answers (2)

Mac_Cain13
Mac_Cain13

Reputation: 3633

I still don't get it why Apple discourages the old method of doing animations and instead says to use blocks.

Apple wants you to use the latest and greatest techniques. Apple will optimize all it's new iOS releases for the block based animations and probably will add new possibilities only to the blocks based animations. So thats why Apple is pushing you to the block based animations.

I mean, how does one realistically stop using the old way? Aren't blocks iOS > 4.0 only?

Yes, blocks are iOS > 4.0 only. So if your App is designed for iOS 4.0+ only you can use block based animations. Or you could check for the availability of blocks and add the specific animation only for the iOS 4.0+ devices.

Completely stop animating the old way is only realistic if you drop support for iOS 3.

Is one supposed to fill the code with ifs and make two different implementations based on the current device's system version? And why do so since the old method works just fine? Plus the underlying implementation should be the same, right? Is there any reasoning behind this aside from the fact that begin/commit produces ugly code?

Well, if the old method is okay for you and you want to support older (iOS 3) devices. Just use the old way of animating. There's nothing wrong with it, don't put unnecessary if-statements in your code. It only makes things complicated and you win nothing by doing it.

If your App is iOS 4 go with blocks, it's shorter and somewhat cleaned. It also should be easier to maintain, because Apple will not keep updating the old way of animating.

(You always can add the if-statements somewhere in the future if there will be animations you only can do with blocks, and then fallback to another less complex animation with the old methods. But thats something for the future.)

Upvotes: 2

chilitechno.com
chilitechno.com

Reputation: 1575

The old method works fine, but I think with blocks you have the option to have a completion block. Where as with 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 move the frame has completed (in this case nested animation blocks). Once the alpha animation finishes, it then removes the view from the superview. 

[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 would have to use [respondsToSelector] to determine if the UIView supports the block method, if not use the old way, and you'd probably have to be creative with timing to reproduce nested animations.

Upvotes: 3

Related Questions