Why would you want to stop the reallocation of the cell that you can't see anymore?
On Fri, May 15, 2009 at 4:33 PM, Mike Manzano <m...@instantvoodoomagic.com>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/edolecki%40gmail.com > > This email sent to edole...@gmail.com > -- http://ericd.net Interactive design and development _______________________________________________ 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
