Re: App Delegate starting up
Re: App Delegate starting up
- Subject: Re: App Delegate starting up
- From: Bill Cheeseman <email@hidden>
- Date: Wed, 25 Sep 2002 07:40:24 -0400
on 02-09-25 12:34 AM, email@hidden at email@hidden wrote:
>
When is the best time for an Applications Delegate to execute startup code
>
like reading defaults, loading data files and placing various application
>
windows up?
I'm not sure why you're limiting your question to the application delegate.
It looks like you might not have meant to limit it that way -- since you
mention awakeFromNib, which is not an application delegate method. So I'll
answer as if you had asked the question more generally. (This may not be
what you wanted, but here it is.)
The answer may be different for different purposes. Also, several answers
might be equally good for a single purpose, depending on your application's
architecture and where you want to put the commands.
This is why you see people doing these things in so many different ways.
For example, user defaults should often be read at the very earliest
possible point, say, in an object's +initialize method (which is called
before any other method in an object, even before its -init method). But
this wouldn't necessarily be true for user defaults relating to GUI
elements, such as, perhaps, the autosaved order of columns in a table view.
A window isn't guaranteed to exist, let alone be fully initialized and
connected to its view objects, until much later in the application launch
process.
Application data held in your model objects can ordinarily be read and
initialized in your -init method, if they don't rely on the GUI being ready
yet. That's basically what the -init method is for in custom classes you
write.
But GUI settings normally can't be read, or at least not applied, until the
GUI is up and ready. If you try to read them before then, say, in an -init
method, you're likely to get 0 or nil when you expected to get a real value
or object. This is a common beginner mistake; it's often hard to debug,
since a nil object can cause repercussions in the oddest places.
For nib-based UI elements in a window managed by a window controller
subclass, one time when you can be sure the GUI is ready for you is when
NSWindowController's awakeFromNib method is called, if you implement it in
your window controller subclass. The window is guaranteed to be ready, but
it isn't yet visible on the screen so you can put data into the views
without worrying about onscreen flicker. For most purposes, you can use
NSWindowController's windowDidLoad delegate method, instead, but I'm not
aware of any reason to prefer it over awakeFromNib, and there are some
(rare) circumstances where it can lead to flicker on the screen.
If your app's architecture makes it easier to do this from the document,
rather than from the window controller, you should use NSDocument's
windowControllerDidLoadNib: method, instead. This is for applications where
the document is the nib file's owner and the nib is loaded using
windowNibName:. That's why you see these two methods in the standard Cocoa
Document-based Application template. For more complex applications, people
tend to remove these two methods and instead write window controller-centric
applications using the techniques described in the previous paragraph.
If you wonder when to load the nib file, it depends. For a document-based
application's document windows, that's done in your NSDocument subclass.
Just implement windowNibName: or makeWindowControllers, and Cocoa will call
them at the right time.
NSApplication's applicationDidFinishLaunching has more specialized uses, I
think. Like, when you want to do something that requires the application to
be up and running, and perhaps a document already loaded if the application
was launched by double-clicking a document icon, but you don't care whether
document-based UI elements are ready yet. In fact, sometimes you want
applicationWillFinishLaunching, instead, if you need to set something up
before the double-clicked document is loaded. Either of these might be good
places to open windows that are not related to a specific document but are
instead application-wide, such as a tool palette.
That wasn't meant to be a scientific description, it's just what rolls off
the top of my head in response to your question. The only way to figure this
out completely is to read all the available FAQ's, Programming Topics, class
reference documents, Web sites, magazine articles, and books, paying
particular attention to little clues here and there about which method gets
called before or after something else. Oh, I left out the Cocoa header
files, which surprisingly often contain comments disclosing little gems of
wisdom that don't show up anywhere else. And even after you've read all that
stuff, you're going to have to use my favorite learning tool, trial and
error.
I don't have any particular thoughts about termination.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook -
http://www.AppleScriptSourcebook.com
Vermont Recipes -
http://www.stepwise.com/Articles/VermontRecipes
Croquet Club of Vermont -
http://members.valley.net/croquetvermont
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.