Re: How to get rid of an NSWindowController? Or: Who is retaining my window controllers?
Re: How to get rid of an NSWindowController? Or: Who is retaining my window controllers?
- Subject: Re: How to get rid of an NSWindowController? Or: Who is retaining my window controllers?
- From: Shaun Wexler <email@hidden>
- Date: Mon, 4 Oct 2004 04:15:22 -0700
On Oct 4, 2004, at 3:22 AM, Christian Gottschall wrote:
I have a document-based Cocoa application with several NIB files. Each
NIB file contains, among other things, a window. For each NIB file, I
have a subclass of NSWindowController, say, MyWindowController.
The problem is: When the user closes the window, neither the NSWindow
nor MyWindowController nor, as it seems, the NSArrayController from
the same NIB file gets deallocated. When I close the last window of
the document, MyDocument does get deallocated, though, and ObjectAlloc
shows its count going back to 0.
I have found a few references to similar problems, but all I
understood was that using bindings might somehow introduce some
circular references. Well, I actually use bindings, but even so: Is
there a simple way of getting rid of an unused window controller, or
do I have to do something very complicated?
IMO, this is a huge bug with Cocoa bindings, which "should" use 100%
non-retained observation, but it doesn't. I think NSObject should at
least provide an -unbindAll method. I find that for all of the code I
save with Cocoa bindings, I spend at least 3x the coding time in
workarounds to use them. As per the doc's, it's not remarkably
efficient nor is it preferred for use in performant code. It's a
convenience API, and optional. Unfortunately, there are a lot of good
things that it brings to the table, and it is fairly powerful; it just
needs a few fixes to make it compliant with the document-based
architecture.
A couple years before Cocoa bindings were introduced, I had written my
own base object class which provides thread-safe non-retained
observation and notification, and use it extensively to this day. Each
object maintains a pair of map tables, and when an object is
deallocated, all its observers and observed objects are first notified
to remove any pointer references. Objects can be registered as
observers of arbitrary objects, and are automatically notified by the
observed object if they implement the notification's selector when it
is posted. This, in conjunction with IMP caching in loops, atomic
bitfields, and several flavors of atomic linked lists, results in an
enormously efficient high-performance model layer. I find that this
cooperates perfectly well with Cocoa Bindings, which still has its
problems with retention and order-of-updating which must constantly be
worked around. Overall, I think Cocoa bindings are good, but
definitely not perfect, and not suitable for all types of applications.
I use them, and try to make the best of it.
Somewhere there has been a suggestion to programmatically removing
certain bindings when closing the window. Not only does this seem a
bit tedious, but as of now I do not understand what bindings might be
responsible, and, hence, what bindings to remove.
One suggestion I read was that bindings going through file's owner
cause a circular retaining relationship. In fact, I have such a
binding in most, but not all of my NIBs. Unfortunately, the single NIB
that has no such binding doesn't get released, either.
The workaround is not to bind anything to/thru the NSWindowController.
You have to place nib outlets in the NSDocument, in which you can bind
to the model objects, etc. Anything in the NSWindowController is
off-limits to bindings. Yes, it breaks (and almost completely
destroys) the elegance of the "former" document-based Cocoa
application, but a lot of view outlets can be successfully eliminated
with the use of NSController and bindings, and a few other outlets
become necessary. I keep my model code in the models, the
saving/loading and nib bindings glue code in the document, and
responder/delegate methods in the controller(s). I hope Apple has
figured out how to fix the retain cycle problem, because we lose a lot
of flexibility when we're unable to use NSWindowController subclasses
as the nib owner.
--
Shaun Wexler
MacFOH
http://www.macfoh.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden