KVO observation vs NSNotificationCenter observation
Asked Answered
M

2

11

I'm wondering if there is a reason to use one over the other in KVO vs NSNotificationCenter observations. Performance, memory usage, speed, etc?

Musical answered 20/9, 2011 at 1:15 Comment(0)
M
15

The two are not always interchangeable. Conceptually, KVO is only for observing a property of an object. For example, you can't use KVO to replace NSApplicationWillTerminateNotification because it notifies observers about an event happening, not a change in a property of an object.

As for performance and memory usage, they are both fast and use negligible memory. NSNotificationQueue has coalescing to stop floods of notifications. KVO doesn't have any coalescing as far as I know, which did cause performance issues for me at one point. I was observing hundreds of objects, and when a batch update happened to those objects I'd get hundreds of KVO callbacks. It wasn't a performance issue with KVO itself, but with my own code running as a result of the batch update.

Performance isn't really the issue, it's more about the best fit for the problem. If it's a property change, use KVO. If it's not a property change, use a delegate or a notification depending on whether you need a single observer or multiple observers.

Manse answered 20/9, 2011 at 4:4 Comment(3)
Ah. Didn't know about the aggregation of notifications. That's a fairly important thing for me.Musical
Notifications are best used where there is no need for one object to know about some specific other object. For example, you might want to refresh a bunch of views if some setting changes in your app and with notifications those views do not have to have any knowledge of the object that manages the settings, which preserves MVC.Snitch
I would add to “if it’s a property use KVO” with if it’s a property of an object that is retained by the observing object use KVO. Because the observed object needs to stay around so remove observer can be called on it.Brought
R
1

A very old question, but thought of adding some points. I agree with Tom Dalling's answer, however, there are many scenarios in big applications where we tend to add observer for a property of an object and we cannot, or, we miss out removing them from list of observers.

Let us consider the following scenario from my application - A ViewController displays a snake object, I am observing for a property change on this object - "venom". So whenever viewController needed to show a different snake I would simply remove the view controller from observer of that snake object.

The app evolved to show a list of snakes instead of a single snake, this means I had to observe for property of all snakes in that object. Now, when an old snake is removed from the array I should get to know about this event so that I can remove view controller as observer from this snake object. To do this, I have to first observe for changes on the array itself. To do this I have to follow particular protocol to insert objects into array and remove them from array. This way the complexity builds on. We all do know the consequences of not removing observer from an object and if that object is released by the OS!

Above is just one example to cite, the main problem here is I cannot get the list of KVO observers for a given object to remove them from observers before this object gets released - This can be easily achieved by NSNotification and NSNotificationCenter. At times, I tend to be inclined towards using NSNotification over KVO, however, KVO always has edge over notification in terms of good design practice.

Rolfrolfe answered 17/2, 2015 at 6:29 Comment(1)
You mean NSNotificationCenter’s removeObserver with nil object will remove all the observations without needing to still have them handyBrought

© 2022 - 2024 — McMap. All rights reserved.