Re: iPhone: NSOperation and UITableVIews
Re: iPhone: NSOperation and UITableVIews
- Subject: Re: iPhone: NSOperation and UITableVIews
- From: Dave Camp <email@hidden>
- Date: Mon, 9 Nov 2009 08:38:16 -0800
On Nov 8, 2009, at 8:35 PM, John Michael Zorko wrote:
I have an indexed table view with -- surprise -- images that take a
long time to load. So, I put the loading into an NSOperation-derived
subclass and have the main() method send a "refresh" msg to my main
thread, telling it to reload the table. This works, but the problem
is that if the user scrolls quickly, a whole bunch of NSOperations
get queued up, even for cells that the user scrolled far past i.e.
they're not anywhere close to being on the screen. This has the bad
effect of making my "refresh" msg get send for cells that have long
since passed, making the app really slow to scroll (which really
defeats the purpose of this whole exercise).
I would like to cancel these extra NSOperation instances, but my app
is targeting OS 2.2.1 and:
1. I can't seem to see a way of determining if a cell is going to be
drawn or not i.e. I don't see a way to cancel the NSOperations that
aren't relevant to the portion of the table view that would be shown
on the screen.
2. I thought maybe -UITableView reloadRowsAtIndexPaths would help
(instead of calling -UITableView reloadData every time, which is why
scrolling is so slow now), but that method is OS 3.1 only.
An alternative implementation might be to have each cell queue up an
operation when it needs to load an image (not the view controller).
Then, each cell could cancel it's operation in [UITableViewCell
prepareForReuse].
Dave
_______________________________________________
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