Each MOA application (Director, FreeHand, SoundEdit 16) ships with an Xtras Development Kit (XDK), included free with the application. Each XDK provides detailed documentation, sample files and header files. Macromedia XDKs and any updates to them are also available in the Xtras Support Center. The XSC provides a variety of resources, including links to downloadable versions of our Xtra Development Kits (XDKs) for various products, online documentation, and support channels.

Once you've developed your Xtra, you can list it among the available Xtras on Macromedia's Web site by filling out this form.

The Macromedia Open Architecture has been optimized to maximize the developer's ability to leverage their knowledge across products and platforms, and provide superior performance, flexibility and simplicity.

• Cross-product applicability: The Macromedia Open Architecture is implemented in several Macromedia products. This enables developers familiar with MOA in one application to quickly begin developing Xtras for another Macromedia application. In addition some Xtras can be used unmodified in multiple Macromedia applications. For example, scripting, sprite, and transition Xtras work in both Director and Authorware.
• Cross-Platform: The MOA architecture was designed to be cross-platform, operating on Macintosh and all varieties of Windows. Director on Mac and Windows supports exactly the same APIs - Xtras written for one platform can be moved to the other platform with a simple recompile.
• Leverage existing knowledge: MOA is based on the COM object model developed by Microsoft as the basis for its object architecture, and a familiar model to programmers.
• Performance: The MOA architecture is optimized for performance. Both at call time and at application launch time, the MOA architecture is designed to provide superior performance. At call time, messages sent to a MOA Xtra are direct procedure calls. At launch time MOA caches Xtra information, minimizing object loads.
• Flexibility and Simplicity: MOA was designed to be extensible, flexible and simple. The way MOA objects are named, called and organized is designed for maximum simplicity. MOA allows the logical grouping of messages to an Xtra; MOA identifiers are guaranteed unique; and MOA objects can easily define interfaces that can be called by other MOA objects, allowing great flexibility and extensibility.
  
  

A number of Macromedia applications support the Macromedia Open Architecture (MOA). MOA provides a rich multimedia platform for both Macromedia and third parties to build on to extend application functionality. The components of this architecture are described on in this document.

MOA is based on the Macromedia Portable Object Model, which defines a way to declare interfaces that are implemented by classes. This model is compatible with the Component Object Model defined by Microsoft as the basis for OLE 2. In addition to the model, MOA provides a highly portable COM implementation that supports in-process objects on both the Macintosh and Windows, with the ability to easily adapt to OS/2, OS/9, Unix, and other operating systems.

MOA objects consist of 1) a set of private variables defined by a developer to keep track of relevant data, and 2) an implementation of one or more interfaces, each of which defines a table of virtual functions that provide the behaviors supported by the MOA object.

MOA objects are designed to be dynamically loaded into an application. They are the fundamental building blocks of Xtras, which contain functionality that can be plugged into Macromedia applications. Application users simply drag Xtras into their application's Xtras folder to augment its functionality.

Macromedia Xtras API enables developers to provide value-added extensionsXtrasfor many Macromedia applications. The real breakthrough of this architecture is the development of Xtras that work not only across the Windows and Macintosh platforms with little or no platform-specific code, but will also work across multiple products (such as a Transition Xtra that works in both Director and Authorware). By having an architecture that is both cross-platform and cross-product, a third party creating an Xtra is assured of broader usage and bigger markets.

Xtras are the most visible and tangible result of the Macromedia Open Architecture for day-to-day users of Macromedia products. Some Xtras are product-specific, while others are designed to work across multiple applications. The table below provides a sampling of how the Xtras can be supported in Macromedia applications and where those Xtras appear in each application's user interface.

Director Xtras	Appears In	Behavior
Transition	Transition Dialog	Performs screen transition effect.
Asset	Insert Menu	Creates an instance of an add-in media type.
Pixel Filter	Auto Filter, Paint	Runs filters (Photoshop and others) that can modify single bitmaps or a range of bitmaps over time (in the Paint or Cast window).
Scripting	Lingo scripting language	Provides additional functions and objects in the Lingo scripting language

