Scott Schiller has updated his popular SoundManager 2 library to include new functionality made possible by Flash 9, such as:
* Full-screen MPEG-4 video (HE-AAC/H.264) and audio support
* “MultiShot” play (layered/chorusing effects)
* Waveform/frequency spectrum data
* Peak (L/R channel volume) data
* Audio buffering state/event handling
In addition, SoundManager 2 now includes improved console.log()-style debugging, a troubleshooting/help tool, and the project website sports redesigned documentation, updated API demos, and more examples.
One of those examples is a “360° UI” sound visualization; this is the screenshot at the head of the post. The website features plenty of other demos, including full-screen video playback, etc.
This obviously takes SoundManager to a whole new level and is very exciting stuff.
SimpleGesture is a GWT (and IT Mill Toolkit) implementation of the mouse gesture recognition method described by Didier Brun at bytearray.org (as I understand it). It allows you to register easy to understand (human readable) gestures, and receive events when these occur. Additionally, SimpleGesture can record new gestures, so that you don’t have to write them by hand.
In this video demo, he’s using a Wii to show it off (this confused me at first, but he’s using the Wii as a mouse and isn’t doing anything with the Wii-specific inputs):
SimpleGesture relies on a bit of Flash to do its thing:
I have used the bytearray mouse gesture library for a Flash project before, and I love how simple the method is, and yet it works very well.
The method works by assigning a number depending on which direction the mouse moves in (moving right will produce “0″, moving down will produce “2″, and so on), and comparing the resulting string of numbers to the registered gestures. The gesture with the lowest Levenshtein distance (and below a set threshold), is considered a match.
There is an interesting blog post* and demo code on Azarask explaining Flash Canvas as a solution for IE’s lack of support for Canvas:
How does FlashCanvas work?
FlashCanvas is modeled after ExplorerCanvas which means it is a turn-key solution for adding Canvas support to IE. You can code away, happily using open standards and then use FlashCanvas to forcefully and silently upgrade IE to also being standards compliant.
There are two main components in FlashCanvas: the base FlashCanvas.swf flash file (a mere 688 bytes), and the FlashCanvas.js wrapper. I’ve used the excellent swfobject.js to embed the Flash into the page.
The FlashCanvas.js file implements a fake-canvas object and converts all existing canvas element into a flash object. The javascript intercepts canvas commands and forwards them to the FlashCanvas.swf movie file using the ExternalInterface provided by the flash player. The flash movie clip then interprets the command and draws accordingly.
Aza originally thought that this would also solve the performance problems other fallbacks to VML have but found out that sadly enough this is not the case because of the lag between ActionScript and JavaScript via ExternalInterface.
Each call via the ExternalInterface is taking approximately 0.5 ms. Since we know the time it takes to call an actionscript method from javascript, we can deduce the amount of time it takes for Flash to render. For the example1.htm page it takes ~24 ms to render 20 anti-aliased lines. In Safari a call into actionscript takes roughly 0.4 ms — this is only the call time, it doesn’t include the time to render anything. For example1.htm a single “particle” calls actionscript 3 times with the commands: [lineStyle,moveTo,lineTo]; each particle takes 1.2 ms in JS-to-AS calls; to take 1 second to render the frame ~833 particles need to be rendered.
There are few more ideas in the comments to the article and this might be an interesting concept to take further. Somehow it seems ironic to go back to Flash to make IE render standards, but then again VML is proprietary, too.
* Hat tip to Scott Schiller for pointing out this older, but somehow forgotten post.
An interesting and also slightly creepy approach to the problem is the JavaScript library Zero Clipboard:
The Zero Clipboard library provides an easy way to copy text to the clipboard using an invisible Adobe Flash movie, and a JavaScript interface. The “Zero” signifies that the library is invisible and the user interface is left entirely up to you.
This library is fully compatible with Flash Player 10, which requires that the clipboard copy operation be initiated by a user click event inside the Flash movie. This is achieved by automatically floating the invisible movie on top of a DOM element of your choice. Standard mouse events are even propagated out to your DOM element, so you can still have rollover and mouse down effects.
I don’t know about you, but somehow “copy to clipboard” buttons seem a bit redundant to me and by keeping this functionality working cause more security holes than usability benefits.
As it is Adobe MAX this week, there is a lot of talk about the Flash platform. How does this relate to the Open Web? Well, it turns out that Dion and I have been discussing how Flash can join and become a part of the Open Web.
Adobe (via Macromedia) has traditionally been a Web designer company, but developers haven’t jumped in to the same degree (note: not to say they haven’t been wildly successful!). I think that the perception is something like this:
Dion discusses how Adobe has an opportunity to position themselves relative to Silverlight much more strongly in the Open Web camp:
With Silverlight making a huge charge I worry about a world where you have “Best viewed in Silverlight and IE” (which in fact is “only viewed in…”) and people often ask: “But isn’t Flash just as bad?”
Adobe has an opportunity here. They can move to the right and Flash could become strongly in the Open Web camp. Then we would all be stronger as we come up against Silverlight :)
The next logical question related to this is open sourcing Flash:
The conversation tends to end up with opensourcing Flash, which I think will happen at some point through necessity, and the sooner the better (for everyones sake). Flex has a loyal base and has some open source help, but hasn’t gotten the love that it could get because it sits on top of something that isn’t open source itself. It is hard to get excited about an open source tech that sits on top of the same vendors proprietary platform!
I agree with Dion that open sourcing Flash and having it join the Open Web camp is a very compelling idea. Open source would just be the first step, though, so following up on Dion’s post I put together an editorial titled “How Flash Can Integrate With The Open Web”:
As Dion points out open sourcing Flash is one big part of making this happen, but another huge aspect would be to have Flash and Flex integrate better into the web stack and be less of a ‘black box’ on the screen…The important point is to integrate Flash and Flex more deeply into how the Open Web works:
Cross-Platform Standards
No Vendor Lock-in
Anyone Can Innovate
Powerful, Universal Clients
Open Source Implementations
Mashable, Searchable, and Integrated
I give a list of suggested ways to do this; the important thing is to have Flash integrate more deeply — these are just some suggestions to kick things off. Here are some of them; click on them to read more in-depth how this might work:
At the end of the day Adobe is a tools company, a really damn good tools company actually. Doing the above should allow Adobe to continue creating powerful tools that help authors and content creators while expanding the size of the market they can target.
The above list was just a suggestion to kick things off. The real focus is on having Flash integrate into the web stack better itself (and evolving both Flash and the web stack themselves into the future).
Right now you can use Flash to work around a lot of JavaScript limitations and many products use an invisible Flash movie to for example batch upload files (Flickr, Wordpress), play movies in a screenreader accessible manner (with DHTML controls outside the main movie - Yahoo Video, for example) or automatically add content to the browser clipboard (snipurl.com).
All of these will cease to work without user interaction in flash as reported on the adobe devnet. There are very good reasons for it as explained by Lee Brimelow but it is a real problem that will cease to make Flash a useful tool to patch inaccessible solutions.
As long as you cannot access a Flash movie in non-Internet Explorer browsers via keyboard, there will be no such thing as an accessible flash page. Research findings presented at Scripting Enabled last week showed that for example many screen reader users skip Flash as soon as they hear that there is a movie on the page, regardless of how much effort you put in to make the movie itself keyboard enabled. DHTML controls worked around that issue - a button that cannot be accessed is very secure, but also pointless.
The Dojo Toolkit now has support for multi-file uploads, thanks to the new Deft project. The dojox.form.FileUploader class embeds a hidden SWF file in the page which, when triggered, will open a system dialog that supports multiple file selection, and also file masks, which allows the user to filter their selection by file type.
Better yet, it’s fully degradable. If the user does not have version 9 or greater of the Flash Player installed it can, depending on the options you set, present the user with a standard HTML file input instead (or the option to install the latest Flash Player). The HTML form also supports multiple files, although due to browser restrictions, only one can be selected at a time. But they are all uploaded at once.
A major benefit to developers is the flexibility to supply your own styled upload button. For example, a paperclip icon toolbar button in an email application should not look like the standard file input with a text field followed by a “browse …” button. What inspired this design was working on projects where designers and clients would hand me a specification which would say, “the upload button looks like this“.
Tom Trenka of SitePen has created a new top-level Dojo package called Deft which "focuses on ActionScript components created in support of the various projects within the Dojo Toolkit (mostly for DojoX). Deft source files are well organized based in part on the organization of other Dojo Toolkit projects, as well as the package structure required by the Flex compiler. Most Flex applications are based on the Flex AS3 Application class, which forces you to write at least one “controlling” MXML file in order compile your code. Instead of this, Deft components inherit primarily from the Sprite class — which allows you to write pure ActionScript code."
It contains a few goodies in it including the multi-image uploader, and pre-alpha quality support for dojox.gfx. Future plans include support for audio and video. "Hopefully Adobe will continue its current path towards being open source friendly, helping Deft flourish."
The article goes into detail on downloading the Flex SDK so you can build applications with it.
This is an interesting experiment in the melding of Flash and Ajax techniques. I would love to see the Flash player giving us more access via simple JavaScript, so we don't even need to create SWF bridges.
Kyle Simpson has announced a new family of opensource projects called flensed and the first project being flXHR which "utilizes javascript+flash to create a complete, literal drop-in replacement (by being API identical) for the native browser XHR (Ajax) communication mechanism. However, flXHR uses Flash Player's security model to enable direct cross-domain communication, and also has a number of other very helpful extensions."
http://flxhr.flensed.com/code/tests/flxhr-4.html
There are a number of demos which illustrate how it easy it is to take the API-compatible flXHR and swap it to any of your favorite JS frameworks (Dojo, Prototype, YUI, ExtJS, etc) in place of its usage of native XHR... once the simple adapt/swap happens, everything else about the framework library communication works the same, because flXHR speaks the same familiar protocol and API, and so it really is what I like to call "set it and forget it" good.
Hasn't this been done before?
There have been several other attempts at similar things before, including SWFHttpRequest, FlashXMLHttpRequest, Fjax, and F4A. However, all those fell short of the mark in different ways. On my site, there are comparison charts and detailed FAQ's which show how flXHR stands up to these predecessors, and exceeds them in very important and powerful ways. I believe flXHR has accomplished its goal, which was to be *the* complete solution for SWF-based Ajax calls as an identical API-compatible drop-in replacement for native XHR, not to mention many helpful improvements including robust error callback handling, timeouts, and convenience configuration functions, to name a few.
Ever since Macromedia and Adobe merged, we have been waiting for a day where PDF and Flash played really nice together, and today is the day. Very symbolic for the folks from the companies before the merge.
As TechCrunch says:
At the same time Adobe is launching Acrobat.com, it is releasing Acrobat 9—a major upgrade to one of its anchor desktop apps. the big news here is that for the first time, Adobe’s PDF-creating desktop software will supports Flash. So people can now create documents with embedded Flash movies from YouTube, or developers can design entire new skins for electronic documents using Adobe’s Flex framework—the same programming tool they use to create Web applications.
PDF documents made with Acrobat 9 also support collaboration among multiple authors and reviewers over the Internet, making them connected documents. Best of all, they no longer take forever to load. The next step is for Adobe to make it easy to turn any PDF into a Web page, and vice versa.
This is the biggest news for me. Acrobat.com itself is a very nice integration of Buzzword, ConnectNow, PDF, and Share. It feels quite snappy (despite the "loading..."), and there are a lot of nice animations of course. A good showcase for Flex.
Harald Kirschner has created a new version of FancyUpload "a file-input replacement which features an unobtrusive, multiple-file selection menu and queued upload with an animated progress bar."
The launch of Adobe Photoshop Express has been much anticipated. We are seeing the move of a large software company going from desktop to Web for a major application.
I am a big fan of Picnik and for awhile was using it quite regularly, so I wanted to see how they compared.
It seems like Photoshop Express is pretty limited and seems very much focused on taking images, putting them online, and doing little touch-ups. One of the things that I am always doing is taking a picture and adding text and shapes to it, and this isn't available, so I kinda don't know when I would use this other than for simple cropping and resizing.
The interface is sleek and Flash-y but somehow doesn't feel as nice as Picnik to me.... I don't know why.
Alistair told us about the application, and some of the fun features:
The initial version was a bit boring looking so I thought it would be nice to pull the 'favicons' for the sites returned in the results. I have detailed how I did this here
Because I could not fetch the icons directly using HTTPService I have used a cgi proxy script written in Python to fetch the target icons and convert them into a Base64 encoded string before returning the data to the Flex application.
The Flex application decodes the Base64 and then passes the data to a modifed version of the IconLoader class from the flexlib library.
The modifications to flexlib took the form of adding in support for 8bpp and 24bpp images.
The graph is implemented using the flexvizgraphlib visualisation component from here:
The application also uses a novel IFrame component which lets you
embed html pages directly into your Flex application.
Brad Neuberg, a partner of crime on the Gears team, has released an update to Dojo Storage that has it cooking with gas on the new Dojo 1.x codebase:
Dojo Storage makes it possible to store large amounts of data (hundreds or megabytes of K) on the client-side, way beyond the 4K limit of cookies. Developers are given a simple key/value storage abstraction, similar to a hash table. What makes Dojo Storage unique is that it automatically determines the best way to achieve this. If Google Gears, a small open-source plug-in that teaches current browsers new tricks, is present then this will be used for storage; if the browser supports HTML 5 DOM Storage, such as Firefox 2, then this is used; and finally, if none of the others are available, then a hidden Flash applet is used to store the data permanently. There are even Adobe AIR storage providers (thanks to SitePen and Adobe) if you are running in an AIR environment!
Dojo Storage has been around for a few years. However, when Dojo made the big move to the Dojo 1.0 architecture, the Flash and HTML 5 storage providers broke; plus, new versions of Flash and new browsers made the old design inefficient. I have seriously re-factored the Flash storage system to be much faster and simpler and fixed bugs in the HTML 5 and Gears storage systems. There is now a new storage.js profile build that you can grab and include in your page to easily use Dojo Storage with the three main browser storage providers: Gears, HTML 5, and Flash. The new Dojo Storage will come out as part of the Dojo 1.1 release coming soon.
I've created a screen cast demoing the different storage providers in action:
Expanding on the project, Ted Patrick, Adobe technical evangelist, said the technology would allow for cross-compiling existing code from C, C++, Java, Python, and Ruby to ActionScript. This would enable components written in those languages to be integrated into a larger project, Patrick said. "That code becomes perfectly portable into our application platform," he said.
For example, an alternative PDF renderer providing a lighter version of PDF could be cross-compiled, and the Flash Player could read it and display PDFs.
"Right now, everything has to be written in ActionScript or our lower level byte code languages," said Patrick.
In Flash Player, everything has to compile down to SWF byte code, Patrick said. The byte code language inside SWF is called ActionScript byte code.
Of course, this has been talked aboutquite some time ago. As Tamarin grows up and becomes a solid VM, we are likely to see the polyglot come to being in full force.
, JavaScript
