Re: awakeFromNib vs appdidfinishlaunching
Re: awakeFromNib vs appdidfinishlaunching
- Subject: Re: awakeFromNib vs appdidfinishlaunching
- From: Karim Morsy <email@hidden>
- Date: Wed, 22 Mar 2006 17:38:41 +0100
thanks for the infos, ondra!
if need be, show a progress indicator in a sheet, along with a
cancel button.
yea, I'm doing all of the lengthy tasks on threads ... but as far as
canceling is concerned, is there any simple way (other than using
darwin notifications or distributed objects) for stopping a secondary
thread from the main thread?
On Mar 22, 2006, at 5:20 PM, Ondra Cada wrote:
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