I have some code inherited from someone else (so I have no answers to
why it's the way it presently is) that's handling retention in a way I
find confusing, and think is not in accordance with the spirit of the
law. But I can't quite figure out how to do it "right". Is there a
pattern I should be following, and at what point am I diverging from it?
The quandary involves two classes, call them "Controller" and "UI".
Controller is created when the NIB is loaded, and lives effectively
forever. From time to time, Controller needs to create an instance of
UI, to manage some user interaction (take some parameters, do some
work, show status, you know the drill). It's possible for there to be
several UI objects alive and on-screen at once. My problem concerns
the retention of the UI objects.
In the current structure, Controller performs
{
UI *ui = [[UI alloc] initWithContext: context];
[ui run: @selector(doSomething) title: @"Title"];
}
That is: the UI object is alloc'ed (creating a release obligation),
but is not (auto)released here, nor is any reference to it saved
anywhere so it may be (auto)released later. Controller has nothing to
do with releasing this object, which is the bit that sticks in my craw.
Rather, over in UI we have:
-(void)windowWillClose:(NSNotification *)aNotification
{
[self autorelease];
}
That is: after UI has done all it needs to do, and the user clicks the
final button (connected here), it autoreleases itself, completes, and
the pool finishes it off.
This is all working; nothing leaks, nothing is prematurely
dealloc'ed. But having the alloc and (auto)release in separate
classes seems unsound.
I found an earlier thread in this list,
http://lists.apple.com/archives/cocoa-dev/2002/Jul/msg01001.html
which is darned close to my situation (almost, but not quite, totally
like). This thread solves its very similar problem by having
Controller keep a ref to UI, and release it during Controller's
dealloc. I can't quite see how to handle that in my case. A minor
problem is that I may have an unpredictable number of these UI objects
about, so I'd need an NSMutableArray of them or something, not just a
scalar field. But a bigger problem is that Controller isn't
dealloc'ed until the end of the program, which is far too late: it's a
long-lived, server-like program, I'd be accumulating these UI objects
forever.
- Is my eternal, shared Controller bogus, and I should be finding
some way to create multiple Controllers, and destroy them more often?
- Is there some way to get the windowWillClose event passed back to
Controller, rather than to UI, so the autorelease can happen there?
- Is there some other rotation I should consider?
- Or, is this actually The Way It's Done?
The code, if you're curious, may be found via Subversion at http://scplugin.tigris.org/svn/scplugin/trunk/
. The players are actually:
"Controller": SCUIDaemonController+SubversionSupport
"UI": several, but most illustratively NewGenericUI
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
