Ted Patrick > { Events & Community } > Adobe Systems

I have been working with shared libraries on a project (FLOW) and discovered some benefits and problems in using them.\0

Runtime Shared Libraries allow you to access library assets of another SWF (shared library) as if these assets were contained the main movie library. Once a shared library has been imported at runtime, you can use these assets identically to anything in the library containing a linkage id.

Main Movie = SWF file that loads a Shared Library at runtime
Shared Library = SWF that is loaded at runtime

A shared library is loaded the moment an asset containing special linkage settings is presented on a keyframe in the main movie. The shared library SWF is then loaded into the main movie to a hidden location (most likely a protected depth). If the shared library is fully loaded, then the included library assets are available, if the shared library has not loaded fully, then the assets will break when added onto stage. Ideally we can preload the shared library and when loading is complete, we can use shared library assets as normal.

Here are 2 sample apps using shared libraries:

Using createObject with RSL
Using Design-Time Components with RSL

Both applications share the same shared library and allow components to be reused across 2 separate applications on different URLs. These two apps filter based on player version and allow you to receive an optimized set of components matching your Flash player capability. Once the first application loads, the second visit to any of these application loads nearly instantly as the shared library rarely needs updating.

**Sometimes the shared libraries load too quickly as the second app can display an error when the library loads faster than the base app. This will be addressed in a later build of the FLOW architecture.

Here is a small sample for those with MX 2004.
http://www.powersdk.com/sample/shared.zip

Strange gotchas and helpful hints:

1. Shared Library assets are fully functional when publishing your main movie to AS1 or AS2. So long as your main movie is structured to use shared libraries correctly, you are no longer restricted to using AS2 with V2 components as the components are already compiled into the shared library.

2. Preloading shared libraries can cause loads of problems (but it is possible). Due to V2 references from _global to manager movieclips, if you preload a shared library before viewing components, you must edit _global prior to unloading the preloaded SWF. This results in a player crash in all tested F6, F7 players including crashing the player within the MX 2004 IDE. The key is removing the _global references to V2 manager movieClips prior to unloading the level/movieclip containing the shared library. I will post this crash example online as a FLAw.

3. All assets within a shared library are available at runtime so long as just one asset shares a linkage id and is set to runtime sharing with a URL. Only one asset needs to be properly linked in the shared library for all of them to be imported.

4. Shared library linkage ids will overwrite local movie linkage ids. If you have a local asset with a linkage of 'Button' and you load a shared library with V2 'Button', the V2 'Button' component will be instantiated not the local movie asset.

5. With V2 components making one large shared library is very efficient as the V2 classes are never duplicated. If you break v2 components into separate libraries, the V2 component framework will break as __proto__ is overwritten in the _global classes, thus breaking inheritance for dependent classes. When the second v2 class is added to the player all dependent classes have broken __proto__ references.

Questions & Comments always welcome.

Enjoy,

Ted ;)