Deitte.com

We have to learn to manage information and its flow. If we don't, it will all end up in turbulence. -Grace Hopper in Prioritizing Information

About a year ago, I stopped reading flexcoders. The mailing list had become turbulence for me, something I couldn't keep up with and which I decided to stop trying to. I thought the blogs I was reading were better for learning the latest on Flex, and so I prioritized flexcoders so low on my technology reading list that it fell off.

I've started reading flexcoders again, and I'm really enjoying it. There's a lot of code to look through for features that I haven't played with, more than I find on blogs. Gmail makes sure that everything is nicely threaded, and so I can manage things better and skip most of the threads.

I've already gotten some payback for the reading through a message by Doug McCune (who I hear is co-writing a new book about Bharathanatyam dancing). It made me think more about what I write about here, that I barely ever write about the things that I'm actually working on. I haven't had a single post on advertising, Cairngorm, functional testing, or the other things I deal with daily. It's something for me to work on, along with adding more code examples.

I just checked to see when I first posted on flexcoders, and it's four years ago, writing about RemoteObject's support for AS2. It doesn't feel that long ago!

Here's tools that I use for Flex and AS3 development:

1. Flash Switcher for switching between Flash players. Actually, I don't use this tool yet, but I plan to start using it soon. I just installed it after reading Oliver Merk's post on it.

2. Charles for looking at HTTP traffic. If you aren't using Charles, Service Capture, or something similar, you should download one of them now. It's extremely useful for daily debugging. Charles has some additional features that I like to use, like the ability to test a SWF from a remote location.

3. tail for viewing flashlog messages. I know there's a lot of GUI flashlog viewers out there, but I find that all I need is a window open with "tail -f flashlog.txt".

4. FlexSpy for inspecting component properties. I don't use it as often as I expected, but it helps to pinpoint components in new code and make design changes.

5. FlashMute for keeping me sane. This is a tool that's really helpful if you want to keep your computer unmuted but work on any Flash applications with sound. Especially if that sound is the same thing, over and over and over.

6. And, of course, FlexBuilder 3.

Any good tools that I've forgotten? What's your list?

The iframe solution to HTML in Flex has become a popular, unsupported way to embed HTML inside of a Flex application. I've written a lot about this, but I've never been very comfortable with the solution. I feel it's time to gather up all the information I've learned and start steering people away. I'll provide some potential alternatives to iframes at the end of the post.

About the IFrame Approach

The use of iframes is very clever- by using a special windowing mode of the Flash Player as well as an iframe, you can layer HTML on top of a Flash application. The HTML is completely separate, and so there's ExternalInterface communication that goes on between HTML and Flash.

The iframe approach is something that Christophe Coenrats came up with, which I ported to Flex 2, and which others have run with to make more versions. The other solutions include Alistair Rutherford's version and the commercial HTMLComponent.

What's Wrong with IFrames

So why shouldn't you use the iframe approach, if you can help it? Because of the setting of the wmode to opaque.

Just Everett wrote an excellent post on this a few years ago where he outlined three problems:

"1. Speed: There is no big surprise here, but when you force Flash to composite the HTML layers above and below, you are adding additional processor load.
2. Accessibility: wmode makes your movie invisible to screen readers
3. Inconsistent Performance"

I've had some experiences with the transparent wmode myself, which is when I started looking into this more again. I went back and looked at the comments about the iframe solution, and I noticed a lot of problems with the opaque wmode:

"Ctrl-Click" events are affected causing components such as the DataGrid to experience problems in FireFox. In this case, the DataGrid loses its ability to do a multiple selection of rows.

"..using "wmode=opaque" on Firefox(Win)leads to trouble like not working mousewheel and not accepting of special characters like "@" of flex2 textinput component.

"The content inside IFRAME gets a very annoying flicker effect which renders this approach into totally unusable under Mac OS 10.4 / Safari 2.0."

"...but some of the iframe content disappears until one of the flex controls gets the focus, at which time it all comes back. Very strange."

The many problems listed above, along with the troubling fact that they are browser-dependent, means that I don't feel comfortable recommending the iframe approach. I can see using it in special circumstances when you understand all of the limitations. But in general, I would use one of the alternatives below.

More on the Opaque WMode

The opaque wmode changes how the browser and the Flash player work together. It's a fairly fundamental change which causes a number of browser-dependent problems. You can read more general information about wmode in this communitymx article.

If you'd like more technical details on wmodes, you can read about it in Tinic's article about the new gpu wmode. He writes:

"opaque: Somewhat esoteric, but it is essentially like transparent, i.e. it is using DirectDraw in Internet Explorer. But instead of compositing the Flash Player just overwrites whatever is in the background. This mode behaves like normal on OSX and Linux."

Solutions to the Problem

If you don't want to use the iframe solution anymore, what's the alternative? There's four different directions that you can go in:

1. Translate HTML tags into Flash
Alex Harui has a partial solution to this, and OSFlash has a whole browser in Flash. I haven't tried either of these, but they look promising.

