On 2011 Jun 08, at 10:31, Jens Alfke wrote:
> You’ll need to build a separate binary, for launchd to invoke, that runs
> without a UI; this can be built like a regular command-line tool, so you
> invoke your code from the main() function, don’t link against AppKit, etc.
Unfortunately there are some Cocoa classes which you need in command-line tools
which are in AppKit; NSWorkspace for example. I have a similar situation and,
for this reason, my command-line tool links against AppKit (indirectly, via a
framework … read on). It is launched by launchd, and it works.
> You don’t need two projects. Just add a new target to your project
Indeed! If you've ever used Project Search in Xcode, you'll want everything in
one project.
> (You could avoid duplicating code by building your shared functionality as a
> dynamic library or framework, then embedding that in the app bundle and
> having both targets link against it.)
That's what I do. All of my app+tool files, except for App-Main.m and
Tool-Main.m, are compiled into a private framework, and both targets App and
Tool link against the private framework. Probably the only advantage of this
is that I can live with myself for not having doubled the megabytes, but that's
probably just because I'm old enough to remember when megabytes mattered. A
few other gotchas…
• If Tool-Main.m accesses symbols from the framework you'll need to export
these symbols.
• If you want to access the app's user defaults in the tool, you need to load
them manually. Let me know if you want the code; it's not trivial.
• You have to decide where to package your tool. If I remember correctly,
Contents/Resources is bad. I was told that putting a helper tool
Contents/MacOS had unsolveable issues, so I chose Contents/Helpers, but had to
do a Method Replacement on -[NSBundle mainBundle] to make some of the Cocoa
classes work as expected in the tool.
• You'll need a separate Info.plist embedded into your tool for Code Signing.
• Where there is GUI code that could but shouldn't run in the tool I do this:
if (NSApp) {
// Do GUI stuff
}
else {
// Non-GUI alternative, if any
}
> Just remember to give the helper app a different bundle ID, or LaunchServices
> won’t allow both of them to be running at the same time.
I don't find that to be the case. My App and Tool have the same bundle
identifier, and they both run at the same time. I just checked them. To read
the Info.plist from a command-line tool, use this shell command:
otool -s __TEXT __info_plist Info.plist_path /path/to/Tool
(Does anyone know how to print that as ASCII instead of stringified-hex
characters?)
For discussion of launchd, try [email protected].
Jerry
_______________________________________________
Cocoa-dev mailing list ([email protected])
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 [email protected]
