Re: awakeFromNib vs appdidfinishlaunching
Re: awakeFromNib vs appdidfinishlaunching
- Subject: Re: awakeFromNib vs appdidfinishlaunching
- From: Ondra Cada <email@hidden>
- Date: Wed, 22 Mar 2006 17:20:12 +0100
Karim,
On 22.3.2006, at 16:23, Karim Morsy wrote:
thanks for the info!
then the app did finish notification gets sent after all obejcts
have been sent awakeFromNib, right ?
Erm... don't please get offended, but these things are documented
quite well.
(That's the good ole "RTFM" for us old-fashioned who don't buy
political correctness :))
Anyway, for very simple apps, yes, but you should not depend on it.
Put the initialization into different places based on its goal, not
its time:
+initialize: whatever needs to be done sooner than anything other
(like registering defaults or KVO dependent keys);
-awakeFromNib: whatever needs to be done with this and other GUI
objects (like setting up doubleActions or populating dynamic popups
and tabviews);
-applicationDidFinish: tasks intended to be done when app starts--
checking licences, showing up splash panels if you insist...
In very simple apps you can skip didFinish, using the awake from
MainMenu.nib instead, but doing that, beware as soon as there are
more NIBs, you can get awake more or less anytime. Speaking of which...
in order for the app to launch faster it would be better to have
cpu intensive initialization in appdidfinischlaunching handler ?
... mind that splitting the app structure (along with its
functionality of course) to more NIBs loaded lazily on-demand is one
great way how to make it launch faster. You can even split the code
itself to bundles loaded lazily, but that's needed for really big
apps, so I guess it won't apply here :)
Other than that... never do *anything* long in the main thread,
regardless whether at launch or caused by some user's action. The
former makes the app jump for too long, the latter brings the rainbow
disc, which is no better. Keep the main thread responsive, and do the
computations in separate threads or in small chunks done when the app
is idle, whatever is in the concrete case better implementation-wise.
If need be, show a progress indicator in a sheet, along with a cancel
button.
---
Ondra Čada
OCSoftware: email@hidden http://www.ocs.cz
private email@hidden http://www.ocs.cz/oc
_______________________________________________
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