Reputation: 53
I'm using part of the Three20 library in a project. Specifically, a view that is essentially a table view with images going 4-wide across each cell to mimic the iPhone's photo app thumbnail view.
I've noticed that the behavior is for each cell to be dequeued as soon as the bottom of the cell reaches the bottom of the navigation bar (which is translucent so we can actually see it disappearing). The problem this presents is that each time a cell is dequeued and then brought back into view it reloads the images, which causes the scrolling to become very jittery at anything beyond a slow scroll of the table. I know the cells are reused to minimize memory usage, but is it possible to prevent the cells from being dequeued? Or re-define the "boundary" for when they're prepped for reuse to create a larger buffer so they only disappear when they're a certain number of rows off screen?
Upvotes: 0
Views: 2819
Reputation: 4519
Try to change its reuse identifier. And then if you want to make it dequeueable, change the identifier back again. I haven't tried yet, but this could work!
Upvotes: 0
Reputation: 113777
You could try putting your images into an NSMutableDictionary. In the place where you build your cell, check if the image you want is already stored. If it is, use that copy, if not load it from wherever you're getting the images from originally and place it in the dictionary. I think I used an NSMutableDictionary with the image identifier as the key and the image as the value to do this and it sped up the table scrolling.
You might want to unload the NSMutableDictionary if you get a memory warning.
Your problem may just be that you're loading images over the network, which makes scrolling jerky. Check here for a solution to that.
Preloading images from URL in TableViewCell
Upvotes: 0
Reputation: 2779
I believe you want to change the table view frame to include your navigation bar region.
[self.tableView setFrame:GCRectMake(0,0,320,480)];
You should keep in mind that this may cause some other issues as that area will be counted as viewable area and you won't be able to scroll the first cell out from under your translucent navigation bar. To work around this you may need to also set your tableView.tableHeaderView
to an empty UIView
that corresponds to the height of the UINavigationBar
(in theory you could have the same problems with a UITabBar at the bottom of your view).
Upvotes: 0
Reputation: 299623
You have dequeuing backwards. UITableView doesn't dequeue. You do that when you call -dequeueResusableCellWithIdentifier:
. To "dequeue" doesn't mean "to release." It means "pull off the queue of cached no-longer-in-use reusable cells." It's called "dequeuing" because it's a FIFO queue of cells, and you are pulling the first one off.
If scrolling is slow you need to improve your drawing speed, and perhaps you need to return cells faster when UITableView asks for them. The system of dequeuing reusable cells isn't to save memory (it actually costs memory); it's to improve performance. You don't want to circumvent it; this is exactly the situation it's there to help fix.
So, how are you drawing these cells, and how are you configuring them when UITableView asks for one? That's where we're going to find your performance improvement.
Upvotes: 2