Re: iPhone: NSOperation and UITableVIews

2009-11-09 Thread Alex Kac
One good reason not to cancel is if a user is going to go up/down the list then going ahead and storing the image you got (caching) is a better deal. That way you aren't continuously reloading that image or canceling or what not. Finally if you use an NSOperation, try to let it work in sequ

Re: iPhone: NSOperation and UITableVIews

2009-11-09 Thread John Michael Zorko
Dave, Alex ... 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]. Cool -- I learned something today :-) I did this, so

Re: iPhone: NSOperation and UITableVIews

2009-11-09 Thread Dave Camp
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

Re: iPhone: NSOperation and UITableVIews

2009-11-09 Thread Alex Kac
There is no need to reload the table. If you simply change the UIImageVIew that the image is assigned to, that will refresh. So you're using a very heavy handed method right now which isn't even needed. Second, if you simply store into your NSOperation-derived subclass the tag of each ima