Re: ARC and NSObjectController bindings through file's owner

[Quincey Morris]

On Aug 1, 2014, at 12:03 , Jerry Krinock  wrote:

> Unfortunately, I’m not able to justify my design pattern based on the Cocoa 
> Bindings API documentation.

As I said earlier in the thread, that fact that the error messages go away 
doesn’t mean the problem doesn’t exist. However, I think you’re correct that a 
good-enough solution is here good enough.

> Looking through my code, although I never really gave this too much thought, 
> it appears that I tend to -unbind: when in doubt.

I’d suggest sprinkling around the setting of relationships to nil (KVO 
compliantly). If you do that, bindings will take care of themselves, and you’ll 
deal with more cases (that is, observations that aren’t bindings).

The other thing we’ve got going for us is that we know *when* the whole 
structure needs to be brought down — when the window closes, or when the 
document closes, depending on which properties we’re talking about — and our 
code can act accordingly. This is not true in the general case of old GC code 
that implicitly relied on a “finalization is eventual resource release” 
heuristic.

As a side effect of this last knowledge, Sean could actually solve his weak 
reference observation problem (though it was not, as it turned out, the cause 
of the error messages in this case) by changing the references back to strong, 
and manually breaking cycles at close time. It’s nicer not to have to do this, 
but it’s certainly feasible.

Rambling on…

I think Swift’s take on the referencing part of this problem is interesting. 
For a situation like this, where the objects have basically the same lifetime, 
as the document, window controller and view controller do in this case, Swift 
encourages you to use ‘unowned’ references rather than weak references to avoid 
the reference cycles.

That’s not quite as scary as the equivalent ‘__unsafe_unretained’ in Obj-C, 
because such references in Swift are *guaranteed* to crash if used after the 
referenced object has been deallocated. In Obj-C, of course, it’s a matter of 
luck whether it crashes.

Unfortunately, Swift has nothing to say (yet) on the subjects of KVO or 
observations, but we live in hope.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC and NSObjectController bindings through file's owner

[Jerry Krinock]

On 2014 Aug 01, at 10:33, Sean McBride  wrote:

> I've tried some similar permutations and they have 'fixed' the issue.  I have 
> about 50 xibs to fix now, so want to be sure I do this correctly. :)  I now 
> find myself questioning basic things. :)

I understand.  It would be nice to have to have a rock solid understanding of 
Cocoa Bindings with no hand-waving.  But I’m not sure that is possible.

> Which parts of a binding's keypath have to be KVO-compliant?  If all parts, 
> how can 'document' and 'managedObjectContext' even be in there at all?  Even 
> in interstitial object controllers as you described?

These are very good questions.  Unfortunately, I’m not able to justify my 
design pattern based on the Cocoa Bindings API documentation.  It’s one of 
those “It makes sense that this could work, and it does work, and it fixes a 
problem, and we need to ship” situations.

On 2014 Aug 01, at 10:51, Kyle Sluder  wrote:

> Because of the NSDocument lifecycle, you can presume these properties will 
> not change while the window is being shown.

Although that is theoretically dangerous, probably thousands of apps are 
dependent on it being true. 

> You could manually unbind the object controller in -windowDidClose: or in an 
> override of -setDocument:, and any other controllers bound through it will 
> hear about the change in a KVO-compliant way.

Looking through my code, although I never really gave this too much thought, it 
appears that I tend to -unbind: when in doubt.

It got me to thinking: I wonder if it is OK to sprinkle -unbind: messages in 
liberally?  Will there be a burp/exception if you -unbind: something more than 
once?  So I did a little test (results below) and it appears that the answer is 
“no”.  But the documentation for -unbind: does not state what happens if the 
indicated binding does not exist :(

I just filed a bug on that documentation: 17887226.  
“-[NSObject(NSKeyValueBindingCreation) unbind:] documentation does not state 
that it is OK to send this message indicating a binding which does not exist or 
has already been unbound. … Because Cocoa Bindings can be constructed in 
various ways, and because exceptions occur if bound objects disappear, 
developers often, sometimes unknowingly, -unbind: a binding more than once in 
edge cases.  That does not cause any trouble.  However, this behavior should be 
documented."

Jerry

*** Test Code ***

// Tags field is a custom control.  This code runs in -windowWillClose.

NSLog(@"tagsField = %@", tagsField) ;
NSLog(@"Before unbinding 1: %@", [tagsField infoForBinding:@"value"]) ;
[tagsField unbind:@"value"] ;
NSLog(@"Before unbinding 2: %@", [tagsField infoForBinding:@"value"]) ;
[tagsField unbind:@"value"] ;

*** Console Output ***

2014-08-01 11:31:43.060 MyApp[5631:303] tagsField = 
2014-08-01 11:31:43.062 MyApp[5631:303] Before unbinding 1: {
NSObservedKeyPath = selectedStarkiTags;
NSObservedObject = "";
NSOptions = {
NSAllowsEditingMultipleValuesSelection = 1;
NSAlwaysPresentsApplicationModalAlerts = 0;
NSConditionallySetsEditable = 1;
NSConditionallySetsEnabled = 0;
NSConditionallySetsHidden = 0;
NSContinuouslyUpdatesValue = 0;
NSMultipleValuesPlaceholder = "Multiple Values";
NSNoSelectionPlaceholder = "No Selection";
NSNotApplicablePlaceholder = "Not Applicable";
NSNullPlaceholder = "No Tags";
NSRaisesForNotApplicableKeys = 1;
NSValidatesImmediately = 0;
NSValueTransformer = "";
NSValueTransformerName = "";
};
}
2014-08-01 11:31:43.063 MyApp[5631:303] Before unbinding 2: (null)

No exceptions were logged.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC and NSObjectController bindings through file's owner

[Kyle Sluder]

On Aug 1, 2014, at 10:33 AM, Sean McBride  wrote:
> 
> On Thu, 31 Jul 2014 09:26:27 -0700, Jerry Krinock said:
> 
>>> One thing I just noticed is that NSWindowController's 'document'
>> property is not actually documented as KVO-compliant.  Maybe that's my
>> problem... but I've been binding through it for over a decade now!
>> 
>> That may well be the real problem, Sean.
> 
> Yup!  Seems like it is.
> 
>> In a similar situation, I solved the “bindings burp” (what I call that
>> nasty message you copied from the console) by inserting *another* object
>> controller into the bindings “path”, to control the *document*.
> 
> I've tried some similar permutations and they have 'fixed' the issue.  I have 
> about 50 xibs to fix now, so want to be sure I do this correctly. :)  I now 
> find myself questioning basic things. :)
> 
> NSWindowController's 'document' property is not documented as KVO-compliant, 
> and neither is NSPersistentDocument's 'managedObjectContext' property.
> 
> Which parts of a binding's keypath have to be KVO-compliant?  If all parts, 
> how can 'document' and 'managedObjectContext' even be in there at all?  Even 
> in interstitial object controllers as you described? 

Because of the NSDocument lifecycle, you can presume these properties will not 
change while the window is being shown.

You could manually unbind the object controller in -windowDidClose: or in an 
override of -setDocument:, and any other controllers bound through it will hear 
about the change in a KVO-compliant way.

--Kyle Sluder

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC and NSObjectController bindings through file's owner

[Sean McBride]

On Thu, 31 Jul 2014 09:26:27 -0700, Jerry Krinock said:

>> One thing I just noticed is that NSWindowController's 'document'
>property is not actually documented as KVO-compliant.  Maybe that's my
>problem... but I've been binding through it for over a decade now!
>
>That may well be the real problem, Sean.

Yup!  Seems like it is.

>In a similar situation, I solved the “bindings burp” (what I call that
>nasty message you copied from the console) by inserting *another* object
>controller into the bindings “path”, to control the *document*.

I've tried some similar permutations and they have 'fixed' the issue.  I have 
about 50 xibs to fix now, so want to be sure I do this correctly. :)  I now 
find myself questioning basic things. :)

NSWindowController's 'document' property is not documented as KVO-compliant, 
and neither is NSPersistentDocument's 'managedObjectContext' property.

Which parts of a binding's keypath have to be KVO-compliant?  If all parts, how 
can 'document' and 'managedObjectContext' even be in there at all?  Even in 
interstitial object controllers as you described? 

Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC and NSObjectController bindings through file's owner

[Quincey Morris]

On Jul 31, 2014, at 09:05 , Sean McBride  wrote:

> Other than use of 'weak', how else might something be changed in a 
> non-KVO-compliant manner in ARC but not GC?  Again, the error is only in ARC 
> and not GC.

I’m not sure this is the most productive way to approach this. The detection of 
an error may depend on the order of deallocation, so your ARC and GC 
implementations may be equally incorrect, but the error not equally reported.

Also, the aggressiveness with which this error is reported may vary with the 
system version and the memory model. I had the impression that Mavericks was 
checking for dangling observers more thoroughly than earlier versions. 




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC and NSObjectController bindings through file's owner

[Jerry Krinock]

On 2014 Jul 31, at 09:05, Sean McBride  wrote:

> One thing I just noticed is that NSWindowController's 'document' property is 
> not actually documented as KVO-compliant.  Maybe that's my problem... but 
> I've been binding through it for over a decade now!

That may well be the real problem, Sean.

On 2014 Jul 30, at 13:33, Sean McBride  wrote:

> - the NSObjectController binds its 'managedObjectContext' binding to:
>   File's Owner.windowController.document.managedObjectContext

In a similar situation, I solved the “bindings burp” (what I call that nasty 
message you copied from the console) by inserting *another* object controller 
into the bindings “path”, to control the *document*.

One of the dangers of Cocoa Bindings is that it is very easy to bind long key 
paths like

   File’s Owner.windowController.document.managedObjectContext.foo.bar.whatever

that work fine in your "proof of concept" but burp or crash when torn down in 
some edge cases.  I’ve found liberal usage of object controllers to be the 
answer.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC and NSObjectController bindings through file's owner

[Sean McBride]

On Wed, 30 Jul 2014 15:45:04 -0500, Ken Thomases said:

>A zeroing weak property changes without emitting KVO change
>notifications.  Therefore, it's not KVO-compliant.  Basically, weak
>properties are incompatible with KVO and bindings.

Ouch!  Didn't realise that.  That's pretty annoying, as weak is useful in ARC 
because ARC doesn't deal with cycles like GC does.  I almost never used weak 
under GC but am now sprinkling them everywhere to deal with cycles.  :(

Is weak KVO-compliant under GC?  I ask because, for now anyway, I'm trying to 
keep my codebase both GC & ARC compliant.

So I changed my property from weak back to strong, but it didn't fix my issue.

I also tried this handy hack to check for KVO+weak, but it didn't find anything 
either:


Know any other way to catch use of KVO+weak?

>Likewise, if any other property along that key path is changed in a non-
>KVO-compliant manner, that would lead to the same sort of error.

Other than use of 'weak', how else might something be changed in a 
non-KVO-compliant manner in ARC but not GC?  Again, the error is only in ARC 
and not GC.

One thing I just noticed is that NSWindowController's 'document' property is 
not actually documented as KVO-compliant.  Maybe that's my problem... but I've 
been binding through it for over a decade now!

Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC and NSObjectController bindings through file's owner

[Quincey Morris]

On Jul 30, 2014, at 13:33 , Sean McBride  wrote:

> File's Owner (my NSViewController subclass) responds to 'windowController' 
> because I have a vanilla synthesized weak property relating my 
> NSViewController to its containing window's controller.

This is the problem. Weak properties aren’t KVO compliant (they change to nil 
when the referenced object deallocates, but no KVO notification is produced), 
so you can’t safel bind through them.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC and NSObjectController bindings through file's owner

[Ken Thomases]

On Jul 30, 2014, at 3:33 PM, Sean McBride  wrote:

> I'm slowing moving my GC app to ARC.  One runtime error I'm stuck at is:
> 
> 
> An instance 0x10f587510 of class MyDocument was deallocated while key value 
> observers were still registered with it.
> 
>  document.managedObjectContext, Options:  
> Context: 0x0, Property: 0x10ee1ac10>
> 
> 
> I have:
> - a nib who's File's Owner is an NSViewController subclass
> - an NSObjectController at the top-level of my nib
> - a strong IOOutlet from my NSViewController to the NSObjectController
> - the NSObjectController binds its 'managedObjectContext' binding to:
>   File's Owner.windowController.document.managedObjectContext
> 
> It's something about that binding that's causing the trouble.  If I remove 
> it, the error goes away.
> 
> File's Owner (my NSViewController subclass) responds to 'windowController' 
> because I have a vanilla synthesized weak property relating my 
> NSViewController to its containing window's controller.
> 
> It works under GC.  I just don't see how this is a problem under ARC... any 
> one have any thoughts?

A zeroing weak property changes without emitting KVO change notifications.  
Therefore, it's not KVO-compliant.  Basically, weak properties are incompatible 
with KVO and bindings.

Likewise, if any other property along that key path is changed in a 
non-KVO-compliant manner, that would lead to the same sort of error.

Regards,
Ken


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com