On 2010 Jan 29, at 07:59, Mike Abdullah wrote:
> Cocoa bindings unbind themselves when the observing object is deallocated.
> You shouldn't need to do anything special. For your own bindings, it's
> probably a good to make them behave similarly.
Thanks, Mike. Here we go with that word multi-purpose word "bindings" again.
I'm presuming that you mean:
"Cocoa bindings" = assigned in a nib
"your own bindings" = made in code with -bind:toObject:withKeyPath:options
Then you're telling me that if I code
[fooObject bind:@"fooBinding"
toObject:barObject
withKeyPath:@"barKey"
options:0] ;
Then it is sufficient to do this
[self unbind:@"fooBinding"] ;
in the -dealloc method of FooObject. Let me know if I am interpreting you
incorrectly.
I may be wrong, but I thought I've had trouble doing this, that I'd sometimes
get a crash when a bindings observation message was sent as a document was
being closed. So I started doing it earlier and the crashes stopped.
>> 3. Cancel NSURLConnections which may send messages to the doc.
>
> What manages these connections normally?
In one application, I make a lot of short-lived NSURLConnections, and they each
have their own delegate. I suppose there are other ways to do this, but let's
not worry about that.
>> I've been using -[NSDocument close], but in its documentation I read that
>> "This method may not always be called". I've not experienced this. When
>> might it not be called? [1]
>
> There are two possible scenarios:
>
> A) The document is deallocated without -close ever being called
> B) The application quits without needing to deallocate or close the document.
>
> In practice, A won't happen unless you start manually allocating documents
> and deallocating without calling -close.
OK, I get that.
> As of Snow Leopard, if an app declares itself suitable, we have fast
> termination. Rather than ask all documents to close, the process will be
> terminated without any methods being called. So, your documents never know
> that will/did close.
Sean, thanks for the links to the Fast Killing. In these notes, Apple explains
that they don't want you to require things that *must* be done in order to
preserve data integrity. They don't discuss my issue, which is things that
*should* be done if the application were going to continue and possibly send
messages to dead objects. But if the app is going to be killed immediately --
I hope -- that shouldn't matter.
In other words, when Apple asks me "Can I kill you?", I'd like to answer "Well,
yes as long as you do so immediately and don't send any messages to half-dead
objects in the process and then tell the user that I 'quit unexpectedly'".
Maybe I'm being too cautious today.
Thanks, guys.
_______________________________________________
Cocoa-dev mailing list ([email protected])
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