The Macromedia Xtras API supports rich, well-defined suites of functionality. One cornerstone of the architecture is the clear delineation of responsibilities between applications and Xtras. On the application side, this means providing a coherent way to expose internal data structures and behaviors to Xtras. On the Xtras side, this means providing modular units of behavior with the correct plugs to fit into corresponding application sockets. To support this, MOA uses interfaces- a standard means of defining the modules of functionality that an application or Xtra provides.

A second cornerstone is the provision of cross-application standards that define the interaction between applications and Xtras as generally as possible, to encourage developers to create Xtras that work across applications. For example, both Director and Authorware provide Xtras with access to the drawing surface of the display in precisely the same way.

All MOA-capable applications support a basic set of callback interfaces, which enable an Xtra to access standard services, including memory allocation, stream access, and simple user interface tools:

MOA Callback Interface	Description
IMoaCalloc	Allows an Xtra to allocate bytes of fixed memory in the host application's heap.
IMoaHandle	Allows an Xtra to allocate bytes of relocatable memory in the host application's heap.
IMoaFile	Provides cross-platform access for reading and writing files.
IMoaStream	Allows an Xtra to read and write a byte stream passed to a MOA object.
IMoaProgressBox	Allows an Xtra to display a progress dialog using the host application's dialog system.

Similarly, all Xtras implement a set of cross-product interfaces so that they can register themselves and be installed into applications in a generic way.

Xtra Interface	Description
IMoaRegister	Allows an Xtra to register itself and store initialization data.
IMoaInitFromDict	Allows an Xtra to initialize an instance of itself from stored data.

Functionality that is similar across applications is gathered into a common set of interfaces which can be accessed by Xtras, allowing a single Xtra to be used in multiple Macromedia applications-even those released after an Xtra was created.

Macromedia defines a set of shared callback interfaces that are supported by Macromedia multimedia applications. These interfaces are called by Xtras to invoke specific multimedia functionality inside an application (such as adding a new asset type to Director or Authorware). All applications that support multimedia implement these interfaces and can therefore share Xtras.

Multimedia Callback Interface	Description
IMoaMMGC	Provides access to platform-specific features of an application's drawing surface.
IMoaMmAssetCallback	Provides asset-specific support from the application.
IMoaMmChangeCollector	Provides methods for improving drawing efficiency.
IMoaMmCuePointCallback	Provides a way for Xtras to signal cue points to an application.
IMoaMmMacEventHandler	Connects an Xtra to the application's event handling on the Macintosh.
IMoaMmPropOwner	Defines general property access methods.
IMoaMmWndMac	Provides access to platform-specific windows on the Macintosh.
IMoaMmWndWin	Provides access to platform-specific windows on Windows.

Xtra Interface	Description
IMoaMmXAsset	Defines media that can be plugged into an authoring or playback system.
IMoaMmXSpriteActor	Manipulates a particular asset that is being played back over time.
IMoaMmXTransitionActor	Defines screen transitions.
IMoaMmXScripting	Defines scripting language extensions.
IMoaMmXTool	Defines authoring features available from Tools menu.

The Macromedia Open Architecture (MOA) is based on the concept of classes whose behaviors are described by interfaces. Each interface describes a clearly-defined unit of behavior. For example, the IMoaCalculation interface might define methods to Add, Subtract, Multiply, and Divide. Interfaces describe a set of methods (behaviors), but not how those behaviors are implemented. IMoaPrinting might define methods such as ChoosePrinter, StartPrinting, or CancelPrinting.

Classes are units of implementation. In defining a class, the implementor chooses one or more interfaces to implement, and provides method implementations for the method descriptions defined in the associated interface. For example, a SimpleCalculator class would implement the Add, Subtract, Multiply, and Divide methods in the IMoaCalculation interface using basic fixed point math. A PreciseCalculator class would implement the Add, Subtract, Multiply, and Divide methods using much more precise algorithms, and might also choose to implement the IMoaPrinting interface methods.

A class is really a template from which multiple objects, each complying to the same behavior (for example, interfaces), can be instantiated. An object is a run-time unit of operation. If you need three calculators, you simply instantiate three SimpleCalculator objects from the class at run-time, and they are used operationally to do the calculation behavior.

Each individual object instantiated from a class needs to be able to hold on to its own private data (for example, a calculator might need to keep track of its own registers and accumulators). Thus, when defining a class, besides choosing and implementing the interfaces, the developer defines a set of instance variables that can hold data specific for each instance of a class. When an object is instantiated from a class, special memory is allocated in each object to maintain the instance variable data. All the interfaces defined by a class have access to the data contained in an instance of that class. MOA is largely used to develop Xtras that can be plugged into applications, and to provide APIs into those applications for the Xtras to use. This is done by taking advantage of the interface/class/object/method taxonomy, as explained in detail below.

Macromedia has defined a set of cross-product application interfaces that are to be implemented by applications and a set of cross-product Xtra interfaces that are to be implemented by Xtras. To implement an interface, a developer typically defines a class that supports that interface.

An Xtra "advertises" its type by registering the interfaces it implements, along with any other required information for that interface, with each Macromedia application. For example, each Asset Xtra registers its implementation of the IMoaMMXAsset interface.

Applications like Director or FreeHand each define a specific class or classes to encapsulate the behaviors of that application. Each class provides implementations for some cross-product interfaces, some product-specific interfaces, and perhaps some shared multimedia interfaces. One class is always designated as the "callback" class of that application, to serve as the primary point of outside contact with that application. This class is instantiated by MOA when the application starts, and the resulting callback object is made available to all Xtras by MOA through the standard pCallback instance variable. Other objects within the application that can be manipulated by an Xtra are represented by additional classes and their interfaces. For example, Director exposes cast members or sprites.

Each type of Xtra (for example, a hypothetical "morphing" Xtra), defines one or more classes that encapsulate the behavior of that Xtra. Each Xtra provides implementations for standard Macromedia-defined Xtra interfaces. In addition, each Xtra developer can define some instance variables that are needed (for example, to record and manage the morphing state).

When an Xtra is prepared for use -- typically when it is invoked by the user from one of the application's menus -- the Xtra is initialized and given a reference to the application's callback class. Whenever the Xtra wants to invoke an operation on the application, it queries the callback to see if the desired interface is available in the application. If it is, the Xtra is free to call any method in that application interface.

An extremely important point here is that clients can take advantage of polymorphism. The client can query a class to discover if a particular interface is implemented by that class; if it is, the client is guaranteed that it can invoke the defined methods of that interface and receive appropriate results, without needing to know how it is implemented.

For example (again, this is hypothetical), the same Xtra for morphing could be used in both Director and Authorware. When Director launches, it sees that the morphing Xtra is in the Xtras folder and registers it. When the user picks Morph from the Xtras menu, Director instantiates and initializes that Xtra, and gives it a reference to the Director callback. This reference will appear to the Xtra as an instance variable named "pCallback" (a pointer to the callback class). The Director callback class has chosen to implement the IMoaPixelAccess interface (which defines several methods, including GetPixels), and has a Director-specific implementation for GetPixels.

Similarly, Authorware instantiates and initializes the same Xtra, and provides a pointer to its Authorware Class (the Authorware callbacks) in the pCallback instance variable of that Xtra. The Authorware Class implements the GetPixels method of the IMoaPixelAccess in an Authorware-specific manner.

To implement a particular type of morph (for example, a slow morph), the Xtra writer defines a SlowMorph class. The code for that class queries its pCallback instance variable to see if the class represented by the pCallback object implements the IMoaPixelAccess interface. If this Xtra is running in Director, pCallback references an object of the Director class and the query is positive. Similarly, if this Xtra is running in Authorware, pCallback references an object of the Authorware class and the query is positive. Now, the morphing algorithm in the Xtra can call any method of IMoaPixelAccess to do its drawing. The interface is application-neutral and makes no references to Director or Authorware; all references go through the IMoaPixelAccess interface, which Director and Authorware have each implemented in their specific fashion. If Extreme3D were to implement IMoaPixelAccess, then SlowMorph would work in that application without recompilation.

