tableView:cellForRowAtIndexPath:


#1

A question about this method.
It appears that this method is kind of like a loop. It’s run for each item in our to-do list that is initially visible in our table view. If there’s 5 items in the to-do list, it’s run 5 times so that we have 5 cells in the table view. Now, since there can only be 9 items visible on the screen at any given point, does this mean that only 9 cells would ever be created? When I had a to-do list with 12 items, only the first 9 items (the items that are visible in the table view) are given cells. After the 9th iteration of tableView:cellForRowAtIndexPath: is run, the program sits and waits. My assumption was these 9 cells would work like a conveyer belt, falling off the leading edge of the list when we scroll through it, and popping up on the trailing edge with a new value inside of it. But, when I scroll down the list with a breakpoint in the code, it looks like a brand new cell is created for items 10, 11, and 12. So, what’s the point of the code on page 187 if we end up with a dedicated cell for each and every item on our to-do list? Won’t a super-huge to-do list cause a crash if we don’t deallocate distant cells? It makes no sense to me to keep cell #1,358,459 around if we’re somewhere around item #5 of the to-do list.


#2

Yes, it works very much as you would hope.

As the table view cells disappear from view, they are put into a pool for reuse. For more information on this, see our “iOS Programming: The Big Nerd Ranch Guide”