Re: Asyncronous message handling
Re: Asyncronous message handling
- Subject: Re: Asyncronous message handling
- From: "Mohan Parthasarathy" <email@hidden>
- Date: Wed, 7 Jan 2009 10:42:59 -0800
On Wed, Jan 7, 2009 at 10:20 AM, Keary Suska <email@hidden>wrote:
>
> On Jan 7, 2009, at 10:44 AM, Mohan Parthasarathy wrote:
>
> NSNotificationCenter? Object Delegation Pattern <
>> http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CommunicatingWithObjects/chapter_6_section_4.html#//apple_ref/doc/uid/TP40002974-CH7-SW26>
>> ? Key-Value Observation?
>> Thanks for your response. I did look at Delegation but perhaps confused
>> because i thought object A also has to know about object B which i guess is
>> not needed. Is the following right understanding ?
>>
>> object A has a method: -(void)fetchData:(id)sender
>> and also looks for a delegate in object B:
>> [sender respondsToSelector:@DataReady]
>>
>> object B sends a message to object A: fetchData:(id)self
>> and implements DataReady
>>
>> This way object A need not know anything about object B i guess.
>>
>> Isn't Notification mechanism used for one-to-many ?
>>
>
>
> The main pitfall to avoid is a retain cycle. In delegation, objects don't
> typically retain their delegates, so you avoid the cycle problem. Delegation
> is often implemented with a protocol, so the objects aren't too tightly
> bound. I.e., the protocol defines the method calls, so you don't need to
> know anything about the delegate, other than it must adopt the protocol in
> some way. Also refer to the URL above with conventions that allow a delegate
> to support multiple "delegators".
So, before making the call to object A, i have to retain the delegate
object. In my use case, the delegate object is the viewController. I am not
sure whether there are any caveats with respect to retaining this. At least,
i can't be sure that this viewController will be the active one and i hope
there is some way to check that.
> Regarding notifications, they simply allow messages to pass between objects
> that aren't related at all--i.e. neither objects has to know anything about
> how to send messages to the other. This allows for a more flexible
> interaction, but is less efficient than delegation. You can also run into
> strange crashes with nested notifications, I have found, but I find
> notifications very useful in many circumstances.
>
> Certainly, delegation is "many-to-one" only in the sense that a delegate
> can be a delegate for many objects but an object can only have one delegate,
> and notifications get around this issue. I would really call notifications
> "many-to-many", since notifications don't have to be specific to certain
> object or class. But there is nothing wrong, IMHO, with only one object ever
> listening for a specific notification (one-to-one).
Thanks for the clarification.
-mohan
>
>
> HTH,
>
> Keary Suska
> Esoteritech, Inc.
> "Demystifying technology for your home or business"
>
>
_______________________________________________
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