On May 18, 2009, at 4:16 PM, Mike Manzano wrote:
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:.
That's great if this works, but it's making a very
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 cel
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
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
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
> j
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
Also, the cell "types" are determined by the string you provide in
initWithFrame:reuseIdentifier:
Each unique identifier will have its own reuse pool which can later be
recalled by using the same string with
dequeueReusableCellWithIdentifier:
The idea is that cells that have the same basi
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 c
