How can I tell if an object has a key value observer attached

Question

If you tell an Objective-C object to removeObservers: for a key path and that key path has not been registered, it cracks a sad, like:

Cannot remove an observer <observerObject> for the key path "theKeyPath" from <objectbeingObserved> because it is not registered as an observer.

Is there a way to determine if an object has a registered observer, so i can do this

if (object has observer){
  remove observer
}
else{
  go on my merry way
}

Answer 1

Put a try catch around your removeObserver call

@try{
   [someObject removeObserver:someObserver forKeyPath:somePath];
}@catch(id anException){
   //do nothing, obviously it wasn't attached because an exception was thrown
}

Answer 2

The real question is why you don't know whether you're observing it or not.

If you're doing this in the class of the object being observed, stop. Whatever's observing it expects to keep observing it. If you cut off the observer's notifications without its knowledge, expect things to break; more specifically, expect the observer's state to go stale as it doesn't receive updates from the formerly-observed object.

If you're doing this in the observing object's class, simply remember which objects you're observing (or, if you only ever observe one object, whether you're observing it). This is assuming that the observation is dynamic and between two otherwise-unrelated objects; if the observer owns the observed, just add the observer after you create or retain the observed, and remove the observer before you release the observed.

Adding and removing an object as an observer should usually happen in the observer's class, and never in the observed object's.

Answer 3

FWIW, [someObject observationInfo] seems to be nil if someObject doesn't have any observers. I wouldn't trust this behavior, however, as I haven't seen it documented. Also, I don't know how to read observationInfo to get specific observers.

Answer 4

The only way to do this is to set a flag when you add an observer.

Answer 5

When you add an observer to an object you could add it to a NSMutableArray like this:

- (void)addObservedObject:(id)object {
    if (![_observedObjects containsObject:object]) {
        [_observedObjects addObject:object];
    }
}

If you want to unobserve the objects you can do something like:

for (id object in _observedObjects) {
    if ([object isKindOfClass:[MyClass class]]) {
        MyClass *myObject = (MyClass *)object;
        [self unobserveMethod:myObject];
    }
}
[_observedObjects removeAllObjects];

Remember, if you unobserve a single object remove it from the _observedObjects array:

- (void)removeObservedObject:(id)object {
    if ([_observedObjects containsObject:object]) {
        [_observedObjects removeObject:object];
    }
}

Answer 6

In my opinion - this works similar to retainCount mechanism. You can't be sure that at the current moment you have your observer. Even if you check: self.observationInfo - you can't know for sure that you will have/won't have observers in future.

Like retainCount. Maybe the observationInfo method is not exactly that kind of useless, but I only use it in debug purposes.

So as a result - you just have to do it like in memory management. If you added an observer - just remove it when you don't need it. Like using viewWillAppear/viewWillDisappear etc. methods. E.g:

-(void) viewWillAppear:(BOOL)animated
{
    [super viewWillAppear:animated];
    [self addObserver:nil forKeyPath:@"" options:NSKeyValueObservingOptionNew context:nil];
}

-(void) viewWillDisappear:(BOOL)animated
{
    [super viewWillDisappear:animated];
    [self removeObserver:nil forKeyPath:@""];
}

And it you need some specific checks - implement your own class that handles an array of observers and use it for your checks.

Answer 7

[someObject observationInfo] return nil if there is no observer.

if ([tableMessage observationInfo] == nil)
{
   NSLog(@"add your observer");
}
else
{
  NSLog(@"remove your observer");

}

Answer 8

The whole point of the observer pattern is to allow an observed class to be "sealed" -- to not know or care whether it is being observed. You are explicitly trying to break this pattern.

Why?

The problem you are having is that you are assuming you are being observed when you aren't. This object did not start the observation. If you want your class to have control of this process, then you should consider using the notification center. That way your class has full control on when data can be observed. Hence, it doesn't care who is watching.

Answer 9

I am not a fan of that try catch solution so what i do most of the time is that i create a subscribe and unsubscribe method for a specific notification inside that class. For example these two methods subcribe or unsubscribe the object to the global keyboard notification:

@interface ObjectA : NSObject
-(void)subscribeToKeyboardNotifications;
-(void)unsubscribeToKeyboardNotifications;
@end

Inside those methods i use a private property which is set to true or false depending on the subscription state like so:

@interface ObjectA()
@property (nonatomic,assign) BOOL subscribedToKeyboardNotification
@end

