you don’t need to enumerate, you simply would ask for the item in the set and it would return the object that you would then copy the data into On Jun 29, 2010, at 4:08 PM, [email protected] wrote:
> For elucidation ... why an NSSet? > > -koko > > On Jun 29, 2010, at 1:44 PM, Scott Anguish wrote: > >> in that case you’d probably use an NSSet rather than an array >> On Jun 29, 2010, at 3:08 PM, [email protected] 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. >>> >>> On Jun 29, 2010 1:59pm, Scott Anguish <[email protected]> wrote: >>>> store the conn_1/conn_2 variables someplace. Then you compare them to the >>>> one returned by the delegate method. >>>> >>>> >>>> >>>> >>>> >>>> On Jun 29, 2010, at 2:53 PM, [email protected] wrote: >>>> >>>> >>>> >>>>> So then if I do this: >>>> >>>>> >>>> >>>>> NSURLConnection * conn_1 = [[NSURLConnection alloc] >>>>> initWithRequest:request_1 delegate:delegate >>>>> startImmediately:startImmediately]; >>>> >>>>> NSURLConnection * conn_2 = [[NSURLConnection alloc] >>>>> initWithRequest:request_2 delegate:delegate >>>>> startImmediately:startImmediately]; >>>> >>>>> >>>> >>>>> Given that my controller is set as the connection's delegate, when data >>>>> returns this will be called: >>>> >>>>> connection:didReceiveData: >>>> >>>>> >>>> >>>>> connection is an NSURLConnection, but how do I determine which connection >>>>> returned data? Is there something in the NSURLConnection object that >>>>> tells me if it was conn_1 or conn_2? What I do with my data depends on >>>>> knowing this. >>>> >>>>> Sorry, if I'm not getting something here. >>>> >>>>> >>>> >>>>> On Jun 29, 2010 1:21pm, [email protected] wrote: >>>> >>>>>> Maybe I'm misunderstanding you, but when your delegate methods (for the >>>>>> connection finishing or failing, receiving data, etc...) get called, you >>>>>> get a reference to the NSURLConnection object that the event refers to. >>>>>> I keep track of multiple connections this way with no problem. >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>>> Eric C. >>>> >>>>> >>>> >>>>>> Blog: http://www.onelazyprogrammer.com >>>> >>>>> >>>> >>>>>> Company: http://www.infusionsofgrandeur.com >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>>> On Tue, 29 Jun 2010 16:00:34 [email protected] wrote: >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>>>> I have and app that needs to send out multiple connection attempts. >>>> >>>>> >>>> >>>>>>> NSURLConnection doesn't appear to allow one to distinguish between >>>> >>>>> >>>> >>>>>>> connections. I found a couple of posts at cocoabuilder that provide some >>>> >>>>> >>>> >>>>>>> guidance, but I wanted to ask about my approach. I'm writing for 10.6, >>>>>>> so >>>> >>>>> >>>> >>>>>>> I'm using a category on NSURLConnection combined with associative >>>> >>>>> >>>> >>>>>>> references. The methods in the category are below, but basically I >>>> >>>>> >>>> >>>>>>> associate an integer with a given connection and track the connections >>>> >>>>> >>>> >>>>>>> using that. So, short of subclassing or following what I've found in the >>>> >>>>> >>>> >>>>>>> archives, does this make sense? Am I missing any details that might >>>>>>> cause >>>> >>>>> >>>> >>>>>>> this to fail? >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> _______________________________________________ >>>> >>>>> >>>> >>>>> Cocoa-dev mailing list ([email protected]) >>>> >>>>> >>>> >>>>> 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/scott%40cocoadoc.com >>>> >>>>> >>>> >>>>> This email sent to [email protected] >>>> >>>> >>>> >> >> _______________________________________________ >> >> Cocoa-dev mailing list ([email protected]) >> >> 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/koko%40highrolls.net >> >> This email sent to [email protected] >> > _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
