|[ LiB ]|
Flash has three general ways to manage media in its internal library. Normal items are those items you either create inside Flash or import directly from file. Shared library items arrive in your Flash movie via another file. Shared items can be set to automatically update each time you publish so that they reflect changes made to their original. Finally, runtime shared libraries (RSLs) contain items that get imported at runtime. This way, items in RSLs are always up-to-date as they get imported at runtime (not unlike SWFs that get loaded via loadMovie() ).
There's not a whole lot I can say about the plain library items created while in Flash. Similarly, a type of media not mentioned yet is external native files ( specifically , MP3s, JPGs, and FLVs). Flash support for these native file formats means that, at runtime, you can import and present them. With both normal items and external media, being productive means being smart with your naming strategy. Because you know that libraries and file folders can sort alphabetically and numerically , for example, you might name your files clip_1.mp3, clip_2.mp3, and so on. However, this section covers the intricacies of shared items and runtime shared libraries.
Perhaps the easiest way to remember this feature is to call it "authortime" shared library items. That is, all the magic happens while authoring. The idea is you can store items in one (source) FLA's library and use them in another (user) FLA. Every time you publish the user movie, it updates the item by effectively reimporting from the source. It's really easy to do.
The benefit of shared items is you can keep a library of common media in one place even if you plan to use those items in several files. For example, you can store your company logo as a shared item. Then, if you get bought out, for instance, you can edit the original, republish all your movies, and they'll all reflect the change. Although there's a slight hassle republishing everything, after you do, the new media is actually in the user files. In addition, you don't have any download considerations (like RSLs do).
You need to know how you get shared items into a movie's library. First realize you need one source FLA that contains library items you intend to use elsewhere. In addition, you need one or more "user" files that share items from the source file. Start with the source file and make a symbol. Save the source FLA in a known location. Then, there are two ways to let the user files share the item (symbol) you just made. The easiest but perhaps less intuitive way is to just copy an instance of that symbol from the stage of the source and paste it into a new file. Then, find the symbol in the new file's library, and select Properties. When viewing the advanced portion of the Symbol Properties dialog box, select the Always Update Before Publishing check box (see Figure 10.8). You'll see additional details in the Source section because Flash knows the item was copied from another file.
Now, every time you test the movie or publish, the latest version of the original symbol is re-imported. In addition, the library item in the user file has an extra option, Update, available in the library's menu to force the re-import.
The other way to get shared items into a user file is to select File, Import, Open Library for Import. This enables you to point to the source FLA, and its library will open in Flash ready to drag and drop instances onstage. As these symbols get added to your file, they will automatically have their Source property set as in Figure 10.8.
Incidentally, the equivalent to Flash's swap symbolas applied to shared library itemsis the button labeled Symbol, also in Figure 10.8. It enables you to swap this item with any item in the source file.
Shared library items is not necessarily a super production saver or particularly useful in every project. However, there are key situations that really call for it.
Runtime shared libraries are like an automated version of loadMovie() . That is, Flash has the power to load in and play SWFs at runtime. RSLs are effectively doing that, but in a way that's seamless to you, the developer. Basically, you make a movie with the library items to be shared and export a SWF. Then, in the files you intend to use as the resources of the shared movie, you point to that exported SWF. The cool part is that because you'll likely have one source and many user files, only the source needs to get updated, because the shared media loads at runtime. (Recall, with shared items each user file had to be republished to reflect a change to the source.)
RSLs get a bad rap because they have some issues you must contend with. For certain situations, however, they're great. Suppose you have a seasonal background imagemaybe a picture of the beach for the summertime. You can store that asset in a RSL. Then, when fall rolls around you could update just that RSL and all subscribed user movies would reflect the change the next time the users visited. Perhaps the single static image isn't a great example because you could also just use loadMovie() to load a JPG and then swap out the JPG. If your background includes animations, you can see how a static JPG won't suffice. Although this chapter deals with "productivity," RSLs also offer another huge benefit: Files will be smaller because shared assets download only once (in the RSL file).
Before I show you the basics of RSLs, I should probably point out a couple limits. In the movies that use the shared items, you'll never see the real thing until you test or publish the movie. Because the item loads at runtime, you won't see it until then. In addition, the default behavior is for shared assets to download before the first frame of the movie displays. As a result, the user sees nothing until that media downloads. For this reason, it's usually best to use RSLs for media that's relatively lightweight.
The thing is, RSLs are so attractive for their efficiency both in reducing the total download across a site and ease of making updates. Interestingly, the entire set of user interface components made for Macromedia Central are contained in a RSL hosted at Macromedia.com. The first time Central runs, the shared assets download to Central's cache. This way, all subsequent apps that use the components won't force any extra download because the shared library is already present. In addition, when Macromedia updates, the components changes will be seen immediately. The only catch is that while authoring, you don't really "see" the components.
Here's a quick walkthrough of creating a RSL. Start with the item to be shared: Save a new movie as shared.fla and draw a shape. Select the shape and convert to symbol (F8), and then in the Linkage section of the Convert to Symbol dialog box check Export for Runtime Sharing. Set the Identifier to MyShape and fill in the URL to read shared.swf as in Figure 10.9.
As it stands, the URL shared.swf is going to be relative to the movie that will use itbut that can be an explicit path including your entire domain and path to where you plan to store this RSL. Now, when you're ready to use the RSL, you just need to note the identifier (myShape) and URL ( shared.swf ). Before you can do that, however, the shared.swf must exist. So, just test the shared.fla movie.
Now, start a new file, name it user.fla , and save it adjacent to the shared.swf . Next, make a shape that will get linked to the RSL. (You could even copy the contents of the myShape clip to get the matching size.) Finally, convert it to a symbol (F8), but this time select Import for Runtime Sharing and specify an identifier of myShape and URL shared.swf (see Figure 10.10). Basically, this says, "Make this symbol import the clip with the identifier myShape that's inside the shared.swf."
That's it. Again, the funky part is you can easily get mixed up when editing the user.fla. Suppose you go and edit shared.fla (for instance, change the color of the myShape symboland be sure to export a SWF by testing the movie). If you go back to user.fla, you'll still be looking at the proxy. Do a test movie in user.fla and you'll then see the updated version. However, the normal sequence is that you'll upload everything, and then later change the shared.fla and make a SWF to upload. From that point forward, all visitors to user.swf will see the new shared symbols. The key to testing this sort of feature is keeping your folders and files clean and working deliberately.
Finally, it's not as though either RSLs or shared library items are better. Instead, they both have their place. I guess my main point in this whole section is that you've got several useful ways to manage the library. RSLs are a way to automatically reflect the up-to-date media and share the download across several files. Shared items are a way to force the latest media into each file as its published.
|[ LiB ]|