@implementation

-(void)subscribeToKeyboardNotifications {
    if (!self.subscribedToKeyboardNotification) {
        [[NSNotificationCenter defaultCenter]addObserver:self selector:@selector(onKeyboardShow:) name:UIKeyboardWillShowNotification object:nil];
        [[NSNotificationCenter defaultCenter]addObserver:self selector:@selector(onKeyboardHide:) name:UIKeyboardWillHideNotification object:nil];
        self.subscribedToKeyboardNotification = YES;
    }
}

-(void)unsubscribeToKeyboardNotifications {
    if (self.subscribedToKeyboardNotification) {
        [[NSNotificationCenter defaultCenter]removeObserver:self name:UIKeyboardWillShowNotification object:nil];
        [[NSNotificationCenter defaultCenter]removeObserver:self name:UIKeyboardWillHideNotification object:nil];
        self.subscribedToKeyboardNotification = NO;
    }
}
@end

Answer 10

In addition to Adam's answer I would like to suggest to use macro like this

#define SafeRemoveObserver(sender, observer, keyPath) \
@try{\
   [sender removeObserver:observer forKeyPath:keyPath];\
}@catch(id anException){\
}

example of usage

- (void)dealloc {
    SafeRemoveObserver(someObject, self, somePath);
}

Answer 11

Long Story Short

Take NSObject category from here and use it like this:

if ([observable tdw_hasObserver:observer forKeyPath:@"key.path" context:nil error:nil]) {
    [observable removeObserver:observer forKeyPath:@"key.path"];
} else {
    // go on your merry way
}

---

Public API approach

For many Foundation classes, which don't have any other observers but yours, you can just check observationInfo property value. The property returns a null pointer when the object doesn't have any observers or an opaque void * pointer otherwise:

if (observable.observationInfo) {
    [observable removeObserver:observer forKeyPath:@"key.path"];
} else {
    // go on your merry way
}

This, however will not work for most of UIKit classes and scenarios where you yourself use more than one observer.

---

Private API approach

If you don't mind messing with private API, any object can provide you with an opaque pointed to its observers data with use of NSObject's observationInfo property. Under the hood the pointer holds an object which in turn holds an array of so-called observances - special data structure to describe a single subscription (every invocation of -[NSObject addObserver:forKeyPath:options:context:] creates a new instance in the array, even if all arguments are the same). An observance memory layout (at the time of writing this answer at least) looks something like this:

@interface NSKeyValueObservance: NSObject {
    id _observer;
    NSKeyValueProperty *_property;
    void *_context;
    id originalObservable;
}

The combination of these variables is the information you are looking for. Of course you cannot reliably extract this data, because it's private API, however the following contract keeps working since ages ago:

1. observationInfo should have an NSArray ivar which holds observances data;
2. _observer, _property and _context ivars names are as is;
3. _context and _observer can be compared with the desired data by pointer addresses;
4. _property ivar has _keyPath of type NSString to compare with the desired key-path;

With that in mind you can extend NSObject with a category and implement a convenient method which checks whether certain combination is present or not.

I don't mind sharing my own implementation but it's a little too much to fit in a single SO answer. You can check it out in my gists page. Be advised, that this implementation performs ivars lookup by name and (sometimes) types. It is somewhat safer than just directly using ivar offsets, but still very fragile.

Here is a simple example of how to use it:

NSObject *observable = [NSObject new];
NSObject *observer = [NSObject new];
void *observerContext = &observerContext;

[observable addObserver:observer forKeyPath:@"observationInfo" options:NSKeyValueObservingOptionNew context:observerContext];
[observable addObserver:observer forKeyPath:@"observationInfo" options:NSKeyValueObservingOptionNew context:nil];
[observable addObserver:observer forKeyPath:@"observationInfo" options:NSKeyValueObservingOptionNew context:observerContext];

// Removes only 2 observances (subscriptions) where all parts matches (context, keyPath and observer instance)
while ([observable tdw_hasObserver:observer forKeyPath:@"observationInfo" context:observerContext error:nil]) {
    [observable removeObserver:observer forKeyPath:@"observationInfo" context:observerContext];
}

Two-Sentence documentation

If context and/or keyPath arguments are nil, the implementation looks for subscriptions with any context and/or keyPath.

In case of any (expected) error, the method returns NO and writes error details to the error object, if corresponding pointer is provided. Expected errors include some minor changes in the private API (but far from any).