Animation Delay

[matt-curtis]

Could this feature possibly be implemented?

[atomkirk]

I dont think its used often enough to be added to method names. I would just use a dispatch_after

[matt-curtis]

I disagree...dispatch_after results in seriously jumbled, less readable code, when you have multiple animations...I suppose one could create their own wrapper function for this, but regardless having the capability already rolled into the library would be nice.

[matt-curtis]

Wow, that was fast! Thanks, much appreciated.

[matt-curtis]

Why use dispatch_after vs CAAnimation's setBeginTime? I'm only asking because one would allow the use of [view.layer removeAllAnimations] whereas the other wouldn't.

[atomkirk]

Ill switch. Thanks for the tip—
Sent from Mailbox

On Tue, May 20, 2014 at 9:43 PM, Matt Curtis [email protected]
wrote:

Why use dispatch_after vs CAAnimation's setBeginTime? I'm only asking because one would allow the use of [view.layer removeAllAnimations] whereas the other wouldn't.

Reply to this email directly or view it on GitHub:
#19 (comment)

[matt-curtis]

Thanks! You've been extremely receptive :)

This is more of a personal thing than anything else, but I'd suggest leaving in the old convenience methods (if feasible) that allowed specifying the views being animated - only because 1.) it would save you the trouble of looping through the window's subviews 2.) allow animation of views in windows other than the keyWindow.

[atomkirk]

I'll try and provide a fair argument for why not:

In regard to number 1), there are a few advantages to searching the whole window for changed views.

• I've found since the adoption of auto-layout, trying to guess all the views that will be affected by a relayout is extremely hard and I've rarely been able to get it right. Really the only way to do it reliably is to just check every view.
• Obviously it just makes the interface much more like Apple's UIView API, which is much easier to use, more familiar, etc.
• I've been investigating a way in Core Animation to automatically animate a superview's subviews as the superview animates and I could never find a way. Apple's [UIView animateWith… was able to do this and I thought it was a very important thing. By checking every view in a window, this behavior is now present, because all frames that change as a result of the explicit changes you made, will be animated.
• There is some concern about performance using this method. Through testing, it appears to be highly performant. I believe the biggest reason for this is because while it does take a snapshot of every view in the window (in order to compare display values after the animation block has run), it then thins down the collection of views down to only those that changed and applies animations to only those. So, how expensive is it to allocate 5 NSValues for every view in a window? I haven't profiled it yet, but I've been using this new approach in my app Calvetica for a few weeks and on a 4S (the slowest device I have) there is absolutely no perceivable delay when an MTAnimation is initiated. So, I have to reason to believe NSValue objects are very cheap.
  Example of initiating an animation in a window with a lot of views (Calvetica):
  And yet, even on my slowest device, there is no perceivable pause to take a snapshot of every view in the window, so it mush happen pretty quick.

In response to 2):

• This is definitely a good point, especially (maybe only) on AppKit, to be able to choose what window get's searched. I'll try to add to the api in the near future that allows this.

[matt-curtis]

Wow, that's interesting. It does seem quite performant. Thanks for the detailed reply and update!

[matt-curtis]

Side note - using [UIView.layer removeAllAnimations] on delayed animations works now, except when called there's a stutter on the animations. They stop where they are for a second, then snap to their end animation, instead of just snapping to the animation's completed state.

Only happens with animations of a delay > 0 so probably a CAAnimation+beginTime bug. Weird.

EDIT: Actually, checking the source code it seems to have something to do with setFinalValueBlock. Dilemma.

[atomkirk]

hmm, ok I'll see what I can do. The problem is that adding a beginTime doesn't postpone the applying of the model layers values. So you set beingTime, then add an animation, then set the layers final values. It jumps to it's final value, then after beginTime it jumps back to it's original position, animates, then stays at it's final position. So I fixed this by postponing the applying of the layers final state until after the delay has elapsed. So, that explains why you're seeing what you're seeing, but I'm not quite sure how to make it so you can both ways.