« June 2008 | Main | August 2008 »
July 20, 2008
Reading Flexcoders Again
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!
July 13, 2008
Six Tools for Flex and AS3 Development
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. Update: I removed the FlashMute link for a bit, because I was very concerned with an alert from Symantec that it was installing Adware.BetterInternet on my machine. I just needed to email the creator to find out what was really happening. He has a long explanation on his site for why FlashMute is getting flagged as adware. But it's not, so I'll still be using it and enjoying it.
6. And, of course, FlexBuilder 3.
Any good tools that I've forgotten? What's your list?
Don't Use IFrames for HTML in Flex
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."
I'll given some potential solutions to the problem after a word from our sponsors.
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.
July 8, 2008
Flash Versions of Lua, Ruby, Perl, and Python?
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.
Flash Job In Flashlog
This wins for the most creative job posting I've ever seen, certainly better than my Brightcove top ten list a year ago. (Although Brightcove is where you should apply of course.) If you view a blip.tv player, you'll see this:
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
Very amusing. Flash video players seem to have a habit of leaving amusing messages.
Posted by Brian at 7:07 PM
July 6, 2008
AIR Conversion of the IFrame Demo
I've converted the iframe demo found in the HTML in Flex post into an AIR demo. In this post is a badge to install the application, a link to the source, and a list of the differences between the two versions. 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.
- 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.
