[…] is it possible to check if an object actually is observing that property? No. When dealing with KVO you should always have the following model in mind: When establishing an observation you are responsible for removing that exact observation. An observation is identified by its context—therefore, the context has to be unique. When receiving … Read more
In iOS 11, you don’t have to. Just let the observer go out of scope. There is no penalty any longer for letting an observer die before the observed or for letting the observed die before the observer, so you have no actual work to do. On the other hand, if you really want to … Read more
Use a delegate if you want to talk to only one object. For example, a tableView has a delegate – only one object should be responsible for dealing with it. Use notifications if you want to tell everyone that something has happened. For example in low memory situations a notification is sent telling your app … Read more
The important thing is (generally speaking) that you use something (as opposed to nothing) and that whatever you use be unique and private to your use of it. The primary pitfall here happens when you have an observation in one of your classes, and then someone subclasses your class, and they add another observation of … Read more
Swift 4 introduced a family of concrete Key-Path types, a new Key-Path Expression to produce them and a new closure-based observe function available to classes that inherit NSObject. Using this new set of features, your particular example can now be expressed much more succinctly: self.observation = object.observe(\.keyPath) { [unowned self] object, change in self.someFunction() } … Read more
You need to add to your UIDatePicker the UIControlEventValueChanged event to handle date changes: [myDatePicker addTarget:self action:@selector(dateIsChanged:) forControlEvents:UIControlEventValueChanged]; Then the implementation: – (void)dateIsChanged:(id)sender{ NSLog(@”Date changed”); }
But shouldn’t the synthesized accessors automatically return such a proxy object? No. What’s the proper way to work around this–should I write a custom accessor that just invokes [super mutableArrayValueForKey…]? No. Implement the array accessors. When you call these, KVO will post the appropriate notifications automatically. So all you have to do is: [myObject insertObject:newObject … Read more
There are usually notifications or other observable events where KVO isn’t supported. Even though the docs says ‘no’, it is ostensibly safe to observe the CALayer backing the UIView. Observing the CALayer works in practice because of its extensive use of KVO and proper accessors (instead of ivar manipulation). It’s not guaranteed to work going … Read more
You still can implement -dealloc under ARC, which appears to be the appropriate place to remove the observation of key values. You just don’t call [super dealloc] from within this method any more. If you were overriding -release before, you were doing things the wrong way.
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 }