Re: Nib files in memory
Re: Nib files in memory
- Subject: Re: Nib files in memory
- From: Philip Dow <email@hidden>
- Date: Sat, 24 Jun 2006 19:52:20 +0200
Two very rude caveats here: 1) Is your controller class a subclass of
NSWindowController? 2) Does your nib file contain any
NSObjectControllers, -ArrayControllers or -TreeControllers (those
green boxes)?
1. As Matt mentions, the window controller will automatically release
the nib, so all the objects inside it are released as well.
However, if your nib's file owner is just a subclass of NSObject or
something else, it is *your* responsibility to release the nib's top
level objects. A top level object is almost anything you can see when
you select "Instances" in the nib's window in Interface Builder. That
means you must release any menus, views, object controllers, other
windows and so on. As you release the top level objects, they release
their children, ie a subview contained in the top level view, and all
of the nibs objects are removed from memory.
2. Your nib's file owner / (window) controller will not deallocate if
it contains one of those green boxes whose content is bound to the
file owner, even if you otherwise obey cocoa memory rules.
So for example if you have an NSObjectController whose content is
bound to the nib's file owner / (window) controller, as you allocate
and release the file owner in your code, it will not deallocate as
expected and the nib objects will never be released. You must first
unbind the NSObjectController's "contentObject" and then set it's
content to nil. Because you must do this *before* the object will
release, the best place to do it with a window controller is in the
windowWillClose: notification:
- (void)windowWillClose:(NSNotification *)aNotification {
[objectController unbind:@"contentObject"];
[objectController setContent:nil];
}
Make sure the window's delegate is set to the file owner / window
controller for that method to be called.
This is apparently necessary because the NSObjectController, -
ArrayController, -TreeController retains the object it is bound to.
When it is bound to the nib's file owner, this results in a retain
circle, as the file owner also retains the object controller. Apple
explicitly warns about doing this in its memory management
documentation, and then it is the default behavior for a nib with an
object controller in it!
It took me a year and a half to learn this.
-Phil
On Jun 23, 2006, at 8:55 PM, Matt Neuburg wrote:
On Thu, 22 Jun 2006 18:35:34 -0700, "D.K. Johnston" <email@hidden>
said:
I have a controller class that is instantiated and released by my
programme many times during a run. When initialising, the controller
object loads a nib file with the loadNibNamed: method, in order to
use a window contained therein. In IB, I set the window to be
released when closed.
What I'd like to know is: What happens to the nib file when one of
these controller objects is released? Does it remain in memory? Is
another copy loaded every time the class is instantiated? I can't
seem to find the answer to this question anywhere in the
documentation.
But this is why god gave you the performance tools, such as
ObjectAlloc, to
find out, so why aren't you using them?
However, here's a quick answer:
* Releasing a window controller releases the nib that it owns; that
is part
of the window controller's job. So, no, it doesn't remain in memory.
This is well documented. For example:
<http://developer.apple.com/documentation/Cocoa/Reference/
ApplicationKit/Cla
sses/NSWindowController_Class/Reference/Reference.html>
It says right at the top: "The window controller is responsible for
freeing
all top-level objects in the nib file it loads".
<http://developer.apple.com/documentation/Cocoa/Conceptual/WinPanel/
Concepts
/UsingWindowController.html>
Also useful:
<http://developer.apple.com/documentation/Cocoa/Conceptual/
Documents/Tasks/F
AQ.html>
(Incidentally, notice that it doesn't say "releases the nib", as I
did,
because what I'm saying is a very loose way of putting it. The nib
*file*
was never really in memory in the first place, except accidentally
as part
of virtual memory. The nib file is just a kind of template on disk
containing instructions for forming some objects. To load a nib
file is to
read those instructions and obey them to form those objects.
**Those** are
the objects that are released when the window controller is
released, and
that's all you care about.)
* Yes, another copy of the nib is loaded every time the window
controller is
instantiated; that is one of the main purposes of having a window
controller
and a nib (since otherwise how would you open two copies of a window
simultaneously, as in any doc-based app?).
Note that your decision to release when closed may be a red
herring. It is
not necessary in order to cause the nib (and the window) to be
released when
the window controller is released.
Finally, you might like to rethink your impulse to release the window
controller at all. It's fine, and I do this with certain kinds of
window,
e.g. something that I think the user will probably summon either
zero or one
times through the life of the app. But if, as you say, the thing is
going to
be instantiated "many times during a run", then why release it? Why
not keep
it on hand as a singleton, so that all you have to do, once you've
instantiated it (the first time the user asks to see the window) is
keep
hiding and showing the window?
m.
--
matt neuburg, phd = email@hidden, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide - Second Edition!
<http://www.amazon.com/gp/product/0596102119>
_______________________________________________
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
_______________________________________________
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