Posts in Category "Flash"

HTML Animation with requestAnimationFrame and Flash Professional CS6

If you’re curious about the new requestAnimationFrame API, here’s a demo along with a code walk-through:

The requestAnimationFrame API is a replacement for setTimeout and setInterval in the context of HTML animations. It has two primary advantages over timer functions:

  1. It is synchronized with the browser’s repaint loop which allows for more highly optimized animations.
  2. Since it’s specifically designed and intended to be used for animation rather than being a general purpose timer, the browser knows that it’s safe to throttle it back when the tab isn’t active. Throttling back animations means freeing up CPU cycles, and reducing unnecessary battery drain on mobile devices.

If you want to see this animation in action (and/or check out the code), it’s available here (Hint: if it’s running slowly, try making your browser window smaller). Thanks to Chris Georgenes for the “rocker girl” animation. And finally, here are the resources I used to learn about requestAnimationFrame:

Continue reading…

My Thoughts on Flash and HTML (as Expressed in an Email to “Tech News Today”)

I’m a big fan of the video and podcast Tech News Today. It’s one of the best technology shows I know of, and I seldom miss an episode. As some of you know, I sent them an email yesterday about our recent announcements around Flash and HTML, and they were kind enough to read some if it on-air. It was way too long for them to read in its entirety, so I figured I’d post the whole thing here.

As someone who has worked on the Flash Platform at Adobe for the last nine years, I just wanted to provide some additional context around yesterday’s announcement. Your coverage was very good, so no complaints, but I feel like it’s worth emphasizing a few things.

Part of Adobe’s story is enabling cross-platform solutions, but since Flash has never been supported on iOS, we weren’t able to deliver on that vision in the context of mobile browsers. With mobile browsers as good as they are now (the ICS browser looks amazing, and mobile Safari has always been awesome), it just makes more sense to use HTML.

In the context of installed applications, however, our story is stronger than ever. We recently released AIR 3 which is an extremely solid option for delivering installed applications through app stores across devices. Installed mobile applications is an area where we have been very successful delivering on our cross-platform vision, so that’s where we’re going to invest. Additionally, I think that model more closely matches the way we use our devices; I think mobile browsers are primarily used for accessing content, and the tendency is to use installed apps for more interactive content like applications and games.

Another point I want to make is in response to Sarah’s comment yesterday about Flash working better on some devices than others. That’s true. Getting Flash to work consistently across all the chipsets that we support (and with all the different drivers out there — some of which are better implemented than others) is a huge amount of work, and requires a lot of engineering resources. At some point, we had to ask ourselves if we wanted to be the kind of company that continues to use resources to pursue something we weren’t convinced made sense just because it’s what we’ve always done, or if we wanted to be more forward thinking. I think we absolutely made the right decision.

It’s also worth pointing out that we’re still investing heavily in Flash in the areas where it makes more sense like installed mobile and desktop applications, and the desktop browser. Specifically, the Stage3D APIs we introduced in AIR 3 are going to provide an in-browser gaming experience like nobody has ever seen (look for videos of Unreal running in the browser), and the new APIs for hardware accelerated video are going to mean higher quality video that uses less CPU and battery. These are areas that HTML5 has not yet fully addressed, so Flash can lead the way. We will continue to use Flash for doing things that HTML can’t, and for the things that HTML can do, we will embrace it.

That brings me to my last point: I think there’s this perception out there that Adobe dislikes HTML, and that yesterday was somehow a bitter concession. As someone inside the company, I can tell you that there are a lot of us who are very excited about what we can do with HTML5. Personally, I’ve been researching and working on HTML projects for quite some time at Adobe, and I’ve been working with a lot of very smart people who are as passionate about it as I am. There are definitely people out there (both inside Adobe and outside) who are passionate just about Flash, but I think it’s more accurate to say that the overwhelming majority of us are simply passionate about the web, and about building awesome experiences. Flash has always been about providing functionality that HTML couldn’t, however now that HTML5 can provide a lot of that functionality, we’re going to have a lot of fun seeing what we can do with it.

