On Dec 16, 2008, at 2:19 PM, Bradley S. O'Hearne wrote:
The reason this is useful is that rather than have this code scattered within an application which needs it, I can instead make a generic utility class out of it (which I've now done) and can reuse it anywhere. In my case, I was creating code to asynchronously load a large number of remote images (located on a server) within my application.
This is definitely the sort of thing NSOperation and NSOperationQueue are designed for. Threads are a useful substrate on which to implement asynchronous behavior, but having an abstraction layer atop them lets your code stay isolated from things like how many threads to schedule.
For example, you can have an NSOperation subclass that downloads a single image and is run by an NSOperationQueue. Then your code can create an operation for each image to download, put it on the queue, and the NSOperationQueue itself will figure out how many operations to run concurrently based on a variety of criteria.
If you have work that depends on specific images, you can also encapsulate *that* as additional kinds of operations, and have those operations depend on the operations that download the associated images. And, again, NSOperaitonQueue will do the heavy lifting of figuring out what to run when for you.
-- Chris _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
