(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 <st...@monkey-tools.com> 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, lorenzo7...@gmail.com 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 (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/stevo%40monkey-tools.com
This email sent to st...@monkey-tools.com
-Stevo
_______________________________________________
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/aglee%40maccom
This email sent to ag...@mac.com
_______________________________________________
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
