Runtime Environment: Chapter 3 - ActionScript 3.0 Cookbook
Pages: 1, 2, 3

Section 3.10: Detecting the Device's Video Capabilities


You want to determine the video capabilities of the device on which the Flash Player is running.


Use the hasEmbeddedVideo, hasStreamingVideo, and hasVideoEncoder properties of the flash.system.Capabilities class.


Before you attempt to deliver video content to a user, it is important to check whether his system is capable of playing video, and how it should be delivered. The most efficient way to deliver Flash video is to stream it to the player. This allows the user to view the video as it is coming in, rather than waiting until the entire (often quite large) file has downloaded. However, the user's system may not be capable of receiving streaming video. To check this, use the flash.system.Capabilities.hasStreamingVideo property. If this returns false, one option is to have the player load another .swf that contains an embedded video. However, before doing this, you should check the property flash.system.Capabilities.hasEmbeddedVideo to ensure that the user can view this content before initiating this download. Your code would look something like this:

if(flash.system.Capabilities.hasStreamingVideo) {
  // Code to set up a video stream and start streaming a 
  // specific video
else if(flash.system.Capabilities.hasEmbeddedVideo) {
  // Code to load an external .swf containing an embedded video
else {
  // Alternate content without any video

Similarly, if your application requires video stream encoding, such as the use of a web cam to transmit live video from the user's system, you want to ensure that the system is capable of doing such encoding. You can test this with the flash.system.Capabilities.hasVideoEncoder property. Like the earlier example, you would probably test this property in an if statement and set up the video streaming only if it tested true. Otherwise, you could display a message to the user explaining the situation or redirect him to another page.

Section 3.11: Prompting the User to Change Player Settings


You want to open the user's Flash Player Settings dialog box to prompt her to allow greater access to her local system.


Use the flash.system.Security.showSettings( ) method.


The flash.system.Security.showSettings( ) method opens the Flash Player Settings dialog box, which includes several tabs. You'll pass a string as a parameter to indicate which tab you want it to open. These strings have been made static properties of the flash.system.SecurityPanel class, to avoid typographical errors. The possible values are:

Allows the user to select a camera to use.
Shows whichever tab was opened the last time the Security Panel was open.
Allows the user to specify how local shared objects are stored, including the maximum allowable disk usage.
Allows the user to select a microphone and adjust the volume.
Allows the user to specify whether to allow Flash access to her camera and microphone.
Opens a new browser window and loads the Settings Manager page, which gives the user several more detailed options and the ability to make global changes, rather than just to the domain of the specific movie that is active.

If you don't pass any parameters to the showSettings( ) method, it uses SecurityPanel.DEFAULT. Here, we open the Settings dialog box to the Local Storage tab by explicitly specifying a value of 1.

// Open the Settings dialog box to the Local Storage tab.

Out of courtesy, you should prompt the user to open the Settings dialog with a button rather than simply opening it without warning. Also, you should alert the user beforehand as to which settings she should change.

Section 3.12: Dealing with System Security


You want to load a .swf from another domain into your application and allow it to have access to the ActionScript in the application.


Use one of the following: flash.system.Security.allowDomain( ), flash.system.Security.allowInsecureDomain( ), or a policy file.


In many cases, all of the .swfs in a multi-.swf application would live on the same server (thus the same domain). There may be cases, however, when your application needs to load in an external .swf from another domain. In such a case, neither the .swf nor the loading application would be able to access the other's code. You can allow such access by using flash.system.Security.allowDomain( ), flash.system.Security.allowInsecureDomain( ), or a policy file.

The .swf that is going to be accessed must explicitly allow access by .swfs in the other domain. It does not matter which .swf is loading or being loaded. To clarify, call the .swf being accessed, accessed.swf, and the .swf doing the access, accessing.swf. Say accessing.swf lives on and loads in accessed.swf from, into an object named content (see Figure 3-1).

Now, accessing.swf tries to access a variable called authorName from the loaded accessed.swf. At this point, accessed.swf complains and won't allow access by a .swf from another domain.

To overcome this, accessed.swf needs the following line:


This lets it know that it is alright to allow access by any .swf from that domain.

You should note that the permission is one-way. If the loaded .swf now needs access to some code in the .swf that loaded it, it would not be able to get at that code. In this case, the loading .swf would explicitly need to allow access to

Figure 3-1: Using Security.allowDomain

The domain can be text-based as in the previous examples, or can be a numeric IP address. It also supports wildcards. If, for some reason, you want to grant access to any .swf, anywhere, to access it, you can pass in the string "*". However, this effectively cuts out all cross-domain security that has been built into the player, and is not recommended.

If the accessed .swf file happens to be on a secure server accessed with https://, then by default it won't allow access to any .swf being loaded from a non-secure domain (http://), even if you have allowed access with flash.system.Security.allowDomain( ). In this case, use flash.system.Security.allowInsecureDomain( ) to allow access to a non-secure domain.

The method mentioned here requires you to hardcode the domain name or names into your .swf. This works fine if you know exactly which domains you will be allowing access from and that these are unlikely to change. However, if you later want to add or change the allowed domains, you have to change the code and recompile and redeploy the .swf. In a situation where this is likely to happen often, it is more efficient to create and use a policy file.

A policy file is an XML file that lists any domains that are allowed access to the code in the .swf. The format of the file can be seen here:

<?xml version="1.0"?>
<!-- -->
  <allow-access-from domain="" />
  <allow-access-from domain="*" />
  <allow-access-from domain="" />

As you can see, it just lists each domain to which you want to allow access. The file should be named crossdomain.xml. Prior to Flash 8, the file was required to live in the root directory of the domain of the .swf to which it applied. Now you can specify and load a policy file from any other location using flash.system.Security.loadPolicyFile( ). This takes a string defining the URL of the crossdomain.xml file you wish to load. This file should be loaded as an early action in your application, before you attempt to load any content from another domain. With this method, you can add, remove, or change allowed domains by simply rewriting the XML file.

As you can see, this method also supports wildcards. For example, if you wanted to allow access to any and all domains, you could use the following line:

<allow-access-from domain="*" />

And if you wanted to explicitly deny access to any domain except the current one, you can create an empty policy file:


This excerpt is from ActionScript 3.0 Cookbook. Well before Ajax and Windows Presentation Foundation, Macromedia Flash provided the first method for building "rich" web pages. Now, Adobe is making Flash a full-fledged development environment, and learning ActionScript 3.0 is key. That's a challenge for even the most experienced Flash developer. This Cookbook offers more than 300 solutions to solve a wide range of coding dilemmas, so you can learn to work with the new version right away.

buy button