So in summary, look for Adobe to continue to push Flash forward in areas that HTML doesn’t yet address, to push HTML forward with contributions to WebKit and tooling, and to provide cross-platform solutions in whatever technology makes the most sense.

If you want to hear it read on-air, it’s at the 45:00 mark in the video below.

Make the mouse wheel work in Flash on OS X

As I’m sure all you Mac users are painfully aware, the mouse wheel doesn’t work in Flash on Macs. Imagine my surprise, therefore, when testing out a new Flex-based bug tracking system, and finding that I was able to use my Mighty Mouse to scroll a List. The source of the page revealed a clue which eventually led to AS3.0 MouseWheel on Mac OS X. Seems to work pretty well, and should hold us over until we get this in the player.

(Note that the mouse wheel works as expected in AIR applications; this is for browser-based apps only.)

The Many Faces of Flash

I’m at Flashforward in Seattle this week, and whenever I go to Flash conferences, I’m always amazed to see all the different ways people are using Flash. I’m mostly consumed with Flex these days, so I tend to forget about all the other places Flash is appearing. In the last day, I’ve seen Flash discussed in the following contexts:

And, of course, in the browser for just about everything you can think of. Am I missing anything?

Flash and Ajax: Happy Together

Adaptive
Path recently released their Flash/JavaScript
Date Slider
under a
Creative Commons License.  It’s a very slick component that
they use with Measure
Map
for visually selecting date ranges, and which
shows excellent interoperability between Flash and JavaScript. It uses
the JavaScript /
Flash Integration Kit
as the bridge between Flash and
JavaScript, and I think integrates very nicely into HTML/Ajax
applications. From the Date Slider site:

The date slider is a Flash visualization that Measure
Map
uses as one way to navigate the site. We are happy to provide a version
of this date slider to the public… SWF version with the
ability to customize the look & feel of the slider as well as
the location and name of
the XML file.

What I really find interesting about this project is that it
is a standalone component which integrates Flash and Ajax very
seamlessly, and therefore tends to blur the line between the two
technologies. Too often I read about the “Flash vs Ajax”
debate when the reality is that Flash is very Ajax friendly, especially
with the new ExternalInterface
object
.

See
it in action.

del.icio.us uses Flash

I’m a big del.icio.us user, but I learned something about them yesterday I didn’t know. During a conversation with Andre Charland, he mentioned that del.icio.us is using Flash to play MP3s. Check out my podcast tag to see what I mean. Whenever you tag an MP3, a little play arrow appears to the left of the title. Click it, and a piece of Flash is dynamically loaded to play the MP3. Simple, but slick.

Are You Using the Flash / JavaScript Integration Kit?

If you have a publicly accessible example, please post it here, send me an email, or if you’re on the Integration Kit mailing list, post it there. I’d love to see all the creative applications people have come up with. Thanks!

Changes to the Flash / JavaScript Integration Kit

Over the last couple of days, we’ve made several changes to the Flash / JavaScript Integration Kit. If you are using the Integration Kit, or if you’re interested in using it, I strongly recommend grabbing the latest code out of Subversion.

Here is a list of the changes we’ve been working on:

  1. The Integration Kit now uses FSCommand to go from Flash to JavaScript on Internet Explorer on Windows. Using getURL causes several issues on IE, and we found that FSCommand works much better in that environment. You will no longer get that odd clicking sound that IE likes to make when you click on a link, and the kit will no longer cause open sockets (images in the process of loading, XMLHttpRequest sockets, etc) to be prematurely closed.
  2. We added the ability to handle multiple consecutive calls from JavaScript to Flash. Before, if you tried to make multiple consecutive calls, typically just the last one would succeed. Now, not only can you make as many calls as you want, but all the calls are guaranteed to happen in the correct order. (Basically we added a queuing mechanism to the JavaScript.)
  3. We added an optional scope argument to the FlashProxy. This allows you to specify the JavaScript scope (object instance) that you want to call functions on from Flash. This argument is entirely optional, and leaving it out will result in the kit working just as it did before (calling functions within the document scope).
  4. We fixed a bug that was breaking function calls from Flash to JavaScript when passing strings with single quotes in them.
  5. We added support for Opera 8.0 and higher (at least that’s what we tested on — it might work with earlier versions) on both Mac and Windows.

