• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: iPhone: NSOperation and UITableVIews
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: iPhone: NSOperation and UITableVIews


  • Subject: Re: iPhone: NSOperation and UITableVIews
  • From: Alex Kac <email@hidden>
  • Date: Mon, 9 Nov 2009 09:45:05 -0600

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 imageview (assign each cell's imageView a tag of the row number), then sure that subclass will be doing work of getting the image (that you can then cache), but when you call viewForTag - it'll come back nil and it'll be a no-op.


On Nov 8, 2009, at 10:35 PM, John Michael Zorko wrote:


Hello, all ...

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.

Any pointers are appreciated! What is available in OS 2.2.1 to help me solve this?

Regards,

John

Falling You - exploring the beauty of voice and sound
http://www.fallingyou.com



_______________________________________________

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

Alex Kac - President and Founder Web Information Solutions, Inc.

"You cannot build a reputation on what you intend to do."
-- Liz Smith




_______________________________________________

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


References: 
 >iPhone: NSOperation and UITableVIews (From: John Michael Zorko <email@hidden>)

  • Prev by Date: Re: beginner question, NSNumber, NSDecimalAsNumber
  • Next by Date: Re: Best pattern for similar objects with differences
  • Previous by thread: iPhone: NSOperation and UITableVIews
  • Next by thread: Re: iPhone: NSOperation and UITableVIews
  • Index(es):
    • Date
    • Thread