First, let me say thanks for your reply. I think I was able to implement a similar algorithm for detecting when a cell has gone off- screen by overriding the table view's -willRemoveSubview:.

What I'm doing is starting an animation by adding it to the cell's layer, and in response to the cell being removed, am removing the animation. However, in my case the animation doesn't actually seem to stop. The way I test this is to set the animation to 5 seconds so I can mess around with the interface. I then scroll an animating cell off the top. My log messages tell me the cell was removed and that the animation was removed from the cell's layer. I then scroll back to the row in question, and it's still animating! Further, if I scroll down a full page of cells (so that the tableview starts reusing my cells), I can see the same animation being performed in the re-used cells at page intervals. What am I doing wrong?

The animation is started in response to user input, and looks like this:

- (void) resetSlidingForCell: (NewsItemTableViewCell *) cell
        {
        _currentlySlidingCell = cell ;
CABasicAnimation *theAnimation = [CABasicAnimation animationWithKeyPath:@"position.x"] ;
        theAnimation.removedOnCompletion = YES ;
        theAnimation.duration = 5.0f ;
        theAnimation.repeatCount = 1 ;
        theAnimation.autoreverses = NO ;
theAnimation.fromValue = [NSNumber numberWithFloat:cell.layer.position.x] ; theAnimation.toValue = [NSNumber numberWithFloat:cell.layer.position.x - cell.frame.origin.x] ;
        theAnimation.delegate = self ;
        self.superview.userInteractionEnabled = NO ;
        [cell.layer addAnimation:theAnimation forKey:@"slideResetAnimation"] ;
        NSLog( @"Started animation on layer %x" , cell.layer ) ;
        }


Here is the above-mentioned -willRemoveSubview: method:

- (void)willRemoveSubview:(UIView *)subview
        {
        if( subview == _currentlySlidingCell )
                {
NSLog( @"Cancelled animation on layer %x" , _currentlySlidingCell.layer ) ;
                [_currentlySlidingCell.layer removeAllAnimations] ;
                }
                
        [super willRemoveSubview:subview] ;
        }

As expected, the animation's delegate is being called when the animation is removed:

- (void)animationDidStop:(CAAnimation *)theAnimation finished:(BOOL)flag
        {
NSLog( @"Animation did stop on layer %x, cancelled: %d" , _currentlySlidingCell.layer, !flag ) ;
        [...]
        }

The output of this NSLog statement tells me that the animation did not finish, as expected.

Any ideas?

Thanks,

Mike


On May 15, 2009, at 1:40 PM, Luke the Hiesterman wrote:

I think a better solution is to not do whatever you're going to do if the cell has gone off screen. You could easily check when your timer fires if the relevant cell is in view. This is where, as I mentioned in another thread, I prefer holding onto a reference to the NSIndexPath of the row you're interested in rather than the UITableViewCell. Then, no matter what happens in the underlying API implementation, at the time you want to do something, you can query whether that NSIndexPath is currently visible and you can also retrieve the UITableViewCell that goes with that by calling cellForRowAtIndexPath:

Luke

On May 15, 2009, at 1:33 PM, Mike Manzano wrote:

Okay, so each row is its own cell instance, and when a cell goes off-screen UITableView re-queues it. What happens, however, if I want to, e.g., start a jack-in-the-box animation in a cell subview that pops after 10 seconds. If the 10 seconds hasn't elapsed yet, but the cell is scrolled off-screen, then basically the whole cell, including the subview performing the animation, is cleaned up. Is there a way to tell the table view "don't re-queue me just yet"?

On May 15, 2009, at 10:56 AM, Dave DeLong wrote:

A different cell instance is used for each visible row. The point of the queue is so that you don't have to instantiate a new cell for every row in your table. The UITableView will "recycle" old cells (ie, cells that are no longer visibly on the screen) when it is about to display a new cell. This helps keep the overall memory footprint down.

Dave

On May 15, 2009, at 8:52 AM, Mike Manzano wrote:

In the template UITableViewController that instantiates cells by first attempting to dequeue them, is that same dequeued cell used to draw all visible rows, or is there a separate cell used for each row? The docs I've read mention queueing different cells of different types, so it's obvious in that case that the cells are different.

If it's the case that only one cell is used, then how do you handle the state related to, e.g., animating or touch tracking?


Mike Manzano
Sent while mobile
_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/mike%40instantvoodoomagic.com

This email sent to m...@instantvoodoomagic.com

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/luketheh%40apple.com

This email sent to luket...@apple.com


_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to