wait, sorry, not a set, a dictionary if you intend to have a data object 
related to the connection


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]

Reply via email to