Setting up a Flash project for local and network playback

From the beginning, Adobe Flash has been a great option for creating content for local or web delivery; but playing content locally has become more challenging as the network features, file structure, and security features of Flash have grown. The best way to save yourself from frustration is to understand the features in place and what your options are for deployment.

Recently I worked with Aperian Global in San Francisco producing cultural training software for soldiers being deployed to Iraq. The project had the requirement of delivering both a web-based version and a non–web-based version of the application. We went the route of creating one Flash application that would be capable of meeting both requirements. To accomplish this, we used static XML files as a data source and built the application (website) in a way that the root folder could be launched from a web server or viewed independently on a local drive. It worked well in the end but there were many challenges and considerations along the way.

This article addresses the key points I learned on the project combined with an overview of the server protocols, delivery options, and security features in Adobe Flash Player. While there will be dramatic improvements in our options for desktop Flash media delivery in the near future, the information in this article is most useful for developers working directly with content in Flash Player 8 and higher.

Flash is, by design, a web-based medium. It uses standard web file formats, a common website-based file structure, and standard web server connection protocols. This foundation inherently creates a challenge for developers who want to deploy content locally using more than just an encapsulated Flash file.

In general, building Flash files that completely encapsulate all their content is the easiest option to work with from a local file system. Encapsulated files don't break any of the security rules because they do not look outside themselves for content and data. While this is definitely something to consider, it's not an ideal production model for dynamic or localized applications. Knowing your range of options will enable you to strike a working balance.

Web-based server protocols (HTTP, HTTPS, RTMP, RTMPS)

Flash Player uses standard HTTP and HTTPS protocols to communicate to external sources. Note that Flash Player deploys the protocols directly, so server communication and file management will work while the SWF file runs in Flash Player locally outside the browser. This is ideal because the browser provides an interface that is often unnecessary or in conflict with the interface contained in the Flash application. However, the problem arises wherein HTTP/S communications can be blocked, depending on the local security settings defined at the time of authoring (see the Flash Player security considerations section of this article for more information).

The RTMP (Real Time Messaging Protocol) is used to communicate to Flash Media Server for streaming audio and video. The RTMPS protocol, which is the RTMP protocol over SSL (Secure Socket Layer), was added in Flash Media Server 2. Both protocols can be used for the playback of FLV-formatted media from Flash Media Server during local playback.

Most commonly you'll be using the HTTP protocol for communicating to external sources in much the same way as a standard website.

Local playback via SWF

Playing a Flash movie locally is easy to do. If the viewer has the standalone version of Flash Player installed, they can view SWF files simply by double-clicking them on the Desktop. If the viewer does not have the standalone Flash Player installed, they have to view the SWF file locally in a browser containing the Flash Player plug-in. (The standalone version of Flash Player is installed when you install the Flash authoring tool.)

Tip: The Flash Player plug-in has been commonly available in the larger browsers since Microsoft Internet Explorer 4. It is relatively safe to assume that your website visitor has some version of Flash Player available. You can install the standalone player by installing the Flash authoring tool or downloading the player from Adobe.

Regarding security restrictions, local playback of a SWF file implements security restrictions specific to the local playback option selected in the FLA file's Publish Settings dialog box during authoring.

Local playback via Flash projector

The need for either the standalone player to be installed or a browser to be present is somewhat of a limitation for locally deployed applications. One longtime Flash solution is the option to export the SWF file as a Flash projector. Flash projectors wrap the SWF content and Flash Player in an executable file (.exe for Windows or .app for Mac OS). This feature enables the Flash content to be deployed locally without the need for a browser or prior standalone player installation.

Tip: You can choose the Flash projector export format and adjust export options for each FLA file using the Publish Settings option in the File menu.

Regarding security restrictions, the Flash projector method resolves the player availability problem but it does not circumvent the security restrictions inherent to Flash Player during local playback.

Caution: Projector files are not intended for web delivery. Using the Flash projector export method adds about 2 MB to the file size of the SWF content when exporting to Flash Player 9. The format is intended for viewing outside of a browser on a local system.

Local playback via Director and Authorware

Macromedia Director and Macromedia Authorware are two software developing tools that ruled the earth in the era of CD-ROM training and entertainment. While focus has shifted to web-based authoring tools, when it comes to creating CD-based local content that contains Flash media, it's hard to beat these applications.

The gist is that both Director and Authorware can embed Flash content and act as a wrapper for communication to external resources. This approach sidesteps the security feature issues that you would hit otherwise. In addition to being able to dynamically feed content to the local SWF, Director and Authorware have advanced features that are not available in Flash, such as file system access, DVD controls, audio/video recording and manipulation, and so on.

Tip: Director and Authorware can also be used to produce web-based applications with some impressive and unique features. There are many people in the Director and Authorware developer communities who can answer questions if you're curious to learn more.

Looking to the future of local playback

