Comments on: Key Value Observing Improvements http://shiftedbits.org/2008/07/24/key-value-observing-improvements/ Bits were made to be shifted Wed, 07 Jan 2009 16:45:21 +0000 http://wordpress.org/?v=2.6.3 By: Devin Lane http://shiftedbits.org/2008/07/24/key-value-observing-improvements/#comment-205 Devin Lane Wed, 03 Sep 2008 05:42:43 +0000 http://shiftedbits.org/?p=23#comment-205 Christian: You raise some good points about the context argument. I've released an update (see http://shiftedbits.org/2008/09/03/key-value-observing-improvements-v12/) that includes the selector in determining the uniqueness of an observation. This allows a class and a subclass to observe a single property on a single object with different selectors. This has several advantages over the static NSString* method: 1. No need to declare said strings. 2. No need to check in your -observeValueForKeyPath method if the context is your context. 3. No need to call super. Christian:

You raise some good points about the context argument. I’ve released an update (see http://shiftedbits.org/2008/09/03/key-value-observing-improvements-v12/) that includes the selector in determining the uniqueness of an observation. This allows a class and a subclass to observe a single property on a single object with different selectors. This has several advantages over the static NSString* method:

1. No need to declare said strings.
2. No need to check in your -observeValueForKeyPath method if the context is your context.
3. No need to call super.

]]> By: Christiaan http://shiftedbits.org/2008/07/24/key-value-observing-improvements/#comment-204 Christiaan Tue, 19 Aug 2008 16:25:20 +0000 http://shiftedbits.org/?p=23#comment-204 The context argument is NOT optional in practice, the fact that the API allows it is no reason you should pass NULL. You should ALWAYS use a context, and I'm quoting several well known Apple engineers. You can google for detailed reasons. The main reason is that otherwise you can NEVER know if the observation message is meant for you (there can be any number of observers for the same key/object pair). Moreover, it should always be a unique pointer, and 'self' is far from unique (given the context). A simple solution is to use a static NSString * with a unique name. The context argument is NOT optional in practice, the fact that the API allows it is no reason you should pass NULL. You should ALWAYS use a context, and I’m quoting several well known Apple engineers. You can google for detailed reasons. The main reason is that otherwise you can NEVER know if the observation message is meant for you (there can be any number of observers for the same key/object pair). Moreover, it should always be a unique pointer, and ’self’ is far from unique (given the context). A simple solution is to use a static NSString * with a unique name.

]]> By: Devin Lane http://shiftedbits.org/2008/07/24/key-value-observing-improvements/#comment-200 Devin Lane Thu, 24 Jul 2008 18:15:48 +0000 http://shiftedbits.org/?p=23#comment-200 Steve: This is already a category on NSObject. I'm not sure what you mean. How would you determine if the context argument is a string? It's not as though you can call methods on it. The context argument is most certainly optional, in the sense that anything that can be interpreted as a pointer (an integer of the right size basically) can be passed. I pass NULL almost all the time. However, setting the context argument to self could be useful for determining if a call to super is needed. Steve:

This is already a category on NSObject. I’m not sure what you mean.

How would you determine if the context argument is a string? It’s not as though you can call methods on it.

The context argument is most certainly optional, in the sense that anything that can be interpreted as a pointer (an integer of the right size basically) can be passed. I pass NULL almost all the time. However, setting the context argument to self could be useful for determining if a call to super is needed.

]]> By: Steve http://shiftedbits.org/2008/07/24/key-value-observing-improvements/#comment-199 Steve Thu, 24 Jul 2008 16:45:04 +0000 http://shiftedbits.org/?p=23#comment-199 I have written code that uses the key and creates a selector "keyChanged" and if its implemented, calls that. If that is not implemented, it has other fallbacks to try. You COULD make this a category on NSObject and never write another observeValueForKeyPath method. You could also see if the context argument is a string and use it help your code decide what to do. Also, keep in mind that the context argument is NOT optional and MUST always be provided and if it is not what you expect, then call [super observeValueForKeyPath....] I have written code that uses the key and creates a selector “keyChanged” and if its implemented, calls that. If that is not implemented, it has other fallbacks to try.
You COULD make this a category on NSObject and never write another observeValueForKeyPath method. You could also see if the context argument is a string and use it help your code decide what to do.

Also, keep in mind that the context argument is NOT optional and MUST always be provided and if it is not what you expect, then call [super observeValueForKeyPath....]

]]>