2. Use AIR
If you can switch to an AIR application, see my post on creating HTML in AIR.

3. Don't layer HTML and Flash
Try to completely separate the HTML and Flash areas on the page or use a link instead of embedding HTML. Most likely this is something that was already considered and discarded, due to non-technical constraints or ease of development. But it's something to consider again.

4. Get a solution from Adobe
This isn't a short-term solution, but it may be possible to have a world where an opaque wmode doesn't cause any problems. I doubt it, though, because it could be problems within the browser instead of problems inside of the Flash player. See this Flex bug for a request for a supported iframe component and judah's post for a list of wmode bugs.

Update: check out the comments for a discussion between the creator of HTMLComponent and myself.

Scott Petersen gave a talk at Mozilla where he showed off "C-compiled versions of Lua, Ruby, Perl, and Python all running on the web in secure Flash sandboxes". There's other goodies, including a Zelda mention, in the link above. Or see this previous post for more links on C and C++ via ActionScript 3.

I wonder what the chances are for this all to get released, given the "native byte array that maps directly to RAM" and anything else that needed to be added the player to get this to work? It certainly would change Flash development dramatically, making a lot more developers interested in the Flash ecosystem. I also think it's something that Adobe would use to bring a lot more applications onto the Web, given the company's history in C and C++ development.

Showplayer initializing...
                              __---__
                           _-       _--______
                      __--( /     \)XXXXXXXXXXXXX_
                    --XXX(   O   O  )XXXXXXXXXXXXXXX-
                   /XXX(       U     )        XXXXXXX\
                 /XXXXX(              )--_  XXXXXXXXXXX\
                /XXXXX/ (      O     )   XXXXXX   \XXXX\
                XXXXX/   /            XXXXXX   \_ \XXXX----
                XXXXXX__/          XXXXXX         \_----  -
        ---___  XXX__/          XXXXXX      \_         ---
          --  --__/   ___/\ XXXXXX            /  ___---=
            -_    ___/    XXXXXX              '--- XXXXXX
              --\XXX\XXXXXX                      /XXXXX
                \XXXXXXXX                        /XXXXX/
                 \XXXXX                        _/XXXXX/
                   \XXXX--__/              __-- XXXX/
                    --XXXXXXX---------------  XXXXX--
                       \XXXXXXXXXXXXXXXXXXXXXXX-
                         --XXXXXXXXXXXXXXXXXX-
(128)



Hello there, Flash cowboy!
If you can read this message, you should apply for a job at blip.tv.
Send an email to careers@blip.tv with your resume and make sure to
let us know that you saw this message.

               Love,
               The blip.tv dev team

A badge to install and run the application is on this separate page until I can figure out how to get Movable Type to stop entitizing scripts. You can also view the source of the demo here.

The AIR HTML demo shows how easy it is to switch from using an iframe to mx:HTML. Of course, it may not be easy to convert some of the particulars of a large application or to convince your boss to use AIR, but the basic conversion only takes a few hours.

Here's what had to change from the iframe demo:

• The IFrame component has been removed and is simply replaced with mx:HTML. The 'source' attribute changed to 'location'.
• No HTML wrapper file is needed, since this is an AIR application. But an AIR badge, not included in these source files, is used to launch the AIR app from a web page. You can find the source to the badge that was used on Adobe Labs.
• Application changed to WindowedApplication, as is needed for all AIR applications.
• HTMLDemo-app.xml was added, the AIR configuration file.

A few more changes were made, additional enchancements that weren't needed for the AIR conversion:

• Cleaned up the MXML, moving code into functions.
• Used the HTML events to show a busy cursor when a page is loading.
• Added back some sites that didn't work in the Flex version.
• Added Wacky HTML mode for the fun of it, to show how easy it is to change the display of HTML in an AIR app.

In case you missed it earlier, note that you can install the application here.

While I've attended AIRCamp and read a good deal about AIR, this is the first thing I've ever compiled with AIR. So just let me know if I've done anything dumb.

The Flex Compiler Design Document has generated some more interest in learning about the Flex compiler. Here's some resources to learn more:

• I've written a little bit about the compiler myself in two posts (here and here).
• You can always ignore all the documents and just go straight to the source to investigate more.
• It's helpful to watch the commits which will show you what's going on with the Flex compiler and framework. There's a way to see the diffs from these commits that I don't remember offhand, but I can look it up if anyone is interested.
• Clement Wong has an excellent blog on the subject, including info on a RPC version of the compiler.
• To see one custom addition to the code, check out Joe Berkovitz's code coverage tool, which had to modify the compiler.

Brightcove announced today the beta of a new set of tools and features. Most interesting for the readers here is the article on Techcrunch, where you can see a tiny picture of one of the Flex applications. As I mentioned here in a previous post, there's a lot of interesting AS and Flex working going on here. And someday soon you'll be able to see more than a little image of it!