views:

526

answers:

1

I have a CABasicAnimation that animating a property of a CALayer e.g. bounds.origin. I want to be able to observe the property changing over time, but haven't really found a method that works 100%.

  1. I tried using KVO (key-value observation) on the presentationLayer's bounds.origin keyPath. The system complains that the object is freed before its observers are freed, leading me to think that the presentation layer is only temporary. Observing presentationLayer.bounds.origin as a keypath doesn't work.

  2. I tried creating a property on another layer and animating that e.g. by declaring the @property and making it @dynamic on that layer. However this new property only gets changed when the presentation layer is accessed (e.g. at the end of the animation), it doesn't seem to update while the animation is running.

  3. I used +needsDisplayForKey on the property in #2, which does trigger updates during the animation, but for these issues:

    • it only works if the CALayer has non-zero frame. Since this layer might be a CAShapeLayer or subclass, it may have a zero frame.
    • it looks like it triggers -setNeedsDisplay for that layer, but since I'm not actually drawing that layer only monitoring the property change, I don't want to cause it to redraw.
  4. I tried scheduling an NSTimer, and within the timer callback sample the presentationLayer. This also works but for these issues:

    • The timer would probably be slightly out of sync with the animation update.
    • Since occasionally the original animation gets pre-empted by another animation, it's difficult to actually get the timer to fire when the animation is running and only when the animation is running.

Any suggestions? All this would be on iPhoneOS 3.0/3.1.

+1  A: 

I think you've named all of the possibilities. In fact, I wasn't even aware of #2 and #3 and I wrote the book on Core Animation. ;-)

KVO is not available for these properties. Would be nice if it were, but I believe the reason for this has to do with the overhead it would take. The value would update very frequently and have to call back to any observers.

Anyhow, I've found the NSTimer to be the most reliable approach, but now I'm not sure from what you've said. What makes you think that the timer is out of sync? Why is it difficult get the timer only to fire when the animation is running? Can't you just check for the condition you want in the timer callback and then do nothing if the condition is not met?

Best Regards.

Matt Long
NSTimers are fired without regard to when the actual layers are being updated, they would always be slightly behind or in front of the layer animation step. What I would need is to be notified *at the same time* as the layer animation. Best bet is to use CADisplayLink (iPhone 3.1 only) or make an artificial layer with option #3 to get notified. In the end, because the environment is so dynamic I gave up on using Core Animation to do it -- I'm now using a NSTimer or CADisplayLink to do the autoscroll.
Glen Low
When I autoscroll, sometimes there is an existing autoscroll animation in the layer that I'm replacing, and sometimes the initial animation has to be delayed by 1/2 second. Thus it's difficult to *know* when the actual animation is running. The CAAnimation delegate callbacks don't happen instantaneously either, so there's a chance that any code depending on it will be out of sync with what's already happened in the animated layer.
Glen Low
See for example: http://developer.apple.com/mac/library/qa/qa2004/qa1385.html. The Apple doc says "NSTimer is a general purpose timer. It is not a timer tied to the display device. The interval, and the instant the timer started firing, have no relation to when the vertical refresh happens. This means that the simple approach of creating a timer at "60.0" Hz is doomed to fail -- the timer will drift in relation to the actual refresh rate, and you will drop or double frames. It also means that the timer calls the application at an arbitrary point into the refresh..."
Glen Low