Re: UITableViewCell instances
Re: UITableViewCell instances
- Subject: Re: UITableViewCell instances
- From: "Eric E. Dolecki" <email@hidden>
- Date: Fri, 15 May 2009 16:35:54 -0400
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
<email@hidden>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
>
--
http://ericd.net
Interactive design and development
_______________________________________________
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