Re: Tracking multiple NSURLConnections
Re: Tracking multiple NSURLConnections
- Subject: Re: Tracking multiple NSURLConnections
- From: aglee <email@hidden>
- Date: Wed, 30 Jun 2010 10:17:06 -0700 (PDT)
- Date-warning: Date header was inserted by spool003.mac.com
(Coming late to this thread...)
I recently used both approaches. Subclassing NSURLConnection worked nicely and was quick to code when I had just one kind of delegate behavior. When I had to add other kinds of delegate behavior I switched to the multiple-delegate-classes approach and used plain NSURLConnection.
My classes are lightweight wrappers that hide the NSURLConnection machinery and define their own delegates (this is the weak pointer Dave described). My classes' delegates are notified when either (1) the connection fails, (2) the connection finishes getting the data and the data is invalid, or (3) the connection finishes getting the data and the data is okay.
This was my first time using NSURLConnection, so I'm glad each of the two approaches I used makes sense to at least one other person. :)
--Andy
On 29 Jun, 2010,at 03:31 PM, Stevo Brock <email@hidden> wrote:
You could also subclass NSURLConnection and add any additional data to your subclass that you can easily access in the callbacks.
On Jun 29, 2010, at 12:11 PM, Dave DeLong wrote:
If you're spawning dozens of connections, you may want to consider giving each one a separate delegate object and encapsulating that connection's specific logic in that delegate. The url connection delegate might then have a weak pointer back to the original controller to notify when the connection is finished, at which point the controller could extract any data it needs from the connection delegate.
Dave
On Jun 29, 2010, at 1:08 PM, email@hidden wrote:
Now, a devil's advocate question:
If I have lots of connections, say two dozen, or say I'm spawning connections continuously, would this be the most efficient way of doing this? I'd likely store them in an NSArray and iterate/compare until I find the right one. There could be lots of comparisons.
_______________________________________________
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
-Stevo
_______________________________________________
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
_______________________________________________
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