Re: NSURLDownload and userInfo
Re: NSURLDownload and userInfo
- Subject: Re: NSURLDownload and userInfo
- From: Ben Lachman <email@hidden>
- Date: Mon, 10 Mar 2008 23:06:04 -0400
On Mar 10, 2008, at 9:52 PM, Jens Alfke wrote:
On 10 Mar '08, at 6:35 PM, Ben Lachman wrote:
Alternatively, if you're managing more than two requests at a time
you can declare a mutable array of connections and then build a
dictionary for each connection that includes any info you want you
delegate to have available.
I think it's cleaner just to declare a class with that info as its
instance variables, and then use a separate instance of that class
as the delegate for each connection. That way you're working _with_
the API instead of around it.
—Jens
I don't know if I agree with the working with the APIs bit. I think
it's obvious that the APIs expect a single delegate to be able to
handle multiple objects using it concurrently, thus the passing of
the object that is delegating to the delegate. Creating 15 delegate
objects over and over again (in my case every time a user does a
search, submit, etc.) doesn't seem to be a very clean solution as it
spreads your networking code out. You'd basically have to have a
class that starts your connections and then have another class that
is the connection's delegate and then possibly have one of those two
classes, or another one, handle cleaning up or whatever (assuming you
do something with any data you receive after
connectionDidFinishLoading:). I'd rather start connections, handle
their delegate calls and handle the retrieved data within a single
class, this is cleaner in my mind.
I also think Jens' general solution ends up being a proponent of lots
of small, barely there, classes. While I'm not a proponent of
monolithic classes I feel like it is all too easy to end up with
either huge numbers of class files that contain basically no code and
just make project management harder or files with multiple classes
per file which also makes project management harder (worse of the
two, IMO). Xcode largely makes it quite easy to find the method
you're looking for so I really don't see the benefit of splitting
things down to the one/variable class point.
->Ben
--
Ben Lachman
Acacia Tree Software
http://acaciatreesoftware.com
email@hidden
740.590.0009
_______________________________________________
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