Archive For: Flash

HTML6 is the only way to do things!

This post is an email from a forum with which I subscribe. All I can say is, I could not agree more! Thanks John.

“I’m sorry but HTML5 isn’t actually an official standard yet and therefore it is impossible for any browser (even the most modern ones) to be compliant with it!

HTML5 absolutely does NOT offer all of the features of Flex. Flex (hosted in Flash Player or AIR) was a truly object oriented language that would allow someone to write code once and deploy to many devices and browsers in a pixel perfect way with little or no compatibility issues.

HTML5 + JavaScript has none of the above properties. Yes, people have faked object oriented like features with hundreds of KBs of JavaScript that you have to load on every page but in my opinion that is bending a technology further than it was meant to go. And yes, people have also built hundreds of KBs of “polyfill” JavaScript libraries but they only support certain brands / versions of browsers to a point (plus you have to load so much stuff so performance will be impacted).

HTML5 is landing us right back into the browser hell of the late 90’s / early 00’s where most of your code was concerned with detecting the browser and working around each of their little quirks (or just simply making it clear that certain browsers aren’t supported).

Even taking into account that the HTML version of Workspace is still in pre-release stage, you’d have to admit that you cannot open the application in Chrome, Safari, FireFox and IE9 and get the exact same user experience in all 4 browsers – conversely, you can open the Flex based Workspace in any of those browsers and you are unlikely to notice a difference. Moreover, you can open the Flex based Workspace in IE6 & IE7 with no troubles at all…you cannot even get past the login screen in the HTML version of Workspace using those browsers. As our current client requires us to support IE7, we have had to build our own HTML Workspace application using “traditional” HTML4 technologies.

Eventually HTML5 will become a standard and every browser will implement it in its own way with its own quirks that will – one day – hopefully converge into a manageable set of known issues that can be easily worked around. Then all we need to do is wait for everyone to get rid of their legacy browsers and we’ll be fine…by which point people will start saying that HTML6 is the only way to do things!

Oh well…at least it keeps us all in a job I suppose.”

-John Nesbitt


Thanks again John, I enjoyed your rant. :)


No one is moving from Flex to HTML5


You can’t make this stuff up. Someone sent me a couple of great graphics supporting my assertion. So please respond with anything that supports the contrary.


After getting a little splashback from some of my friends and colleagues, I thought that I’d add a little supporting evidence to my assertions.

“Moving” to HTML5 at this point is senseless gambling.

I’m not just blowing smoke up your pipe here either. Open your browsers to HTML5test.com and see for yourself. Come on… go ahead and do it!

The HTML5 support score on latest Windows 7 browsers that I have: IE 138; FF 330; Chrome 400. And then on the Mac OSX 10.6 that I have; Safari 319; FF 340; Chrome 400. That makes Chrome our top student with a whopping 80%. And I’m what many would call an “Advanced User.” Expect less from the general public.

Last I checked, 80% was a low “B-”. And with over 50% of the browser usage coming from browsers that have failing scores, you can see why I would not recommend HTML5 except in specific edge cases. And you thought IE6 was bad! (Browser stats from w3schools.com)

As a mobile or web developer, adding HTML5 to your list of skills is imperative. But with the severe lack of consistent support, moving an enterprise development project to HTML5 now is purely experimental or an exercise in ego.

If you think I’m wrong, please provide supporting evidence and I’ll gladly educate myself.


Original Post:

The fear, uncertainty and doubt (FUD) is being slung around by profiteers like folding chairs at a WWE event. The haters are still being haters. Nothing new there. But now I see JavaScript companies’ desperate pleas for Flex developers to start using their HTML5 software.
The context is all wrong here.  Very, very few Flex developers have shifted, moved, changed over, or whatever you want to call it… to HTML5 (or anything else JS-based.)


There is not a move to HTML5

I will go as far as to say that there is not a move to HTML5. The simple fact is that, developers are being developers. No matter the background, we are always trying to broadening our skill sets. This includes HTML5 since it started showing up a few years ago. For anyone to imply, or state outright, that there is some mass exodus from Flex is completely false!

The reality is still the same, Flash Player is still the most consistent cross-browser, cross-OS, and cross-device platform for software development.

It doesn’t matter if you are building business software or games, with one technology you are able to build for the desktop, Internet Explorer, Chrome, Firefox, Safari, Android, iPad, iPhone, Blackberry and Internet TVs.

What most haters fail to realize is how nice it is to go through your bug list and not find ANY bugs that are browser/platform specific. The only bugs I have, are actual bugs that I can fix. Not browser support related issues that you have no control over. For the first time in years I had to deal with browser specific issue when our On3 client embedded the application in a JSF, JSTL, ADF container. It reminded me of how good I have it. I don’t have to deal with this headache on a daily basis. In fact, it was one of the complete joys that drove me from building DHMTL development to Flex development.

So, the next time someone says, “Flex is dead” or “Everyone is moving to <insert tech here>,” take it with a grain of salt. In all likely hood, they have a hidden agenda.


Thank you Moai for this great graphic on the HTML5 Hype vs. Reality.


Adobe Flash Player licensing doesn’t apply to you!

Let me start with the punch line: Adobe’s announcement only applies to browser-based applications that use domain memory IN COMBINATION WITH hardware accelerated Stage3D in Flash Player

If you don’t know what these features are, this announcement does not effect you.

It’s funny to me how a simple statement gets construed when passed on to even one person. This phenomenon is called  Chinese Whispers. Unfortunately, in our fast paced world, we don’t actually pay attention enough to prevent this from happening nor the erroneous blow back regarding the Chinese Whispers. As many of you know, I work with several Adobe products. So I follow them closely and hopefully understand their direction better than most. So let’s clear this up.

Yesterday, Adobe announced that they are adding a licensing component to 2 specific features of Flash Player for developers.

This does not effect you if:

  • You create anything using Adobe AIR including the use of Stage3D and domain memory
  • You create anything for mobile devices using Adobe AIR including the use of Stage3D and domain memory
  • You create anything for the browser in Flash Player that use Stage3D
  • You create anything for the browser in Flash Player that use domain memory

This only effects you if:

  • You create browser-based applications that use domain memory in combination with hardware accelerated Stage3D in Flash Player AND the revenue for the application is $50,000 or higher

The licencing is very clear that it is for two (2) specific features used in combination that are most likely to be used by game developers. The features are domain memory and hardware accelerated Stage3D.

It is important to note that games and applications using either hardware-accelerated Stage3d OR domain memory individually do not require a license.

Game developers, before you get all WoW on Adobe, be sure to read the whole announcement and make sure that it does apply to you. And if it does apply to you… congratulations of creating a successful game!


Unstoppable force, meet immovable object

First of all, the sky is not falling. Flash is not dead.

But with a poorly handled announcement by Adobe regarding the Flash Player plug-in for “mobile browsers” it really caused quite a stir. Unfortunately, the intent of the communication was not clear enough for most people. Including most of us in the community. Adobe can only blame themselves for this.

What was lost in the message is that, although they will not be actively adding new features to the mobile browser Flash Player, they are continuing to support the mobile plug-in.

So what does this change? Nothing.

The Flash Player for mobile is already NOT on iOS devices. That is not changing that we know of. Flash Player 11 for mobile is already on Android, Windows Phone, Blackberry and others.

So again, what has changed? Nothing.

What made Flash Player dominate the desktop was its ubiquity. You could count on it being there. Unfortunately, that isn’t that case for mobile.

And for all the haters, this is by no means throwing in the towel or admitting defeat. Flash Player for mobile is already on 80% of mobile devices. iOS market share is still dropping. Just say’n.

But the key thing for Adobe was that without the ubiquity that Flash Player has on the desktop, it’s hard to make the same claims of rich interface consistency across platforms. Without the consistency across platforms, you might as well use HTML 5 which is supported as best as possible by all smart phone browsers. And as a tools provider, there resources are better spent where they will make the biggest impact.

You do have to take this decision with a grain of salt. HTML5 is still a specification that is being worked on for a couple of more years. Yes, YEARS before it will become a standard. See some of my points regarding HTML5. We, developers, will have to live through browser compatibility hell again as we did for a decade with JavaScript. yeah.    Since HTML 5 still needs work to get to its promise (http://www.w3.org/TR/html5), it makes sense for Adobe to put more resources into HTML 5.

Flash Player is not going anywhere, for now. Flash Player for the browser and AIR for Mobile and Desktop at still the easiest and most consistent way to put consistent cross platform engaging experiences in front of users.


As an aside, I still think that it is a huge mistake by Apple to not allow users to install Flash Player on their tablet. I can care less about phone browsers, they are simply too small. But I am always using the “full site” option when browsing on my tablet. And because I’m on a Galaxy Tab, I get to enjoy all sites as they were meant to be. I do give Apple credit for their impact on the mobile phone world, but I don’t think it will carryover as well on tablets. The competition in the space has already caught and passed them from a quality product perspective. They may have the tablet market share currently, but just like the PC and the phone, they will eventually be swallowed up by the flood of less expensive options that are as good as or even better.

The “Jimmy the Greek” predictions of the demise of Flash have emerged again with fervor. To their chagrin, they are slowly realizing that this is not the case. In fact, Flash is still expanding into new areas. Cases in point, TV and embedded devices. HTML 5 is still not good enough nor consistent enough to replace Flash Player, even on mobile.

Flash Player is not open == big fat lie; HTML5 is the saviour

Flash Player is open and SWF is documented

The core of Flash Player is the Tamarin Virtual Machine, which is an open source project under Mozilla. While the SWF file format is not fully open, it is documented by the community on osflash.org. Additionally, there are numerous open source products that read and write SWF files.

The Flash Player’s product direction has traditionally been heavily influenced by the community and their needs. The core language for Flash Player is an implementation of ECMAScript 262, which is the same specification for JavaScript. Flex also uses CSS for styling of components/applications.

There are also several libraries included with Flash Player that are licensed through other parties (i.e. h.264) that are not open. Thus, preventing Adobe from making the whole thing open source if they wanted to. Not sure that they would, but this definitely kills the idea.

Come save us HTML5 in 2022 AD

HTML5 has been in the works since 2004 and is still in “draft”. Its primary intent is to reduce the need for proprietary plug-ins (like Flash Player and Silverlight).

I can definitely see the benefit of not relying on a plug-in for multiple reasons. There is a concern if users will have the plug-in, but the bigger concern is vendor dependence. I think Adobe has the install base issue covered fairly well, yet it should still be a concern for locked down environments. To the bigger concern, I’d say that we already depend on companies like Apple and Microsoft quite heavily and that Adobe is far from a fledgling start-up that would be considered very risky. Naturally, I understand to the concern and will help my clients choose the appropriate technology.

The reality is that HTML5 is not coming anytime soon

Steve Jobs, CEO of Apple, claims that “the world is moving to HTML5″. How is that going to happen Steve when Ian Hickson, editor of the HTML5 specification, expects the specification to reach the W3C Candidate Recommendation stage during 2012, and W3C Recommendation in the year 2022 or later?[http://en.wikipedia.org/wiki/HTML5]

Should we hold off development for a few years while Google (Ian works at Google) finishes the specifications?

Finally, how many different implementations of HTML5 do you think there will be?. There will most likely still be cross browser compatibility issues to deal with.

Flash Player and Silverlight

I’ll sticking with vendor dependence that I can use now over incomplete technology with potential compatibility nightmares any day!


Adobe Flash and Flex Accessibility with Screen Readers

If you are dealing with 508 compliance and wondering if a Flex application is accessible, this is your post.

First, yes, screen readers can read Flex applications. And yes, its fairly easy. But, I’ll discuss how in a future post.

But, if you’d rather send people to your old HTML version of your site when using a read, there is good news. Flash Player has the ability to detect if a screen reader is running on the client machine, even if JavaScript is disabled and/or the Flex application is not compiled as an “accessible swf”. This is possible with the Accessibility class.

It is important to note that if the Flex application is compiled as an “accessible swf”, the screen reader will also be able to read content in the swf. If not, the screen reader only reads the words “flash movie start” whenever you interact with it. Talk about a usability buzz kill.

So, here is the code to see if a screen reader is currently running (not just installed) and then adds a LinkButton that calls a navigateToURL on click.

private function init():void
  // this is the only thing you need to do
  if( Accessibility.active )
    var linkButton:LinkButton = new LinkButton();
    linkButton.label = "Click here to go to HTML site";
    linkButton.addEventListener( MouseEvent.CLICK, goToSite );
    this.addChildAt( linkButton, 0 );

private function goToSite( eventObj:MouseEvent ):void
  navigateToURL( new URLRequest("<screen reader friendly site>") );

There are more properties available on the Accessibility class, but this is all you need to give accessibility an option.


Security Soapbox – Decompile Flash/Flex

Having built/architected/developed/consulted many Adobe Flex applications and being one of the first certified Flex instructors in the world, I’ve seen a lot of Flex applications. Some good, some bad.

But no matter how many applications or who I’m talking to, I always stress the importance of securing proprietary information. By securing, I mean don’t put it in your application. Unless your are encrypting your application and decrypting at runtime, you are subject to a decompiler exposing your secrets.

There are Flash decompilers that will take any SWF and give you the source:
Trillix Flash Decompiler is one of the best commercial tools I’ve found.
I’ve even seen guys decompile, make changes and then recompile a Flex app. This is scary! Say goodbye to licensing software in Flash.

But HP just released a tool that has caught my eye as well. (Note: I have not tested this tool) It claims to decompile and test for security weaknesses. It’s called SWFScan and it’s a free Windows based tool from HP.

If security in a Flex or Flash based application is a concern for you, you must look at these tools. If security is not your concern, look anyway.


Adobe Camp in Denver

One thing I have to say is that the Adobe community is alive with collaboration and events. There are tons of people sharing their work and their ideas on better development with the Adobe products. One more example, the local Rocky Mountain Adobe User Group is hosting a very inexpensive event for the Flash Platform, Dynamic Media and eLearning.

“Adobe’s Flash Platform is a powerful tool set that spans digital disciplines such as application development, media production, and eLearning. Join us at Rocky Mountain Adobe Camp on June 22, 2009 in Denver for in-depth presentations and unique hands on activities for everyone from newbies to gurus.”

It sounds like a day well spent. See you there.


If I were in academia, I’d love Adobe!

Okay, maybe I do already love the Adobe RIA tools, but… if I didn’t, I’d be smitten with their latest offer to the community.

Once again, Adobe is reaching out to the community by giving away free licenses to their RIA development tools. Free Flex Builder licenses to academia and to the unemployed. And now, free ColdFusion licenses to academia.

So, if you had your choice of using the best RIA development platform (for free) or any of the up-and-coming tools, which would you choose?

Check my post on On3 for information about free Adobe licenses.


Use AMF with JavaScript in Adobe AIR

I’ve been working with Adobe Flex since its beta and have been a long time believer in using Action Message Format (AMF) as the communication protocol. I’ve also been working with Adobe AIR since its beta, but had only used AMF with Flex-based AIR applications. Until now…

I was working on a JavaScript-based AIR application (some refer to this as an AJAX-based application) recently where they wanted to use AMF, but didn’t want to hide a SWF in it to facilitate the AMF communication. Since there are other Flash Remoting gateways available, like openAMF and AMFPHP, it would be great if I could just use a JavaScript library to do the communication with those gateways.

If you look at examples in Flash that do this type of connection, you’ll notice that they use a NetConnection class. Guess what?! That class is also available in the JavaScript API for AIR. Yes, its that simple!

So with a simple refactoring of the same code from Flash, I was able to get my JavaScript-based AIR application to communicate with a Flash Remoting gateway. This example assumes you have installed a Flash Remoting gateway somewhere, that you replace [my_flash_remoting_gateway] with the gateway root and you’ve created a class with a method that you can invoke.

<title>JavaScript-based Flash Remoting</title>
<link href="sample.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="lib/air/AIRAliases.js"></script>
<script type="text/javascript" src="lib/air/AIRSourceViewer.js"></script>
<script type="text/javascript">
function doAMF()
var netConnection = new air.NetConnection();
var responder = new air.Responder(onComplete, onFail);
netConnection.call("HelloWorld", responder);
function onComplete(results)
alert( results.length );

function onFail(results)


<h3>Get data over AMFPHP</h3>

<li>Has access to AIR APIs:
<input type="button" onclick="doAMF()" value="Make AMF call"/>



Here is an example class in PHP:

class HelloWorld
function HelloWorld()
$this->methodTable = array
"say" => array
"access" => "remote",
"description" => "Pings back a message"