I wish I’d read this years ago:
AppKit, the GUI framework, is not thread safe. In order for things to work properly, you (almost) always need to update GUI classes from the main thread
—Dave Dribin (slightly edited)
I’ve run into UI + threading problem before, but I’d just never seen this limitation of AppKit spelled out.
Dave’s article explains how to call code on the main thread better then I can.
I ran into an issue at work where sometimes an application would have two “Help” menus, on OS X 10.5 “Leopard” (but not on OS X 10.4 “Tiger”). The problem was interacting with the UI before the application had finished enough of the AppKit-initialization process.
The application had to install a component, which involved displaying authentication dialogs and such. Because the component was necessary for the application to work correctly, I thought it would be safest to do this as early as possible. But displaying a dialog in code called from awakeFromNib ended up being the cause of the double Help Menu issue.
Waiting until applicationWillFinishLaunching: or applicationDidFinishLaunching: to interact with the user fixed the problem. (In my case, it was safe to defer the installation until then.)
I am not aware of any other issues from putting up a window “too early” … however, it seems to me that doing it is asking for trouble. The AppKit/Cocoa environment obviously isn’t 100% ready at that point. Why risk running your code with half-baked libraries if you don’t have to?
Whenever possible, I will defer “first run” behavior until applicationWillFinishLaunching: or applicationDidFinishLaunching:.
Powered by WordPress