In the ATGMobileCommon project, a new group was added, called Plugin. This group includes several classes:

ATGPluginRegistrant

All plugins to the ASA app must create a class that conforms to the ATGPluginRegistrant, which is responsible for registering plugins. When a plugin registrant is created, it must be registered in the application’s Info-plist file in order to be picked up by ASA. For example, for the ASA ORMPOS, the following would need to be added to Agent-Info.plist:

<key>ATG_PLUGIN_REGISTRANT_CLASSES</key>
 <array>
   <string>ATGPOSPluginRegistrant</string>
 </array>

While there is only one plugin in this example, more than one plugin registrant could be listed here. To remove all ORMPOS-related plugins, you would remove the ATGPOSPluginRegistrant string from this file. The app delegate must be coded to load the plugins:

// Load the plugins.
  [[[ATGPluginManager] pluginManager] registerAllPlugins];

This method looks for all the plists registered, and reads the list of classes defined in each.

The NSBundle+ATGPluginAdditions provides a method that retrieves the class list from the plist, resolves the classes, and returns them in an array. The ATGPluginManager class takes these classes, and invokes the registerPlugins method, as defined by the ATGPluginRegistrant protocol. The plugin registrant implementation simply registers all the plugins it wants to use. In the ATGPOSClient project, its plugin registrant registers the following plugins:

  [[ATGPluginManager pluginManager] registerPlugin:[ATGPOSLoginPlugin class] ofType: ATGAgentLoginPlugin];
  [[ATGPluginManager pluginManager] registerPlugin:[ATGPOSSuspendOrderPlugin class] ofType: ATGAgentCartActionPlugin];

This code tells the plugin manager about ATGPlugin subclasses and provides a type string. If the app is launched, the app delegate requests that the plugin manager invoke all registrants, the ORMPOS registrant is found and loads all its plugins into the plugin manager.

If you want part of the application to support plugins, you must code it that way. For example, the shopping cart page could be written to support plugins, using the type string that was supplied when the plugin was registered. The shopping cart page would ask the plugin manager for all plugins of type ATGAgentCartActionPlugin as a string constant:

NSArray *plugins = [[ATGPluginManager pluginManager] loadPluginsOfType:ATGAgentCartActionPlugin];

For each plugin that is returned, the shopping cart page adds a button in the cart controls area. For example, the following two lines in the POS plugin registrant would result in the buttons shown in the following illustration:

[[ATGPluginManager pluginManager] registerPlugin:[ATGPOSSuspendOrderPlugin class] ofType: ATGAgentCartActionPlugin];
[[ATGPluginManager pluginManager] registerPlugin:[ATGPOSTestPlugin class] ofType: ATGAgentCartActionPlugin];

Loading Buttons Example

If either of these two lines were removed from the plugin registrant, or if the entire plugin registrant was removed from the Info plist, only the Discounts and Checkout buttons would display.

The ATGPlugin class defines some properties and methods that attempt to handle the majority of plugin use cases:

A display name property. This is a localized string, and is used by UIs that use a labeled UI control as the launch point for a plugin’s UI (as in the button example).

Without Using ATGPluginRegistrant

Without the registrant plugin, in Agent-Info.plist, a list of plugin plists is supplied:

<key>ATG_PLUGIN_PLISTS</key>
 <array>
     <string>AgentPlugin</string>
     <string>POSPlugin</string>
 </array>

For each entry in here, using the example of the POSPlugin, there is a plist that supplies a list of plugin classes:

<key>PLUGINS</key>
 <array>
    <string>ATGPOSLoginPlugin</string>
…
</array>