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
>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
