Re: Sublclassing NSThread
Re: Sublclassing NSThread
- Subject: Re: Sublclassing NSThread
- From: Chris Hanson <email@hidden>
- Date: Tue, 16 Dec 2008 18:10:18 -0800
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@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