There's little information out there on this subject. Tim Walling has a post on this which points to some problems, but there's nothing else that I've been able to google. I'm surprised that there's not more people who are stuck on this.

A colleague of mine, Crystal West, is the person who is really banging her head on this. She created an example to show the issue. The example has two SWCs within it, one created using Flash Authoring and one created using Flex 3. Try compiling swc_test.fla with just flash_bc_ads.swc in the same directory (that is, remove flex_bc_ads.swc). The fla should compile fine. Then try with just flex_bc_ads.swc. You should get a number of compile errors for the AdTranslator class.

She tried a lot of variations on compiling with flex_bc_ads.swc, and nothing has worked. flex_bc_ads.swc was built using the compatibility flag and doesn't use any of the Flex framework. She also tried compiling the Flex SWC using compute-digest=false (as recommended by the Tim Walling post mentioned above). That didn't work either, and, according to some of the comments on this blog post, didn't work for others.

Anybody have any experience here or any suggestions?

Update: A minute after I posted, Oscar told me about a Yahoo post on the subject. It doesn't seem like this is the same problem, however, since a related post says the problem is "code SWCs". So hopefully this isn't our problem, since we are trying to create a SWC which can be used as a Sprite.

He already has some long posts on unit testing and assertions. I know he'll have a lot more posts about Flex, so go check it out.

I wanted to convert some Ant builds to use the Flex Ant tasks, but it's painful to convert Ant targets that use "java". The problem is that all existing "java" calls will use command-line arguments, aka the "arg" element. The "arg" elements follow the command-line use of mxmlc and compc, and it's a different format than the Ant tasks.

In order to get the "arg" support, you'll have to do the building of the Ant tasks yourself. I could have just provided the jars here, but I don't have a clean copy locally. And it's good to have the source locally to know how to make more changes. Here's the steps:

1. Download the Flex 3 source.
2. Open the Ant tasks you want to alter. They're found in "modules/antTasks/src/flex/ant/".
3. Add the following line somewhere within prepareCommandline():
cmdl.addArguments(getCommandLine().getJavaCommand().getArguments());
4. Recompile the jar by running "ant" when in the directory "modules/antTasks". You'll have a new version of the Ant tasks at "lib/flexTasks.jar".

If anybody creates a version of the flexTasks.jar with just this change, I'll link to it here.

Why would you want to convert existing targets to use the Flex Ant tasks? I thought that the usual reason was to get wildcard support for compc arguments, but I don't see this feature in the documentation. In any case, Brightcove already had this support through some complicated Ant work. The reason I was looking into this was for some performance improvements.

I thought I could get some speedup by keeping a bit of shared state between compilations, and doing this required some Flex Ant task and compiler changes. I had forgotten, though, how much shared state is needed to really improve the performance. So although I started to convert over some of the Ant targets, in the end I left them all as "java" calls.

A better approach to getting some faster Ant builds is to use the compiler API in a set of new Ant tasks. If anybody has any Ant tasks out there for this, I'd be interested in using them. I know about the Maven support, but it looks to me like I need to create some Ant tasks myself to take advantage of the compiler API.

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!

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?

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.

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. ]]> http://www.deitte.com/archives/2008/07/an_air_version.htm http://www.deitte.com/archives/2008/07/an_air_version.htm Flex Sun, 06 Jul 2008 21:07:08 -0500 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.
• A customization with the Compiler API is explained on iconara.net

I had a backup, but Movable Type's odd linking structure has left me with a few missing files. So now I'm stuck with an odd-looking blog until I find the time to fix things. It's better than the default look, as long as you don't look at the bottom of the front page. (You looked, didn't you?)

On the subject, if you have or know someone with the following four characteristics:

- CSS knowledge
- know Movable Type or are willing to put up with a wacky templating system
- a good knack for design
- free time

Send me an email at bdeitte at gmail dot com with your rates. Obviously I can't spend a fortune on a free blog, but with my lack of time, I'm more than happy to pay for someone else to clean up my mess (and then make it much better).

"3608: 'getString' has been deprecated since 3.0. Please use 'ResourceManager.getInstance().getString()'."

I tried turning this off by setting show-deprecation-warnings to false until I noticed that this setting doesn't really work in Flex 3.

So I created a SWC which has a modified version of the ResourceBundle class. Yeah, I could have also monkey-patched the ResourceBundle class, but putting it in a SWC was helpful in my situation. I know these have to be changed eventually, but it's a slow conversion from Flex 2. Feel free to use for your own ignoring-for-now purposes.

Watchpoints for debugging
Compiler performance improvements
A new Flash format tag, DefineFont4, and generation from OpenType CFF font files

One gripe, however, is that it's obvious from the level of commits showing up that not everything is visible. The team must be working off of a branch, as there's not nearly enough activity showing up for the Flex team. Hopefully they'll change this practice soon and start using the public branch.

The scale of things at Brightcove is something that drives a lot of what happens with Flex and Flash at Brightcove. From the slides:

135 Million Unique Users/month (as of 6 - 9 months ago)
1.5 Petabytes (1,500,000 GBs) of media delivered/month
Thousands of platform users, hundreds of major media brands, 
  50 television networks, newspaper and magazine publishers, 
  and all the major record labels in the US.

All of these users and media go through the Brightcove players, which have AS1, AS2, and AS3 versions in hundreds of different permutations. Some of the data on the AS3 versions from the slides:

ActionScript 3, AVM2
AMF3 as client/server communication protocol
~70K LOC written

There's nothing too surprising in there, but there's some more interesting size information in the slides. Keeping down the size helps the performance, and there's been a lot of work by Todd Yard (and others) on making the players faster and faster for the 135 million (or whatever the current number is) users.

The players and videos are managed by manager applications that were created with Flex. When some of your customers have thousands of videos and thousands of playlists of videos, the management becomes... tricky. The slides touch on some of the ways this happens:

AVM2
Structure server API; initial view, lazy load, different types of DTOs
Make clients intelligent about their needs 
Datagrid presentation strategies

I'm sure there's some questions on some of the above, like the datagrid presentation strategies, but I'll have to expand on them another day. These business applications have some other data points on them that I can share:

Flex 2, AVM2
Flex vs. ActionScript vs. DHTML
AMF3 as client/server communication protocol
Cairngorm as micro-architecture
~100K LOC written, 150 Commands
FlexBuilder as IDE/Developer Tool
FlexUnit for unit testing
Homegrown integration tool

There's a lot more in the slides below, including info about Brightcove as a service, code layout, the use of Scrum, our Java setup, etc. If you'd like to hear more about any of this, just comment or send me an email.