Category Archives: javascript

Using Flash Player Express Install with FlashObject

Posted on by

Please note that the newest version of FlashObject (1.3) changes how ExpressInstall is invoked when using FlashObject. Check out the FlashObject page for examples of using ExpressInsatll.

I’ve just updated FlashObject (now version 1.2.3) to support the new Macromedia Flash Player Express Install.

Macromedia recently introduced a new feature of the Flash Player called “Express Install.” This new method of upgrading offers a few very nice benefits:

  • No need to redirect your users to Macromedia.com to upgrade their player.
  • No need to rely on built in browser upgrade mechanisms. Internet Explorer users have become more and more wary of trusting the ActiveX install dialog box that pops up all the time and is generally associated with spyware or malware. While Firefox has an excellent plugin finder, other browsers that use the Netscape plugin architecture aren’t so fancy.
  • Nearly full control over the upgrade experience, which means no matter what platform your users are running, you will be able to walk them through a nearly identical install proccess.

Because of these benefits, Express Install is now my recommended upgrade method. When used in conjunction with FlashObject, it offers the best possible user experience for your users who need to upgrade their Flash player.

Here’s how it works:

First, add Express Install support to each of the swf files that may require an upgrade. These files need to be at least 215px x 138px in size. This is so the entire upgrade dialog can be seen by the user if the Express Install is triggered. It may also be a good idea to only place one swf with Express Install functionality on each page. This way users won’t be greeted with multiple upgrade dialog boxes and be forced to choose one (keep it simple for your users!).

I’ve included a new AS2.0 class in the latest version of the FlashObject script called ExpressInstall.as – this class contains all the code needed to invoke the Express Install process. All you need to do is place the script somewhere in your Flash class path, and place this code on the first frame of your swf:

if (ExpressInstall.init()) {
    stop();
}

The ExpressInstall.init() function returns true or false depending on whether the Express Install was started. If it starts, it returns true, if it doesn’t start, it returns false.

All other functionality should be moved to at least the second frame of the swf. This ensures that even someone running Flash player 6.0.65 can view the first frame of the movie and will see the upgrade dialog.

Next, you’ll need to upgrade your FlashObject script from 1.2.2 to 1.2.3 (you can get FlashObject here) and alter the embed code slightly only for the swf files that contain the Express Install code.

The new embed code should look like this (view example page):

var fo = new FlashObject("myswf.swf", "myswf", "400", "300", "8.0.22", "#fffff", true);

The only thing that changes is one more parameter after the color set to true. This does three things:

  1. Tells the FlashObject script that you want to allow for ExpressInstall. The script then gathers the needed information and passes that information into your Flash movie using flashvars.
  2. Checks to make sure the user has at least Flash player version 6.0.65 installed – this is the lowest version that supports the Express Install process.
  3. Then, if the user has at least version 6.0.65, but also has a version less than the required version specified in the FlashObject embed (in this example it was “8.0.22”), the Express Install process is started.

Once the install is completed, the installer launches a new browser window, and the user is redirected back to your original page with the new plugin.

And that’s it. You can grab the newest version of FlashObject with the ExpressInstall class here: http://blog.deconcept.com/flashobject/ or you can view an example page that uses this method.

UPDATE (08-18-2005): Macromedia recently updated the Express Install feature, and because of this, my ExpressInstall class was broken. I’ve just fixed it, however, and you can get the latest version by downloading the latest version of FlashObject here.

UPDATE (08-29-2005): If you are not using Actionscript 2, or are exporting your classes on a frame after frame 1, you can use this adaptation of my ExpressInstall class that Carlos Rovira wrote.

UPDATE (12-22-2005): If you are using ExpressInstall on your site, go tell Macromedia what you think about it.

The AJAX danger that never was

Posted on by

I can’t believe how much hype this article is generating. From the article:

Like so many technologies-gone-bad before it, this technology was created for the purpose of good. And until now, the XMLHttpRequest has been so good it could almost be considered saintly, providing users and developers alike with such conveniences as input validation without post-back, text area spell checkers, and Gmail. Interfaces built with AJAX are fun to use and even more fun to program. It’s almost hard to imagine that such a miraculous object could ever do wrong.

But even without the discovery of a giant security hole, the XMLHttpRequest will likely fall from grace. Its fall will be in the form of “user over-profiling” for want of a better description. Currently, user profiling helps Web site owners detect trends, track page viewing habits and iron out usability problems. Until now though, developers could only analyze posted data—data that users decided they wanted the server to get, and were happy to send off for processing.

This is just ridiculous. Not only is it dead wrong technically, it makes assumptions that just because a technology is gaining recent popularity, the potential is there for security flaws to appear.

Let’s take a look at this claim from the article: Until now though, developers could only analyze posted data—data that users decided they wanted the server to get, and were happy to send off for processing.

