Comments on: Cocoa Tutorial: Adding Plugins to a Cocoa Application http://www.cimgf.com/2008/09/17/cocoa-tutorial-adding-plugins-to-a-cocoa-application/ Taglines are for Windows programmers Mon, 26 Jul 2010 16:50:30 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Chris Hanson http://www.cimgf.com/2008/09/17/cocoa-tutorial-adding-plugins-to-a-cocoa-application/comment-page-1/#comment-807 Chris Hanson Thu, 18 Sep 2008 07:37:24 +0000 http://www.cimgf.com/?p=272#comment-807 <p>A couple of points to keep in mind.</p> <ol> <li><p>The term on Mac OS X is "plug-in" with a hyphen, capitalized as "Plug-in" and inter-capped in APIs as "PlugIn". cf. Apple Publications Style Guide, the old CFPlugIn API documentation, the "Plug-ins" section of the Get Info panel in the Finder, and the Contents/PlugIns directory of the application you've embedded a plug-in within.</p></li> <li><p>A plug-in <strong>doesn't</strong> need to have a main class or nib defined. It could supply some other metadata, for example via its Info.plist file, or via subclassing of known classes, that the host application could use to locate appropriate plug-in facilities.</p></li> <li><p>Don't use -[NSBundle pathsForResourcesOfType:directory:] to locate embedded plug-ins, just look for packages with an appropriate extension in [[NSBundle mainBundle] builtInPlugInsPath].</p></li> <li><p>Don't use "bundle" or "plugin" as your plug-in path extension; use something unique to your application. After all, your application can't load just any plug-in, and other apps can't necessarily load yours.</p></li> <li><p>On Leopard, use -[NSBundle loadAndReturnError:] to load plug-ins. This will tell you why a plug-in failed to load; for example, it may not have been compiled for your current architecture or with the right garbage collection flags. You can use -preflightAndReturnError: and -executableArchitectures to check basic things like architecture match in advance of loading.</p></li> <li><p>Unloading plug-ins that use Cocoa is very hard, and may not necessarily be feasible. For example, you would need to guarantee that all literal NSString instances that came from a loaded plug-in were no longer in use. Similarly, any caches that may be maintained on a per-class basis may need to be cleared, including those within Cocoa. Depending on what your plug-in does, it may not be able possible to unload.</p></li> <li><p>Finally, if you're building a plug-in API, don't just look in your application's embedded plug-ins folder, look in its Application Support folder in all available domains as well. Your users shouldn't be putting extra plug-ins inside your application; they'll get lost when you do a Sparkle update, for example.</p></li> </ol> <p>7.1. Also for development purposes it can be useful to tell your application an additional path or set of paths to load plug-ins from via a user default. This should usually be searched <em>before</em> your standard set of paths, because then you can find the in-development version of a plug-in you're working on in Xcode and use it in favor of the release version installed on your system.</p> A couple of points to keep in mind.

  1. The term on Mac OS X is “plug-in” with a hyphen, capitalized as “Plug-in” and inter-capped in APIs as “PlugIn”. cf. Apple Publications Style Guide, the old CFPlugIn API documentation, the “Plug-ins” section of the Get Info panel in the Finder, and the Contents/PlugIns directory of the application you’ve embedded a plug-in within.

  2. A plug-in doesn’t need to have a main class or nib defined. It could supply some other metadata, for example via its Info.plist file, or via subclassing of known classes, that the host application could use to locate appropriate plug-in facilities.

  3. Don’t use -[NSBundle pathsForResourcesOfType:directory:] to locate embedded plug-ins, just look for packages with an appropriate extension in [[NSBundle mainBundle] builtInPlugInsPath].

  4. Don’t use “bundle” or “plugin” as your plug-in path extension; use something unique to your application. After all, your application can’t load just any plug-in, and other apps can’t necessarily load yours.

  5. On Leopard, use -[NSBundle loadAndReturnError:] to load plug-ins. This will tell you why a plug-in failed to load; for example, it may not have been compiled for your current architecture or with the right garbage collection flags. You can use -preflightAndReturnError: and -executableArchitectures to check basic things like architecture match in advance of loading.

  6. Unloading plug-ins that use Cocoa is very hard, and may not necessarily be feasible. For example, you would need to guarantee that all literal NSString instances that came from a loaded plug-in were no longer in use. Similarly, any caches that may be maintained on a per-class basis may need to be cleared, including those within Cocoa. Depending on what your plug-in does, it may not be able possible to unload.

  7. Finally, if you’re building a plug-in API, don’t just look in your application’s embedded plug-ins folder, look in its Application Support folder in all available domains as well. Your users shouldn’t be putting extra plug-ins inside your application; they’ll get lost when you do a Sparkle update, for example.

7.1. Also for development purposes it can be useful to tell your application an additional path or set of paths to load plug-ins from via a user default. This should usually be searched before your standard set of paths, because then you can find the in-development version of a plug-in you’re working on in Xcode and use it in favor of the release version installed on your system.

]]>