Cancelling an animation in a UITableViewCell was Re: UITableViewCell instances
Cancelling an animation in a UITableViewCell was Re: UITableViewCell instances
- Subject: Cancelling an animation in a UITableViewCell was Re: UITableViewCell instances
- From: Mike Manzano <email@hidden>
- Date: Mon, 18 May 2009 16:16:26 -0700
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 (email@hidden)
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:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden