For Realm Objects, the dealloc spy doesn't seem to work. I think perhaps because they're trying their own variant of removing all observers when deallocating. For example, if I add a KVObserver to a Notification object's application key, when the Notification deallocs I get an exception:

Cannot remove an observer <PMKVObserver …> for the key path "application" from <RLMAccessor_v0_Notification …> because it is not registered as an observer.

I'm working around it for now by calling .cancel() liberally, sort of like normal KVO deregistering but at least more safe. I'm not sure if this is really a bug in PMKVObserver, but I figured I'd at least pass on my findings.

The new #keyPath expression that landed in Swift 3 allows to designate an ObjC selector that can be enforced by the compiler: https://github.com/apple/swift-evolution/blob/master/proposals/0062-objc-keypaths.md

It would be awesome for PMKVObserver to make use of #keyPath instead of relying on a simple String.

Hi @lilyball 👋

This library has been great so far, thanks for your work on it!

I did notice a crash in the dealloc observer when this was use for a camera session, specifically when switching between front and rear cameras.

We use a single queue for all camera operations.

I can try and put together a repro sample project as well once I get some time to test it in isolation. For now, switching back to normal KVO seems to work fine.

The following code causes KVO to raise an exception:

#import "ViewController.h"

#import <PMKVObserver/PMKVObserver.h>

@interface ChildObject : NSObject
@end

@implementation ChildObject
@end

@interface RootObject : NSObject
@property (strong, nonatomic) ChildObject *child;
@end

@implementation RootObject
@end

@interface Observer : NSObject

- (void)start;

@property (atomic, nullable) RootObject *root;

@end

@implementation Observer

- (void)start {
  [PMKVObserver observeObject:self keyPath:@"root.child" options:0
                        block:^(id object, NSDictionary<NSKeyValueChangeKey,id> *change,
                                PMKVObserver *kvo) {}];

  dispatch_apply(100000, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0),
                 ^(size_t i) {
                   RootObject *root = [[RootObject alloc] init];
                   root.child = [[ChildObject alloc] init];
                   self.root = root;
                 });
}

@end

@implementation ViewController

- (void)viewDidLoad {
  [super viewDidLoad];

  Observer *observer = [[Observer alloc] init];
  [observer start];
}


@end

I reported this issue to Apple, but they claim that this is the expected behavior.

Given that PMKVObserver mission is to provide "Modern thread-safe and type-safe key-value observing for Swift and Objective-C", I assume that this is a use-case that the library should handle.

The latest pod spec with Swift and ObjC subspecs has not been pushed to the central CocoaPod repo so currently can't be used.

Could you please update it.

PR that was merged with the updated spec https://github.com/postmates/PMKVObserver/pull/7

The existing pod spec brings in the objective-c files and swift. If using this pods in a project which includes static libs then the pod can not be used as it contains swift and there has to be a framework.

This PR includes a 2 subspaces one for ObjC and one for Swift.

Example usage just for ObjC

      pod 'PMKVObserver/ObjC'

I've been putting off filing this issue because of procrastination and because I haven't been able to create a sample project to recreate the crash, but I'll try and provide as much info as possible.

I work for an unnamed food delivery service that rhymes with "roast dates". We recently updated to Swift 5.2 and found a crash in production that only happened in a certain scenario with compiler optimizations on. I found that you had already discovered some strange behavior while compiler optimizations are enabled here: https://github.com/postmates/PMKVObserver/commit/778390212076933d66325756a3f91d26698e4e34

So I updated the SDK, but still saw the same crash. The stack trace in production looks like this:

And our code that is using the library looks like:

extension UILabel {
    private static var map = AssocMap<(style: TextStyle, observer: KVObserver)>()

