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
