This explanation is good to start with but the reader has to read a much more in depth explanation afterwards because the example given by the author is flawed:
He is registering an observer without using a context. If you remove the observer without specifying a context then bad things can happen if two observers do the same. For this reason there is a new method for this in 10.7 and this fact should have been mentioned because so many people have wasted so many hours debugging KVO.
I have used KVO for quite some times and I've never had to add a context to it. This could be because I don't see the benefit of adding such context.
Would you have any example to show the use of context? I've always wondered why I should use context so this would not only educate me but others that are like me: clueless about context ;)
“…by specifying a context every time and using one that’s not only unique to your object but also to the file containing your subclass you can ensure that the message sent to you is actually for you and you avoid potentially stepping on the toes of your super class.”
You also could use [object class] instead of an arbitrary static pointer.
I never had issue with a class and a subclass using the same observer keypath. Whenever I use it I always call super to make sure everything underneath is called. But that's a good thing to know for sure, thanks.
andrewsardone already gave you a hint but allow me to say a bit more:
If you look at the Key Value Observing Protocol you will find two methods that allow you to remove an observer again (remember: You have to remove an observer at the appropriate time - otherwise you will receive exceptions and your app will probably crash):
removeObserver:forKeyPath: and removeObserver:forKeyPath:context:. The first one has been around forever but it does not allow you to specify a context - only an observer and a path. This is problematic and andrewsardone gave you an example. This is why Apple introduced the second method in 10.7/iOS 5 which allows you to specify a (unique) context. The documentation says:
"Examining the value in context you are able to determine precisely which addObserver:forKeyPath:options:context: invocation was used to create the observation relationship. When the same observer is registered for the same key-path multiple times, but with different context pointers, an application can determine specifically which object to stop observing."
Always specifying a context makes your app more robust.
Yeah, I'm sorry. I first entered a comment saying that the website was down due to "Error establishing a database connection" and I saw your comment and decided to comment on it.
I then forgot to say I couldn't read the post since the site was down:( I will read it when it gets back online.
Another tip I would add is that messages sent to observeValueForKeyPath:ofObject:change:context: may not occur on the main thread.
For example, if you have multiple operations in an NSOperationQueue (like web service requests), and one of those operations updates a property on the object being observed, the observing method is called on that operation's thread. This can cause issues if the observing method needs to update the GUI. In this case, you'd need to use GCD to make sure the contents of the listening method execute on main thread (or alternatively, make sure the object's property is updated on the main thread).
It's a very minimal explanation. But it's good that more people know about KVO, it can really simplify your code. It becomes even nicer when you use something like BlocksKit, because then you don't have to do the annoying checks in the observer method: http://dizzytechnology.com/data/BlocksKit/Categories/NSObjec...
He is registering an observer without using a context. If you remove the observer without specifying a context then bad things can happen if two observers do the same. For this reason there is a new method for this in 10.7 and this fact should have been mentioned because so many people have wasted so many hours debugging KVO.