Re: Looking for info on creating Plugins/Modules
Re: Looking for info on creating Plugins/Modules
- Subject: Re: Looking for info on creating Plugins/Modules
- From: Tom Jones <email@hidden>
- Date: Sat, 13 Dec 2008 07:47:22 -0800
This is great, thanks! I think you even covered follow up questions,
now it's off to read the Apple documentation.
Thanks again,
tom
On Dec 12, 2008, at 1:05 AM, Chris Hanson wrote:
On Dec 12, 2008, at 12:16 AM, Kyle Sluder wrote:
On Fri, Dec 12, 2008 at 2:58 AM, Tom Jones <email@hidden>
wrote:
I'm hoping someone could point me in the right direction. Where
would I read
up on how to create modules or plugins for a Cocoa application?
I'm not even
sure I'm asking the right question :-)
CFPlugin.
CFPlugIn is a poor choice for Cocoa applications because it assumes
a COM-style infrastructure and ends up both requiring more work than
and providing fewer features than the Objective-C runtime gives you
for free. I would not recommend CFPlugIn for Cocoa (or really any
new) development.
What you want to use is NSBundle and its concept of "principal
class." You can put a framework in your application that both it
and your developers' plug-ins can link against, which provides an
API for your application. Among other things, your application's
API can include a "MyAppPlugIn" class that your developers' plug-in
bundles must subclass and specify as the NSPrincipalClass in their
Info.plist file.
Then it's simply a matter of looping through an appropriate set of
directories at application start-up, loading all of the bundles you
find in those directories that have an appropriate path extension
(e.g. those whose path extension is "myappplugin"), asking each
bundle for its principal class, and creating an instance of its
principal class provided it's the right kind of class. (Why do you
need to do an -isKindOfClass: check? Because -[NSBundle
principalClass] is documented to use the first class found in a
bundle if no NSPrincipalClass key is specified in its
Some points you'll want to remember in designing your plug-in
architecture:
- Provide a user default that developers can use to add to your plug-
in search paths. By default you'll want to probably search for plug-
ins inside your application, and then in your application's
Application Support folder in every domain (user, local, system,
network). You should provide the ability for a developer to tell a
single instance of your application, during debugging, that it
should look first in another directory. Since you can override user
default values using command-line arguments, they're the ideal
solution there: During debugging your developers can pass -
AdditionalPlugInPath to your app and have it look in their build
folder first.
- Only load the first plug-in with a given identifier. In
combination with the search path strategy above, this means a
developer can easily have the GM version of a plug-in installed on
their system and also easily do development of the next version.
- Use a path extension other than "bundle" or "plugin" for your own
plug-ins. These two path extensions are utterly generic; without
specific support, one application can't magically use another
application's plug-ins, so they shouldn't be named in a way that
implies it's possible.
- Your plug-ins should have a document type and UTI declared in your
app's Info.plist so they can be recognized as file packages rather
than folders by the Finder and get a nice icon. The UTI for your
plug-ins should conform to the "com.apple.bundle" UTI. (Having a
distinct path extension and UTI means you could write a Quick Look
importer for plug-ins that, say, shows some information about the
plug-in to the user when they highlight it in the Finder and press
the space bar.)
- Remember binary compatibility. Don't just expose all of the guts
of your application through your framework, create a properly-
abstracted API that you feel comfortable supporting for at least a
couple versions of your application. Don't underestimate how
attached users are to the things they wind up able to accomplish
with third-party plug-ins to your application, especially if they
can do things with plug-ins that get saved in your application's
documents.
- The Apple Publications Style Guide term is "plug-in" with a hyphen
in prose, "Plug-in" capitalized, and "PlugIn" when using intercaps
in class and directory names.
Hope this is useful!
-- Chris
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden