Flex SDK 4.1, Flash Builder 4.0.1, and “Hero”

Lots of interesting news this morning…
There are new updates for Flex SDK and Flash Builder , which include native support for Flash Player 10.1 and AIR 2.0, layout mirroring, Omniture SiteCatalyst extension for Flash Builder, and other enhancements.
Also, the next release of the Flex SDK, code-named Hero, has been officially announced. “Hero” will be built on [...]

Flex SDK 4 and Flash Builder 4 Updates Now Available!

The Flex team is very excited to announce the release of Flex SDK 4.1 and Flash Builder 4.0.1 which are available for download today! Flex SDK 4.1 is an update to Flex 4 and includes:

  • Support for mirroring layouts and text in order to support right-to-left- locales. The goal of this new feature is to trivialize the work involved to re-purpose Flex applications designed for left-to-right locales for deployment in right-to-left locales.
  • Native support for Flash Player 10.1 and AIR 2.
  • Critical bugfixes and enhancement requests.

To support this new SDK, Flash Builder has shipped an update which lets developers target Flex SDK 4.1 (as well as support applications that target AIR 2). Additionally, the Flash Builder 4.0.1 update contains critical bugfixes. You can grab the Flash Builder 4.0.1 updater here.

Finally, be sure to check out newly shared information about the next release of the Flex SDK (code-named: Hero)!

Sincerely,

Deepa Subramaniam & Andrew Shorten
Flex SDK & Flash Builder Product Managers

Flex SDK 4 and Flash Builder 4 Updates Now Available!

The Flex team is very excited to announce the release of Flex SDK 4.1 and Flash Builder 4.0.1 which are available for download today! Flex SDK 4.1 is an update to Flex 4 and includes:

  • Support for mirroring layouts and text in order to support right-to-left- locales. The goal of this new feature is to trivialize the work involved to re-purpose Flex applications designed for left-to-right locales for deployment in right-to-left locales.
  • Native support for Flash Player 10.1 and AIR 2.
  • Critical bugfixes and enhancement requests.

To support this new SDK, Flash Builder has shipped an update which lets developers target Flex SDK 4.1 (as well as support applications that target AIR 2). Additionally, the Flash Builder 4.0.1 update contains critical bugfixes. You can grab the Flash Builder 4.0.1 updater here.

Finally, be sure to check out newly shared information about the next release of the Flex SDK (code-named: Hero)!

Sincerely,

Deepa Subramaniam & Andrew Shorten
Flex SDK & Flash Builder Product Managers

Introducing the MultiDraggable Touch API

Updates: I changed the name of the post as technically this is not a gesture API. It is a way to achieve gesture-like effects using touch data. Also the code below was missing an important line. You have to set the input mode to touch point in order for any of this to work.

As part of my multi-touch session at Flashbelt I introduced a new API for getting true multi-touch gestures in Flash. Windows 7 has a pretty big limitation when it comes to gestures as it is only capable of doing one at a time. Since Flash listens for these native events, we also get that limitation when doing multi-touch in Flash.

Tim Kukulski, who is a member of the Adobe XD team, has written a great set of classes that listens for raw touch events instead of the built-in gestures. The main class, called MultiDraggable, does all of the work for you and allows you to quickly add zoom, rotate, and drag gesture effects to any DisplayObject. See the video below for an example.

The code needed to implement the gesture effects is extremely simple. Below is a code snippet of how to do it. You simply add your DisplayObject to the display list of a MultiDraggable instance. Then add the MultiDraggable instance to the main display list.

1
2
3
4
5
6
7
8
9
10
import xd.parts.MultiDraggable;

Multitouch.inputMode = MultitouchInputMode.TOUCH_POINT;

// box is a MovieClip in the library
var b:MovieClip = new box();

var dragme:MultiDraggable = new MultiDraggable();
dragme.addChild(b);
addChild(dragme);

Big thanks to Tim for releasing this code. Photos and artwork in the video are from Ralph and Mario. Go ahead and download the files and have fun spawning multiple gestures!

Lee

Introducing the MultiDraggable Gesture API

As part of my multi-touch session at Flashbelt I introduced a new API for getting true multi-touch gestures in Flash. Windows 7 has a pretty big limitation when it comes to gestures as it is only capable of doing one at a time. Since Flash listens for these native events, we also get that limitation when doing multi-touch in Flash.

Tim Kukulski, who is a member of the Adobe XD team, has written a great set of classes that listens for raw touch events instead of the built-in gestures. The main class, called MultiDraggable, does all of the work for you and allows you to quickly add zoom, rotate, and drag gestures to any DisplayObject. See the video below for an example.

The code needed to implement the gesture effects is extremely simple. Below is a code snippet of how to do it. You simply add your DisplayObject to the display list of a MultiDraggable instance. Then add the MultiDraggable instance to the main display list.

1
2
3
4
5
6
7
8
import xd.parts.MultiDraggable;

// box is a MovieClip in the library
var b:MovieClip = new box();

var dragme:MultiDraggable = new MultiDraggable();
dragme.addChild(b);
addChild(dragme);

Big thanks to Tim for releasing this code. Photos and artwork in the video are from Ralph and Mario. Go ahead and download the files and have fun spawning multiple gestures!

Lee

“Build an app in a Week” online seminars starts today

Over the next 4 days the European Flash Platform Evangelism team will be delivering a series of online seminars demonstrating how to create a multiscreen application from design to deployment using the latest Flash Platform technologies and tools.
The schedule is the following:

June 7th – 12:00 – 13:00 GMT Erase the Designer to Developer gap: Adding [...]

Thoughts On Apple’s HTML5 Demos

I had heard through the grapevine that Apple would be posting a set of HTML5 demos today. To be honest I was kind of looking forward to seeing some cool stuff. Instead they have presented a set of basic demos that have very little to do with HTML5 or web standards. On top of that they have implemented a browser-detection scheme that is quite deceptive to say the least.

The image below was circulated on Twitter and it shows that on Apple’s demo page you are unable to view the examples using Google Chrome, Opera, Firefox or any other browser and are instead asked to download and install Safari in order to see the demos. That is quite odd seeing as though Chrome has much better support for the future HTML5 standard according to the site html5test.com.

In an ironic and funny side note, the browser sniffing was apparently blocking people from viewing the demos on their iPhone, although I can’t confirm that. The performance of the demos on the iPhone may have something to do with that, as most of the demos crawled on my 3GS.

If you go to the developer section of Apple’s website you can view the demos using Chrome and are not directed to download Safari. So on to the demos themselves. I made a joke on Twitter about how these were equivalent to things created in Flash 8, but to be honest that is being kind. A photo slideshow and 360° PNG sequence are more like Flash 5. The reality is that HTML5 is capable of much more than that so it is odd that they considered these to be a good showcase of what is possible. Apple should really consider hiring some Flash developers to create some badass HTML5 demos. Many in the community have been dabbling in it and have created much more impressive demos than these.

Other browser manufacturers have rightfully jumped up to dispute Apple’s questionable browser-sniffing policy. Opera’s Haavard Moen blogged that

“when the page doesn’t work in Opera or other browsers it isn’t because these browsers don’t support HTML5. It’s because Apple uses browser sniffing and vendor prefixes, and in addition to that they aren’t really testing a lot of HTML5 at all. Most of their demos seem to have got nothing to do with HTML5, as a matter of fact.”

Christopher Blizzard from Firefox was more direct saying

“Apple’s messaging is clearly meant to say ‘hey, we love the web’ but the actual demos they have and the fact that actively block other browsers from those demos don’t match their messaging. It’s not intellectually honest at all.”

A quick review of the source code shows that it is littered with WebKit-specific prefixes and extensions. The messaging surrounding the demos is also iffy at best. In the Light Table demo, which is actually pretty nice, the messaging states that

“Using CSS3 transforms and transitions, photos can be easily sorted, shuffled, or displayed in a slideshow with just a few lines of CSS and JavaScript.”

Of course I was curious as to the contents of those 3 lines as they must be the most powerful 3 lines of code ever written. In actual fact, the JavaScript file that drives the demo is 700 lines long.

Personally I look forward to the day when simple things like video playback and photo galleries can be handed off to browsers to handle. Flash has always been about pushing the envelope. So long as there are standards, there will always be technologies and developers who want to go beyond that.

Lee

Thoughts On Apple’s HTML5 Demos

I had heard through the grapevine that Apple would be posting a set of HTML5 demos today. To be honest I was kind of looking forward to seeing some cool stuff. Instead they have presented a set of basic demos that have very little to do with HTML5 or web standards. On top of that they have implemented a browser-detection scheme that is quite deceptive to say the least.

The image below was circulated on Twitter and it shows that on Apple’s demo page you are unable to view the examples using Google Chrome, Opera, Firefox or any other browser and are instead asked to download and install Safari in order to see the demos. That is quite odd seeing as though Chrome has much better support for the future HTML5 standard according to the site html5test.com.

In an ironic and funny side note, the browser sniffing was apparently blocking people from viewing the demos on their iPhone, although I can’t confirm that. The performance of the demos on the iPhone may have something to do with that, as most of the demos crawled on my 3GS.

If you go to the developer section of Apple’s website you can view the demos using Chrome and are not directed to download Safari. So on to the demos themselves. I made a joke on Twitter about how these were equivalent to things created in Flash 8, but to be honest that is being kind. A photo slideshow and 360° PNG sequence are more like Flash 5. The reality is that HTML5 is capable of much more than that so it is odd that they considered these to be a good showcase of what is possible. Apple should really consider hiring some Flash developers to create some badass HTML5 demos. Many in the community have been dabbling in it and have created much more impressive demos than these.

Other browser manufacturers have rightfully jumped up to dispute Apple’s questionable browser-sniffing policy. Opera’s Haavard Moen blogged that

“when the page doesn’t work in Opera or other browsers it isn’t because these browsers don’t support HTML5. It’s because Apple uses browser sniffing and vendor prefixes, and in addition to that they aren’t really testing a lot of HTML5 at all. Most of their demos seem to have got nothing to do with HTML5, as a matter of fact.”

Christopher Blizzard from Firefox was more direct saying

“Apple’s messaging is clearly meant to say ‘hey, we love the web’ but the actual demos they have and the fact that actively block other browsers from those demos don’t match their messaging. It’s not intellectually honest at all.”

A quick review of the source code shows that it is littered with WebKit-specific prefixes and extensions. The messaging surrounding the demos is also iffy at best. In the Light Table demo, which is actually pretty nice, the messaging states that

“Using CSS3 transforms and transitions, photos can be easily sorted, shuffled, or displayed in a slideshow with just a few lines of CSS and JavaScript.”

Of course I was curious as to the contents of those 3 lines as they must be the most powerful 3 lines of code ever written. In actual fact, the JavaScript file that drives the demo is 700 lines long.

Personally I look forward to the day when simple things like video playback and photo galleries can be handed off to browsers to handle. Flash has always been about pushing the envelope. So long as there are standards, there will always be technologies and developers who want to go beyond that.

Lee