One of the exciting new technologies on Adobe's horizon is Adobe® Integrated Runtime (AIR), the cross-OS runtime platform that will allow you to build and deploy desktop-based Internet applications. At the time of this writing, Adobe AIR™ is in its beta development phase. (It was code-named Apollo in its alpha release.) Adobe AIR is built on the foundation of ActionScript 3.0 and Flash Player 9 and enables a developer to create a desktop-based Flash application using Flash, Flex, HTML, Ajax, and JavaScript.

In a nutshell, Adobe AIR will enable you to build a Flash application using techniques similar to what you already know but you'll be able to run the content in the Adobe AIR runtime and forego the browser altogether. This is ideal because Flash applications frequently don't need the interface of the browser to be present. Or even worse, the presence of the browser interface interferes with the intent of the Flash user interface.

In addition to losing the browser, Adobe AIR is built for desktop deployment and will not contain many of the roadblocks seen in handling Flash Player 8 security restrictions. Adobe AIR also adds access to the file system on top of ActionScript 3.0 for the possibility of true online/offline application integration. This is very exciting stuff!

A "local" SWF file is a file that resides on the viewer's computer instead of the Internet. Flash files running locally are subject to the Flash Player security model, wherein by default they are not allowed to communicate with the Internet or network-enabled files on the local file system. This is the challenge present when creating dynamic local Flash content.

The security model explained here exists in Flash Player 8 and higher. Flash Player 7 is more relaxed in its local security settings, but you have to assume that your general audience will be viewing your application using the current player version—which is now Flash Player 9.

Publish settings security options for local playback

You can affect local playback by setting the local security options in the Publish Settings dialog box for each FLA file. You can either allow the SWF to communicate with local files only or allow the SWF to communicate with network files only (see Figure 1). You cannot allow both options during authoring; only the client can allow both local and network access. By default, Flash allows access to the local file system only.

The default setting of local files limits only the Flash file to loading known assets from the local file system, with the exception of loading network-enabled SWF files. I have also seen situations where static XML files will not load from a relative path while using the local files-only setting.

Switching to the network-only setting will allow you use ActionScript and XML permissions files to interact with network-enabled SWF files and server requests. This setting limits you by not allowing the SWF to interact with local non-network SWF files and local content.

Tip: In the scenario wherein you need to communicate across domains from a network file, or you need to communicate to a specific domain from a local file without accessing other local files, then look into using the network-only security setting and use the System object in ActionScript or an XML policy file to allow the cross-domain access.

Tip: In the scenario wherein you need to deliver a local application built with a website file structure (external images, XML files, etc.), you have to use the local-files-only setting and then instruct the viewer on how to enable file system and network access. Only the client can allow both settings at the same time.

Allowing network and script access in the HTML settings

If you would like your SWF file to be able to communicate to other HTML pages while running locally from an HTML page, you have to set the allowNetworking parameter to "all." The same HTML page can access locally available web features such as JavaScript and ActiveX objects if the allowScriptAccess parameter is set to true. Try to experiment with these features before looking to more complex solutions. See Restricting networking APIs in the Flash CS3 Professional LiveDocs for more information.

Note: If you're not using an HTML page for local playback, these parameter settings will not apply to you.

Using the Global Settings Manager

The only way for a locally deployed SWF to load content and data from the local drive and from the Internet is for the client to allow the movie as a trusted site. To do this, the client has to connect to the Internet once to allow the Global Settings Manager to add the site (see Figure 2).

To enable local and network access in a Flash application viewed in Flash Player 8 and higher from a local drive, you have to export for local files only and allow the application as a trusted site on a client-by-client basis.

Tip: Allowing each application individually as a trusted site is a best practice. Allowing the desktop, or a general folder, as a trusted location can work well for prototyping.

Please see Specifying trusted files using the Settings Manager in the Flash CS3 Professional LiveDocs for more information about global security settings.

Using Flash Player configuration files

It's interesting to note that the author of a Flash application (or anyone who has Flash installed) has a special flag set on their computer that determines if they are a Flash author. The author of the application can see the developer-oriented view of the Global Security Settings panel instead of the user-oriented view others will see. For testing purposes, authors can change the flag from "Author" to "User" in the FlashAuthor.cfg configuration file on their computers. This will allow them to experience the settings manager as a user without Flash installed on their machines.

Also interesting to note is that it's possible to create a list of trusted sites manually by creating a FlashPlayerTrust folder on the client's computer, containing any number of configuration files pointing to trusted sites.

For more information on using Flash configuration files, see Creating configuration files for Flash development in the Flash CS3 Professional LiveDocs.

Two general scenarios exist for deploying web-based applications locally. The first scenario deploys an application that works both online and offline. The second scenario deploys an application that works only offline. While the scenarios share some commonalities, you'll find that the right approach for your project will be based on your specific needs.

