Accessibility

Table of Contents

Setting up a Flash project for local and network playback

Options for Flash delivery and playback

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!