Re: NSURLRequest and NSOperationQueue
Re: NSURLRequest and NSOperationQueue
- Subject: Re: NSURLRequest and NSOperationQueue
- From: Dave DeLong <email@hidden>
- Date: Sun, 17 Jan 2010 12:33:51 -0700
Thanks for the responses! It hadn't occurred to me to spin the runloop myself.
My main reason for using an NSOperationQueue for the connections was because the spawner of the connections was also the connection delegate, and it would've taken some interesting code dancing to handle the delegate callbacks of all the possible connections, the model objects they're attempting to create, etc in the same object.
What I ended up doing was creating a new class, "DDURLConnectionDelegate", that is init'd with the object spawning the connections. This object exists solely to encapsulate the delegate callbacks of the NSURLConnection, and then, when finished, reports back to the connection spawner with the results, and is destroyed by the runloop. Now I can freely spawn as many connections as I need, all on the main thread, and have them all handled on a single thread, without having to worry about which connection is supposed to be manipulating which object.
Cheers,
Dave
On Jan 17, 2010, at 9:20 AM, Keith Duncan wrote:
>> Solution 1 would be to have you do a synchronous NSURLConnection in your main method. This will show you everything is working in that thread and that you do indeed get data back from your server.
>
> This isn't a good idea since it limits the cancelabilty of your operation.
>
>> NSRunLoop* currentRunLoop = [NSRunLoop currentRunLoop];
>> if ( currentRunLoop )
>> {
>> // 1. Start the URLConnection!
>> mURLConnection = [NSURLConnection connectionWithRequest:mURLRequest delegate:self];
>> [mURLConnection start];
>>
>> // 2. We have a run Loop, so wait until the connection is finished
>> while ( !done && ![self isCancelled] )
>> {
>> // Run the RunLoop!
>> NSDate* dateLimit = [[NSDate date] addTimeInterval:0.1];
>> [currentRunLoop runUntilDate:dateLimit];
>> }
>>
>> // 3. Report your results to your main thread!
>> …
>> }
>
> This is polling and is generally a bad idea, also with such a low timeout your thread will thrash. Furthermore it ties the worker thread up until the operation is complete.
>
> You should instead make a 'concurrent' NSOperation subclass as it's described in NSOperation parlance. What it really means is an asynchronous one.
>
> Implement all the required 'concurrent operation' methods, and in -start you do as you were doing, create an NSURLConnection and schedule it in the +[NSRunLoop mainRunLoop]. In the completed callbacks (under error or success conditions) you mark the operation as isFinished.
>
> This makes your operation cancellable, and frees the worker thread up to service other work units.
>
> Keith
>
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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