Window loading question


#1

I did some research in order to solve the Ch. 12 challenge and have a question to make sure I understand what is going on.

I’m going to use pseudocode so as not to give the solution away for those who have not solved it.

My solution:

- (IBAction)showAboutPanel:(id)sender {
    //load panel from nib
    //make panel key window
}

This code works just fine and as I understand it, the panel is released from memory when closed since the Behavior checkbox “Release When Closed” is selected in IB.

When researching how to make the window key, I found a solution that used this logic:

- (IBAction)showAboutPanel:(id)sender {
    if (!aboutPanel) {  //aboutPanel is my outlet for the panel
        //load panel from nib
    }
    
    //make panel key window
}

In order for this to work, the “Release When Closed” checkbox must be deselected. This method would only load the nib once and keep the panel loaded in memory when it is closed.

Please let me know if I am missing something in my interpretations?

Now the real question. Assuming I am correct in understanding what is happening here, what are the pros/cons to each method? For a simple about panel, I don’t see any benefit in retaining the window. I’d release it since it is small and loads fast. For a larger more complex window, I could see a benefit of retaining the window, but that could be an inefficient use of memory. What is the Cocoa best practice for loading and releasing or retaining windows?

Thank you.

John


#2

John,

In general you aren’t going to be creating windows like this chapter’s challenge asks you to. You’ll be creating them via their NSWindowController subclass, as described in the bulk of the chapter.

For the about box case, I can see why you might consider not bothering to keep a reference to the window, however you will probably want to even in simple cases like this so that on the off chance the user selects “About” multiple times without closing the prior about windows, they don’t end up with multiple copies of your about window sprinkled about the screen.

For larger windows it does make sense to keep them around even when they aren’t on screen. In most apps the memory impact of an extra window isn’t going to be significant. Practically speaking, however, if you’re going to want to destroy a window, you will want to destroy the window controller (and the window would follow).

Adam


#3

Thank you Adam. I didn’t even think about the problem with multiple windows. As for larger windows, I think I was equating documents to windows. I wouldn’t want to keep a large document in memory after it is closed, but that is taken care of by the document controller. I think I’ve got it now. Thanks again.

John


#4

I was just about to ask why the the panel outlet is needed in the challenge, when I read this thread.
Like John I didn’t think about the multiple windows problem, funny :smiley:

Vertex


#5

Ahh, well this makes sense then. I missed the whole “add an outlet” thing, which would have helped, instead I came up with a workaround.

Note to future self: read the challenges more carefully.