Comments on: FTUtils: A New Open Source iPhone Library

By: Bruce

Bruce — Wed, 19 May 2010 14:23:42 +0000

Hey Nathan, playing with your FTAnimation code – good stuff, thanks! Seeing something strange and can’t figure it out. I was hoping you my have a thought. Using the Popin animation, popin and popout work find first time, then each following invocation fails to show the popin animation (also, the view isn’t displayed). But, I can click in the view (triggering the Popout), and the popout animation is shown. Any thoughts? Thanks in advance Nathan.

By: neror

neror — Thu, 18 Mar 2010 20:06:55 +0000

@Florent Pillet

I'm glad you like FTUtils and that you're getting a lot of use from it!

The reason I set removedOnCompletion to NO is that I want to manually remove the animation in the aminationDidStop:finished: delegate method. FTAnimation assumes that it will always be the delegate for any animations it creates, and it forwards the delegate calls to the startSelector and endSelector. As a result, the animation should be removed every time, but you found a bug in my delegate method. I was calling removeAnimationForKey: inside of an if statement when it should be called all of the time. I've pushed up the fix to github already.

The reason I have to manually remove the animation is because after an "out" animation completes, FTAnimation sets the hidden attribute of the view to YES. In many cases, the view wasn't being hidden quickly enough after the transform was reset, and the view would flash visible for a split second. My solution was to set the fillMode of the animation to kCAFillModeForwards (or kCAFillModeBoth) and hide the view before removing the animation from it. This is a fairly old optimization, and I don't know if it's still necessary. I've kept it there just in case. I could probably optimize further by only doing this for "out" animations, but I don't think there is really any significant performance penalty for manually removing the animation.

Thanks a lot for pointing this out, and I hope my explanation and fix help.

By: Florent Pillet

Florent Pillet — Mon, 15 Mar 2010 13:31:38 +0000

Hi Nathan, FTUtils is a nice library. I started using it and was wondering why you are setting the removedOnCompletion for animation groups to NO. This makes it so that each animation persists in the view layer, even though it's complete. Moreover, since you're keeping a reference to the view (kFTAnimationTargetViewKey) in the animation, this has a later impact on memory management: if I show a view using, say, a back-in effect then make it disappear with a slideOut effect, since the backIn animation is never removed from the layer, there is a live reference to the view, so even if I do a removeFromSuperview: call from the slideOut delegate's stopSelector, it's not enough. I have to -removeAllAnimations on the target view first, so that -removeFromSuperview causes a dealloc of the view object.

I'm interested in hearing your thoughts about these!

Thanks for making FTUtils public!

By: Mike Ross

Mike Ross — Sat, 23 Jan 2010 22:24:31 +0000

Thanks for taking the time to respond Nathan. It was user error; I was passing in a different key on the addAnimation: call. This led to the problems noted above. Great stuff Nathan – I appreciate you making this available to us.

By: neror

neror — Fri, 22 Jan 2010 20:56:02 +0000

Mike: Interesting behavior. I'm not sure exactly what's happening. The animations all take over the hidden attribute on UIView to hide or show the view based on the type of animation. This is because the animations were originally designed as transitions. For example, after popOut is finished, the hidden attribute is set to YES right before your delegate selector (if there is one) is called. There might be some kind of race condition going on, but it's hard to say.

I can take a look at it if you can give me a small example.

By: Mike Ross

Mike Ross — Fri, 22 Jan 2010 20:28:26 +0000