The above describes how an Xtra can operate in multiple applications that implement the same functionality. But for functions like morphing, the application needs to drive the Xtra, for example, in order to obtain names to put up in application dialogs, in order to post Xtra-provided dialog boxes, and in order to step morphs, or transitions, or animations through their steps. As expected, all Xtras that provide the same level of functionality (i.e. they need to be stepped through a series of phases), would implement an interface like IMoaStepper, with methods Start, Step, and Stop. All morphs might implement an IMMMorph interface as well. In an application, when you clicked on the Morph menu item, the application would query all Xtras to see if they implemented the IMMMorph interface. If they did, the application would issue a query to each Xtra that answered positively to obtain the name and icon of that particular morph, and put those in the Morph dialog box presented to the user. When the user chose a particular morph type from the dialog, the application would query and obtain a reference to the morph Xtra's IMoaStepper interface and invoke the Start method of that interface on the Xtra. As the application continued, it would, at appropriate points, call the IMoaStepper::Step() method of the Xtra. When complete, it would send IMoaStepper::Stop().

Unlike SoundEdit, Director implements a number of interfaces. Interfaces are defined for the Director player, a Director movie, a cast, an individual castmember, a score, a sound, a frame, and a sprite.

Some applications, like SoundEdit, can define a single callback class that wraps together all of the interfaces that need to be implemented. However, Director's interfaces are designed so that an Xtra writer can have full access to the run-time data structures of Director, where there may be two movies open, five casts, 300 cast-members, two score-sounds, 30 active sprites, etc. Thus, for each major object type in Director, a class is defined that has instance variables to maintain information about that type of object and implements a MOA interface for that object type. An Xtra writer can then instantiate 15 objects from the MoaDrCastMem class if they want to have an Xtra that operates on a number of cast members.

In particular, the product-specific classes/interfaces implemented by Director are:

Class	Interface	Description
MoaDrPlayer	IMoaDrPlayer	Top-level interface to the Director playback engine.
MoaDrMovie	IMoaDrMovie	Gets movie-level information and invokes movie-level behaviors.
MoaDrCast	IMoaDrCast	Gets cast-level information and invokes behaviors on entire casts.
MoaDrCastMem	IMoaDrCastMem	Gets information and invokes behaviors on individual media assets.
MoaDrScoreAccessor	MoaDrScoreAccessor	Accesses, traverses, and edits the Director score.
	IMoaDrMedia Accessor	Accesses media tracks in the score.
MoaDrScore	Frame IMoaDrScore	Gets information and invokes behaviors on individual score frames.
MoaDrScoreSound	IMoaDrScoreSound	Gets information and invokes behaviors on sound channel in the score.
MoaDrScoreSprite	IMoaDrScoreSprite	Gets information and invokes behaviors on sprites in the score.

A real power of the MOA interface is the ability to specify well-defined interfaces that can abstract and encapsulate application and Xtra functionality. One example is the IMoaPixelAccess/IMoaPixelFilter interface set. IMoaPixelAccess provides an abstracted model for accessing and modifying a set of pixels, such as TIFF images. IMoaPixelFilter provides an abstracted model for a piece of code that uses IMoaPixelAccess to "filter" the pixels. These interfaces are not tied to any application and have few underlying assumptions. This technique makes it easy to write "adapter" Xtras for other plug-in technologies.

In addition to supporting the MOA component architecture, Macromedia has developed an asset Xtra for Director and Authorware that supports Microsoft's ActiveX control technology. Currently available for Windows only, this Xtra allows any ActiveX control to operate inside a projector, a .DIR movie, or an Authorware piece. A Shockwave movie can't host ActiveX controls because of security reasons.