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.
, Adobe
