Comments on: NSNotification, UserInfo and Object Methods http://iPhoneDeveloperTips.com/cocoa/nsnotification-userinfo-and-object-methods.html iOS Developer Tips, Tricks and Tutorials. Wed, 08 Feb 2012 06:31:16 -0600 hourly 1 http://wordpress.org/?v=3.3.1 By: Paulo Khouri http://iPhoneDeveloperTips.com/cocoa/nsnotification-userinfo-and-object-methods.html#comment-23246 Paulo Khouri Wed, 11 Aug 2010 14:28:29 +0000 http://iPhoneDeveloperTips.com/?p=6450#comment-23246 Thanx, helped a lot =D Thanx, helped a lot =D

]]> By: Charlie http://iPhoneDeveloperTips.com/cocoa/nsnotification-userinfo-and-object-methods.html#comment-19227 Charlie Thu, 08 Jul 2010 12:28:48 +0000 http://iPhoneDeveloperTips.com/?p=6450#comment-19227 Very good. Very good.

]]> By: Michelle http://iPhoneDeveloperTips.com/cocoa/nsnotification-userinfo-and-object-methods.html#comment-18474 Michelle Thu, 01 Jul 2010 15:28:27 +0000 http://iPhoneDeveloperTips.com/?p=6450#comment-18474 Actually, the object method is a bit more complex than you suggest. It does not give you the object that sent the notification; rather, it gives you whatever was assigned in postNotificationName:object. This need not be the notifying object. This allows a shortcut, albeit one that some developers would consider poor practice: instead of messing around with the userInfo parameter, just pass the data that the observer needs (an NSString, say) as the object. So long as the relevant data is only a single object and the listeners don't need to specify a single object to listen to, this will work just fine. The advantages of that approach are 1) a tiny increase in efficiency by not having to create the dictionary, release it, put an object into it and pull it out, 2) fewer lines of executable code, 3) not having to create a key that has no other purpose and expose it to both the senders and receivers. Also note that there is some unfortunate coupling when you use the standard userInfo-related method: you need a notification string and a set of notification key strings that have to be managed as a unit. Ultimately, using the shortcut is a matter of taste. I can understand the distaste some might have for it, but it has its uses. Actually, the object method is a bit more complex than you suggest. It does not give you the object that sent the notification; rather, it gives you whatever was assigned in postNotificationName:object. This need not be the notifying object.

This allows a shortcut, albeit one that some developers would consider poor practice: instead of messing around with the userInfo parameter, just pass the data that the observer needs (an NSString, say) as the object. So long as the relevant data is only a single object and the listeners don’t need to specify a single object to listen to, this will work just fine.

The advantages of that approach are 1) a tiny increase in efficiency by not having to create the dictionary, release it, put an object into it and pull it out, 2) fewer lines of executable code, 3) not having to create a key that has no other purpose and expose it to both the senders and receivers.

Also note that there is some unfortunate coupling when you use the standard userInfo-related method: you need a notification string and a set of notification key strings that have to be managed as a unit.

Ultimately, using the shortcut is a matter of taste. I can understand the distaste some might have for it, but it has its uses.

]]>