    var textStyle: TextStyle? {
        get {
            return UILabel.map[self]?.style
        }

        set {
            if let style = newValue {
                let observer = KVObserver(object: self, keyPath: \UILabel.text, options: .new) { object, _, _ in
                    object.updateTextWithStyle()
                }

                UILabel.map[self] = (style: style, observer: observer)
                updateTextWithStyle() // Update last, once the token/observer and style are registered
            } else {
                UILabel.map[self]?.observer.cancel()
                UILabel.map[self] = nil
            }
        }
    }

We are using the AssocMap library as well. Do you think TSAO needs to be modified in a similar way as you did to this project?: https://github.com/lilyball/swift-tsao/blob/e15c51277b84be62cf003cd654ad02245f87e15d/Sources/TSAO.swift#L31

Why I hesitated to file this is because I'm not sure what exactly causes the crash. The crash logs in Xcode would open unrelated places in the code where we were setting .text which makes me think it's accessing other labels in the AssocMap and finding deallocated labels. Let me know if I can provide any more info or if I should just wait until this Swift PR is merged and released and see if that resolves this issue: https://github.com/apple/swift/pull/31662

Thank you!

It would be great to have a kvoController.cancelAll().

For example, if I have a childViewController which is observing some properties only when it's on screen, then cancelling all each when disappearing, reobserving when reappearing... In the implementation, I have to keep a reference on each token, then cancel them all one by one. It's ok to do this burden, but I think that's would be a cool feature for PMKVObserver :)

@kballard

Here's a fix for https://github.com/postmates/PMKVObserver/issues/10

Most of the migration work was done automatically with the Xcode migration tool. All I had to do is to play around with NSKeyValueChangeKey and unsafeDowncast.

All tests pass on both OSX and iOS.

I would suggest to merge this code in a new branch swift-3.0 to keep the code separate until Xcode 8 is released.

Let me know if you have any questions!

This change is

When replacing the spinlocks, we added a pthread_mutex_t to each observer. We need to profile this to find out how expensive it is to create and destroy these things. And if possible, find out how many system resources a mutex takes as well. If it turns out to be expensive, there's a few reasonable alternatives:

1. Use a dispatch_queue_t instead. IIRC they're somewhere on the order of 100-200 bytes, which isn't too bad, and the system should support creating as many of these as we need.
2. Use a bank of mutexes instead, picking one based on a hash of the observer address. This is similar to how the obj-c runtime handles its internal (safe) spinlocks. The benefit is the memory overhead is fixed no matter how many observers we create; the downside is access to a mutex can block because a different observer is using it.
3. Use @synchronized(self). I avoided it because it's not really clear what the runtime behavior of that is; I don't know if it uses a mutex per object, or a bank of mutexes, or even something else.

Hopefully mutexes turn out to be sufficiently cheap that we can keep the current behavior.

I've been using your library for some times now and it work as intended.

I tried today to add it to a new project but I'm unable to have the block triggered after the call for .initial. I've tried it on xcode 9, iOS11 swift 3.2 as well as Xcode 8, iOS 10 and swift 3 without success. I'm using version 2.0.2 of PMKVObserver. Even in an empty project with just the following code in the root view controller, the block is called only one time and display the initial value for my property.

var foo:String = "foo"
var token:KVObserver?

override func viewDidLoad() {
   super.viewDidLoad()
   // Do any additional setup after loading the view, typically from a nib.
   
       token = KVObserver(object: self, keyPath: "foo", options:[NSKeyValueObservingOptions.initial, NSKeyValueObservingOptions.new]) { (object, change, kvob) in
           print(object.foo)
       }
   
       DispatchQueue.main.asyncAfter(deadline: .now() + .seconds(2)) { [weak self] in
           guard let strongSelf = self  else {return}
           strongSelf.foo = "foooooooo"
       }
       foo = "fuuu"
}

This code result only on foo being printed one time with it's intial value : "foo". I'm pretty sure I'm missing something very obvious but cannot find what.

Experimentally, it seems that when using "deep" keypaths (keypaths with multiple components), automatic deregistration doesn't work properly. The problem is that by the time the observed object deallocates (and therefore cleans up the observer), the leaf object has already deallocated, and so it throws an exception when trying to unregister the KVO. This pattern should work if the observed object outlives self (assuming you use observer: self), or if the observed object deallocates prior to the next object in the path, but in the common case the observed object owns the deeper object and so doesn't deallocate in time.

AFAIK the only way to truly fix this is to completely sidestep KVO's built-in handling of "deep" keypaths and rebuild that ourselves, so that way we can attach the dealloc spy to every component of the path. This is a lot of work and would be very tricky to get right so I'm reluctant to do this. Alternatively we could actually isa-swizzle the observed object in order to clean up KVO at the start of dealloc instead of the end, but that's really nasty.

In the meantime, we should document this scenario.