Women in Technology

Article:		Plug It In, Plug It In
Subject:		complex Plug-Ins
Date:		2002-10-28 23:15:15
From:		stevesheets
Thanks for a great article! However, what about complex plug-ins, which consist of multiple objects taking up a sizable amount of memory? In these cases, you do not want to invoke an object for each plug in that you might have in your various paths. This would take up to much memory! You may want to store the name of the plug ins, and only create them when the user invokes them. This is especially true in the instance where each plug in object might be invoked more than one time at same time (ex. each plug in creates a different window, and you might want two instances of the same window up on the screen). In these cases, should you only store the name of the plug in? And when user invokes it, find the path to correct bundle? Or would this take to long, and it be better to open each Bundle, and keep the Bundle object around, ready to be invoked when needed? Or as alternative, should you invoke a small primary object at startup (as your example program does), which would only create more complex objects when the user invokes it? In that case, if you have simple object from a plug in bundle, can it safely create new objects from that bundle without any problems (ex. your filter bundle has an EditFilterSetting method which invokes a Window/WindowController and new custom view)? I was not sure you could link to other code in the bundle, after the NSBundle instance has been autoreleased. What do you think? Keep up the great work! Steve Sheets

Showing messages 1 through 1 of 1.

• complex Plug-Ins
  2002-11-08 11:34:18  Michael Beam | [View]
  
  
  These are good points you raise here. For handling a great number of plugins I would agree that initially storing a path to the plugin would work. It doesn't take all that long to load a bundle, and the user probably wouldn't notice it. Plus, once it is loaded, it wouldn't need to be reloaded. Some might take this idea further and do something like keep a count of how many times certain plugins have been used over all sessions in the application. The application could check at startup if this count is above a threshold, and if so preload the plugin in anticipation of the user needing it.
  
  As for complex plugins, a bundle is like a mini self contained application. I've made plugins that work with the architecture we setup here that will load a window with controls that let you tweak how the plugin operates. For example, in the method filterImage: you could load a nib included with your bundle's resources that contains a UI for interacting with the plugin. This would load a window with all of the controls for the plugin. there would probably also be OK and Cancel buttons. Cancel would cause filterImage: to return the original image, and OK would be made to execute the core filter code.
  
  There are lots of possibilities with this, and quite likely this architecture may not be the best for many people. It is, however, one way of solving the problem, and gives an idea of the mechanics involved.
  
  Mike