Re: Nib files in memory

FROM : Philip Dow
DATE : Sat Jun 24 19:52:20 2006

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_removed>> 
> 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_removed>, <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_removed>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/<email_removed>
>
> This email sent to <email_removed>
>