There is one additional issue with respect to getURL and FSCommand I need to explain. If your Flash content is compiled for Flash Player 7 or higher, the Integration Kit will automatically use FSCommand where appropriate and getURL everywhere else. This is definitely the recommend usage. If your content is compiled for Flash Player 6, getURL will be used universally. That doesn’t mean it won’t work in IE on Windows, but it doesn’t work nearly as smoothly as FSCommand. The bottom line is that if you can compile for Flash Player 7 (which now has more than 90% penetration), you should do so.

We have not done another official release of the Integration Kit with all these changes yet. Right now, the official release is pretty old code with lots of issues, so we definitely recommend using the newest code from Subversion. We hope to do another official release of both the code and documentation very soon (maybe next week).

Let me know if you discover any issues so we can get them fixed before the next official release.

Future Proofing Your Flash Content

Now that Flash Player 8 is in public beta, if you’re a tester, you are going to start noticing something annoying. As you surf the web, dutifully fulfilling your responsibilities as a public Flash Player beta tester, you will occasionally come across a site which will tell you don’t have the right version of the Flash Player installed, and in some cases, you may even be told that you don’t have a new enough version of the Flash Player installed. Naturally, you will be confused because your Flash Player version is, in fact, the newest of the new, and is nothing short of bleeding-edge Flash Player technology. The problem is that the site’s Flash Player detection scripts are most likely hard-coded for what was once the newest version of the Flash Player.

If this describes your site, check out Mike William’s article on the Macromedia Developer Center entitled Future-Proofing Flash Player Detection Scripts. Mike not only discusses the issue of expiring detection kits, but also provides a new, very robust detection solution that fixes the future-proofing problem and other common version detection mistakes.

Using JavaScript to Render Flash Tags

The first time I embedded a piece of Flash into a ColdFusion application, I wrote a ColdFusion custom tag to render the Flash tag for me. Yesterday, I wrote a JavaScript class that essentially does the same thing, but renders the Flash tag client-side rather than generating it on the server. Why encapsulate the process of writing out a Flash tag?

  1. Flash tags are complicated. They have a lot of different options. The FlashTag class supports 17 different properties. You can set the ones you need (only four are required), and defaults are used for the rest. Also, the FlashTag JavaScript class validates the information you set on it to make sure all the values are supported (if not, it throws exceptions).
  2. Flash vars can be a pain. Flash vars are passed into Flash movies at load-time, and have to be formatted as a URL encoded string. The FlashTag makes setting Flash vars much easier (see code below).
  3. Encapsulation is good. What if you wanted to change something across all your Flash tags? Wouldn’t it be better to change it one place?

Here’s some sample code. First, load the required classes like this:

<script type="text/javascript" src="/path/to/Exception.js"></script>
<script type="text/javascript" src="/path/to/FlashTag.js"></script>

The Exception class is required so that the FlashTag class can throw exceptions if something goes wrong. Now, create an instance of the FlashTag and write it out:

<script type="text/javascript">
// The arguments below are path, width, height, and Flash Player version number.
var tag = new FlashTag('/path/to/flashContent.swf', 300, 300, '7,0,14,0');
tag.write(document);
// or
document.write(tag.toString());
</script>

You can set properties like this:

tag.setBgcolor('ff0000');
tag.setMenu(false);

You can add Flash vars like this…

tag.addFlashVar('someName', 'some value');

… or like this…

tag.addFlashVars('a=b&b=c&a=c');

Why use JavaScript rather than rending Flash tags server-side? JavaScript runs everywhere whereas ColdFusion only runs on a ColdFusion server which makes the JavaScript solution more versatile. Also, using JavaScript allows you to render Flash dynamically and on demand, after the page has loaded, which is becoming more relevant as internet applications become richer and more interactive.

I wrote the FlashTag JavaScript class as part of the Flash / JavaScript Integration Kit. You can grab the source from Subversion here:

I tested it fairly well, but if you find a bug, let me know and I’ll get it fixed right away.

Update: As “sang” points out in the comments, this is also a good way to keep your pages W3C/XHTML compliant.