Memory Management of Nib Objects

At various points in a Cocoa application’s runtime life, one or more nib files are loaded and the objects they contain are unarchived. Who is responsible for releasing those objects when they are no longer needed?

Let’s begin by briefly reviewing what’s in an nib file. When you open a nib file in Interface Builder, the items you see in the Instances pane of the nib file window are known as top-level objects (see Figure 1). Some of these items, such as File’s Owner and First Responder, have special significance; they function as proxies or aliases that confer a certain status on true objects. For example, the File’s Owner instance represents an object external to the nib file that is considered its owner; it’s usually (but not necessarily) the object that loads the nib file. Other instances in a nib file window are the root objects of object graphs, such as windows, panels, and menus. And yet other instances can be without graph dependencies, such as mediating controllers used for bindings or custom controller proxies used for making target-action and outlet connections. When a nib file is loaded and its objects unarchived, all top-level objects are assigned a reference count of one.

Figure 1 Top-level objects in a nib file

<IMAGE>

Note: For more on nib files and their contents, see Resource Programming Guide and the section on object archives and nib files in “The Core Application Architecture" of Cocoa Fundamentals Guide.

The File’s Owner of a nib file is typically responsible for releasing the top-level objects in a nib file as well as any non-object resources created by the objects in the nib. The release of the root object of an object graph sets in motion the release of all dependent objects. The File’s Owner of an application’s main nib file (which contains the application menu and possibly other items) is the global application object NSApp. However, when a Cocoa application terminates, top level objects in the main nib do not automatically get dealloc messages just because NSApp is being deallocated. In other words, even in the main nib file, you have to manage the memory of top-level objects.

The Application Kit offers a couple of features that help to ensure that nib objects are properly released:

NSWindow objects (including panels) have an isReleasedWhenClosed attribute, which if set to YES instructs the window to release itself (and consequently all dependent objects in its view hierarchy) when it is closed. In Interface Builder, you set this option through the “Release when closed” check box in the Attributes pane of the inspector.
If the File’s Owner of an nib file is an NSWindowController object (the default in document nibs in document-based applications), it automatically disposes of the windows it manages.

So in general, you are responsible for releasing top-level objects in a nib file. But in practice, if your nib file’s owner is an instance of NSWindowController it releases the top-level object for you. If one of your objects loads the nib itself (and the owner is not an instance of NSWindowController), you can define outlets to each top-level object so that at the appropriate time you can release them using those references. If you don’t want to have outlets to all top-level objects, you can use the instantiateNibWithOwner:topLevelObjects: method of the NSNib class to get an array of a nib file’s top-level objects.

The issue of responsibility for nib object disposal becomes clearer when you consider the various kinds of applications. Most Cocoa applications are of two kinds: single window applications and document-based applications. In both cases, memory management of nib objects is automatically handled for you to some degree. With single-window applications, objects in the main nib file persist through the runtime life of the application and are released when the application terminates; however, dealloc is not guaranteed to be automatically invoked on objects from the main nib file when an application terminates. In document-based applications each document window is managed by an NSWindowController object which handles memory management for a document nib file.

Some applications may have a more complex arrangement of nib files and top-level objects. For example, an application could have multiple nib file with multiple window controllers, loadable panels, and inspectors. But in most of these cases, if you use NSWindowController objects to manage windows and panels or if you set the “released when closed” window attribute, memory management is largely taken care of. If you decide against using window controllers and do not want to set the “release when closed” attribute, you should explicitly free your nib file’s windows and other top-level objects when the window is closed. Also, if your application uses an inspector panel, (after being lazily loaded) the panel should typically persist throughout the lifetime of the application—there is no need to dispose of the inspector and its resources.

< Previous PageNext Page >

Hide TOC

Last updated: 2008-02-08

Did this document help you?
Yes: Tell us what works for you. It’s good, but: Report typos, inaccuracies, and so forth. It wasn’t helpful: Tell us what would have helped.




	Get information on Apple products. Visit the Apple Store online or at retail locations. 1-800-MY-APPLE Copyright © 2007 Apple Inc. All rights reserved. \| Terms of use \| Privacy Notice