Who owns an NSWindowController, in standard practice?

Question

I'm seeking further clarification after seeing What is responsible for releasing NSWindowController objects?

I'm writing a simple inventory management application for my nephews. I have a table view that displays the contents of their "library", etc. To add a new item to the library, they click a '+' button. This button opens a new window prompting them the details of the item, and validates the input when they click 'OK'.

All of that is working just fine. However, I have a question about the memory management. To create the new window, I use the following code:

- (IBAction)addNewItem:(id)sender {
  LibraryItemEditorController *editorController = 
    [[LibraryItemEditorController alloc] 
          initWithWindowNibName:@"LibraryItemEditor"];

  [editorController showWindow:nil];
  // editorController is "leaked" here, it seems.
}

I cannot release (nor autorelease) editorController at the end of addNewItem:, because nothing else is referencing editorController; if I release it, the window immediately disappears. I do, however, want the window controller to be released once its window is closed. In Apple's Window Programming Guide, I read the following:

If you want the closing of a window to make both window and window controller go away when it isn’t part of a document, your subclass of NSWindowController can observe NSWindowWillCloseNotification or, as the window delegate, implement the windowWillClose: method and include the following line of code in your implementation:

[self autorelease];

I've used [self autorelease] in the windowWillClose: method of the window controller. This works, and doesn't leak memory. However, it just feels ugly; addNewItem: looks like it's leaking memory, and static analysis thinks so too. I know that it's actually taken care of in windowDidClose:, but it just feels wrong. Further, the window controller is now releasing itself without ever having retained itself. This all goes against the memory management rules I've learned.

My other option is to put an ivar on the parent controller (either an NSWindowController or an NSMutableSet of NSWindowControllers) and then watch for the NSWindowWillCloseNotification in the parent controller and release it in response. This is cleaner, and is probably what I'll do. It's also a fair amount more work, though, which leads me to my questions.

Is watching for the NSWindowDidCloseNotification the standard way of doing this? What's the standard way of managing NSWindowControllers that are created and destroyed on demand? Is the [self autorelease] way the traditionally-recommended option, and it's only now that we have static analysis that this is a problem?

Answer 1

It sounds like your window is modal, in which case:

[NSApp runModalForWindow:[editorController window]];
[editorController release];

Here's one pattern for non-modal windows:

@implementation QLPrefWindowController

+ (id) sharedInstance
{
    if (!_sharedInstance)
    {
        _sharedInstance = [[QLPrefWindowController alloc] init];
    }
    return _sharedInstance;
}

- (void)windowWillClose:(NSNotification *)notification
{
    if ([notification object] == [self window] && self == _sharedInstance)
    {
        _sharedInstance = nil;
        [self release];
    }
}

Then anyone who wants to access or display the window can do so through the +sharedInstance class method. If the window not is already visible, it's created, otherwise they get the currently-visible window.