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
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
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
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