Workshop Chapter 1. Ensuring That Users Have the Flash Player 6

CONTENTS

Workshop Chapter 1. Ensuring That Users Have the Flash Player 6

    It's safe to say that most everything covered in this book is specific to Flash MX. This means that your audience must be equipped with Flash Player 6 or later. Although it's possible to target older Flash Players using the Publish Settings (see Figure W1.1), selecting any option lower than Flash 6 causes much of the scripting capabilities to be off-limits. It's actually possible to work in Flash MX and deliver to Flash 4 or Flash 3; there are just so many details that we're not even going to discuss it. The fact is that at the beginning of 2002, about 98 percent of all Internet users had at least the Flash Player 3; even the relatively new Flash Player 5 has reached 85 percent. Although your Flash 6 movies might not work for these users, the solution outlined in this workshop will easily identify those users with anything less than the Flash Player 6 and provide alternatives for them. These alternatives range from a link to Macromedia (so that they can upgrade) to channeling them to a different version of your web page. The technique you'll learn in this workshop uses Flash to identify which version of Flash the user has.

    Figure W1.1. You can target old versions of Flash using the Publish Settings, but you won't be able to use most Flash MX features.

    graphics/17fig01.gif

    Naturally, using Flash to test which version of Flash is installed assumes that users have at least some version of Flash. To provide a seamless experience for those 2 percent of users without any Flash Player, you have a host of alternatives. Unfortunately, I don't think any solution is 100 percent foolproof. I'm not saying that the alternatives I'm about to present have inherent flaws; it's just that they also rely on technology that may not be functional. For example, if you try to use JavaScript to determine whether the user has the Flash Player, it's possible that the user has turned off JavaScript in her browser. Anyway, there are some near ironclad solutions to reach any users, even if they don't have Flash.

    First I'll provide a quick rundown of two non-Flash solutions, and then walk through exactly how to use Flash to check which version of Flash is installed.

    The non-Flash solutions use what's commonly called a "sniffer" script an HTML file with scripts that attempt to sense which version of the Flash Player is installed (if any). The sniffer script is a file that serves as a gateway to redirect users to the appropriate content. Every user who visits your site always starts by visiting this gateway file. The file tries to determine whether the user can see Flash. If the user has Flash, he goes to the Flash version of your site (another page); if the user doesn't have Flash, he goes to the non-Flash version of your site. You can even send a user to a third place if he has Flash, but needs to upgrade to the latest version. The non-Flash site can be as simple as a page that provides the user a link to Macromedia, where he can download the Flash Player. The non-Flash site can also be as complex as the whole site built in HTML. The point is that the sniffer or gateway page sends the user to one of two places: the Flash site or the non-Flash site.

    Macromedia has a nice set of instructions and sample files that can help you produce a sniffer page. The Flash Deployment Kit (which you can download for free from www.macromedia.com/software/flash/download/deployment_kit/) includes a gateway page (enter.html) and scripts in both JavaScript and VBScript, as well as plenty of documentation. Although there are a lot of features, they all come down to how you use the "dispatcher." Basically, you just provide the appropriate parameters to the MM_FlashDispatch() JavaScript function. You specify the URL for where your Flash content resides (the page where users with the appropriate Flash Player automatically go), the minimum version of the Flash Player required (for example, version 6,0,23), whether you want to require the revision number (for example, 23) or just the major version number (such as 6), the alternative URL for those users who don't have Flash, the upgrade URL for those who have Flash but not the required version (this can be the same as the alternative URL), and finally, whether you want to remember (by way of a JavaScript cookie) when a user says she doesn't want to upgrade so that you don't even bother with this whole scenario the next time and instead automatically jump to the alternative URL. So really, you just specify the web addresses to which you want to send users in different situations, and you're done. As you might expect, there are more details in the documentation that comes with the Flash Deployment Kit.

    Note

    By the way, there's another nice set of scripts included in the Flash Deployment Kit called the Flash Dispatcher behaviors. It's really a set of Dreamweaver behaviors. The same dispatcher code from the Flash Deployment Kit is included in the behaviors (but made especially for Dreamweaver). A big advantage of installing the Flash Dispatcher for Dreamweaver is that the code comes in the form of a Macromedia extension. By using the free Macromedia Extension Manager program, you can easily manage various extensions (including this one). The reason I mention it is that you can make Flash extensions that are also managed through this tool. It's nice for users because they can download and install components, Flash libraries, and Dreamweaver behaviors and manage them all through the Extension Manager.

    Before we get into the main workshop, I want to mention a suitable alternative to Macromedia's set of sniffer scripts. Colin Moock has produced the Moock Flash Player Inspector (Moock FPI), which provides a similar set of alternatives to the Flash Deployment Kit. You can download the Moock FPI from www.moock.org/webdesign/flash/detection/moockfpi/.

    Because this is a workshop, we're going to step through an exercise. The following exercise assumes that your user has at least the Flash Player 2. We'll create a Flash sniffer that redirects the user if he has anything less than Flash Player 6. This exercise is based on a Flash file that comes in the Flash Deployment Kit called detectFlash.fla. We'll build our own version of this file by following these steps:

    1. In a new file, select File, Publish Settings. Under the Formats tab, make sure that Flash is selected. Select the Flash tab and select Flash 4 from the Version drop-down menu (refer to Figure W1.1) and click OK. After making this change, notice that many of the ActionScript components are highlighted in yellow, meaning that they're unavailable because you changed the Publish Settings to Flash Player 4.

    2. In frame 1, place the following script:

      atLeastFlash4 = "1";

      This script sets a variable, which will be ignored in any version of Flash lower than 4. That's because Flash 4 was the first version to introduce variables.

    3. Insert a blank keyframe in frame 2 and place the following script:

      if (Number(atLeastFlash4)==1) {   } else {     tellTarget ("flashThreeButton") {     gotoAndStop (2);    }    stop ();  }

      Basically, if the variable atLeastFlash4 is indeed 1 (as we just set it in frame 1), nothing really happens, and we'll proceed like normal to frame 3. Because versions prior to Flash Player 4 don't support if statements, this script effectively will be ignored. Actually, Flash Player 3 and earlier versions don't totally ignore if statements; they execute only the else part of the statement. Why, I don't know. What happens is that any version before Flash 4 will execute the tellTarget() and stop() methods contained in the else portion of the statement. The tellTarget() method is the old way to attach a method to an individual instance. Translated to Flash 6, the script says this.flashThreeButton.gotoAndStop(2). We'll make a clip with the instance name flashThreeButton that will jump to frame 2 for these (less than Flash 4) users. Finally, the stop() method just prevents our main timeline from going any further.

    4. Let's build the clip for users of Flash 3 (and earlier). Select Insert, New Symbol. Select Movie Clip and name it "Flash3."

    5. You should be inside the Flash3 symbol. In frame 2, insert a keyframe and draw the shape for a button. Convert the shape to a button symbol (select it, press F8, and select Button). Attach the following script to the button:

      on (release) {   getURL ("http://www.macromedia.com/shockwave/download/index.cgi?  [ccc]P1_Prod_Version=ShockwaveFlash", "_blank");}

      Notice that the web address should appear on a single line. The idea is that if the user doesn't even have Flash 4, he'll see this button, which will take him to Macromedia where he can upgrade. You may also want to center the button instance within the Flash3 symbol.

      Note

      This movie must work in Flash 3, so we can't assign a callback function to the button instance. However, because I think it's such a great way to work, we will use that technique in all the rest of the workshops.

    6. In frame 1 of the Flash3 symbol, place a stop() script. Now the clip will normally sit in frame 1 (effectively as an invisible clip) and jump to frame 2 only when the button appears. You can place more content in frame 2, such as the message, "Click the button to upgrade" (using Static text). If you want the user to automatically jump to the Macromedia site, you can take the getURL() code from the button and place it in frame 2. However, if you do this, it might be unclear to the user what is happening.

    7. Go back to the main timeline, and drag an instance of the Flash3 symbol that we just made into frame 2. (Remember, we just did a New Symbol and not a Convert to Symbol, so there's no instance on the Stage yet). Give this invisible clip an instance name of flashThreeButton.

    8. Now that we've taken care of the sub-Flash 4 users, let's see whether the user has Flash 6. Insert a blank keyframe in frame 3 and place the following script in that frame:

      playerVersion = eval("$version");  revision = substring(playerVersion, 5, 1);  if (Number(int(revision))<Number(int(6))) {   tellTarget ("lessThanSixButton") {   gotoAndStop (2);    }  } else {   getURL ("flash_six_content.html", "_self");  }  stop ();

      The first line assigns the variable playerVersion equal to the old $version variable that was introduced during the Flash 4 era. Unlike most variables, you can't just say playerVersion=$version; the dollar sign is not a legitimate way to start a variable name. The eval() function evaluates the value of the built-in $version variable. The form returned to the playerVersion variable looks like this: "WIN 6,0,23,0" (see Figure W1.2). platform major minor revision unused

      Figure W1.2. The $version variable contains five key elements.

      graphics/17fig02.gif

      The $version variable is a very specific string with information about the platform, the major version, the minor version (which is rarely if ever updated), the revision (also sometimes called the "patch" version, which is occasionally updated to provide added features and bug fixes for example, the ignoreWhite XML property was introduced in 5,0,41), and the last number (which isn't even used). What might mess you up is that we assign the variable revision using the substring() function (not the preferred and only available in Flash MX substring() method of the String object). This function behaves differently, as discussed in Chapter 9, "Manipulating Strings." The if statement in line three just checks whether an integer version of revision is less than 6. If it is, we tell the lessThanSixButton clip (that we're about to build) to go to frame 2, where the user will see a button to upgrade. Otherwise (if the version number is not less than 6), we do a getURL() to jump the user to our "real" HTML page with Flash 6 content. Just replace flash_six_content.html with the name of the HTML file that contains your Flash 6 content.

      Note

      If you ever need to use the Flash 4 substring() function to ascertain the revision number, use substring(playerVersion, 9, 2). An issue that might really freak you out is that the $version variable wasn't released with the very first version of Flash Player 4. The earliest versions of the Flash Player 4 won't recognize this variable. That's not a problem, however, because the if statement in line three will still work. Also, notice that the int() function is used to convert the version string to a number that can be used in a conditional statement. That's simply because Flash 4 didn't have the Number() function.

    9. Now let's make the lessThanSixButton clip. Just duplicate the symbol called Flash3 (and rename it Flash4), and then change any Flash3-specific text contained in the symbol. Make a new layer and drag an instance of the Flash4 symbol onto the Stage. It doesn't matter that this instance will start in frame 1; it just must be present at the time tellTarget() is called. Make sure to give the symbol an instance name of lessThanSixButton.

    10. At this point, you can export or publish the .swf.

    We have just made a Flash 4 movie that acted like a sniffer to sense for sub-Flash Player 6 users. Those folks with Flash, but not Flash 6, are redirected. Those users with Flash 6 won't notice much at all because they'll jump to the right page.

    There's one last task you may have to resolve: making sure that your Flash Player 6 users have the latest revision of the Flash Player 6. For example, you might really need to take advantage of a new feature (or lack of bug) in a later release. For example, the current release is 6,0,29,0 (6,0,21,0 in the authoring tool), but for all I know, some bug will be found in this Player and fixed in a later revision. It may be important to ensure the user has a later revision. Once you know the user has Flash 6, it's easy to check for the actual revision number (and tell the user if it's not new enough).

    You can use any of the String object methods on either the built-in $version variable (which, unlike in Flash 4, can be used as-is and doesn't require the eval() function) or the new version property of the System object (which looks like System.capabilities.version). Consider these five expressions to extract key portions of the $version variable:

    //form:  WIN 6,0,21,0  platform=$version.substr( 0, 3 );  major=$version.charAt(4);  minor=$version.charAt(6);  revision=$version.substr(8,2);  unused=$version.charAt(11);

    These String object methods should look familiar if you've read Chapter 9. Basically, I just came up with five custom variables to represent each portion of the $version variable. Most likely, you'll just need the line revision=$version.substr(8,2) to extract the revision number of the Player (because this is the portion that is updated most often). By the way, you can replace $version with System.capabilities.version in any of the preceding code.

    Personally, I'm a paranoid person. The preceding scripts are not guaranteed to work if the Flash version numbering system ever changes. For example, what if there's a Flash 10? Although most web sites created today will probably need an overhaul that far in the future, here are a couple of alternatives to parsing individual elements from the $version variable. By using the indexOf() method, we can find the location of the commas and then set our minor, revision, and unused variables:

    var startMinor=$version.indexOf(",",5)+1;  var endMinor=$version.indexOf(",",startMinor);  minor=$version.substring(startMinor,endMinor);  var startRevision=$version.indexOf(",",endMinor)+1;  var endRevision=$version.indexOf(",",startRevision);  rev=$version.substring(startRevision,endRevision);  var startUnused=endRevision+1;  var endUnused =$version.length;  unused=$version.substring(startUnused, endUnused);

    If nothing else, this example provides a good reminder of how to use the indexOf() method. Notice that all the expressions shown with the $version (string) variable return strings. You can always use the Number() function if you need to.

    Now that you're familiar with the ways to ensure that your users have the Flash Player 6, we can move on to much more fun workshop chapters! I included this workshop chapter because I really wanted to concentrate on Flash MX. All the great Flash MX movies you make will go unrecognized if you can't upgrade your users.

    CONTENTS


    ActionScripting in MacromediaR FlashT MX
    ActionScripting in MacromediaR FlashT MX
    ISBN: N/A
    EAN: N/A
    Year: 2001
    Pages: 41

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net