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: Chris Hanson <email@hidden>
- Date: Fri, 12 Dec 2008 01:05:43 -0800
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