My Cocoa app has an auxiliary executable, a tool which is invoked by
launchd agents to do little jobs occasionally. It runs for a few
seconds and then quits.
The user can command the app to do these same jobs, "manually". Now,
I understand that a conventional design approach would be to compile
the "do work" code into the worker executable, and have the app launch
the worker as needed using NSTask. But for a couple reasons [1],
instead I put all of the project's code except for the main()
functions into a framework and linked to it in both the app and worker
targets. To do work, the app invokes code in the framework directly.
I thought that I was going to have to be very careful that the code
invoked by my worker didn't try to access the gui, but it appears that
this care is not necessary...
int main(int argc, const char *argv[])
{
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init] ;
NSLog(@"Worker has launched. NSApp = %p.", NSApp) ;
#define IMAX 1
for (NSInteger i=0; i<IMAX; i++)
{
// Will this crash or be ignored ??.....
NSRunInformationalAlertPanel(@"Hello", @"World?", nil, nil,
nil) ;
}
NSLog(@"Worker is working") ;
... code to do work
NSLog(@"Worker is done") ;
[pool release] ;
return 0 ;
}
Result: The NSRunInformationalAlertPanel() seems to be a no-op, as
desired. My explanation is that since NSApp is nil, any messages to
the window server, etc., become no-ops. There may be some thrashing
going on at the first invocation, because the typical elapsed time for
the loop to execute depends on IMAX thus...
IMAX time (milliseconds)
0 40
1 200
1000 200
More typically, the "do work" code shows a progress bar, which is
wanted when run by the app, but not when run by the worker.
Now, I understand that this design may not look good from the high
level -- for example, what if the user really needed to see that
alert. But has anyone ever gotten into trouble by assuming that gui
calls "just won't work" if NSApp is nil?
Jerry Krinock
[1] My reasons for not having the app invoke the worker:
1. Original design did not have the worker.
2. As a child, I learned to avoid NSTask whenever possible.
_______________________________________________
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 arch...@mail-archive.com