Let me share some information with you: The internet is not private. Ever since the first day you opened a web browser and started visiting websites you have been tracked. This is no secret, everyone knows about cookies and how websites use them to store data. Recently there have even been reports of people realizing that they might not need cookies and starting to regularly delete them.

You don’t need to submit any forms for them to track you. You don’t even need AJAX or even Javascript. You merely need to visit their website with a web browser that accepts cookies or images. Nearly every browser does this by default and behind the scenes so you never know it’s happening. Advertising companies are tracking the ads you view, remembering which ones you click on so they can target you with ads they think you will click more. Websites you visit are tracking your movement through their site to see which pages you view most, and which pages you miss. They’ll be analyzing this data in their board rooms and asking questions about how to make you stay longer and click more ads.

AJAX brings nothing new to the table. Even in a browser that doesn’t support XMLHttpRequest, I can track your movements and clicks and any information you put into forms (yes, even before you submit that form). All you need is some very simple Javascript and a server side language to catch the input. This can be done easily in Netscape Navigator 3.

When you use the internet, you are giving up parts of your privacy. When you enter information into a website you are trusting that website with whatever information you give it. This is how the internet works, and how it will work for years to come (if not forever). Either get used to it, or it’s time for you to get a bigger tin foil hat.

Anyway, back to my original point: The article is simply uninformed whining, and I’m very surprised any technical website would publish such a hyped up piece of crap. They may as well have written an article on the ‘Dangers of cookies’ and published that instead. I’m even more surprised at the amount of attention it’s getting.

The new Macromedia Flash Player detection kit

Posted on by

With the announcement of Flash 8 today, Macromedia also quietly pushed out their new detection kit. The detection kit has has been around for the last few versions of Flash, and usually changes with each version to include whatever the latest trends in Flash detection are.

It’s no wonder then, that the latest version uses Javascript as the suggested detection method. Unfortuntely, it’s not perfect. While it’s a good first try, it is greatly lacking in a few basic needs of most web developers. Here’s the issues I have with it:

  • Inline Javascript code (and lots of it) – Who wants to copy a bunch of Javascript and VBscript onto every single page that uses Flash? While it might be possible to move the Javascript into an external file, you would still have a small amount of VBScript on each page (or another external file to include). I’m not sure why they decided to leave in the VBScript when there are other reliable ways to create and test for ActiveX objects. Also: what happens if you need to upgrade the Javascript for some reason? While the code should be very futureproof, you never know when a bug might pop up, and you’ll be stuck editing all of your HTML files that have Flash movies included in them.
  • Tough to modify the code – It suffers from the same drawbacks as most Javascript embed techniques – placing tons of Javascript document.write() calls and writing out your object or embed tags to the page. This is a hassle to edit if you need to make changes, and makes it very tough for designers who don’t know Javascript to go in and modify attributes.
  • It’s not valid HTML or XHTML – Valid XHTML documents aren’t for everyone, but when you have clients specifically asking for them it’s nice to be able to deliver. The new detection doesn’t even come close to validating.

If you want to compare the new Macromedia detection to my FlashObject script, check out this new article that shows how to use it:

Best Practices for Flash Player Detection

Then compare the steps needed to get that working with using FlashObject:

  1. Include single .js file.
  2. Add a few lines of code (see example of bare minimum).
  3. Sit back, relax.

I think the choice is clear.

Now when you downloaded the new detection kit you may have noticed another folder hiding out in there with the name of “Express Installation.” This is Macrmedia’s new way of upgrading your Flash player without the need to go to macromedia and download the new plugin. I’ll be writing up a new entry soon that gives some tips and best practices on using this method in the very near future.

Safari’s hidden debug menu

Posted on by

Trouble debugging your Javascript in Safari? Me too! That’s why I found this little tip useful (notice I say ‘useful’ and not ‘very useful’).

Safari is usually a very large pain when building Javascript apps. There are many small issues that seem to pop up all the time. But now with the release of Safari 2.0, you have a bit of help. Safari now has a Javascript console! It’s nothing fancy, and the errors it shows are sometimes less than optimal, but it’s far better than just guessing randomly at the problem.

To enable the Javascript console, first you must enable Safari’s debug menu. Do this by opening your Terminal and inputting this line:

defaults write com.apple.Safari IncludeDebugMenu 1

Now the next time you start Safari, you’ll have an extra menu up top called “Debug” and inside are all kinds of goodies. Here’s what the menu looks like:

Safari debug menu

Back to the original point of this post, one of the items is “Show JavaScript Console” and selecting that item opens up this little window:

Safari Javascript Console

It’s not nearly as sleek and useful as the Firefox/Mozilla Javascript console, but it’s a step in the right direction, and definitely better than nothing.