The following tips are based on insights from my last project, in which I had to deliver a single application capable of online and offline playback. The application was built to use images, audio, an ActiveX audio recorder, and data (XML) supplied from external files.

Tip 1: Supply media and external data locally for local playback

Whether you use a Flash projector, a SWF file, or a SWF file embedded in an HTML page, applications intended for local delivery should include all their content locally along with the SWF. Usually, the rationale for creating a local Flash application is the desire not to have to be connected to the Internet or to at least not have to download all the related assets.

If content can be contained entirely in a single SWF file, taking this route will provide the easiest local delivery method. In cases where text needs to be split from the SWF for localization, use text files or XML files supplied with it. When dynamic templates are being used, split the images, audio, and text from the SWF to files stored alongside the application. When your Flash application needs to communicate with a server in addition to loading local content, set the FLA file's local security publish settings to local files only and allow the application as a trusted site on a client-by-client basis.

Tip 2: Run local files from a local drive instead of a CD

Generally, when distributing a locally run Flash application, you will use either a CD or web page download as a delivery method. In regards to the CD-based delivery method, there are a handful of useful things to know. One of the first things to consider is that Flash applications built with a website structure tend to load slowly when played directly from a CD or DVD. The limitations are related to the CD player read speed and a number of hardware factors that are not normally involved with delivering a web-based application.

It could be considered a best practice to run Flash applications built with a website structure on a local drive instead from the CD drive. This means that the application folder would be manually copied from a CD to the user's hard drive, copied from the CD to a hard drive via an installation program, or downloaded to a user's hard drive from a website installation page.

Note: Several inexpensive and freeware applications are available to help create an installation application for you—for example, Advanced Installer from Caphyon (Windows only) and DropDMG from C-Command Software (Mac OS). Either may be a good option for delivering by CD or download.

Tip 3: Use an Autorun.inf file to play a CD automatically

If you use a CD to deliver a Flash application or an installation file that installs a Flash application, you can place a text file on the CD that will autorun an executable or HTML file. In the case of an executable installation file, the installation dialog box appears and prompts the user to proceed. In the case of the HTML file, a browser opens and displays the file.

To create an autorun file and include it on your CD, follow these steps:

1. Open Note Pad or any text editor and enter the following text into the editor:

2. Replace the InstallerFileName text with the name of your file. If you're targeting an HTML file instead of an executable file, use the following format:

3. Save the file next to your Flash application. Name the file Autorun.inf while saving it.
4. Burn the Autorun.inf file and the executable installation file (or site files) onto the same CD.
5. Play the CD to see the autorun feature work.

Note: Including this file will work for running files from a CD on a computer running Windows.

Tip 4: Supply instructions for client settings using the Global Settings Manager

For Flash applications that will be deployed locally, load local content, and need to access Internet-based features and network-only files, you will have to allow the application as a trusted site on a client-by-client basis. This process needs to occur only once per client, and the client must be online to do it.

It's a best practice to provide the user with some kind of documentation on the steps necessary to allow the application as a trusted site using the Settings Manager.

Tip 5: Create an installation page for ActiveX content and local security settings instructions

When working with ActiveX content and global security settings for Flash Player, you have to connect to the Internet at least once for installation and security settings management. If you're building an application with complex needs, it's a good idea to build a web page that includes an installation of the required ActiveX controls and instructions regarding how the viewer should allow the application as a trusted site. The URL is supplied along with the delivery of the application, and visiting it becomes a requirement for the installation process.

Note: In general, ActiveX controls are not designed to be friendly to use for local browser playback. If you try to run an ActiveX control locally from a browser, the ActiveX control has to be installed from the Internet alongside the application in a location on the active user's desktop. This can get really tricky in any kind of a nonstandard computer configuration. It's a best practice to avoid using these types of controls for local browser playback and to stick with simply creating a security settings instructions page. Alternatively, you may want to consider using the strengths of Director or Authorware to combine web content such as SWFs and ActiveX controls.

Besure to visit the Active Content Developer Center for more information about using active content in some web pages.

Tip 6: Use XML and shared objects to store and synch data

You can use local shared objects to store persistent data locally between application sessions. Flash shared objects are similar to browser cookies in that they save runtime data to the local hard drive. Assuming the client has allowed the local application as a trusted site, the application could load initial settings from static local XML files, save data to local shared objects during offline usage, and (if required) sync to a server to save the data at a later time when the client has returned to an online status.

Where to go from here

If you are seriously pursuing local Flash content delivery, your best option will be to watch for the upcoming release of Adobe AIR as an official cross-OS runtime platform wherein the experience will be improved for web-based applications on the desktop. In the meantime, familiarize yourself with the information in this article and the various security resources available in the Flash Player Developer Center.

Here are a few resources to get you started:

• Publishing files for local deployment (LiveDocs)
• Creating configuration files for Flash development (LiveDocs)
• Security Topic Center
• Flash Player Help: Settings Manager