Releasing all nib objects [Was: instantiateNibWithOwner:topLevelObjects: usage]
Releasing all nib objects [Was: instantiateNibWithOwner:topLevelObjects: usage]
- Subject: Releasing all nib objects [Was: instantiateNibWithOwner:topLevelObjects: usage]
- From: Ricky Sharp <email@hidden>
- Date: Sat, 3 Dec 2005 09:05:58 -0600
On Dec 2, 2005, at 4:11 PM, Ricky Sharp wrote:
When I find a solution to all this, I'll post back here. My hope
is to have a nice recipe for apps that store windows in multiple
nibs, yet those windows are not controlled by a window controller.
This is probably the exception to the rule, but I'm finding that
this setup is working out the best for me in my kiosk-style apps.
OK, I found a winning solution.
Problem:
Application has a single window whose content view will be swapped
out over time. The content view is replaced by the content views of
panels such that you have one panel per nib. As views are swapped in
and out, all bindings must be reestablished and all top-level objects
must be managed correctly to not leak.
Solution:
(1) MainMenu.nib - Contains app delegate (app controller) and the
main window (Main Window is an outlet named say 'widow_outlet'
(2) AppController (owner of MainMenu.nib) which has an ivar to
maintain the current window controller
(3) ScreenController (base class for all our individual "screens".
(4) Subclasses of ScreenController; one for each screen (nib) we
have. These will be the owners of the nib.
(5) WindowController (custom subclass of NSWindowController)
(6) One nib for each "screen". Contents are as follows:
- File's owner is an instance of ScreenController subclass
- Panel whose content view is the UI of the screen (this is an outlet
in ScreenController base class)
- Any model object instances as needed
- Any NSObjectController instances as needed
This allows for one to set up bindings as expected (i.e. between UI
elements on the Panel to either the owner (controller) or other
object controllers.
How it works...
Upon receiving applicationDidFinishLaunching:, we go to our initial
screen via a gotoScreen: API.
In gotoScreen, we first create the appropriate instance of our
ScreenController subclass to represent the screen we want (e.g.):
theScreenController = [[[MainScreenController alloc]
initWithAppController:self] autorelease];
We then create a new instance of WindowController:
[[[WindowController alloc]
initWithScreenController:theScreenController screenName:theScreenName
window:window_outlet] autorelease];
where theScreenName is the name of our nib file and window_outlet is
the NSWindow* representing our main window
initWithScreenController:screenName:window: looks like this:
- (id)initWithScreenController:(ScreenController*)aScreenController
screenName:(NSString*)aScreenName window:(NSWindow*)aWindow
{
if ((self = [super initWithWindowNibName:aScreenName
owner:aScreenController]) != nil)
{
[self setScreenController:aScreenController]; // We hold on
to this so we can release it properly later on
[self window];
NSLog (@"isWindowLoaded = %@", [self isWindowLoaded] ?
@"YES" : @"NO");
[aWindow setContentView:[aScreenController contentView]];
}
return self;
}
Note the call to [self window]. I purposely ignore the NSWindow*
return value. This line will actually load the nib, bind all your
objects, etc. So, as expected, the NSLog like will say "YES".
contentView is an API of ScreenController that will obtain the
NSView* from the Panel in the nib.
Now, whenever my app moves from screen to screen, I get proper
cleanup of all top-level objects. Previously, I was leaking many
model objects and views. The trick seems to be to have an object on
the side (our window controller) which manages the nib. And, that
the window controller not be the owner of the nib.
This confirms the findings of Dennis De Mars last year** where he
stated that as long as the window controller is _not_ the owner of
the nib, all objects in the nib can be released correctly.
** <
http://www.cocoabuilder.com/archive/message/cocoa/2004/6/7/109092>
___________________________________________________________
Ricky A. Sharp
mailto:email@hidden
Instant Interactive(tm)
http://www.instantinteractive.com
_______________________________________________
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