Now that we have a type and some interfaces, let's look at how a plug-in that supported this type would be implemented. First, consider the information property list for the plug-in in Listing 1-4.
{ "CFBundleExecutable" = "MyTestPlugIn"; "CFPlugInDynamicRegistration" = "NO"; "CFPlugInFactories" = { "68753A44-4D6F-1226-9C60-0050E4C00067" = "MyFactory"; }; "CFPlugInTypes" = { "D736950A-4D6E-1226-803A-0050E4C00067" = ("68753A44-4D6F-1226-9C60-0050E4C00067"); }; }
The information property list defines various aspects of the plug-in's runtime behavior and contains optional static registration information for the various types the plug-in supports. For more information about static and dynamic registration, see the section Plug-in Registration.
In this example, the
CFBundleExecutable
key tells CFBundle the name of the executable and is used by the primitive code-loading API of Bundle Services. The rest of the keys are specific to the PlugIn Services model.
The
CFPlugInDynamicRegistration
key indicates whether this plug-in requires dynamic registration. In this example, static registration is used, so the dynamic registration key is set to
NO
.
The
CFPlugInFactories
key is used to statically register factory functions, and the
CFPlugInTypes
key is used to statically register the factories that can create each supported type.