February 13, 2011

Lessons Learned with StageVideo

Last week, along with the release of Flash Player 10.2, Brightcove released a page showing off the Brightcove player using StageVideo.

Here's the lessons I learned from working with StageVideo:
  • Getting started with StageVideo is fairly simple. The article on getting started spells things out well, and while the StageVideo object is quite different from the regular Video object, it's not hard at all to use.
  • Things can get tricky when using StageVideo with a complicated player given the fact that StageVideo sits below all objects on the display list. If you had your Video object added on top of a complicated display, you'll need rework this.
  • You can use StageVideo in a player that doesn't require Flash Player 10.2 Try loading the Brightcove player page in a browser using an older version of the Flash Player to see this- it can even be loaded with Flash Player 9. This isn't done too easily but can be managed with loading the StageVideo code in its own SWF as needed.
  • The StageVideo numbers are impressive, as shown in the link above. I heard more than one person surprised at how much it knocked down the processing power needed on their machine.
Posted by Brian at 9:56 PM

Come Work at Brightcove

It's incredibly exciting to work on a video player that can be seen on websites I visit every day. Want to do the same? We have positions open on the player team and all over the company. There's more than 25 job openings in a lot of areas.

I'm more than happy to answer questions- email me at bdeitte at brightcove dot com for anything you'd like to know.

I wrote another "come work at Brightcove" post nearly four years ago. How time flies... most of that post is no longer relevant, but the view is the same.

Posted by Brian at 8:40 PM

October 31, 2010

Speaking at RIA Unleashed

I'm excited to say that I'll be speaking at RIA Unleashed in two weeks in Boston. The talk will be about the future of video players from the perspective of someone working on them at Brightcove.

Tickets are still available for the two-day conference that has a lot of exceptional speakers from the Flash community. It also includes a night of geeking out at the MIT museum.

And a welcome back to any blog readers! I've had one month absences from this blog of five years, but this is my first six month absence. I don't expect to keep up very well in the short term, but the blog ain't dead yet. You can also hear from me on Twitter or at brian at deitte dot com.

Posted by Brian at 7:52 PM

March 8, 2010

How RIA Advertising Works

Below is the presentation that I gave along with Melissa Gregory at 360Flex a few hours ago. It's about the life of an ad and a little bit about Brightcove.

To anybody reading this who wasn't at the conference- I talked a lot about each slide and don't have any of those notes in the presentation. I'd be happy to explain anything more in the comments.

How RIA Advertising Works And a Little Bit About Brightcove

Posted by Brian at 4:42 PM

February 24, 2010

How RIA Advertising Works at 360Flex

I'm excited to announce that I'll be giving a talk, How RIA Advertising Works, at 360Flex. You can hear me at lunch on Monday, March 8th.

I've been building advertising SDKs for more than a year at Brightcove, and I want to share the things that I've learned about how advertising works- we'll go over the basics of advertising (CPMs, Mad Men, ad networks), the life of an ad (ad policies, ad delivery, impressions), and the emerging standards (VAST, VPAID). It will be a very technical dive into an area that many of us make our living off but which not a lot of people understand. A coworker of mine, Melissa Gregory, will also be giving a ten-minute introduction to Brightcove at the beginning of the talk.

The presentation I'll be giving is a sponsored presentation for Brightcove. I don't want this to dissuade those who just want to hear about RIA advertising, as my goal is to make this a talk that's the same as the non-sponsored talks at the conference. Being a former speaker at 360Flex in Seattle, I know I can make this happen, no matter if you use a different video platform or none at all.

I'm happy that Brightcove is a Bronze sponsor at the event. We'll have a booth there, which I'll be manning at points and where you can learn more about what we do (and pick up some schwag).

Not signed up for 360Flex? If you can get to San Jose in two weeks, you should sign up now. This is the original Flex conference, and the people who attend make it a one-of-a-kind event. I went to the first 360Flex in San Jose as well as 360Flex in Seattle three years ago. I met so many incredible people at both events, and I'm sure it will be the same at this one.

Posted by Brian at 8:52 AM

February 15, 2010

Brightcove on Mobile Flash Player 10.1

I'm very excited to see all of the news about Flash today, but I'm most excited to be able to talk about the work that Brightcove has been doing with Flash 10.1. As you can see in the video below, we've been working hard here to have different versions of the Brightcove player on mobile devices as well as making sure the current ones work as expected in the beta of Flash Player 10.1. The Brightcove player does a surprising amount, in my biased opinion- runtime layout with BEML, hundreds of API methods to call, segmented SWFs for optimizing size, handling large number of CDNs, support for every major ad server, and a lot more. And all of this is happening on the Android device below.

Posted by Brian at 2:43 PM

February 10, 2010

Ten Reasons to Use Flash

I was handed very odd timing for a brown-bag presentation last week. The talk was scheduled months ago for an overview on new Flex and Flash tools, but as the time approached the iPad and HTML5 "discussions" in the blog world kept getting louder. I wanted to give a Flash developer's perspective on things, and so I created the presentation below.

As a hopefully-obvious cavaet, these are just my reasons and have nothing to do with Brightcove. We have plenty of excellent people focused on the JavaScript side as well here, and I'd read Jeremy Allaire's post on TechCrunch if you're looking for a more Brightcove-centric response.

Posted by Brian at 8:59 PM

November 3, 2009

mxmlc: fitter, happier, more productive

Below is the presentation I'll be giving tomorrow night at the Boston Flash User Group, Brightcove edition. The avid fan will notice that it's partially material rehashed from this blog. But I investigated a few new things, and the discussion at the user group is always entertaining. And there's pizza and beer. Everyone is welcome to attend:

November 4th at 7pm
One Cambridge Center, 12th Floor
Cambridge, MA

Posted by Brian at 8:23 PM

October 25, 2009

Thanks For Voting!

After my lament on Flash/Flex bug voting three weeks ago, I was very happy to see all of the votes on the bugs mentioned:

EventDispatcher should expose list of attached listeners went from 4 votes to 16 votes.
Include FlexPMD went from 3 votes to 9 votes.
Expose more of "additional compiler options" in the UI went from 3 votes to 12 votes.

If you haven't seen them yet, there's plenty more voting suggestions in another post on mine (although two of them have already been fixed in 10.1).

Posted by Brian at 8:54 PM

October 18, 2009

Updated IFrame Component

The Flex IFrame component has been updated again to fix issues and improve the code. More information can be found on netthreads. I have a feeling that a lot of the issues I've mentioned in Don't Use IFrames for HTML in Flex are still around, but it's possible that some of them are now being worked around.

Posted by Brian at 7:44 PM

October 4, 2009

Why Don't You Vote for Flex Bugs?

I posted a month ago on My Requests for the Flash Platform, and I've been surprised at the lack of votes for the items I listed. Let me explain why.

My logs show that the blog post was viewed 840 times. I'll take off more than half of that number to account for crawler visits, people who didn't read the article, etc. So that leaves us with 400 people who could have voted on a bug.

Keeping 400 people in mind, here's what I see for the bugs that I entered in the list:

EventDispatcher should expose list of attached listeners. 4 votes
Include FlexPMD. 3 votes
Expose more of "additional compiler options" in the UI. 3 votes

That's a depressing voting percentage. There are a lot more bugs in the original post, and they don't look to have changed much in numbers either.

So why didn't people vote for these bugs? Here are my guesses:

1. You find it too much effort to vote for bugs

This is probably because you don't want to spend the time to register for an account. To show how easy this is, I just signed up for another account (which I will use to double vote for everything*). It took me less than 3 minutes, and most of that time was waiting for the email registration. The total time in which I was really doing something was less than a minute.

After you have an account, you can vote by clicking on a link in the left-hand column of the bug report.

It does take a bit more effort to create new bugs for things that are bothering you, and I know I haven't been very good at this. But I've been getting better as I've been thinking more about point #2.

2. You don't think voting for bugs matters

You voted for a bug that got deferred without explanation, or an enhancement that feels like it's being ignored. Or you've read stories about this, or you just don't believe anybody pays attention to a few votes on here.

I can understand why a lot of people would think this, but I think they're wrong. Unless things have changed dramatically since I was on the Flex team, opinions like this matter a lot to the team and future planning. The thing that's hard to see from our outside-the-team perspective, however, is all the other inputs going into the decision of what gets done or not. There's corporate goals, other internal team requests, what will make money, what people on the team want to work on, etc. So it isn't the only "vote" on the matter, but I think it's a very important vote.

3. You didn't like the bugs I entered

Now this is a reason that I can completely understand. Maybe you're focused on the Gumbo components, or better data services, or you just want more cowbell. In any case, if you didn't like the bugs I pointed to, I hope you're finding or entering the issues that concern you.

4. You don't have to vote to get something fixed... you have other ways

I think this only works if you're Doug McCune or work at Adobe.

* Of course I'm kidding about double-voting. Unless FP-444 doesn't really get fixed.

Posted by Brian at 1:16 PM

No MAX for Me

I won't be at Adobe MAX this year, but I'm excited to see that I can watch the keynotes online. I'll be setting up a room at work to watch this and hopefully hear more about GPU accelerated video, Flash mobile, and whatever else is cooking. Oscar Cortes will be representing Brightcove, and I believe we'll also have a booth there for more information on using Brightcove.

I'm missing MAX to keep my wife company as we expect our first child when it gets a bit more cold out. So if you don't hear me blogging for a few months, this is the reason. :)

Posted by Brian at 11:24 AM

September 6, 2009

My Requests for the Flash Platform

Ted Patrick wrote last month about The Future of the Flash Platform and asked people to be more vocal about the features and bug fixes they're looking for. Here's my in-depth lobbying session.

Below are my top requests for the Flash platform. Most of the links are to associated bugs. I created a bug if I couldn't find an existing one and the request wasn't too generic, and of course I voted for all of the ones I found. Please vote for them yourself if you'd like to see them get worked on.

As a hopefully-uneeded cavaet, especially to all the members of the Flex team that I used to work with, this list doesn't mean I don't continue to go all googly-eyed for the Flash platform. Also, I mention Brightcove a few times below, but this is just my personal wants- I don't mention anything about FMS, video encodings, or the other possibilities for others at Brightcove.

Now on to the good stuff, in no particular order.


Flash Player and AS3 improvements

More compiler optimizations for smaller SWFs. Some of this covered by a bug, although its title is harsh. Some can be found in the new and very intriguing project called TAAS.

Mobile versions of the standard Flash Player. I know there's been announcements about this, I know multiple ways I'd want to use this at work and for play, and I don't think I need to say anything more on this one.

Get all classes in the player. I've needed this more than once, but I don't remember the scenarios anymore. It'd definitely be helpful for frameworks.

Private/protected constructors. Ted's post mentions that this is in the works, but I'm still noting it since it's marked as Open.

Abstract classes.

Ability to catch all uncaught errors. The bug is Under Investigation so this may not need any more votes. I could use this in multiple scenarios, both for testing and general error logging.

Include flexcover or create a new code coverage tool. And after this is done, I'd love to see support for this in Flex Builder, something at the same level as the profiler support.

EventDispatcher should expose list of attached listeners.

Headless player for unit tests. I heard at MAX last year that it's possible that the Ichabod player that's being used for search could be repurposed for this, which also has some tricks in it for not waiting as long for code to run. Having a headless player that could also run unit tests faster would be fantastic.


Flex SDK improvements

I want to first note the absense of Spark bugs and improvements in here. I've spent most of the last year working in straight ActionScript rather than the Flex framework, and so while I've read a lot about them, I haven't had much time to play with Spark components and Catalyst. They look interesting and helpful, but until I start building things with them, I can't add anything it to my requests. And I'm not sure many of my requests would be higher than the other items on this list.

Even faster compiles. A lot of work went into Flex 4 for this, but an even faster compiler would make me even happier. This isn't necessarily a Flex SDK thing, and there is a Flex Builder bug open for this. Since that's the top-level, with possible work needed at the Flex SDK and AS3 level as well, I'll put my vote there.

Binding improvements. What improvements are needed would just be based on what would most help out the performance of an application that uses bindings thousands and thousands of times. One-time binding and Support delayed evaluation of MXML bindings are good possibilities.

Allow compilation in the SDK using FlexBuilder project files.


Flash Builder improvements

Flash Builder on Linux. We use xen boxes with Linux at Brightcove and not being able to use Flash Builder there makes me sad. I assume that design view is the problem for this, and having Flash Builder without design view on Linux is is completely fine with me.

Support QuickFix for developer productivity.

Include a code formatter. The third-party plug-in for this that's mentioned in the bug is great, but having built-in support (hopefully leveraging the existing project) is much better.

Include FlexPMD. See the previous comment about built-in support being
better.

Generate Handler in ActionScript.

Expose more of "additional compiler options" in the UI.

Better refacoring support. I've noticed the name of a coworker of mine as the submitter of a couple of the bugs I've mentioned in here, and his name comes up on all but one of the bugs below. Adam Brod entered a lot of much-needed bugs for refactoring, and I think it's good to call out all of the ones I'd like to see below individually to recognize that these can be a very large bucket of things to do (and every one would be appreciated):
Move refactoring
Pull Up/Push Down/Change Method Signature Refactoring
Extract Method Refactoring
Extract Local Variable Refactoring
Extract Constant Refactoring
Inline Refactoring
Convert Local Variable to Field
Extract Superclass
Extract Interface
Use Supertype Where Possible
Introduce Indirection
Introduce Factory
Introduce Parameter Object
Introduce Parameter (not Parameter Object)
Encapsulate Field
Create Script (refactoring scripts)


Other Requests?

If you find yourself agreeing to a lot of the bugs above and have other bugs and features that you'd like to see done, please link to them in the comments so that I can vote for them. Thanks!

Posted by Brian at 12:21 PM

August 2, 2009

Flex Compiler Extensions

In the latest Flex 4 SDK builds, you can write Flex compiler extensions which allow custom Java code to be inserted into the compiler. This is thanks to SDK-18718 and the work of Andrew Westberg.

I'm very interested to see the extensions that come out of this. Here's some possibilities:

  • custom metadata processing that's similar to Java's annotation processing, which someone is already working on
  • a better-integrated version of flexcover
  • different databinding solutions
  • conversion of more media types for embedding
  • SWF size reduction with new compiler optimizations
  • Posted by Brian at 11:05 PM

    July 26, 2009

    Flash on Phones

    I'm a week late in my posting on this, but as I've been horribly behind in my posting lately, I'll just ignore that fact. And I still wanted to be able to point out the Flash multi-touch goodness. I can't wait to see the finished APIs and play around with them.

    Relatedly, while Brightcove has had an iPhone integration for awhile, I didn't realize that other people were watching video through Skyfire, which will soon be making its way to Blackberry devices.

    Posted by Brian at 9:43 PM

    June 8, 2009

    Flash Builder 4: It's Fast

    I just did some stopwatch performance tests of Flash Builder 4 against Flex Builder 3, using the same files that I did for the faster Flex 3 SDK tests. Here are the results:

    Build All, in seconds, after changing two UI classes
    Flex 3: 42.5
    Flex 3 fast: 36
    Flex 4: 38
    Flex 4 with libraries: 26.5

    Build All, in seconds, after changing a ModelLocator
    Flex 3: 47
    Flex 3 fast: 36.5
    Flex 4: 34
    Flex 4 with libraries: 26

    The projects with libraries were very impressive. For these admittedly simple performance tests, I'm seeing the best Flex 4 project as 70% faster than the regular Flex 3 project.

    The "Flex 3 fast" and "Flex 4" results are so similar because some of the improvements are already in Faster Flex 3 SDK. This was unexpected to me, so I ran a few more tests. Sure enough, some more complicated compilations showed more of an improvement for Flex 4.

    The "Flex 4 with libraries" test took advantage of the library sharing and other multiple project work that has gone into Flash Builder 4. The project that I was building was divided into three library projects and one main project. The library projects only have acyclical dependencies, which likely made the compilation easier.

    More details on the test: the Flex 3 tests were done in Flex Builder 3 using 3.2 or the modified version of 3.2 from the faster Flex 3 SDK page. The Flex 4 tests were done in the beta of Flash Builder 4. The project was simply converted for Flash Builder 4, and only two simple changes to the code were needed to build the project. I only reran two of the three tests from the Faster Flex SDK page for no good reason. I ran each build a few times and averaged out the results.

    Posted by Brian at 9:53 PM

    May 25, 2009

    Image Effects in AS3

    If you want to know more about manipulating images in Flash, I have an excellent new book to recommend. It's Foundation ActionScript 3.0 Image Effects by Todd Yard, a coworker of mine at Brightcove.

    I was the technical editor of the book, and I really enjoyed reading it and learned a lot about a lot of AS3 APIs that I haven't used before. It goes over the basic drawing API, blend modes, many other bitmap manipulations, Pixel Bender, the Flash Player 10 3D APIs, a custom (and newly open sourced) animation and effects library, text effects, video effects, and more that I'm sure I'm leaving out. Outside of the book, there's the new library I just mentioned as well as a huge numbers of samples that can be used in Authoring or Flex/Flash Builder.

    This is in the same series (and a great followup) to Keith Peter's ever-popular Making Things Move book.

    Posted by Brian at 1:46 PM

    April 25, 2009

    The Demand for IFrames in Flex

    No matter what I've tried, the demand for iframes in Flex doesn't go away. Recently there's been a number of interesting comments on an old post of mine about Embedding HTML in a Flex application using an IFrame. Dennis wrote new instructions for using the code in Flex Builder 3, ariel linked to an issue with Firefox zooming, and Kedungwuluh linked to an example application.

    All of these comments come after I've essentially stopped commenting on the iframe posts that I've written. There's also some great alternatives, as linked in the Embedding HTML post, which have had more active development than my solution. And most importantly, I've written Don't Use IFrames for HTML in Flex which I prominently link to in the Embedding HTML post.

    But my passive and active attempts at moving people away from the iframe post hasn't worked at all. The post is consistently the most popular on this blog, getting about 3500 views a month, and the 159 comments keep growing. Of course, writing all this new information isn't going to help, but I don't think it really matters. Obviously the solution is good enough for a lot of people. And there's a lot of people still searching for a really good solution for HTML in Flex.

    Posted by Brian at 9:49 AM

    April 12, 2009

    Boston Flash Platform User and Design Patterns and Beer at Brightcove Group

    The Flash platform user group at the Brightcove office has been going through a bit of an identity crisis lately. The sessions used to be focused on design patterns, but lately we've been veering off into the general Flash platform territory. This has led to some great talks, but it's a little confusing. It can't be called the Boston Flash Platform Group, as this is an offshoot of the meeting in Brookline. So how about my name in the title of the post? Everyone will remember BFPUDPBBG.

    In any case, the group is always looking for good speakers, whether it's talking about design patterns, a new open source project you're working on, or anything else you can dream up about Flash and Flex. Want to talk? Send an email on to boston.flash.platform@gmail.com, and Sam Robbins (or if he's busy, Doug Martilla or me) will get back to you.

    Want to learn more about the group? Join the mailing list, which will also tell you about the meetings in Brookline.

    We're always happy to welcome new people to the group, whether for one meeting or every month. You'll always learn some new things, have some pizza and beer, and can join us at Characters after the meeting. Check the mailing to make sure, but they almost always occur the first Wednesday of the month at 7pm. They're at the Brightcove office, which is right near the Kendall Square subway at One Cambridge Center. Just go inside the building and tell the security officer why you're there. You can then go up to the 12th floor and someone will let you in.

    Posted by Brian at 4:57 PM

    Bindable Getters and Getting Faster

    We had a "bring your questions" session at our last Boston Flash User Group meeting at Brightcove, and I thought three of the items I answered would be helpful for more people to read.

    Bindable Getters: If you're creating a component for someone else to use, you don't have to expose a setter for a bindable property. It's not very obvious that you can just expose a getter from the documentation, but it's simple to do. When you set up the getter, name the event for the Bindable property:

    [Bindable(event="changeMyProp")]
    public function get myProp():String {
      return _myProp;
    }

    Then when you set the value for the property, dispatch the named event. That's it:

    _myProp = "my value";
    // dispatch the event so that bound listeners know about the change
    dispatchEvent(new Event("changeMyProp"));

    Public MXML: Also on the subject of creating components, it was asked whether one should choose MXML or ActionScript for a class that's being used as a component. In general, I suggest to use ActionScript. This is because of all the public variables that are exposed when you use MXML, since all of the UI elements set up in the XML are public. This violates the open/closed principle and can be a problem for components that are used outside of a small project.

    Fast and Stable: If you've been unsure if you can use the Faster
    Flex SDK
    for your own project, it should make you feel better that it's being used to build the Brightcove players that run on the New Yorks Times and many other major websites. So if you're concerned about the stability of the changes, I wouldn't worry about it. It's also being used at Brightcove to build some very large Flex manager applications without any problems.

    Posted by Brian at 4:44 PM

    March 25, 2009

    I'm on The Flex Show

    I'm on the latest episode of The Flex Show, where I talk about making changes to the Flex SDK and the Faster Flex 3 SDK.

    It was a lot of fun to do the interview with Jeffry Houser and John Wilker, and I'm glad they gave me the opportunity to do this. They've interviewed nearly everyone I read or admire in the Flex world, so make sure to check out the other podcasts if you haven't already.

    Thankfully they cut out the part where my phone rings and the other amusing parts. Although I need to respond to one of those missing pieces: yes Juan Sanchez, I do like quesadillas.

    Posted by Brian at 10:35 PM

    March 11, 2009

    Flex SDK Hackery

    I presented at the Boston Flash Platform User Group (Brightcove office edition) tonight as a last-minute fill-in. I put together the following presentation which gives details on making changes to the Flex SDK. It doesn't have too much information in it, but people at the meeting asked for it to be posted for the links. And it should fit in well with my upcoming interview on The Flex Show.

    Posted by Brian at 9:33 PM

    U2's Flash Site

    In honor of U2 playing in Boston tonight, here's some emails between my wife and me today. She's a big U2 fan and just found they're playing again in Boston in September.

    Betsy wrote:

    This is the stage- this is amazing!

    http://360.u2.com/

    Brian wrote:

    They need to work on their programming skills, got a Flash error in the debugging version of the Flash player. :P

    TypeError: Error #1009: Cannot access a property or method of a null object reference.
    at Main/initSound()
    at Main/init()
    at Main/frame5()

    Brian wrote:

    Well that's cool though, that's some good Flash 3D. I bet they are using Papervision3D, what everyone is using for 3D in Flash.

    Betsy wrote:

    Could we talk about U2?

    Posted by Brian at 9:20 PM

    February 22, 2009

    Fighting Brain Crack: Goodbye swclibrary.com

    I read John Wilker's post on fighting brain crack, getting rid of the ideas that stick around in your head forever even though nothing is done with them. Immediately one thing came to mind: swclibrary.com

    I registered this domain name, along with swclib.com, in October of 2005. I was working on the Flex team at the time, and my development of compc and asdoc led me to see the need for a good component site for Flex. I was envisioning something like ScaleNine (which wasn't around yet) for SWCs.

    Through the years, I've held on the domain name and some notes on the idea. And through the years, other components sites have come along:

    • FlexBox, which isn't being updated anymore but which still brings in a surprising number of hits to my blog for the HTML component.
    • Adobe Flex Exchange , which has a grab-bag of components, themes, and applications.
    • FlexLib, which isn't really a component site but a group of open source components that a lot of people use.
    • The flex.org component site, which probably has the best list but which needs some interface love.

    None of the sites felt quite right to me, so I kept the idea around. Then another big change to Flex got me thinking about it again, as the Gumbo component model will bring about a whole new set of components.

    I still had it somewhere in my head when I recently saw Jeffry Houser's FlexTras, but the idea is so far back there that the idea didn't move an inch.

    So it's time to come clean with myself. My off-work computer time has been full of Brightcove dabbling or blogging, and I plan to keep it that way. The domain names won't be renewed, I'll delete all my notes, and I'll keep fighting the good fight against brain crack.

    Posted by Brian at 11:20 AM

    February 15, 2009

    Flex 4 Compiler Speed

    The piece that I've been most excited about in Flex 4 is the faster Flex compiler. So I was interested to see Enrique's post on some of the speedups. To quote, "The performance test suite went from full compiling in four minutes with Flex 3 to two minutes with Flex 4." I expect it to be even faster when the final version is done, and this will be immensely helpful to large projects, like the ones I work on at Brightcove.

    Another article on the subject in the Notes on Compiler Improvements from the Gumbo specs. It's a low-level look from a compiler guru at Adobe who's looking into how to speed up the ActionScript compiler. Most of it won't be of interest if you haven't looked into the compiler source code, but the graphs at the end provide some insight into the progress.

    For some Flex 3 compiler information on this blog, you can check out A Faster Flex 3 SDK and Flex Compiler Resources.

    Posted by Brian at 10:30 PM

    January 13, 2009

    Comments Are Off (Temporarily)

    Sorry if you're coming here to comment between January 14th and February 2nd, as comments will be turned off. I still get a few spammers who sneak through ever week, and I'd rather not let them get away with it. So I'll be turning off the comments as I go get married and spend some time in Costa Rica. It's nice get off the grid for a bit, something I haven't done for a few years. Not that I'd have much of a choice in the matter- I have a suspicion that my soon-to-be wife would have a bit of a problem with me posting to the blog in the next week...

    While I'm away, you should see some articles appear on the Brightcove developer center from me. There will be one that gives an overview of the advertising SDK as well as one on advertising in custom templates.

    Posted by Brian at 1:08 AM

    December 27, 2008

    A Faster Flex 3.2 SDK

    I've updated the post A Faster Flex 3 SDK with the files for Flex 3.2. If you're using Flex 3 and Flex Builder, I'd suggest checking out these changes for a significant performance boost.

    My apologies to those who were patiently waiting for these changes to be ported to Flex 3.2. It's been a little busy here, between the holidays, some interesting work for Brightcove, reviewing a book, and the little fact that I'm getting married in three weeks. Happy Holidays to everyone!

    Posted by Brian at 12:34 PM

    December 21, 2008

    Tools for Brightcove Developers

    With the recent news about the Brightcove API partners, I wanted to go over some of the tools for those API partners and more importantly, for developers creating websites using Brightcove.

    Features

    There's four major areas in Brightcove 3 to focus on: the media API, player XML (BEML), the player API, and the ad API. There's a lot more information in the linked documentation than I could mention here, and you should be able to get a good idea there of how you can manipulate players, videos, playlists, etc.

    I've been working a lot on the ad APIs, and I'm always happy to answer questions on them (just see the next section). We've doing a lot to make it easier to integrate new ad platforms with Brightcove, which you can see in the ad translator and ad SWF documentation.

    Community

    Brightcove has been working a lot on the documentation and community on its site lately. You can see this in the development help, which includes links to the new forums and development documentation. There's also still the Yahoo group brightcove-dev.

    Recent Changes

    We continue to release new updates that include changes that are helpful for developers. On help.brightcove.com, you can get a general overview of the changes in Brightcove 3.1 and Brightcove 3.1.1

    Some of the notably recent changes include additional player templates, a player SWC, and new player logging.

    Thoughts?

    So what do you think is missing above? What developer tools does Brightcove need to work more on?

    Posted by Brian at 3:47 PM

    November 20, 2008

    Day 3 at MAX

    Here are my notes from the third and final day at MAX. It includes info on searchable SWFs, Google working on external media in SWFs, Cairngorm tips, new Cairngorm directions, the Marshall Plan, and Salesforce services.

    Flex Framework Features to Support Large Applications

    The Marshall Plan in Flex 3.2 allows an app to utilize sub applications built with different versions of Flex.

    Limitations- needs full sub applications, styles aren't marshalled, resource bundless aren't marshalled, drag and drop requires extra work, mouse and key events need to be listened to differently, sub applications must load their own RSLs, need to create a different domain to use AMF, doesn't prevent different sub applications from reach into each other, and can sort of create subdomain security with a lot more limitations.

    My take-away from this session was that I won't be using the Marshall Plan for any applications anytime soon. But it was still very interesting to hear more about ApplicationDomain and SecurityDomain. I thought that ApplicationDomains were very similar to Java ClassLoaders, but I now see the distinctions.

    The Searchable SWF File

    Previous solutions for a searchable SWF were workarounds using swf2html or attaching xml to a page. Adobe and Google have worked together to make SWFs show up in Google results.

    A special version of the Flash Search Player (Ichabod) steps through visual states and gets the text. It only finds text fields that would actually be shown in the display list. Ichabod must be fast, so it executes faster than real time and doesn't render. Since it must be deterministic, there's no network access, sockets, or threads (sound). Thinking about providing a version of Icabod that's available to everyone to allow you to search SWFs yourself.

    If you use SWFObject or Adobe detection kit to embed, your SWF will be found. Other Javascript embeds may not be found, but they are looking into improving this.

    If you load in any external media, this currently won't be used within the SWF. But Adobe has fixed their side of this issue, and it just needs some work from Google to work correctly. It's expected that when Loader.load() is used, Google will fetch or get a cached version of the call. An example of this from the Adobe side was used with the Flex store.

    What's next, in no particular order:
    1. Dealing with external media, as mentioned above.
    2. Deep linking. It doesn't currently deal with unique URLs for different states in a SWF, but they're trying hard to get this done.
    3. Partner with Yahoo and other search engines.
    4. Getting accessibility text.
    5. Thinking about getting metadata from progressive download videos, especially with the work at Adobe for getting text from video.

    It's possible to use Ichabod for unit tests if this player gets released. It could be extremely helpful for this, since the tests would run much quicker.

    The questions at the end turned into a session on how to try to thwart the system. I'm not going to post the suggestions that came out of it, but it was pretty creative.

    Building Business Applications in the Cloud with Force.com and Adobe

    He listed about 40 things that you need to have to be a platform as a service- data center, disaster recovery, sharing, integration, authentication, API, workflow, monitoring, updgrades, backup, etc, etc. A good list to show all the things that you may not think about when you do a service yourself. "It's more than just imaging a server and putting it up in the cloud"

    Some interesting numbers: 150M+ transactions daily with an average speed of 210ms. ~37% global deployments. Allow people to create any schema they want: 8,700,000+ schema edits. 160,000 SQL statements per second. 1.75 billion API calls per month. 28+ billion total API calls.

    Created an ActionScript library for using salesforce services. They have a SWC which can be used to query salesforce.

    The web services have 1 noun and 19 core verbs (and 4 verbs constitute 90% of usage). Batch based API. Architected for high volume and high velocity. They create revisions of their API and are now at the 14th generation. He says that people have integrations that have been running for 8-10 years which have barely changed at all.

    Unrelated to the above, but which I heard after the Salesforce session, it that the Flex framework RSL is cached by over 50% of users in the US. I'm not sure how this was calculated, if it refers to a specific RSL, etc. But that's surprisingly high to me.

    RIA Development with Cairngorm: Tips from the Experts

    This started out with a general explanation of Cairngorm, which I didn't take notes on. Lots of great info like this is available on cairngormdocs.org

    They showed off a refactored version of the Cairngorm Store. As part of this and in the middle of the talk, a lot of excellent suggestions were given for working with Cairngorm. Here's some of them:

    1. The presentation model works well for large applications.
    2. Can use the model for functions which are called from the view and dispatch events. This function can send a result handler through the event and handle the result itself (instead of setting the model directly in the command).
    3. Models should be passed down to components (instead of calling ModelLocators directly). Call ModelLocator.getInstance() in the view only once! Do everything else with data binding.
    4. Responders should be used used to handle service requests. It can be helpful to have a base class to implement a common fault method.
    5. Anti-pattern: the fat controller. Group controllers in functions or create sub-controllers.
    6. Anti-pattern: model locator landfill. The model locator should not store properties. Group properties into clases, ie presentation models.

    They also informally announced the Cairngorm Committee, which will guide the future of Cairngorm. I'm happy to say that I'm on this committee.

    It's "all about the timing" for when to use Cairngorm, different project structures, different patterns. It's not about doing everything up front, which can mean that business value can't be shown quickly. But it's also not good to wait too long and cause even more pain, either.

    They're thinking about using inversion of control instead of ModelLocator- something for the community to think about.

    They demo'd the Cairngorm Plugin which creates commands and events easily.

    Posted by Brian at 1:31 PM

    November 19, 2008

    Day 2 at MAX

    Here are my notes from the second day at MAX. It includes info on the keynote, development best practices with Flex, Flash security, RTMFP, and speech to text.

    General Notes

    A lot of people were interested in the basics of Brightcove but didn't know a lot about the technology. I've been meaning to write more about certain areas for awhile- advertising, BEML, a few other things- and this reminds me to do this.

    I got a lot of comments on the compiler update I've released, and I appreciate all the comments on it. But I want to make clear again that I didn't make the compiler changes myself! I've merged the changes from the Flex compiler team- thank Paul Reilly and the rest of that group for doing the real work.

    Keynote

    Besides making me go slightly deaf with the sound system, they showed off a lot of new features in CS4 and other products. They showed off a literal copy and paste from CS4 applications to Catalyst which was then turned into components. This round tripping is done through FXG support in CS4 applications and Catalyst.

    I saw Alchemy again as they showed the following demos in Flash: open SSL encryption, decoding of Ogg Vorbis, decoding of RAW images, showing PDFs in Flash, Doom, and Mario. The showing PDFs is particularly interesting for the future of the Flash player and the Adobe Reader. I wonder if some of PDF viewing will switch over to the Flash player?

    On the .NET front in Flex, they have a partner plugin to Visual Studio and a possible C# version of BlazeDS.

    In addition to multi-bitrate and RTMFP, they showed off an interesting live feature in FMS. You can now record a stream and stream it live at the same time to have a DVR-like experience.

    Developer Best Practices With Flex

    This session was about developer best practices with Flex with a particular focus on using Catalyst. There was quite a bit a talk about general engineering practices that should be used in Flex as they should be used elsewhere: use coding standards, comment code, and use design patterns. Nothing too surprising in this part of the talk other than advocating code behind, which I don't think works very well for Flex.

    They talked about various things that developers should do to prepare their projects for Catalyst development, such as applying metadata to files and laying things out properly. There will be a lot more code-level interaction with designers when Catalyst is used.

    One more interesting note, something which I didn't know yet, is that Catalyst is built on Eclipse.

    Flash Security: Why and How

    This was an explanation of content restrictions with the Flash Player. Deneb had a few overriding rules for Flash security: use least privilege, validate input, deploy HTTPS consistently, prototype early, and keep track of security changes.

    You need to call Security.allowDomain() if a SWF loads from another domain. This allows the SWF you are loading to call things within the parent SWF. The wrong way to do this is to call Security.allowDomain("*"). "There are rare times when you might want to do this."

    You need to specify allowScriptAccess or allowNetworking in the HTML to allow your SWF to script the HTML from a different domain. allowScriptAccess set to never isn't used anymore because there really isn't a way in Flash to stop same domain communication between the SWF and a browser.

    Data loading requires permission because it's data that the user can access but not necessarily data that's publically available. So a cross-domain policy file is required so that the server gives permission for the data to go elsewhere. Flash is also the first client to allow direct cross-domain data loading, although browsers are looking into similar abilities in HTML5.

    You must use a socket policy file with any socket connection (including the same domain).

    You need to specify allowInsecureDomain() to allow HTTP connection when HTTPS is being used in the main SWF. This can cause a man in the middle attack. Allowing HTTP content in HTTPS is even worse.

    Sneak Peeks

    I saw RTMFP yesterday, but there was a live demo of the many-to-many feature in progress today. RTMFP application-level multicast allows for many-to-many broadcasting, live streaming from one client to many clients without using a server.

    Nitro is a platform to create Flash widgets which can be distributed to desktop, Web, TV, and mobile.

    Content Intelligence Toolkit can find different scenes in a video and give information about each scene in metadata: lighting, activity, etc. Includes tracking of faces, and most impressively, speech to text of the video.

    Posted by Brian at 3:25 AM

    November 18, 2008

    Day 1 at MAX

    Here are my notes from my first day at MAX. It includes info on the keynote, using C/C++ libraries in Flash, Python in Flash, Thermo (aka Catalyst), RTMFP, and peer-to-peer communications.

    Keynote

    The keynote presentation had a major focus on "The Flash Platform", which includes the Flash Player, Flex, etc. It's was the main thing talked about by Shantanu Narayen. Nearly everything that CTO Kevin Lynch talked about were in Flex, Flash player, AIR. He also talked about "Mobile first", thinking of mobile design before thinking of desktop view.

    There was an amusing mention of MLB.com and a NY Times AIR app. Both of these are conversions from Silverlight, two of the largest reference applications that I've heard about for Silverlight.

    My favorite part of the presentation was the Salesforce VP talking about "platform as a service". A quote that got a big reaction: "For 20 years, enterprise software has been where innovation has gone to die." The speaker thinks that Salesforce is changing this with cloud computing, Flex frontends, and their development platform. They have a massive development platform- 87,000 custom applications on force.com, tons of apps on appexchange.com

    Lazy Innovation: Strategy for the Design of Innovation User Experiences

    This was a presentation by Adobe Consulting. I didn't take any notes from this presentation. I heard that at a different presentation at this time Ely Greensfield was going to mention me for my porting of compiler SDK work. But I was cut out of the talk, in the interest of time. My 15 minutes of fame has been thwarted.

    Using C/C++ Libraries in Flash Player and Adobe AIR

    There was so many people just grinning with excitement at this talk, before and afterwards. This is research project at Adobe, now known as Alchemy and released on labs.

    It's based on LLVM, has partial POSIX emulation later, full port of the BSD standard C library (which is about 140 KB), and partial autoconf support. There's a C/AS3 bridge API athat llows access from one language to the other. There's also experimental support for debugging the C code from Eclipse while the code is running in the Flash player.

    Surprisingly enough, and I'd like to learn a lot more about this, is that they see it run up to 25x faster than hand-written AS3. This is due to the AS3 API added and code optimization from LLVM.

    They showed examples of using C++ libraries, using libpng library to encode a PNG, tracking an item through a web cam, and a voice synthesizer.

    They have converted Perl, Python and Ruby interpreters, and they do run. So you can have these languages hosted within a Flash player. There's some work that still needs to be done to make this easier to use, but Python can now be interpreted at runtime within the Flash player? Wow.

    Introduction to Thermo (aka Catalyst)

    Thermo, now knows as Catalyst, was the hot topic of the day. This was a sold-out session, and they added a second session which sold out as well. Two quotes which sum things up to me: "Let designers design the entire interface, not just component skins." "Allow designers and developers to work in parallel."

    An important note from the middle of the presentation: at least a year away from releasing the product.

    Flex is spreading out from just being code-centric tool. Extending out to designers through Flash Catalyst, Flash Pro CS4 support, and FXG.

    Create graphics in MXML (in FXG) format using Photoshop, Illustrator, and Fireworks. Support for this is available today. Skins can be visually designed through FXG. Merge tool for conflict resolution within Flex Builder for dealing with Catalyst changes. Obviously trying hard to deal with round-trip development, which is essential.

    They also went over Flex Builder improvements for Gumbo, a huge list of interesting things: network monitor, improved compiler speed, reduced memory consumption, move refactoring, ASDoc tooltips in code hints, file templates for new classes, event handler generation, debugger expression evaluator. FlexUnit support, and more.

    Future of Communication with RTMFP

    RTMFP is Secure Real-Time Media Flow Protocol. It's a new alternative RTMP in the player.

    RTMFP is based on UDP, which allows it to do a number of things that RTMP can't, since it's based on TCP/IP. It has a sophisticated protocol based on top of UDP: multiple parallel media flows of messages, variable congestion response, allows for peer-to-peer applications, fast recovery from brief outages, and IP address mobility.

    Developers just need to change the protocol in their URL to use RTMFP. It requires port 1935 and multiple high UDP ports. There's no tunneled counterpart as there is in RTMP.

    Peer to peer connections are a new use in RTMFP, which allows media to bypass FMS and travel directly between Flash players. FMS still used to introduce the peers and server still available if firewall blocks or RTMFP connection can't be made. In order to use this feature, need to add one parameter in NetStream code to get and identify the publishing id.

    Stratus, available on labs, makes RTMFP available for use today.

    Future possibility in RTMFP includes "groups", self-organizing overlay networks of peers. This may work with a "Groupspect" instead of a publishing id.

    Posted by Brian at 3:07 AM

    October 29, 2008

    Going to MAX

    I'm happy to say that I'll be heading to the MAX conference in November. I'm expecting an excellent conference given the hard-to-pick sessions. I'm also looking forward to saying hello to old and new friends, as well as the people you usually just read online. Anybody who would like to say hello or who would like to take a peek at Brightcove 3, send me an email at brian at deitte dot com.

    Posted by Brian at 8:48 PM

    October 26, 2008

    A Faster Flex 3 SDK

    At Brightcove I've spent some time creating faster Flex 3 SDKs by merging some changes from the Flex 4 SDK. It's not a lot of changes, but it makes a fairly significant improvement in compilation speeds in Flex Builder. I find for small changes in a large project, there's about a 20%25% speedup, but this varies greatly depending on what you're doing. I'll give some performance numbers below and explain exactly what changed, but first I'll show you how you can use these changes yourself.

    Using the Changes

    Here are the files you'll need, with one zip file for Flex 3.0, Flex 3.1, and Flex 3.2:

    fast-3.0.zip
    fast-3.1.zip
    fast-3.2.zip

    Inside of the zip files you'll find jars that should overwrite existing files in FLEX_SDK/lib, where FLEX_SDK is the location of the Flex SDK you are using. If you are unsure of this location and you are using Flex Builder, you can find it in the "Properties" for your project. Select "Flex Compiler", then select "Configure Flex SDKs". If you "Edit" the SDK listed, you'll see it's location.

    There's another zip file that you can try out, which contains some more changes from Flex 4. Given the number of changes, I've labeled it experimental. There's only a Flex 3.0 version:

    fast-experimental-3.0.zip

    Performance Numbers

    For fast-3.0.zip, I ran some tests on the building of the media module at Brightcove:

    Changing the main MXML file: from 13 seconds to 8 seconds
    Changing two UI classes: from 41.5 seconds to 34.5 seconds
    Changing a ModelLocator: from 47 seconds to 39 seconds

    Why I Did This

    Now that I've given out the files and shown the performance, I'm sure I've lost half of the readers as they go update their SDK. But for those of you still here, I'll explain things more. As you may have seen in a recent post of mine about ways to speed up Flex Builder, I've been working on strategies at Brightcove for increasing everybody's ability to work quickly on Flex and AS3 projects. As a part of this, I've been very interested in the Flex 4 performance changes.

    I talked to Paul Reilly and Pete Farland at Adobe a bit about my work, and they thought what I was planning to do made sense. Paul also suggested that I try to use Flex 4 directly. I did try this, but I ran some issues. It also just wouldn't work out to have everyone use the pre-alpha of Flex 4 on a large codebase at Brightcove. But I still wanted to use some of the performance changes. That's not a problem when a project is open source, thankfully! I used svn to merge some of the changes back to Flex 3, and we've been using these changes at Brightcove since then.

    More on the Changes

    Here's are the diffs for fast-3.1.zip and fast-experimental-3.0.zip. I'd have to remake the changes to get the diffs for fast-3.0.zip, but I believe they're identical to fast-3.1.diff and fast-3.2.diff.

    fast-3.1.diff
    fast-3.2.diff
    fast-experimental-3.0.diff

    The subversion changes I merged for the fast versions: 2850,2931,2941,3290,3369

    The subversion changes I merged for the experimental version: 1237,2001,2627,2673,2850,2931,2941

    fast-3.0.zip is based off of 3.0.1.1092, fast-3.1.zip is based off of 3.1.0.2710, fast-3.2.zip is based off of 3.2.0.3958, and and fast-experimental-3.0 is based off of 3.0.1.1092. The 3.0.1.1092 version was used for the Flex 3.0 changes because 3.0.0.477 doesn't have the asc compiler. There are barely any changes between the two versions of the compiler.

    The experimental version had a lot of merge conflicts that I'm not positive I merged correctly. I've been using it myself a lot, and it's definitely faster. I can't wait to see the speed of Flex 4, which has a lot more changes that I didn't try to merge.

    Posted by Brian at 6:18 PM

    October 14, 2008

    Brightcove 3 Now Available

    When I had posted the screenshots of Brightcove's new Flex applications two days ago, I had forgotten what was happening today. Brightcove 3 is now available, and if you talk to our friendly sales department, you can now see the new Flex and AS applications we've been creating. And I can now talk about it all.

    Some of the things I'm excited about in Brightcove 3:

    • BEML (Brightcove Experience Markup Language), an XML markup language for creating players. It has bindings, hbox, label, and a bunch of other things that will be familiar to Flex developers, and it'll allow everyone to create new players quickly.
    • Fast and light AS3 video players. Part of the lightness is accomplished by a lot of SWF loading to only load in what is needed.
    • Well-designed Flex 3 applications for managing videos, players, advertising, reports, etc. These are applications that we've been working on for more than a year and are already being used by large publishers to manage thousands of videos.
    • More media, player, and advertising APIs. You can access all of this in AS3 or Javascript, accessing the videos or controlling your videos in too many ways to mention here.

    There's a lot more to talk about in the items above, but I'll have to leave that for another day. Some helpful links for learning more about Brightcove 3:

    Posted by Brian at 8:13 AM

    October 12, 2008

    How Do You Speed Up Flex Builder?

    I've been spending some time at Brightcove trying to figure out ways to speed up Flex Builder for some of the larger applications we're developing here. I have a few things I'm working on myself, but I wanted to hear what others have done to improve the compile times in Flex Builder.

    Here are some of things we do:

    • Build every application in one project using multiple source paths (instead of using extra library projects)
    • Build parts of the applications as SWCs (instead of referencing their source paths)
    • Close extra projects
    • Use a system font instead of embedding fonts
    • Run "eclipse -clean" occasionally
    • Turn off "Copy non-embedded files to source folder"
    • Turn off "Build Automatically"

    Things we haven't tried or just trying now and which may be helpful:

    • Build a lot of the application as SWCs or anything as an RSL
    • The Hellfire compiler
    • Use the Flex 4 SDK (or just the compiler portion) with Flex Builder
    • Merge some of the many Flex 4 compiler performance changes into a Flex 3 SDK, and using this in Flex Builder

    I should explain the last two items a little bit more. I've been watching the Flex 4 changes related to compiler performance with a lot of interest. There's an incredible amount of work going on there, and we can all expect to see some major improvements.

    Do you have any other suggestions, unique hacks, custom workarounds? What do you think of the things we haven't tried? I'd love to hear everything, even if it seems specific to your situation.

    Update: See A Faster Flex 3 SDK for another option for speeding up Flex Builder.

    Posted by Brian at 4:48 PM

    Screenshots of Brightcove's New Flex Applications

    Brightcove has announced a major upgrade to its features, and now I can show a few screenshots of the Flex applications. Or rather I can link to some leaked screenshots on TechCrunch. It's a bit confusing if you just look at the page for the screenshots, as it includes both the old Brightcove and the new Brightcove. But once you know that, it's easy to tell which ones are new.

    The home page is HTML, but the rest of the new screenshots show Flex 3 applications. This was a large undertaking by a lot of people here at Brightcove. I'd love to write some more about this, but I'm going to have to wait until it all goes public.

    Update: You can now read a lot more about the release.

    Posted by Brian at 2:42 PM

    Even if You Don't Write Music, Check Out Noteflight

    I'm not a composer myself, but I've had a lot of fun playing with Joe Berkovitz's new application Noteflight. It's a pretty amazing Flex app, even if you can't write anything more complicated than Mary Has a Little Lamb. You can read more about it on Joe's blog or flex888.

    Posted by Brian at 2:29 PM

    September 20, 2008

    Flex 4: Two-way Bindings and Other Improvements

    Reading through the subversion commits, I've seen a number of interesting changes for Flex 4.

    Carol Frampton added inline support for two-way binding. Using the syntax of "@{expr}", you can now more simply support two-way binding.

    Paul Reilly has submitted a number of compiler performance improvements, including one which results in significant improvements in Flex Builder.

    Gaurav Jain added support for ASDoc comments in MXML files. "For adding comments at the class level or to properties defined inside mxml use the syntax <!--- comment (notice 3 dashes at the start) -->"

    Posted by Brian at 1:26 PM

    September 7, 2008

    Flex Builder Plug-in for Cairngorm, Code Metrics, and More

    I've been playing with the Flex Builder plug-in for enterprise development, a new add-on to Flex Builder which has some very useful features for the average developer. I'll share below the good and bad of what I've seen.

    The good:

    There's a huge number of features, a lot of things that I want to use right away:
    Enhanced AS3, MXML and Cairngorm wizards
    Cairngorm Explorer
    Flex Code Metrics Explorer
    FlexUnit test and test suite generators
    Flex Package Explorer

    It's been stable for me. That's always a plus for a beta that's being used in your main work environment.

    The bad:

    My main gripe, and the only reason I won't be using the plug-in right now, is that it only picks up the details of the main source folder. In the projects that I work on, most of the source files are in the "additional source folders". The plug-in does not use these source folders to find Cairngorm commands, compute code metrics, etc.

    It'd be very helpful to allow the copying of the text in the code metrics explorer.

    The unknown:

    How many of these features are already planned for the next version of Flex Builder? It's not great for the plug-in, but there's a lot of things in here that I just expect Flex Builder to get to eventually. On the other hand, it does feel to me like there's a lot of niche enterprise-y features to do to keep the plug-in going.

    There's a lot of new directions that the product can go in, a million feature that could be added. I wonder what will happen next? I hope that the product can first make sure the current pieces are solid and start selling the plug-in, as I think it'd be a great addition to the Flex ecosystem.

    Posted by Brian at 10:07 PM

    Update on Using Flex SWCs within Flash CS3

    I wanted to give an update on Using Flex SWCs within Flash CS3?, the post I wrote last week about using framework-less Flex 3 SWCs within Flash CS3. The coworker diving into the problem, Crystal West, has solved the issue, and you'll be able to use the SWC yourself (in time) to build advertising products for Brightcove.

    So what had to change in order to use the SWC in Flash Authoring?

    1. In the compiler arguments, set compute-digest to false.
    2. In the compiler arguments, use include-namespaces and namespace to include the classes. Use this instead of include-classes.
    3. Change main classes that extend Sprite to extend MovieClip.
    4. In the compiler arguments, add flex.swc to external-library-path.

    The first three changes are ones that you can find on other blogs or in the helpful comments to the first post. The last one needs a bit more explanation.

    I assumed we weren't using any Flex classes in the SWC for Flash Authoring, but the Flex classes that are being included aren't referenced directly. It's all classes that come in from Embed statements, which generate code that use Flex classes. Rather than removing the Embeds or creating class-level Embeds, we used the external-library-path to remove the references. Simply pointing to flex.swc within the Flex SDK will do the trick.

    Posted by Brian at 9:04 PM

    August 25, 2008

    Using Flex SWCs within Flash CS3?

    Can you use framework-less Flex 3 SWCs within Flash CS3? I assumed that you could do this if the compatibility-version flag was used and you didn't use any of the Flex framework. I haven't been able to get this to work, however, so I'm hoping someone else has had some luck with this. I've also asked about this on flexcoders, so I'll update this post with any information I learn there.

    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.

    Solution: There's a new post with an update on the issue.

    Posted by Brian at 2:51 PM

    August 11, 2008

    New Flex Blog by Al Manning

    Al Manning has an excellent new Flex blog. Some of you may remember Al from his days working on Spectra at Allaire. I've gotten to know him as a lead Flex developer at Brightcove.

    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.

    Posted by Brian at 11:34 PM

    Improving the Flex Ant Tasks

    I've been looking at ways to improve some Ant Flex builds, and in the process I've added "arg" support to the Flex Ant tasks. I'll show how this can be done below, and I'll also share a bit about my investigation into speeding up Flex builds.

    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.

    Posted by Brian at 11:22 PM

    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!

    Posted by Brian at 5:45 PM

    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?

    Posted by Brian at 10:25 PM

    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.

    Posted by Brian at 5:25 PM

    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.

    Posted by Brian at 11:22 PM

    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.

    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. Posted by Brian at 9:07 PM

    June 19, 2008

    Flex Compiler Resources

    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
    If you know of any resources that I forgot, please leave a comment! Posted by Brian at 12:30 PM

    June 9, 2008

    Please Ignore the Blog Mess (aka Want a Freelance Job?)

    So I haven't played around with the design of this site in a long time, and while it's a pain to do in Movable Type, I figured it was time to do some damage. Apparently I did a little too much damage while watching the Celtics game tonight, as I managed to completely mess up my setup.

    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).

    Posted by Brian at 6:32 AM

    Ignoring the ResourceBundle Deprecation Warnings

    I understand that ResourceBundle has a lot of deprecated methods in Flex 3, but getting a few thousand warnings like this gets annoying:

    "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.

    Posted by Brian at 6:28 AM

    May 29, 2008

    Learning About Flex 4 Through Commits

    I've really enjoyed having access to the Flex SDK subversion commits, so that I can see the actual changes going into Flex 4. I have an email subscription to the commits, which I read over when I find the time. I've seen a couple of interesting things go in:

    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.

    Posted by Brian at 9:38 AM

    The Making of a Platform with Adobe Technology

    Brightcove is using Flex and Flash in many significant ways to make a video platform, and I thought it'd be interesting to some people to share some of the uses. I can't share a lot, but I can take the information from a keynote presentation by Ashley Streb at Webmaniacs 2008. You can also see the full presentation embedded at the end of this post.

    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.

    Posted by Brian at 9:15 AM

    April 13, 2008

    Random Compiler Thoughts, Part II

    I went to the first Boston Flex User Group meeting last Tuesday, and I took some notes through Pete Farland's presentation. This is more of a ramble on the compiler than on the presentation (similar to my previous post on the compiler), although there's a few pieces from the talk below. You can find the PDF for Pete's presentation on his blog. If you want to understand some of comments about the compiler source, you should grab the SDK source from opensource.adobe.com.

    The general talk about the compiler made my mind wander on to SWCs. The SWC format is centered around catalog.xml, a file you can find inside of the zip file which is known as a SWC. Using any normal unzipping tool, you can check out catalog.xml and see the components (what the MXML compiler looks for), classes (for the AS compiler), assets (used by Flex Builder mostly) and features (used by no one). All of this is processed within the flex2.compiler.swc package in the compiler source. The entry-point, flex2.tools.Compc, corresponds to compc. As an amusing aside, compc was supposed to be a placeholder name, something temporary that I submitted until a real name was chosen. So much for temporary, eh?

    ASDoc was briefly talked about, and while looking at the ASDoc Java source will only given you heartburn, there's some other interesting asdoc files to feast upon. The asdoc directory contains a huge number of stylesheets and HTML files which I've never really understood myself. But they're all there for a purpose, and you can play around with these files to completely change the look of your documentation. You don't need to check the source to do this, since it's a directory in the regular SDK as well: asdoc/templates.

    Pete turns off "Build Automatically", and it's always interesting to hear who keeps this turned on or off. (I turn it off.)

    There was a question about native code in the Java code. There's no native code in the Flex compiler, but there is Adobe code that isn't released as open source within jar files. I know there's some font code in there, and probably other pieces as well.

    Data binding does a lot under the covers and produces a sizable chuck of extra code. Joe Berkovitz has written about some potential improvements to this on the compiler mailing list.

    Pete showed a little-known trick for debugging bindings.

    As the discussion went on to classes getting linked in, I wondered about something that I had a discussion about last week, which is whether there is a way to rip out methods within the AS compiler. Given the node transversal in Evalutators within the compiler, it doesn't seem like it'd be too difficult to simply have specific FunctionNodes ignored. I haven't asked any of the AS compiler folks about this, though, and I have a feeling it's not really that simple. But if you could rip out the right methods, then you more-easily remove parts of the framework you know you don't use in a better way than monkey-patching. Or you could take a stab at what isn't used by using a code coverage tool and unit tests to remove methods.

    Pete mentioned that turning off optimize is a way to speed up the compiler. You can do this by setting optimize=false, but I didn't noticed any real difference in the current project I'm working on. It would make sense to me that this would speed up compiles, but I just don't see much of an effect. The optimization code, for those curious, is in flex2.tools.Encoder (for merging ABC blocks) and macromedia.abc.Encoder (for ActionScript peephole optimization).

    Pete went over a lot of other things that what I rambled on within this post, but that's it for my notes. After the presentation, I saw Joe Berkovitz talk with Paul Reilly about the profiler and show a preview of his fantastic code coverage tool.

    Posted by Brian at 11:27 PM

    March 31, 2008

    Code Coverage in AS3, ECMAScript 4, and More

    Here's a grab-bag of links, with the first one being the most well-known on the Flex blogs. I still wanted to link to Joe Berkovitz's post on code coverage in AS3, because I'm excited to see this getting done (and someone making some interesting changes to the compiler). But I don't have much to add to the discussion. Go read Joe's blog for all the good details.

    A new draft of ECMAScript 4 is out, and the mailing list is getting filled with interesting posts on the final proposals. Check out Insurrection, a thread which contains a thoughtful critique of ECMAScript 4.

    I don't see anything interesting happening yet in the commit logs for Flex, but they're fun to watch again.

    Nearly as much fun as the commit logs is seeing random new developments in all corners of the Flex world. I don't keep up with a good fraction of the blog posts on Flex anymore, so I'm sure I'm missing a lot of things like an Emacs mode for Flex.

    Posted by Brian at 10:05 PM

    The Boston Flex User Group

    The Boston Flex User Group starts a week from Tuesday at the Adobe office in Newton. Find out more at the it's-just-missing-drop-shadows homepage.

    There's already a lot of other groups that touch on Flex already- Boston Flash Platform User Group, Boston Design Patterns Group, Adobe Boston User Group, Flex App Incubator Group, and Boston ColdFusion Group. Until I typed them out, I had forgotten how many groups there are. But it'll be excellent to have one that's just focused on Flex, and I know there'll be a better chance for a lot of people to talk with the Flex team, given the location.

    Posted by Brian at 9:38 PM

    March 10, 2008

    Decompiling AS3 and Random Compiler Thoughts

    When the Flex compiler was open sourced, I wanted to get my hands dirty and make a change or two myself. In the first week I dug into the source and looked to make a change to decompile (or rather disassemble) AS3. Of course, after I'd dug into things I realized that Adobe has already done this. And someone created an AIR app. And a commercial decompiler. This is what I get when I don't keep up with my blog reading.

    While I didn't end up making any changes, I'm going to give a partial explanation of this code.

    The entry-point for the AS3 disassembler is flash.swf.tools.SwfxPrinter. If you take a look at this class, you'll see a method for each tag that needs to be handled, with each method taking in a Tag class. These correspond to the different tags in the SWF format. The one that is of interest for AS3 decompiling is DoABC. (To be pedantic, we actually use the DoABC2 version of this tag, which is a bit confusing, but the original DoABC tag was never released.) This is the tag which contains ABC, the compiled AS3 that the Flash Player runs. Going back to SwfxPrinter, you'll see the DoABC method takes this bytecode and through the magic of AbcPrinter prints out all the operations.

    I assumed that the SwfxPrinter would work by parsing Nodes and not directly work from the ABC. As explained above, the ABC is what's actually in the SWF, and it's contained within a DoABC tag. The Nodes are an abstraction of the bytecode that the AS3 compiler uses. It's what is generated within the compiler when you first compile an application, but there's also a way to get Nodes from a finished compilation. You can see this in action within the SwfxPrinter.doABC() tag. Within the showActions code, you can see how the ABC is turned into the top-level Node, a ProgramNode, which then can be printed out via the PrettyPrinter. I tried enabling this code myself, and it doesn't work very well. There's a lot of missing pieces to the output, so apparently everyone should keep using the existing path of parsing the ABC bytecode for printing.

    That's a little more insight into the class used for AS3 disassembling, but it doesn't even touch the real work in decoding the ABC format, TagHandlers, etc. There's always plenty more to learn in the compiler, and hopefully I'll be able to blog more in the future about the parts that I know.

    We were talking about the compiler and ideas for improvements at the last Boston Flash Design Patterns Group, where we stopped talking about design patterns for a week and instead talked about the Flex compiler and the need for more comments. People wanted to know the easiest places to make some changes, and I couldn't come up with much. There's some jumping-off points in flex2.tools.Compiler or flex2.tools.Compc. Changing a Transcoder could be interesting, or adding one to the list in flex2.tools.API.getTranscoders(). If you'd like to try something for fun, you could always alter Grammar.jj to change the core of MXML. Daniel Rinehart is looking at making a change to the compiler, and it's going to be interesting to see all the changes coming in from around the community.

    Update: See Random Compiler Thoughts, Part II for more info on the compiler.

    Posted by Brian at 12:20 AM

    March 9, 2008

    Nevermind This Post

    I've been looking again at Ted's post on Extending Adobe Flash Player and Adobe AIR with C and C++ via ActionScript 3 as well as the video on Quake on the Flash player. I had a long post written, giving my guesses on what's happening. And then I did one last search and realized I missed a great interview by Ryan Stewart, where most of my postulations have real answers. So nevermind.

    Posted by Brian at 11:56 AM

    February 25, 2008

    Open Source Flex Compiler

    Flex 3.0 and AIR 1.0 are here. Congrats to the teams, and I hope they're all getting some sleep now. Even more interesting to me is the open sourcing of the Flex compiler and framework. It's something which may get lost in the shuffle today, especially without a lot of developer documentation out there yet, but there's a lot to dive into.

    Once you get the source, you'll have Eclipse project files in the 'development' folder. You can compile easily and start seeing what you can break. I was just poking around, and I'm remembering a number of interesting files to look at:

    flex2.tools.Compiler, the entry-point for mxmlc
    flex2.tools.Compc, the entry-point for compc
    flex2.tools.flexbuilder.*, the interface to FlexBuilder
    flex2.compiler.as3.EmbedEvaluator and flex2.compiler.*Transcoder, the heart of Embed
    *.vm files like flex2/compiler/binding/BindableProperty.vm for some interesting codegen
    flex2.linker.FlexMovie, the confusing guts of the Flex SWF

    I see something I'm going to look at already, a simple change I'll try to blog about this week.

    Posted by Brian at 12:28 AM

    February 4, 2008

    Vote on Some Deferred Bugs Today

    Sure, if you're in one of 24 states in the US, you should do your civic duty and vote today. But the real voting is going on in Super Tuesday Flex Voting. Adobe has fixed JIRA so that you can vote on deferred bugs, so vote early and often. While Matt's request is for a specific group of bugs, see my previous post on voting to get a full list of bugs.

    Posted by Brian at 11:17 PM

    January 17, 2008

    The Most Voted For Bugs in Flex

    I just read Matt Chotin's post on Addressing Bugs in Flex, and I love the fact that Flex is so open. Unfortunately I don't have a teddy bear to give to the team, but I can give something to the community: a better way to see the most voted for bugs.

    You may have already seen the "Popular Issues" tab in each project, but there's two problems with this view of votes. It's missing the deferred bugs, and it only shows the votes for one project at a time. You can fix both of these issues through a search and sort, but it's not immediately apparent that you can do this in the bug base.

    Use this search to see the most voted for bugs. The most voted for bug, by the way, is design view for Linux.

    With the search above, you can't see the number of votes in the main search listing. This can be fixed, however:
    1. Log In, if you aren't already. After you log in, you should be back at main search listing.
    2. On the right-hand side, click on Configure your Issue Navigator.
    3. Next to Add New Column, select Votes, and click Add.
    4. Go back to the main search listing, and you'll see the votes in the last column.

    Matt said that not much is going to be fixed for Flex 3, but that's just a better chance to vote for big items for Flex 4. I have a humble suggestion for a place to put your votes: more refactorings in Flex Builder. A co-worker at Brightcove, Adam Brod, created a group of bugs on this that await your vote.

    Posted by Brian at 10:00 PM

    January 7, 2008

    FlexSpy, a New Tool for Design

    When I took a trip into HTML/Javascript work last year, I had to make some pages look like a given design. I asked a co-worker at Brightcove, Leonard Sutton, to check over what I was doing. He took one look at my computer and installed Firebug. My CSS work changed completely after this. The Firebug extension has a few purposes, but the most useful function is the dynamic setting of CSS. If you hadn't tried it, it may not seem like a big deal to reload a page on every CSS change... until you've made a few hundred of them. And half of them don't look the way you expect. I ended up making almost all my CSS changes in Firebug.

    Now Flex has a similar tool in FlexSpy (found on riapedia.com). Unlike riapedia, I don't think of this as a "component for developers starting to learn Flex" but rather as a component for anybody making a lot of design changes in Flex.

    Before FlexSpy, when I got handed a design, I'd make a few changes, recompile, navigate to a component (or change code to navigate to it), see the design (which sometimes didn't look the way I expected), and start the process over. This gets very tedious very quickly. Now I can make a change with FlexSpy and see it immediately in the application.

    Hopefully Thermo will make me very happy, allowing me to stay away from more of the design implementation. Until then, I'll be using FlexSpy.

    I didn't see a way in FlexSpy to grab all the changed values, which would be very helpful. I'd also love to have shorter lists for the properties and styles, both a list of the most commonly-changed keys and a list of the keys I changed most often. But hey, it's an open source project, so I only have myself to blame if those features aren't there.

    Posted by Brian at 8:07 AM

    January 6, 2008

    Future Features in AS3

    After reading Keith Peters' post on singleton's and abstract classes, I wanted to see if there was more public information about the state of abstract classes in ECMAScript 4. As most readers of this blog will know, AS3 will be an implementation of ECMAScript 4, and some of the lack of features in AS3 is related to the state of ECMAScript 4. But that also means that we can peer into the future of AS3 by looking into ECMAScript 4.

    I found a bug on bugs.ecmascript.org titled "Private constructors are useful, common, and need to be supported" and marked as Resolved. That's great to read, and it means that someday we'll have a real way to create abstract classes in AS3. (Update: that could be wrong. Read the comments below.) The word "someday" is important here, though, as ECMAScript 4 looks very large, and I doubt anyone knows how long it will take to implement it all.

    ecmascript.org has a lot more information to dig through, such as the proposals section of the wiki. There's way too much to read here that's interesting, but here's a few that stood out to me: type parameters, resurrected eval, generic functions, and Meta-object. Just this small snippet of the proposals page includes information on generics, method overriding, and class reflection.

    Posted by Brian at 4:57 PM

    Write a Book on Flex?

    I've been thinking about co-authoring a book, and so Jesse's recent post and Joe's response really interested me. I've been meaning to ask on here for awhile: any authors have any advice or suggestions? All comments, happy or bitter, are appreciated. If you don't want to comment here, you can send me an email at brian at deitte dot com.

    Posted by Brian at 4:27 PM

    December 16, 2007

    Thinking About BlazeDS with Amazon ES2

    With the current focus on Amazon's services (because of the release of SimpleDB) as well as the release of BlazeDS, I was wondering whether Amazon Elastic Compute Cloud (aka EC2) could be used with BlazeDS. I know that people set up Tomcat on EC2, and it'd be pretty interesting to start using BlazeDS on projects so easily.

    Reading about EC2, I see that there's two ways to get data from your application, SOAP and a query API. The query API looks like it would work fine for getting AMF information from an application. I assume, however, that some changes some need to be made to Flex channels and adaptors to work with the request signatures required by Amazon? I don't know enough about EC2 or BlazeDS to answer this question, or to know whether StreamingAMFChannel would work. But I'd love see instructions on creating an Amazon Machine Image containing BlazeDS.

    Posted by Brian at 5:50 PM

    Sudden Flash Problems? Read About the Security Changes

    If you're having complaints from customers about certain media not showing up or problems clicking on links, then I recommend reading about the security changes in Flash Player 9,0,115,0. Actually, I recommend reading the article no matter what, as there's a significant amount of changes.

    I'm surprised there hasn't been more blog posts on this (although here's a recent one), as I generally keep up with mxna, and I haven't seen information on it. The changes caught me, and it'll be a good reminder to test new players while they are still in beta.

    Posted by Brian at 5:10 PM

    December 13, 2007

    What's In Blaze DS?

    So I'm not usually for the "me too" posts, but I'm excited enough to add to the blog overflow. The open sourcing of remoting and messaging is as big of news as the opening sourcing of the SDK. I won't rewrite what has already been said- see the posts by Christophe and Ted. But I couldn't find a detailed list of what's included in Blaze DS. I haven't paid much attention to Adobe Livecycle Photoshop Acrobat Data Service (that's the name, right?), and I don't know what comes with "remoting and messaging". Here's what I see from the examples in the download:

    Sample 1: Accessing data using HTTPService

    I assume this isn't just the HTTPService that gets the resource, but that it's using the HTTP proxy to get the resource. I know this piece pretty well, since I spent a long time working on it, way back in the day. It allows whitelists be set, simplifies some issues with data and the player, etc.

    Sample 3: Accessing data using Remoting

    AMF3 remoting, the piece that most people will be using, and which should need little explanation.

    Sample 6: Publish/Subscribe Messaging (Data Push Use Case)

    This is the "messaging" part of the release, and the part I definitely know the least about. It allows messages to be pushed to different clients with a minimal amount of work. The data is pushed with channels you can set up and use, both AMF and RTMP. And now there seems to be one more, "a new HTTP Streaming channel for real time applications that require very low latency." Exciting stuff!

    Update: I assumed that RTMP was included for messaging, but according to a comment Dirk Eismann on Christophe's post, it isn't included. It looks like that's part of the reason the new HTTP channel was created.

    If anybody has a more succinct list of what's included, I'd appreciate a link.

    Posted by Brian at 8:53 AM

    November 21, 2007

    The World of ECMAScript

    Here's a wonderfully detailed cloud of everything ECMAScript (found via Artima). From Artima's count, there's "eight different implementations of ECMAScript, sixteen ECMAScript engines implemented in six different languages, and many more applications that provide an ECMAScript execution environment." Not a big surprise, but Mozilla, Microsoft, and Adobe dominate the cloud.

    Posted by Brian at 8:49 PM

    November 19, 2007

    Ask Steven Webster for Adobe At Your Doorstep

    Ok, so not at your doorstep, but at your next conference's doorstep. I noticed in a post on flexcoders.nl this comment from Steven Webster:

    "What are the advanced topics you would look for in a Flex conference ? There is an army of Adobe Consultants - some of whom spoke at MAX, but more of the places were given this year to the community speakers - who are ready, willing and able to deep-dive into Flex discussions, whether it be architectural, component-level, inspirational user-experience design talks or deep-dives into things like messaging with Livecycle Data Services. If anyone has an event where they'd like advanced (or even introductory) level Flex talks, then drop me a note and I'll do my best to ensure we can provide speakers from the field to these events.

    If you ask us, we will come."

    So Steven, I'd like to formally invite you to the Brightcove Scotch Drinking Night In Boston, which involves Cairngorm-loving Brightcove employees and scotch. No? What if there were conference t-shirts? :) Did I mention the scotch?

    More importantly, I see that Steven announced a code-coverage tool that Alex Uhlman is working on for Flex 3. I was hoping that the profiler meant that a code coverage tool was coming, but I never guessed that it would be this quickly.

    Posted by Brian at 11:23 PM

    November 18, 2007

    Linking to External Source Folders in Flex Builder

    One problem I've always had with Flex Builder is that I can't reuse projects which link to source folders outside of the main source folder. These external source folders are usually defined with an absolute file path, which makes the project files unusable by other developers without changes. And changes mean that project files don't stay in sync, which is just one more thing to worry about.

    Usually, the external source folder is a folder for test files, but it can also be some folders that really should be in a SWC. In any case, the project file isn't sharable in the current form, and we all like to share.

    I learned from some developers at Brightcove that there is a solution to this using a built-in Eclipse feature. First, you need to set up a linked resource:

    1. In Flex Builder, go to "Window > Preferences".
    2. Navigate to "General > Workspace > LinkedResources".
    3. Within LinkedResource, create a new variable that links to the folder you want to include or some common base directory. Usually, you'd enter some base directory within source control that could be reused for more than one external source path.

    Once you have the linked resource, you'll want to add a source path to your project. Right-click on the project, go into "Properties", "Flex Build Path", "Source Path". As normal, select "Add Folder", but don't browse to the directory. Instead, use the linked resource name, either by itself:

    ${LINKED_RESOURCE_NAME}

    Or if it's a base directory, you can tack on directories:

    ${LINKED_RESOURCE_NAME}/my_source/location

    OK it, and it's all set up. Then you can share the project file to other people on the team, or check it into source control. Each member of the team will need to define the linked resource, as shown in the steps above, but the project files don't have to change.

    Posted by Brian at 6:47 PM

    November 9, 2007

    Aftermix wins a MITX

    In front of 1000 people last night in Boston, Aftermix won the Massachusetts Innovation and Technology Award for Rich Media Application. Congrats to the whole team! I was the one person currently working on the project who couldn't be there, but the poster from the awards that greeted me this morning (a half-naked lady and a guitar) makes me think the ceremony was a lot of fun.

    Of the five finalists in the Rich Media Application category, two of them (and maybe three) were Flex applications, which won't surprise anyone reading this blog.

    Posted by Brian at 9:22 AM

    November 5, 2007

    Flex Camp Boston

    If you're in the Boston area, check out Flex Camp in Waltham on December 7th for a mere $10. You'll see a number of folks from Brightcove there. It's being put together by Brian Rinaldi, and it has a bunch of people from the Flex team speaking at it.

    Posted by Brian at 11:44 PM

    October 13, 2007

    I'm doing Javascript work now

    It's been a bit too long since my last update, but blogging keeps getting pushed down on the TODO list. I have a long post on components in the works, but I wanted to post something else in the meantime to get myself back on the blogging horse.

    So it's true that I'm doing Javascript right now, although it's just for a week before I head back to Flex-land. But it makes for a great headline, no? This past week, I delved into innerHTML and the rest of the Ajaxy world that I've never been in before. I did this to help create some HTML pages for work, and in the sprit of Scrum, this was a task that I volunteered for. I wanted to learn the basics, and it's been pretty easy to do so. One thing I've enjoyed in my scripting is the instantaneous nature of the changes- there's a noticeable difference between waiting less than a second and waiting up to five seconds to see a change. One thing I haven't enjoyed is, well, Javascript. I've been spoiled by AS3.

    What else have I been up to, technology-wise? Well, MAX was not one of those things, although I really wish I could have gone. I didn't keep up with the mountain of blog postings last week, but I did read a lot of the great posts on Thermo. I'm waiting to see the code generation before I know how excited to get.

    Aftermix is still going strong, and in time I'll be able to talk about some very interesting changes ahead. And Brightcove is going strong, with lots of big deals and news lately. Brightcove is a great place to work, and if you're a Flex/Java developer/QA looking for a job, send me an email at bdeitte at brightcove dot com.

    Posted by Brian at 7:25 PM

    September 16, 2007

    HTML in Flex (Without the Extra HTML)

    Alistair Rutherford has extended the existing component for displaying HTML in Flex, and unlike the previous work by Christophe and me, this component only needs one simple HTML change, handles multiple HTML windows, and figures out the visibility automatically. Great work that you can read about, see an example, or get the source.

    Posted by Brian at 8:49 PM

    September 13, 2007

    Invite-free Aftermix on Brightcove.TV

    You can now play with Aftermix without an invite by going to the welcome page. It's still in beta, but let me know what you think. The welcome page will take you to the contests for Avril Lavinge, Mashers of Horror, and Big and Rich.

    You may also notice that this is a link to brightcove.tv and not brightcove.com. You can read more about Brightcove.TV on the Brightcove blog or on Mashable.

    Posted by Brian at 10:15 AM

    August 21, 2007

    The Future of Flash Video

    Adobe just announced support for H.264 in the Flash Player.

    What does this mean? For a short primer on H.264, see Apple's page on the subject. For the technical overview, check out Tinic's extremely detailed post. Now I'm not going to be able to sleep, as it's time to go read Tinic's post closely and salivate over the details.

    Posted by Brian at 1:11 AM

    August 19, 2007

    My Slides From 360Flex

    The slides from my presentation on Aftermix and Video at 360Flex:

    You can also download the PPT from slideshare.com by going to their site and clicking on "Download file". The slides have a lot of notes in them, as I tried to keep the slides themselves concise.

    Thanks to John and Tom for putting together a great conference. Thanks to effectiveui for the boxers that made me laugh when I finally saw the joke ("don't just focus on the backend"). Thanks to Jeff Tapper and Mike Nimer for getting a bunch of interesting folks together for dinner on the last night. And thanks to all the people who stuck it out for the last session on the last day to see my talk.

    Posted by Brian at 11:58 PM

    The End for JRun

    I noticed last week that Adobe has finally announced the end of development for JRun. It was the first major product I worked on, for two years, and it taught me a lot about software development. Ten or so of the core development team for Flex came from JRun (although you'll now see a few of them in other places). The JRunners live on.

    Posted by Brian at 11:35 PM

    Junk Comments

    I was just trying to catch up on this blog by answer comments in Using Resource Bundles in Flex and Embedding HTML in a Flex application when I had my new comment show up as a Junk Comment in Movable Type. Err, that's not good.

    If anybody has posted on this site and didn't see their comment show up, please email me at brian @theurlyouseeabove.com or try to repost it. Sorry about that.

    Also, if you're looking for the slides from my presentation at 360Flex, I should have them up here by the end of the day.

    Posted by Brian at 1:00 PM

    August 9, 2007

    Aftermix on Mashable

    Things have been very quiet on the Aftermix front lately, but if you have access to the beta, you should notice a few bug fixes today. On the news front, there was a lot of interest on Mashable for getting invites.

    Want to hear more about Aftermix or about video in general? There's still space at 360Flex in Seattle next week. I'll be speaking at 4pm on Wednesday.

    Posted by Brian at 5:44 PM

    July 29, 2007

    17 Thoughts on Scrum

    Scrum is a development process most recognizable by its 30 day sprints. Brightcove uses Scrum for all of its development. I recently went to a course from Ken Schwaber for the exalted title of Certified Scrum Master (which comes with its own secret handshake). From my notes on this course, I've written some thoughts on Scrum, which are below.

    The notes below aren't meant to encompass all aspects of Scrum. For a better overview, read the Scrum wiki page, get Agile Project Management with Scrum, or take one of Ken's courses (which I highly recommend if you can get your company to send you).

    1. ScrumMaster is a silly name on purpose to make sure it's not a Grand Title. ScrumMasters are there to try to help the team become self-managing.
    2. Scrum should be results orientated, not effort driven.
    3. If at all possible, start with the "right" way to Scrum and then customize later. Usually the changes that are requested show a problem within the organization.
    4. Team self-organizes as needed. Some teams won't need their own ScrumMaster in time and will only need the ScrumMaster to remove impediments.
    5. A common bad and wrong assumption is that by telling people how to do things, they'll work better.
    6. Don't make Scrum an iterative death march.
    7. Backlog shows the remaining time. Don't confuse this with time worked, which is simply not a part of Scrum.
    8. There needs to be one product owner, who can report to other product owners and listen to the team. One product owner leads to a single decision point.
    9. The team owns all aspects of development. It's not features owned by engineering, testing owned by QA, etc. There's not the normal functional groups as there is for waterfall but rather a shared "done".
    10. It's important to keep Scrum teams together, as they are much more effective in time. Also, after a few sprints, teams are better at determining their velocity.
    11. If a team is dependent on people external from the team, then it can't reliably commit to tasks.
    12. Scrum doesn't make a lot of sense for R&D or other open-ended experiments. This isn't to mean its not for prototypes but rather that its not really suited for basic research.
    13. Development often shows too much unneeded coding details to the business side without giving enough visibility into progress. It's the worst of both worlds.
    14. Development should give the risk to the product owner and not try to take on risk that isn't rightfully theirs.
    15. If we celebrate the amount that gets done, then the more done isn't done and future sprints slow down.
    16. There's no such thing as a failure of a sprint. There can be a failure of a product but not a failure of a sprint. What gets done has gotten done and the product owner will make choices based on the new reality.
    17. Expand on "done" so that tasks don't have later ramifications. Make sure everyone knows what "done" is.

    Posted by Brian at 11:04 PM

    July 25, 2007

    Scamming in Au Bon Pain

    While trying to finish my speech for 360Flex at Au Bon Pain, I witnessed one of the oddest things I've seen in awhile.

    The whole second floor of the restaurant (the Au Bon Pain near MGH, for the Bostonians reading) was full of people trying to schedule interviews or interviewing potential "employees", people who mentioned they had no money and were looking for a second income. It's hard to explain, but it was like a scene out of Glengarry Glen Ross, trying to keep people on the phone for as long as possible, using every trick I could think of to get people to go to some conference. We asked an employee why all these people were allowed to run the place as an office, and they said they've had a lot of people complain and were talking with the police. But "they couldn't kick them out since they bought something", which makes no sense to me.

    I'm a bit tempted to go back there tomorrow myself, but I don't see that I'll have time, especially since I plan to go to Joey Lott's talk at BFPUG.

    Posted by Brian at 12:45 AM

    July 8, 2007

    Why 360Flex Seattle?

    Unlike a year ago, there's a lot of conferences these days where you can learn about Flex. So why head to 360Flex Seattle?

    Besides it being a Flex-only conference and having great speakers, the last incarnation of the conference should send you to this one. Was 360Flex San Jose the first Flex-only conference? I think so, and even if it wasn't, it felt like it. New and old Flex experts, large parts of the Flex team there (with Matt hitting me a few times), meeting pre-Adobe Ryan Stewart, beer, and good sessions.

    So check out 360Flex Seattle. I'll be going and be presenting on Aftermix and its creation.

    Posted by Brian at 11:19 PM

    June 26, 2007

    Aftermix, Invites, and Remixer

    Ryan Stewart, who keeps growing on his uncanny ability to find stories, posted a link to the Aftermix invite form in a blog post last week.

    We won't be allowing everyone into Aftermix for the short term as we still work like mad on the beta version. But I hope everyone still fills out the form to check this out, and I'll also be posting a way to make sure your request is selected. (And sorry but it won't be a Flex quiz.) There's also the invites at 360Flex.

    Last but not least, a very late congrats to the team at Adobe for the Remixer app on YouTube.

    Posted by Brian at 12:02 AM

    June 25, 2007

    Testing a SWF From a Remote Location

    Recently someone taught me a neat trick with Charles. I had a SWF that was loaded in a much larger SWF and HTML page, but I didn't want to build these other pieces. I had access, however, to a testing site where the SWF/HTML pages were located, and with this I could use "Map Local".

    Map Local allows you to map URLs to local directories. This means that you can test a SWF that should be on a remote site. It's incredibly useful for the large project problem I was having or for debugging problems on a live site.

    Posted by Brian at 11:40 PM

    June 11, 2007

    My Flex Bugs

    As you've probably already heard (even a half hour later, from the blog posts I just saw), Flex 3 is available for download and the bug base is now open to all.

    I wish I had a little time to play with it, but it's a weekend and week of heavy Aftermix coding. I had to spend a few minutes, however, to run this amusing JIRA report:

    My Flex Bugs

    Since it's been seven months since I worked there, that's a good indication of how open they are being with the bug base. And I'm excited to see how many of the bugs are fixed!

    Unrelatedly, I keep meaning to write more about 360 Flex and my talk on Aftermix there. When I figure out what exactly I'm going to say, I'll write some more here.

    Posted by Brian at 12:23 AM

    May 23, 2007

    Buzzword, FlexBox, and Transformers

    Too much work and too little blogging. Here's a catch-all post to catch up on Flex things.

    I've seen Buzzword, and... wow. Congrats to the Flex team there. I'm most impressed by the details, the way that little things just work.

    The news is old, but I'll still point out that FlexBox has been updated. It's an excellent way to find new Flex components.

    And related to FlexBox, since the IFrame component is on there, is that I've finally responded to the last month of comments on Embedding HTML.

    And Transformers. What does Transformers have to do with Flex? I could make up a metaphor here about the versatility of Flex. Or make an awful joke about Flash being more than meets the eye. But really, I just wanted to be a geek and embed this:

    The movie looks a lot like all the rest of the Hollywood action films in recent years, but it's Transformers. The ten year-old kid in me is very excited.

    Lastly, as a non-Flex update, there was an update to brightcove.com last night, but I'll wait to post more on this, as I can't yet talk about any video mixing part of this update.

    Posted by Brian at 6:47 PM

    May 8, 2007

    Details Leaking Out on Aftermix

    Details on Aftermix have been slowly emerging, and Anthropomedia points to two of them in a post on Brightcove's Aftermix. For the MediaPost video mentioned, go to the 35 minute point to see Jeremy Allaire's demo of Aftermix. Or you can check out the early support video.

    I can't comment on the blog post's questions on the underlying business model, but I can briefly comment on the blog post's suggestion that Aftermix is half-baked right now. We have a team here that includes people who previously worked on Flex, which is the development technology for Aftermix. This Flex group includes me, and you can also see that I went to Brightcove seven months ago. Hopefully I've been doing something since then. :) I wish I could say more, but that's for another day. In time, on this blog, you'll hear more about the fully-baked version.

    As for the version of Aftermix shown in the videos, a lot has changed (and is better) in our local builds. To let out one detail, the tab navigator is gone. Those of us who have seen too many Flex applications that look alike will appreciate this.

    Posted by Brian at 11:29 AM

    May 2, 2007

    Looking for More Flex or Flash QA (and Developers)

    Do you want to test or develop a video player that's viewed millions of times a month? How about working on a brand-new video editor? Brightcove is looking for more Flex and Flash people to work on brightcove.com. We're looking for both QA and developers to work on Aftermix, the site's video player, and more.

    Check out my previous post, Top 10 Reasons to Work at With Flex Brightcove, for some Aftermix-focused reasons to check things out.

    You can ask questions or email your resume to work AT brightcove DOT com. And you can always ask me questions at bdeitte AT brightcove DOT com.

    Posted by Brian at 10:11 PM

    April 26, 2007

    Open Source Flex

    Perhaps I'll be making changes to the Flex compiler once again. The Flex SDK is going open source.

    This is a great day for Flex! A few random thoughts:

    1. I think the biggest change for a long time will not be open submissions but open bug reports. In time, the community contributors will matter more, but having everyone adding and sorting bugs will be a big deal. Flex has had a great beta program, but it doesn't compare to having everyone on the bug base.

    2. I joked about making compiler changes above, but in the long term, I'm most excited to see what people do with the AS3 and Flex compilers. I always enjoyed compiler work, but I don't count myself in the group of people who thrive off of it. There's a small group of people who love compiler work and can change how we write code. While there's a number of these people already working on AS3 and Flex, I hope a few more are inspired by this.

    3. The number of cool new Flex components is going to make my head spin.

    4. The SDK was already free, so it doesn't change the revenue model for Adobe. This means (or at least I think it means) we still get a large team of developers working full-time on all things Flex.

    5. In time, we will start seeing AS3 in the strangest places. Since both the runtime (in Tamarin) and the compiler will be available, people will end up putting AS3 in new plug-ins, devices, and more.

    6. I'm happy that this is going to take awhile to get out there. That sounds strange, I know. But I don't want to see the team get too distracted from working on Flex 3, as I'm still waiting for a few features. After that, I'll be ready to play.

    Posted by Brian at 12:35 AM

    April 22, 2007

    Why Use MXML?

    Why should you use MXML? Given that Flex Builder doesn't require the use of MXML, why not write everything out in Actionscript, especially if that's what you are used to?

    I was asked a question like this recently, and I'm sure others have asked similar questions. I expected to find a simple answer in searching, but I could only find more general articles. Did I miss an obvious post or page?

    I wrote parts of the answer below and then expanded on it for everyone to read. I've grown so used to using MXML with Actionscript that I had to think about my answer for a bit to express what I now take for granted.


    Here's the advantages I see in MXML:

    1. The declarative nature makes it a lot less verbose for setting up visual components, and it's easier to picture the layout. A Canvas within the Canvas can easily be seen in MXML, while addChild() scripting is harder to visualize.

    2. It's easier to separate your view code from the rest of your code. MXML is almost completely visual components, which solves the V in MVC.

    3. There's a lot of shortcuts and syntactic sugar in MXML to help in writing code. Styles can be put into CSS, and styles and events can be set as attributes. Embeds (and the other @ directives) are less verbose than the equivalent Actionscript metadata. Binding with curly brackets is easier to write and read.


    And here's a few potential reasons to not to use MXML:

    1. You aren't using any of the Flex framework classes. I don't agree with this one, personally, as you still get the benefits mentioned above.

    2. You're creating a super small widget, and the size of your application will be slightly bigger with MXML. I believe that MXML will add a very small amount of size, due to some generated code, but I don't know the exact amount.

    3. You want to use all of your code inside of Flash Authoring. There's an emphases on the word all here. Often you can separate out your utilities or components in ActionScript and still use MXML in places.

    Posted by Brian at 11:25 PM

    April 17, 2007

    Runtime Resources Bundles in Flex 3

    Gordon mentioned on flexcoders that the next version of Flex will have runtime resource bundles. I'm very happy to hear this. It's something that has been talked about before (and I mentioned in this article), and I think it's been holding a lot of people back from using resource bundles, including me.

    Posted by Brian at 6:18 PM

    April 16, 2007

    Brightcove's Planned Support of Silverlight

    Brightcove is now planning to support Silverlight in addition to Flash video.

    I'm just posting this to give Ted Patrick and Scott Barnes the opportunity to have a "discussion" on the matter. :)

    Back to Aftermix work, which yes, is still in Flex 2.

    Posted by Brian at 7:03 PM

    April 10, 2007

    Using Multiple IFrames With Flex

    If you're looking for a way to get multiple HTML pages in a Flex application without using Apollo, check out this code. It's an update to the Embedding HTML code which allows multiple iframes in a page. I haven't tested it myself, so let me know if there's any issues with it. I would give credit for the update to the code, but the person who wrote it is being humble and asked not to be mentioned. So you can just thank me instead. :)

    Posted by Brian at 9:10 PM

    March 27, 2007

    The Flex.org Beta

    I got an email from a friend telling me about the flex.org beta. As I can't keep up with the Flex category on MXNA anymore, I must have missed the news that this was out there. I haven't seen much discussion on this, so perhaps it isn't widely known.

    It's a lot better than the old flex.org, which I think we've all grown to ignore. It's simple and looks like a much better place to point newcomers to Flex.

    Posted by Brian at 7:00 PM

    March 19, 2007

    How Has HTML in Flex Worked For You?

    With the release of a little, barely-written-about project called Apollo, I've been looking at a lot of HTML in Flash. Last week I also read about the release of a different iframe solution to HTML in Flex, and I continue to get comments and questions on my site about my port of Christophe's iframe solution.

    All of the above has gotten me thinking about HTML in Flex and how it works for everyone. The comments I've read on my site have brought up a lot of problems and idiosyncrasies. I wonder if people have solved the problems they write about, given up, or just live with a bit of strangeness. I've tried to answer what I can in the comments, but I haven't been able to answer a lot, and I'm hoping that others can share their experiences.

    So how has HTML in Flex worked for you? Do you start from the code found on this site, another site, or something you came up with yourself? What are the hair-pulling bugs that you solved (or you see as unsolvable)?

    Posted by Brian at 11:52 PM

    March 7, 2007

    New Spanish Blog and 360Flex News

    There's a new blog in Spanish from someone working with me on Aftermix, Oscar Cortes. I can't read it, but I'm still sure it's very insightful!

    Ryan Stewart was making fun of me yesterday for putting real Flex news in a Twitter, so here it is in a blog post Ryan. :) At the Flex Q&A yesterday, it was noted that the player team is working on full bi-directional support. There was also talk of cross-domain module support as well as having default cross-domain framework modules. And expect a lot of flex.org changes.

    Posted by Brian at 11:58 AM

    March 5, 2007

    At 360Flex

    I'm sitting in on David Zuckerman's session on Flex Builder, where he just announced refactoring and "find all usages" support in the next version of Flex Builder. That makes me very, very happy.

    I don't think I'll be providing any more updates on this blog from 360Flex, but you can see my current doings on Twitter.

    Posted by Brian at 4:03 PM

    February 27, 2007

    Aftermixing at Brightcove

    Today at the Adobe Engage event, Jeremy Allaire showed a little bit of Aftermix, an unreleased video mixing application from Brightcove. I'm very excited to see all of the posts and discussion on Aftermix and its possibilities, especially since I have my hand in the making of this Flex 2 application. Here's a roundup of what others are writing about Aftermix:

    A GooTube lookout from David Berlind.

    Jeff Barr writes about Aftermix, consumers, and the video-snacking culture.

    Kristen Nicole suggests that Brightcove keeps quality first.

    Everyone's favorite prolific blogger Ryan Stewart has a post.

    Mashable has a post with a title we can all agree as hyperbolic, Brightcove Launching AfterMix - Pulls Ahead of YouTube?

    James Governor's post asks Brightcove to remember the 'roots.

    Posted by Brian at 11:30 PM

    February 21, 2007

    Using Asserts In Flex

    I find myself using assertions all the time in my Flex classes and am curious if others do the same thing. Along with a logging system (to turn tracing on and off), and some unwritten unit tests, I find the asserts to be the most helpful tool for keeping myself sane as my current project keeps growing.

    Here's a good explanation of asserts for C++ and here's one for Java. I tend to use assertions in a lot of complicated AS classes or really any place where I expect something not to happen (since, of course, that impossible thing eventually does happen).

    So do you need an Assert class? It's not hard to add one to your project. Here's a simple class that will work. You may need to modify it to show an alert if you're catching a lot of errors.
    package
    {
    public class Assert
    {
      // call enabled before calling assert().  This value is 
      // usually tied to a constants file where the value 
      // can be tokenized and turned off in production
      public static const enabled:Boolean = true;
    
      public static function assert(assertion:Boolean, 
          msg:String = null):void
      {
        if (! assertion)
        {
          throw new Error("An assertion failed" + 
              (msg ? (": " + msg) : "."));
        }
      }
    }
    }
    
    Posted by Brian at 10:12 PM

    YouTube's Hidden Anger for the Play Button

    This was too amusing not to post* and a reminder to make sure no traces show up in a production SWF. Below is the trace output from an embedded YouTube video. In the middle of the output: "showing the goddamn play button".

    Constructing movie
    Warning: onStatus is not a function
    Ending the movie is :_level0.tube.movie
    constructing MovieController:undefined
    timer.seek_total_timeundefined
    regular:undefined smal._xstart:undefined
    constructing EmbedSoundController:undefined
    setting movie
    setting the movie video_id:1AH9VEM_qC0 base_url:http://www.youtube.com/
    DIFFERENT loading :undefined vs http://www.youtube.com/get_video?video_id=1AH9VE
    M_qC0&t=OEgsToPDskKQgp5rypS4WQ0olAuex1N1
    registering controller to:_level0.tube.movie
    registering sound to:_level0.tube.movie
    controller movie is:_level0.tube.movie
    show v:100
    showing the goddamn play button
    sw:425 sh:350 rw:450.55 rh:356.1
    resizing to:425:350
    resizing to:425:318.75 ratio:1.33333333333333
    overlay: 425,318.75
    end_screen: 425,318.75
    actual size of movie is:425:318.9
    resize width:425 bg offset30.55
    moive_width:425 w:425 mx:0
    px:undefined py:undefined
    fiting image to:425:318.75 actual:425:318.75
    we loaded the image

    *Yes YouTube is a competitor in some ways to the company I work for, Brightcove, but it's certainly not meant as a dig at them!

    Posted by Brian at 5:55 PM

    February 19, 2007

    Head of the Data Services Team is Blogging

    William Wechtenhiser, the manager of the Flex data services team, has a new blog. He does mention in the blog that this is what he does, but I bet most people missed it. Whether you use data services now or not, this is a good blog to subscribe to.

    Posted by Brian at 10:33 AM

    February 17, 2007

    Error #1010: A term is undefined and has no properties

    A lot of people have been looking here for information on "Error #1010: A term is undefined and has no properties". One of the iframe posts is bringing people here, but they aren't getting any error details from the post. You can read more about this error and all other runtime errors in the language reference. This error most commonly occurs when you try to access a property on an undefined Array item. For example:

    var array:Array = new Array();
    var noProp:Object = array[1].prop;

    You may run into this error in the framework, especially in the datagrid. To read more about this, try a mail-archive.com search of flexcoders.

    Posted by Brian at 4:16 PM

    February 15, 2007

    I'll Be At 360Flex

    On a cold and icy day like today in Boston it's nice to remember that in a few weeks I'll be in San Jose at 360 Flex. I hope to meet a lot of Flex developers and see many of the familiar Adobians. I'll be heading there with Tom Ruggles for Brightcove.

    Posted by Brian at 12:58 PM

    January 28, 2007

    Speeding Up Builds with the Flex Compiler Shell

    Two Flex projects were recently released on Adobe Labs, Flex Ant Tasks and Flex Compiler Shell. You would expect the Ant tasks to be the more exciting of the two from the build perspective, but the compiler shell (fcsh) could be the better choice for large, complicated projects. That's because fcsh allows multiple compilations to occur in one process without the need for reloading SWCs, restarting Java, etc. When you can use fcsh in a non-interactive manner, this can be very helpful for speeding up a build.

    How can you use fcsh, which is supposed to be an interactive shell, in a build file? Simple piping of a file will do the trick. As an example, put the following in a file named "buildscript":

    mxmlc -library-path+=frameworks/locale/{locale} -source-path+=samples/photoviewer/locale/{locale} -locale=en_US samples/photoviewer/PhotoViewer.mxml
    mxmlc samples/restaurant/recentReviews.mxml
    mxmlc samples/restaurant/finder.mxml
    mxmlc samples/explorer/explorer.mxml
    mxmlc samples/flexstore/flexstore.mxml

    Then call the following:

    bin\fcsh < buildscript

    In Ant, you'd use the input attribute instead of "< buildscript".

    I see a roughly 50% increase in the compilation speed from this example. But there's two problems with using fcsh:

    1. Status codes are not returned correctly. Hopefully Adobe can fix this, but in the meantime, you'll need to search the output yourself for "Error".
    2. You don't get the wildcard fileset benefits of the new Ant tasks.

    Posted by Brian at 11:48 AM

    Apollo on Techcrunch

    I was doing some morning reading and was interested to see an Apollo article from Ryan Stewart on Techcrunch. The comments were the most interesting part, seeing the confusion and differing opinions on what Apollo will do. Most of the negative comments have to do with security: it's more clear to me now how important the security perception battle will be for Apollo. I couldn't find any public security articles to point to, so hopefully someone at Adobe will come out with one now.

    For anyone coming from Techcrunch looking for more Apollo information, here are a few places to look:

    Developer's FAQ
    Detailed presentation
    Screenshots
    Blog posts

    Posted by Brian at 11:35 AM

    January 23, 2007

    Flex Talk Tomorrow in the Boston Area

    The illustrious Joe Berkovitz is speaking tomorrow at 7pm in Brookline. Read more (and get directions) here. The speech is a part of the Boston Flash User Group meetings. I've really enjoyed going to these meetings lately to learn more about Flash/Flex and drink with fellow coders.

    Posted by Brian at 5:35 PM

    January 5, 2007

    FlashType Support in Flex 2.0.1

    One major feature that wasn't talked about in Ted's post on 2.0.1 is the addition of FlashType support in Flex. Whenever you embed a font, the font will now use FlashType by default.

    What is FlashType? It's technology in the Flash Player for providing clearer text, especially when the text is small. Here's an example:

    Before 2.0.1, in order to use FlashType, you had to first embed the font in Authoring and then use the Authoring SWF in Flex. Now, you simply need to embed a font in Flex, and FlashType is automatically enabled.

    Also, as an update to the ASDoc fixes, note that Linux support was not added. I could have swore that I read that this was added, but I just read the release notes and see it as an open bug. Ah well.

    It feels strange to talk about FlashType and ASDoc, as these were the last two features I developed at Adobe. From now on I'll have to wait for Matt, Ted, and others to blog about features to know about them!

    Posted by Brian at 12:59 PM

    December 31, 2006

    Happy New Year

    A Happy New Year to all! Between a trip around the world to a new job to so much else, this has been a very interesting year for me. I hope everyone has a good year ahead.

    Posted by Brian at 12:05 PM

    December 21, 2006

    Simplicity in Software

    I just came across an excellent discussion on simplicity in software (via a post on scary software). It's on the blog of Nick Bradbury, who wrote Homesite and FeedDemon:

    Simplicity Ain't So Simple

    It's of special interest to me right now as I develop an application that users actually have to... you know, use. I picked up a few ideas here, like this:

    "Sometimes in beta versions I'll deliberately remove (or obscure) access to a specific feature just to find out if people really use it. If a lot of beta testers complain about the feature being removed, then it's an 80% feature that needs to be an obvious toolbutton. If only a few complain, then it's a feature that only 20% want so it can be demoted to a menu item."

    Posted by Brian at 10:44 AM

    December 18, 2006

    Top Ten Reasons to Work with Flex at Brightcove

    We're still in need of Flex developers and QA for an exciting project at Brightcove. In the spirit of Ted Patrick, here's my top ten list for working at Brightcove:

    1. First off, I'd like to stress that you don't have to know Flex. Knowing your UIComponents would be helpful, but we're more interested in your ability and willingness to work on a Flex project. In other words, we're interested in athletes more than experts.

    2. It's a new project, which means that you get a lot of say on how things work in the development and testing environments. You'll be on the ground floor of a new project and the first floor of a growing company.

    3. Work with Flex 2 every day, all day.

    4. Work directly with three former members of the Flex team. This includes Sean Neville, who was writing about Flex more than three years ago and me.

    5. Work close to a lot of excellent Flex, Flash and Java developers. This includes one of the authors of the AS 3.0 Cookbook, Keith Peters, Flasher extraordinaire Sam Robbins, and a swath of people who've helped build J2EE servers.

    6. It's a project that Jeremy Allaire is excited about. He'll come by occasionally and ask about the project.

    7. My HR one-liner: Brightcove has a good set of medical, dental, 401k and other benefits.

    8. You won't have to see any more posts on this site about the subject. I can't help but try to get more people on board to the project I'm on. Like the threat in an NPR fund drive, you could make the world a better place and help me get back to more insightful posts by working here.

    9. Brightcove is all about video, video, video. The online world is currently abuzz with video. Wouldn't you like to work with video?

    10. Have you seen the view out of our office at One Cambridge Center in Kendall Square?

    Apply by emailing your resume to resume to work AT brightcove DOT com or finding the job through the career site. And if you have any questions for me, I'd be more than happy to answer them at bdeitte AT brightcove DOT com.

    Posted by Brian at 3:12 PM

    December 17, 2006

    An Ajax Look at Flex, New TV, and More

    Three groups of links for your Sunday reading:

    1. Andy Budd has a fascinating post on going to the Flash on the Beach conference as an Ajax developer: The Lion's Den (found via Aral Balkan) Having lived in Flex-land for too long, I always find it interesting to hear a perspective, positive or not, from someone in the majority group of Web development. To quote: "The thing that excites me the most about FLEX 2.0 is how similar it is to standards based development. You have an declarative XML-based mark-up language to build the UI. You can then add style in the form of CSS and behaviour using the ECMAScript based Actionscript language. Cool huh?"

    2. I saw the newwteevee.com blog after a post on Brightcove's user upload feature. I'm now a daily reader, as the blog is the best place I've found to read about everything happening with online video.

    3. The folks at Jive Software (founded by fellow University of Iowans) have had a number of good posts about software companies, the latest being about creating an open organization.

    Posted by Brian at 10:05 AM

    November 24, 2006

    Search for MXML and ActionScript in Google Code Search

    Now that Google Code Search allows for searches by file name, you can search for MXML and AS3 files. MXML files can be searched for by specifying file:.mxml$. You can search for AS3 files in a similar way, although it will search for AS/AS2 files as well, since the file extension is the same.

    Here's an example of a MXML and AS search:

    file:.mxml$ tabnavigator
    file:.as$ displayobject

    There's not a lot of results at the moment, but I expect that Google will improve that in time.

    Posted by Brian at 2:11 PM

    November 19, 2006

    Tamarin, AS 3.0 Cookbook, and Jobs

    A late congratulations to the Adobe team on Tamarin. A bunch of the team had been working hard on this in the Boston office, and it's great (and a little surprising) to see this unveiled. Hopefully I am linking to something not everyone has seen in a link to an interview with Dan Smith on artima.com.

    In a late review, a thumbs up to the AS 3.0 Cookbook. I bought and have read snippets of this book, and I found it very helpful in rounding out my AS3 library knowledge. In an amusing Brightcove anecdote on this book, I told Sean Neville that I was interested to see that Sam Robbins reviewed the book, someone who I knew worked at Brightcove. Sean then told me to look across the hall, where Keith Peters sits, one of the authors of the book. Good to know!

    And to mention for Brightcove again, we're looking for more great people at Brightcove. If you're in the Boston area and you're interested, feel free to send a resume to work AT brightcove DOT com. Or you can email me at bdeitte AT brightcove DOT com with any questions.

    Posted by Brian at 1:38 PM

    November 5, 2006

    Designing in Flex and Site Updates

    I've asked a few questions lately on flexcoders that relate to creating a Flex application with a designer's help. I have some notes on how I've been approaching this, and I plan to post a blog item on this when I find the time so that I can share what I've learned and to hear how others do this.

    If you've been on this site lately, you may have noticed some strangeness with comments and trackbacks. There's been some spam showing up when it shouldn't, some issues with counts, and one trackback that refuses to show up (from here). This all started after I updated MovableType, and so you'll see them for awhile, until I update again.

    As for other activity on this site, the Embedding HTML and ASDoc posts are still getting comments and questions, and I'll continue to answer what I can there.

    Posted by Brian at 10:07 PM

    October 24, 2006

    Brightcove looking for Flex developers and QA

    Brightcove is looking for developers and QA for an exciting, new Flex 2 project. This is the project that brought me to Brightcove, so you'll be working with me on creating an application that focuses on video on the Web.

    We would love Flex experience, but if you're just starting down the path of Flex and want to keep learning more, we're definitely interested as well.

    The positions are based in Cambridge, Massachusetts. To apply, please see the links below or send your resume to work AT brightcove DOT com.

    Software Engineer: http://tbe.taleo.net/NA4/ats/careers/requisition.jsp?org=BRIGHTCOVE&cws=1&rid=116

    Senior QA Software Engineer: http://tbe.taleo.net/NA4/ats/careers/requisition.jsp?org=BRIGHTCOVE&cws=1&rid=112

    Posted by Brian at 12:05 PM

    October 22, 2006

    ASDoc: a list of fixes and how to alter the output

    Update: Flex now includes ASDoc. The documentation is here.

    ASDoc, currently on Adobe Labs, will be included in the next update to Flex. I don't know the full list of ASDoc fixes, but I can share that the top three issues in the Labs build have been fixed:

    • UTF-8 characters show correctly
    • Bindable metadata doesn't affect output
    • No more circular inheritance errors when using doc-sources
    I also wanted to share some information on altering the output. If there's a small bug in the output or it doesn't look quite right to you, there's something that can be done already to fix this. You can alter the the files in the templates directory, asdoc/templates. You should copy this directory to have different template files for different ASDoc builds. Point to a different template directory with templates-path.

    The templates directory contains HTML files which can be edited to alter the look of the final HTML files. There are also XSL files in there for the adventurous. It's not a supported feature to alter these files, and they will certainly change in future releases, but they are helpful in getting the final output to look just right.

    Posted by Brian at 5:53 PM

    October 21, 2006

    Category Feeds and Other Updates

    This blog went through an overhaul* today, with a new look and new feeds. If you only want to read about Flex now, you can use this feed:
    RSS 2.0 (Flex category only)
    If you're coming here for video and Brightcove information, then use this feed:
    RSS 2.0 (video category only)
    And all of the posts are still available on this feed:
    RSS 2.0

    Also, unrelatedly, I've been asked by a few people if I'll be at MAX this year. I won't be there, as I'll be diving into the new job. I'll just have to drink with everyone another day.

    * I updated Movable Type to 3.3, which was surprisingly painless. The snazzy new CSS styling is from Lilia Ahner. The category feeds were figured out from Anders Jacobsen's blog.

    Posted by Brian at 5:12 PM

    October 12, 2006

    Heading to Brightcove

    I'm leaving the house of Adobe and heading out to sea. I've decided to join Brightcove, where I will be working on a Flex application and helping the push towards Internet TV.

    It was not an easy decision- I've worked with many great people during my six year stint in the Boston office, and Adobe is an excellent company to work for. But I've gotten very excited about the job at Brightcove and what the company is doing.

    I plan to still stay involved with Flex at some level, as I think it has a very promising future. This blog will now talk about Flex as well as Internet video. Separate RSS feeds will be set up soon.

    To end with, here's part of the email I sent out to the people I work with:

    It was beer-o-clock on Friday that I finally realized that I'll soon be leaving here for good. More than six years ago I came here, and I couldn't believe that I got to work on JRun, a product I was already using. We put out a few releases, decided dung beetles weren't a good idea for an advertisement, and then scattered. I ended up on ColdFusion, where Damon put Erik and me to work on eeking out performance improvements, and where I got to give a code name to a product (RedSky). From there it was on to Royale, where I saw many parts of Flex. I went from RemoteObject advice from some Scottish voices to arguing web services with Tom Ruggles to SWCs and Flex Compiler Core.

    I would mention all the people who stick in my mind over the years here, but that would take up all the time I need to still finish my last feature... but I do want to say thanks to everyone. I very much appreciate all the friends (and products) that have been created in my time here.

    Posted by Brian at 5:08 PM

    October 6, 2006

    Using Resource Bundles in Flex

    An important note: if you're planning to use this information for Flex 3 development, please see the documentation instead. There's a number of significant differences in using resource bundles in Flex 3. This information is only applicable to Flex 2.

    This 1100-word article was supposed to be published, but I haven't heard anything about it in a long time. So I'm sharing it here:

    There comes a day when we all need an application in multiple languages. In Flex, the solution to this problem is resource bundles. In this article, I'll describe the basic use of resource bundles and create a small example in Flex Builder. I'll also suggest some resources for further exploration and ponder some potential future directions of this feature.

    The Basics of Resource Bundles

    A resource bundle is a simple file, commonly called a properties file, where keys and values are stored. The file format for resource bundles is similar to Java properties files, with a "key=value" on each line. The main difference from the Java properties format is that files with non-ASCII characters in them should be stored as UTF-8.

    Properties files are put in directories where they can be searched for by the compiler in the same way that other source files are found. The properties files should be arranged in directories in a specific way that's explained in the example below.

    The values in the resource bundles can be accessed in Flex through @Resource in MXML or through ResourceBundle metadata and the ResourceBundle class in ActionScript. There's two pieces of information that are needed to access resource bundles in MXML or ActionScript- a bundle name and a key. The bundle name is the same name as the properties file. So if you create HelloWorldBundle.properties, the bundle name is HelloWorldBundle. The keys are found in the properties file, to the left of the values.


    Setting Up the Flex Builder Project

    We'll start off the example by creating a new Flex project in Flex Builder. When creating the project, select Basic for data access and name the project whatever you'd like. Click on "Next" to enter more information.

    Before entering anything else in Flex Builder, we need to create directories for the properties files. The files should go in their own directories that are outside of any current source path. I've created the main directory for the properties file in the default directory for projects:

    	   C:\Documents and Settings\bdeitte\My Documents\Flex Builder 2\locale
    

    We also need to add subdirectories for each language we plan to have resource bundles in. The subdirectory names should match the locale names we plan to use We'll be using en_US for our English strings and sp for Spanish strings. So now I have:

    	  C:\Documents and Settings\bdeitte\My Documents\Flex Builder 2\locale\en_US
    	  C:\Documents and Settings\bdeitte\My Documents\Flex Builder 2\locale\sp
    

    We'll get back to putting files in these directories later. Now we want to finish setting up our Flex Builder project. To have the project find the resource bundles, we need to add the directories we've just created to the source path. We don't add a source path for both en_US and sp, but rather we use the special "{locale}" signifier. So I add this folder as a source path in Flex Builder:

    	  C:\Documents and Settings\bdeitte\My Documents\Flex Builder 2\locale\{locale}
    

    The Main application file name should be changed to HelloWorld.mxml. Then click Finish.

    Creating HelloWorld.mxml

    You should now have a HelloWorld.mxml file in front of you in Flex Builder. In Source mode, change HelloWorld.mxml to the following:<.p>

    	<?xml version="1.0" encoding="utf-8"?>
    	<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
    		<mx:Label text="@Resource(key='hello', bundle='HelloWorldBundle')"/>
    	</mx:Application>
    

    This is all of the MXML for the Hello World application that we are building. Note the use of @Resource for the Label's text and the key and bundle information. At this point you can try to compile HelloWorld.mxml, but you'll get the following error:

       Unable to resolve a class for ResourceBundle: HelloWorldBundle.	
    

    A class is mentioned here because the Flex compiler thinks of the properties files as classes, and it can't find a properties files.

    Adding the Properties Files

    Create the file HelloWorldBundle.properties in the en_US directory created earlier. Add the following to the file:

    	   hello=Hello World
    

    Create HelloWorldBundle.properties in the sp directory, and add the following to the file:

    	   hello=Hola Mundo
    

    The names of the properties files correspond to the bundle value we specified in @Resource, and the key value corresponds to the left side. We could add more key values as needed, like this:

    	hello=Hola Mundo
    	one=uno
    	bye=Adios
    
    Building and Running the SWFs

    We can then go back to Flex Builder and run HelloWorld. When you run the project, you should see on the screen the most exciting of Flex applications, "Hello World".

    To run the project in Spanish, right-click on the project name and bring up the properties for the project. In the additional compiler arguments, change the locale from "en_US" to "sp". The "sp" matches the folder name where we put the second HelloWorldBundle.properties. When you run the project after this, you will see "Hola Mundo".

    If you were building these Flex applications for later use, you would have to copy the directory of output files from the English version before building the Spanish version. Alternatively, you could build these files with the command-line compiler when creating the final SWFs. You would also need to build a page in HTML or Flash for choosing between the different languages.

    Further Exploration

    We only explored using @Resource within MXML and did not use the ResourceBundle metadata in ActionScript. This is an essential part of using resource bundles. Check the "Localizing Flex Applications" section of "Flex 2 Developer's Guide" in the Flex documentation to learn more about this.

    We didn't discuss a few of the more advanced features of resource bundles in this article:

    • Resource bundles can be used inside of SWCs if you create resource bundle SWCs.
    • Complete classes and media such as images can be internationalized by using custom resource bundles.
    • All of the framework uses properties files, and by using the framework source you can localize the framework.

    More information about these features can also be found in the "Localizing Flex Applications" documentation.

    The ResourceBundle API documentation can be used to learn more about resource bundles, but try to ignore the main summary on the page. Significant pieces of the description are currently incorrect.


    Future Directions

    There's a few issues with resource bundles which will be fixed in the next update to Flex. Most notably, Flex Builder can show an error after updating a properties file. You'll know you are encountering this problem if you see an "Unable to resolve a class for ResourceBundle" error where the class mentioned ends with "_properties". Clean the project in order to remove the error.

    We haven't decided on this change, but Flex Builder could remove the need to copy directories. This could be done through a publish dialogue that allows multiple locales to be chosen.

    Flex could allow resources to be dynamically retrieved at runtime. For now, Flex only supports the compiling of resource bundles into the SWF.

    In the far future, Flex may allow different translation formats than properties files, such as the XML Localization Interchange File Format. We also plan to allow media and classes to be added to properties files. This will mean that custom resource bundles won't be needed for complex resource bundles.

    Update: As noted in the comments, this article was published.

    Update2: This article has been translated to Chinese on zhuoqun.net.

    Posted by Brian at 1:17 PM

    August 20, 2006

    Finally Updated: Embedding HTML in a Flex application using an IFrame

    I've updated to Flex 2 (and which can also be used in Flex 3) the code by Christophe Coenraets for embedding HTML in a Flex application using an iframe.

    You can see a demo of it here.

    You can download the code here.

    To run locally, first compile IFrameDemo.mxml. If you are using Flex Builder, unclick "Generate HTML wrapper file" in the Flex Compiler settings before publishing, since there is an existing HTML wrapper. After this, you can view IFrameDemo.html. If you get a "Security sandbox violation" error, you need to put the IFrameDemo directory in the local-trusted sandbox. See the Flex documentation for information on updating FlashPlayerTrust files.

    There's been some comments below that say these instructions are no longer valid in Flex Builder 3. So check out the comments if these instructions don't work for you.

    The one cause for limitations in this code is the use of opaque for wmode. I've seen reports of tabbing problems in the player, and running more than one player when using opaque wmode seems to degrade performance.

    Check below the ad for some very important updates. The comments also have a lot of excellent details in them.

    Update 1: see this post for an update to the code that needs less HTML changes, allows multiple HTML pages to be referenced at once, and controls the HTML visibility as needed.

    Update 2 (an important update that I highly suggest you read): for my new views on iframes and Flex, read my post from July 2008: Don't Use IFrames for HTML in Flex

    Posted by Brian at 11:20 PM

    August 18, 2006

    Save your CSS with the Flex 2 Styles Creator

    Derek Wischusen has posted a helpful example that allows you to download all the CSS generated from the Flex 2 Styles Creator. I also recommend checking out the rest of his new blog, flexonrails.net for advice on using Flex with Ruby on Rails.

    Posted by Brian at 9:31 AM

    August 11, 2006

    ASDoc is Available on Labs

    Update: Flex now includes ASDoc. The documentation is here.

    ASDoc, the Flex and AS3 documentation tool, is now available on labs:

    http://labs.adobe.com/wiki/index.php/ASDoc

    The page on labs has everything you'll need to get started: a link to asdoc.zip, instructions on installation, an explanation of the examples, and links to the two additional pages of ASDoc documentation.

    If you have any questions on ASDoc, you can ask them here or on flexcoders, and I'll try to answer them.

    Posted by Brian at 2:25 PM

    August 10, 2006

    The Article to Send to Your Friends

    Send this article to your friends and coworkers:

    How Flex Can Transform the User Experience on the Web

    I don't normally link to other articles, since so many people read blogs from MXNA, but this one is worth special mention. Christophe makes a great case for Flex without even needing to mention the free SDK. The only issue I have with the article is the phrase "available today... across all major operating systems". I can see Linux users ready to pounce on this already. It'll be "available soon, we promise".

    If you send Christophe's article on to a friend, the reader will of course be itching to find out more about Flex. You can then soothe their itching with Manish's Hello World article.

    Unrelatedly, for those wondering, we are still planning to release ASDoc to labs. The concoction should be emerging soon, I promise.

    Posted by Brian at 9:18 AM

    July 27, 2006

    The Plan for ASDoc on Labs

    Update: Flex now includes ASDoc. The documentation is here.

    We're hoping to release ASDoc, the Flex and AS3 documentation tool, to labs within the next month. As Matt Chotin already let the cat out of the bag on flexcoders, I figured I could get away with a post on this not-guaranteed-but-that's-what-we're-planning release.

    ASDoc is the tool that was used to create the language reference. Current output from this tool looks very similar to the language reference. I'll give a little idea in this post on how the tools is used, but you'll have to wait until an actual release of the tool to get the full details.

    The HTML files are created by entering a list of classes, sources or namespaces, as well as additional parameters for controlling the look of the output.

    Creating comments in code follow the conventions shown in the Flex source. Here's an example of documenting a function:

    /** 
     * This is the typical format of a simple multiline (single paragraph) main description 
     * for the myFunction function, which is declared in the ActionScript code below. 
     * Note the leading asterisks and single white space following each asterisk. 
     * 
     * @param param1 Param1 description. 
     * @param param2 Param2 description.
     * @return Return value described here.  
     */
      public function myFunction(param1:String, param2:Number):Boolean
    

    Comments can be added to public class definitions, public function definitions (including getters and setters), public class-level variables, Event metadata, Style metadata, and Effect metadata. All other comments are ignored. There's a lot of tags, like @param and @return, that can be used to provide meta information to ASDoc. Some of the most popular are @author, @default, @private (no parameters, to hide a function/var/class), @see, @throws (two parameters, name and description).

    This is the project for labs that I mentioned a few posts ago that I am working on. It's coming along well, with the integration into the core of the Flex compiler being surprisingly simple but with lots of time being spent on making the details work right.

    Update: ASDoc is now out. See here for details

    Posted by Brian at 10:27 AM

    July 24, 2006

    Incremental Compilation from the Command-line

    A not-well-known but powerful feature of the command-line compiler is the "incremental" parameter. You should add this parameter to any command-line compilation that you call frequently. Flex Builder uses a version of this feature to speed up its compiling. It's also similar to the FastMxmlc idea that I posted about for Flex 1.5, except that this one is built-in and faster.

    You can read the documentation for this parameter here.

    As a related aside, if you're trying to find the Java class names for mxmlc and compc, they're flex2.tools.Compiler and flex2.tools.Compc.

    Posted by Brian at 10:13 AM

    July 3, 2006

    Updated performance tests for Flex and Flash Player 9

    I saw a question about performance tests today, and so I looked around a found a nice set of performance tests by Mike Lyda. Performance numbers comparing Javascript and Flash Player 7/8/8.5 can be found here.

    Curious to see the latest numbers, I updated the MXML tests for the latest version of Flex and Flash Player 9. You can get the updated source and SWFs here.

    I'll leave the posting of a complete set of performance numbers for someone else. A few of my impressions:

    Based on the relative speed of the Javascript tests, all but one (test 8) of the tests run faster than the Flash Player 8.5 (the beta for Player 9) numbers posted in October 2005.

    Initial string concating is much faster than in the 8.5 numbers. (Alternatively, string interning doesn't give as much improvement.) The first half of test 3 and 4 are only twice as slow as the second half.

    The harmonic, substring, and empty-for-loop tests (5, 6, 9) are blazingly fast now. 5ms, 10ms, and 60ms on my machine.

    Lastly, I'll describe the changes made to the tests. The namespace in each MXML page was updated. Types were added to all variables, which should make the tests faster and clear up the warnings. Other simple warnings were cleared. The MD5 source was downloaded from the suggested site and quickly converted to AS3.

    Update: The source and SWFs have been updated with a working test 10 from Mike. I've also updated the tests to clean up the MXML and remove the many warnings from MD5.as. Mike has also told me that he plans to update his page with the new results, and I'll update this page with a link when that happens.

    Update 2: Mike has updated the numbers.

    Update 3: Mike has updated the chart again, showing Java applets as well as the numbers for the latest version of Flash.

    Posted by Brian at 4:47 PM

    June 28, 2006

    The Launch of Flex 2 And Beyond

    Flex 2 is out. You can download Flex here. The pricing is the same as many had "guessed" in the past few days. I'm very excited about the pricing model that Flex is going with even if it means that, as a SDK team member, I no longer work on a product that makes money!

    I had a sabbatical set up long ago and ended up missing some of the end game of development. When I got back to work, things were quiet. Too quiet. There were fire drills and small fires, but none of the explosions I've seen in the past. That's a great sign for all for a release involving five products, three development offices, and no choice but high quality (as the player team is a bit of a stickler on this).

    So what is the development team up to now? Many of us are taking time off, nursing our wounds, and having some beers. We're also starting side projects, looking at those bug queues (or rather management is), and working on the things that were put on the back burner. I've heard of a couple of interesting projects happening on the compiler and data service teams. So enjoy the Flex 2 and Flash Player 9, but we're not done yet...

    Posted by Brian at 12:53 AM

    June 25, 2006

    Roger's Blog, Flex Conference, and Being Back

    I'm back and blogging, having finished my five-week trip and come back to only seeing India and China at lunch.

    Matt beat me to the punch, but I noticed that Roger has a blog:

    Interesting Flex/Flash hacks that are occasionally even useful.

    Roger is one of the other five programmers on the Flex Compiler team, a very smart guy who writes long emails. He often writes interesting emails on modules, RSLs, embedding, and many other topics that he'll now be able to share on his blog.

    So many blogs, books, articles, and other things happening around Flex 2 that I don't try to keep up with everything anymore. One neat thing to mention is that there's already a Flex conference coming up, on August 14th:

    Real-World Flex Seminar

    I've been working on something for after Flex 2.0, a project for labs that I'm excited to see done. I probably shouldn't mention what it is yet, so I'll just say that component developers will be very happy with me.

    Posted by Brian at 9:39 PM

    May 2, 2006

    A Sabbatical, Adobe, and Allaire

    I haven't been active blogging or on message boards lately, but I'll be even less so for the next five weeks. I have started my sabbatical, which includes a five week journey where I won't have a laptop, work email access, or many other of the things that I've come to find nourishment from.

    A great job where you get a sabbatical, get to work on something as cool as Flex, where you have managers who (I'm guessing reluctantly) let you jet away in the middle of a release. Did I mention we still have job openings for those interested?

    To go on a tangent, I recently found a hilarious picture in my office, an advertisement I was in from the Allaire days. To embarrass myself, here it is.

    Finally, if you'd like to read about my travels, you can do so.

    Posted by Brian at 2:06 AM

    Update to Embedding HTML in a Flex Application

    An update to this example for the final version of Flex 2 can be found here.

    I updated the files for Embedding HTML in a Flex application in AS3 in this directory. I didn't test the files with beta 2, but they should work with the upcoming beta 3.

    One important change is in the HTML wrapper, which was causing the HTML to sometimes disappear when using IE. There needs to be a parm setting wmode to opaque. I also updated the HTML wrapper to a newer version, and made a few other minor changes (which I would list, but it's been so long I've forgotten them...)

    The migration text I promised a long time ago doesn't look like it'll ever get completed, so I'm just going to copy the 80% done version below for those interested.

    When migrating Christophe's solution, Embedding HTML in a Flex application using an IFrame to Flex 2, I kept detailed notes of what I was doing. Below is the prettified version of these notes.

    The Easy Changes

    After writing this part of the migration explanation, I realized it wasn't really necessary, that it's easy for anybody to compile, see the errors, and look up in the help system any of the errors that come up. This worked very well, and I was easily able to figure out most of the issues I came across. But I kept writing things out, so here's the full migration info for those interested.

    I took the compile-fix-repeat method of fixing the issues. A studying of a migration guides along with a more structured search and replace would make more sense for a large project, but I knew some of the issues already, and I'm only converting three files.

    The first thing I did, without thinking, was change the mxml namespace from "http://www.macromedia.com/2003/mxml" to "http://www.macromedia.com/2005/mxml". The next change I made with my eyes closed was to add access modifiers to functions and type declarations variables. So "function moveIFrame()" became "private function moveIFrame()".

    Adding a type declaration of Object to pt gave me the Error "Implicit coercion of a value with static type 'Object' to a possibly unrelated type 'flash.geom:Point'". This made it obvious that I needed to change:

    var pt:Object={x:0, y:0};

    to:

    var pt:Point=new Point(0, 0);

    After that, I compile the add and got the error "Overriding function that is not marked for override" in IFrame.mxml, which extends Canvas, on this method:

    public function set visible(visible: Boolean): Void {

    That's another thing I should done off the bat, which is add override to methods that override:

    override public function set visible(visible: Boolean): Void {

    Next I'm told that getURL doesn't exist:

    getURL("javascript:hideIFrame()");

    I search the help and see that this line now needs to be:

    public var u:URLRequest = new URLRequest("javascript:hideIFrame()");
    navigateToURL(u);

    And I add "import flash.net.navigateToURL;" to the top of the Script block.

    Next I saw "Type annotation is not a compile-time constant: Void", which means I needed to change Void to void everywhere I see it.

    doLater() showed up as removed, so after searching the docs I changed this it to callLater, from:

    doLater(this, 'moveIFrame')

    to:

    callLater(moveIFrame)

    Dealing with HTML and ExternalInterface

    At this point everything compiled fine. I put index.htm into the directory where the SWF was (since I couldn't tell Flex Builder to use a custom html wrapper) and then clicked on the file to display... nothing. Ah yes, the SWF name was different now, from IFrameDemo.mxml.swf to IFrameDemo.swf. So I load it again and... nothing. I load just the SWF and it displays. I take the script out of the HTML page and see this error from Flash:

    SecurityError: Error #2051: Security sandbox violation: 'file:///C:/dev/flex/projects/iframe/IFrameDemo.swf' may not evaluate scripting URLs within 'file:///C:/dev/flex/projects/iframe/index2.htm'.

    I remembered that there was a new restriction in Player 8 (and 8.5) where local files and network files could not be accessed in the same movie. I wondered if relative URLs were thought to be network files. Sure enough, when I loaded the SWF through JRun, I didn't get the error anymore. But the page within the page still didn't show up. I figured out that unlike getURL(), navigateToURL() would not work allow any frame to be given as the second argument. So I decided to go ahead and convert the navigateToURL() calls to ExternalInterface.

    This took awhile. Converting the navigateToURL() calls was easy, as the ExternalInterface calls were very simple, like this:

    ExternalInterface.call("loadIFrame", source);

    But still the html page was not showing up. What was going on?

    At this point I conceived my my "debugging strategy" in Javascript, which consisted of looking at Firefox's Javascript console and throwing alerts up as debug statements. Ug. Is there a better way to do this? After sifting through the methods, I figured out that only the first argument to moveIFrame had all of argument information in it. So I changed:

    ExternalInterface.call("moveIFrame", pt.x+","+pt.y+","+this.width+","+this.height);

    to:

    ExternalInterface.call("moveIFrame", pt.x, pt.y, this.width, this.height);

    Once changed, the html finally showed up. But the frame showed up in the upper left hand corner. localToGlobal did not look to be working correctly.

    var newPt = this.localToGlobal(pt);

    After this, everything finally worked!


    Making Things Better

    The one problem I had at first with the generated html in Flex Builder was that I didn't know there was a to interject Javascript into the page. (html-template)
    Add the Javascript functions (moveFrame, etc). Added onMouseDown="document.body.focus();" to the embed, alhtough not sure if htat was needed. Also added + 'wmode="opaque"'
    + 'swLiveConnect="true"' to the embed. Added the iframe named 'myFrame'.

    The Tree on the left still looked really odd. Apparently the......

    Tried adding "rootVisible="false""

    Change the change attribute value in Tree from :

    iFrame.source=tree.selectedNode.attributes.path

    to

    iFrame.source=tree.selectedNode.path

    I made a few cleanup changes. The VBScript and related Javascript method in index.htm were removed, since it was only needed for some commented-out fscommands. In IFrame.mxml, I added a check for ExternalInterface via ExternalInterface.available, throwing an Error if it wasn't available. In IFrameDemo.mxml, I added a third section of links for Flex sites.

    Posted by Brian at 1:54 AM

    March 1, 2006

    AS3 Documentation and Libraries

    Update: If you're looking for the documentation of the AS3 and Flex APIs, you can find it here: http://livedocs.macromedia.com/flex/3/langref/.

    In the past few days, two important resources have been released for those interested in ActionScript 3.

    The first resource is the AS3 Language Specification. This is a highly detailed document showing the innards of how AS3 works. It should explain anything you need to know about AS3. And if you're a language geek and want to know things like the name for the expression of types of an instance*, then this is for you.

    The other resource is the AS3 libraries released by the Adobe Developer Relations team. These are seven free ActionScript 3.0 APIs for your own hacking. If I had the time right now, I'd love to be doing some amusing things with these APIs, like keyword searching on Odeo and Flickr together, showing a gallery of images that match the keyword when the podcast is playing. I hope others can amuse themselves with these APIs (and share the results, please!)

    *they're called traits

    Posted by Brian at 11:50 AM

    What I've Been Doing

    I haven't finished the migration post I mentioned weeks ago, the one related to Embedding HTML in a Flex application in AS3, as life has been busier than usual here lately. It's at a 80% done point where it may sit for a long time.

    One interesting thing happening for me is the recent approval of a sabbatical starting May 1st. I'll be taking six weeks off to travel the world, mostly India and China. If you live in one of those countries or know somehow who does, send me an email at brian at deitte dot com!

    I still find time to read blogs, though, of course. Ryan Stewart has turned his blog into one of the best in the Flex sphere. David Zuckerman from the Flex Builder team has started an interesting blog. And there's always the excellent posts from
    Steven Webster
    , which includes links to his Cairngorm articles on devnet.

    Posted by Brian at 11:22 AM

    February 8, 2006

    Localizing Flex Applications

    One thing that may not be noticed in the Flex 2 beta is that we now have built-in support for localization. I found out from Mike Peterson that "the new 'Localizing Flex Applications' chapter didn't make it into the Flex Builder help system or LiveDocs, but it is included in the PDF at this URL":

    http://www.macromedia.com/go/flex2_devapps_pdf

    So you can check out the localizing chapter there and start playing with @Resource and resource bundles.

    At the end of the 'Localizing Flex Applications' chapter, there's a simple example of localizing. I've put together the example to download here:

    The zip file is out-of-date for the final version of Flex 2. See the documentation for the example.
    http://deitte.com/rb_example.zip

    We're only supporting compile-time localization for Flex 2, but we've set things up in such a way that adding runtime localization will be easier in a future version. You can still do runtime localization manually, of course. And you may still be able to find an unoffical way to do runtime localization using the existing mechanism, but you'd have to track down Roger Gonzalez on flexcoders and see if he can cook up a way.

    Posted by Brian at 3:10 PM

    February 5, 2006

    Embedding HTML in a Flex application in AS3

    An update to this example for the final version of Flex 2 can be found here.

    I converted Christophe's solution, Embedding HTML in a Flex application using an IFrame* to AS3. It also now uses ExternalInterface, provides source with a right-click, and has some other minor improvements.

    You can try it out here.

    You can see the source by right-clicking in the application and selecting "View Source", courtesy of a new Flex Builder feature.

    To run it yourself:

    1. Install the Flex beta on your machine so that you have the latest player.

    2. Get the source to the example.

    3. If you are using Flex Builder to edit the source, you'll need to do one thing after creating a project. Go into Properties, then Flex Compiler, and uncheck 'Generate HTML wrapper file'. There is an existing HTML wrapper that shouldn't be overwritten.

    4. After modifying the code, copy IFrameDemo.html and IFrameDemo.swf to a webserver and call the html page through the webserver. This is needed in order to not run into a security error. If you do not do this but instead run the html page from the local filesystem, you will get the error "Security sandbox violation: ExternalInterface caller 'file:///IFrameDemo.swf' may not access 'file:///IFrameDemo.html'." I still need to investigate whether this is an expected error.

    It's a fairly small application, but there's three TODOs in there, little things that I will look into. I also have a very detailed writeup on my experience of migrating this application. I hope to post this either tomorrow or sometime next weekend.

    *whenever I click on a direct link to Christophe's site, I get a server error. It goes away, however, when I reload the page.

    Posted by Brian at 2:01 AM

    January 31, 2006

    Free Flex

    I'm actually surprised with the announcement tonight of a free license for the Flex SDK and Enterprise Services. I do usually know of things like this beforehand and I had heard internally that this was being considered, but I didn't know it was a certainty. I'm very excited to hear this, as I think it will help Flex grow and grow and grow. I'm also happy because I work on the Flex compiler, and pieces that I work on, like compc, will have a large audience.

    I've been MIA for awhile, but I do have a large post I've been working on when I can in the past few weeks. I rewrote Christophe's example for Embedding HTML in a Flex application using an IFrame for Flex 2.0 and to use ExternalInterface. It was a pretty small example that allowed me to detail all the steps I took. I will be traveling a lot in the next few weeks, but the post is nearly ready.

    Posted by Brian at 8:35 PM

    October 17, 2005

    ActionScript Projects in Zorn

    I've seen some people at the MAX conference get 2400 baud modem speeds while downloading the alpha version of Zorn from the new Macromedia Labs site. Remember that if you're here at the conference, many of us working on Flex have the software on a USB key. We're happy to let you copy the bits and start playing around.

    At lunch today, talking with some people who haven't played with Flex, I realized that many people think that Flex is just for big applications. While we do want to do large enterprise apps well, we're certainly trying to help developers create smaller apps as well. And really, really small apps can be created if that's what you need, less than 1k, by just using ActionScript 3.

    It's not that I want to promote building just in AS3 over Flex. The framework provides all the components that make life easier, plus I work on the Flex compiler. But for people who just want to play with AS3, need really tiny movies, or want to isolate a problem, I think it's very helpful to be able to write just ActionScript in a project.

    I'm sure there's documentation on ActionScript projects, but here's a simple example to illustrate how to do this in Zorn. Create a "New Actionscript Project" and name it "ImageTest". Put a PNG called "myimage.png" in the directory of the project, which defaults to "C:\Documents and Settings\username\My Documents\Flex\ImageTest". Replace the code for ImageTest with this:

    package 
    {
            import flash.display.MovieClip;
            import flash.display.DisplayObject;
    
            public class ImageTest extends MovieClip
            {
                [Embed(source="myimage.png")]
                public var embedClass:Class;
    
                public function ImageTest()
                {
                    var embedObj:DisplayObject = new embedClass();
                    embedObj.x = 100;
                    embedObj.y = 100;
                    addChild(embedObj);
                }
            }
    }
    

    Then go to "Run > Run", set up a new configuration, and you'll see the image in a movie in the browser. With a png of 805 bytes, this creates a movie of 1,809 bytes for me. Looking at the AS3 and Embed documentation, you'll be able to see all sorts of interesting things you can do with the combination of Embed, DisplayObject, Bitmap, etc.

    Posted by Brian at 6:29 PM

    October 14, 2005

    A Little Info on the Proxy in 1.5

    Some more airport blogging. I was going to write an article on the proxy, the part of Flex that is used by HTTPService and RemoteObject to access resources. I never found time to write much about this, though, and I don't see much time clearing up in the weeks ahead. Here's the notes I've jotted down for why you'd want to use the proxy:

    1. To have a centralized whitelist or when crossdomain.xml can't be used.
    2. When you need to have the text from errors. This doesn't show up without the proxy because the player isn't always given the text from the browser when there's an error status code.
    3. When you want custom dialog boxes for security, since the proxy is the only way to do custom authentication/authorization.
    4. And there's probably more reasons in 2.0. I don't know much about what's happening in the enterprise offering, but I do know the team has some amazing people on it who have been working like mad.

    Posted by Brian at 6:38 PM

    J2EE Application Server Support in Flex

    Before the deluge of Max, Zorn, Flex and AS3 postings, let me slip a few thoughts out on J2EE application server support. The below won't even be applicable to the 2.0 alpha, since there isn't a server in alpha quite yet. You'll have to wait until the enterprise offering is in alpha to start thinking about the below. So for now this is simply some lovin for all the 1.5 customers.

    I often see questions on support for different J2EE application servers. I spent time on both ColdFusion and Flex trying to get various app servers to work correctly, so I've been interested in this subject.

    The first thing to do is to see if your app server is supported. You can see the list of supported servers here. If your app server is in the support app server list, then nothing else should be needed! We have QA'd these app servers and we'll answer support questions on these servers. The only time you may need something else is if you are running on ATG Dynamo, which is available via hotfix.

    If your app server isn't supported, make sure to search blogs and flexcoders for known issues, as the few issues that are known have been discussed in multiple places. For instance, JBoss is not officially supported but is often asked about. The only issue I've heard about is answered in this message and in other places.

    To expand on the JBoss support issue, something that has come up many times, make sure to turn off the unified class loading behavior for the Flex web applications. You can do this by setting loader-repository in jboss-app, as shown here.

    I've generally seen things work for unsupported app servers. Flex is written without any native code, and it doesn't interact with the J2EE APIs too much.

    The areas that should be looked out for on unsupported app servers:

    a. loading of classes- class loading within Java can be tricky, and even trickier to diagnose. If you see a strange ClassCastException or problems on startup, it could be a class loading issue. We've tried to separate Flex from the rest of the app server via our own class loader, which is why most of the jars are in a "jars" directory rather than in "WEB-INF/lib". There's not much that can be done about this issue by yourself, if you do think something is wrong. You can try copying jars from your app server to the "jars" directory or vise versa, but that's really not recommended, as you're likely to break something else. If you're using the samples server, you can also try replacing or removing the axis.jar from WEB-INF/lib, since this jar has caused problems at certain points.

    b. webtier compilation- one of the places we interact with the servlet API is through compilation on server. If you don't see SWFs being compiled correctly but can compile them correctly with mxmlc, then this is the problem. I haven't heard of any problems like this that we haven't fixed, but if you suspect a problem, I would compile with mxmlc and place the SWF on the server. You'll miss out on some things if you do this (JSP tag library, ease of development, etc) but it may allow you to work with an unsupported app server.

    c. data services- this refers to using RemoteObject or using WebService and HTTPService with the proxy. It's another place where we interact with the app server through the servlet API. It's hard to diagnose this problem if it's occurring with RemoteObject, but for WebService and HTTPService you can set noProxy to true on the tag to determine whether this is the problem. If you are using HTTPService and having problems receiving data, try setting "flex.addFormParameters" to true as a JVM setting. Other than that, you'll have to set noProxy to true or email on flexcoders for help.

    d. data service security- if you're using RemoteObject custom authentication, make sure that your app server is supported. See "resources/security/CustomLoginCommand" within your Flex installation for information on setting up custom authentication on an unsupported app server.

    The above are the major areas of concern for using Flex with a given unsupported app server. Again, in general I've seen things work fine for unsupported app servers. It is also often hard to tell if a problem is really an issue just on a given app server, but the above can help narrow down the areas where problems could arise.

    Posted by Brian at 6:31 PM

    October 7, 2005

    Did You Hear the News?

    Hey, did you hear the news? I'm kidding, as I've seen more posts and more excitement than I imagined on the upcoming alpha of Flex 2. When you have your head down coding for so long, you sometimes lose sight of how all the daily changes being made will be seen.

    As long as I'm posting things a little late... I've already welcomed some of them, but a scotch toast to those from iteration::two. I'll be waiting (I'm sure in vain) for Macromedia to send me out to the great city of Edinburgh.

    Going to MAX? I'll be there too- feel free to say hello if you see this guy.

    Posted by Brian at 9:28 AM

    September 20, 2005

    Updates and Carrot Cake

    It didn't take too long for me to have a languishing blog. I do have half of my thoughts written down for a post on the proxy, but it might be a week or two before I finish them. So this will have to do for a quick grab-bag post.

    I haven't had too much time lately, and all of us working on Flex have been hard at work lately. Those on the flexcoders mailing list have probably noticed the decrease in posts from us. Ok, so I'll let you in why we've all been so busy lately... we're baking everyone a cake, a big carrot cake. No, we're just all hard at work for the next release.

    If you read this blog from MXNA, which I'm guessing many people do, you already know that IFBIN has launched a new site. I wanted to mention it anyways, though, since I've enjoyed watching the examples pile up there.

    I'm glad so many people have gotten use out of my FastMxmlc fix. From what I hear, this may soon become an official patch through a technote. I wish I could provide really helpful fixes like this all the time, but I should warn everyone that this is the only fix I have up my sleeve. I have other new things to show, though, and perhaps I will find another gem like that in my investigations.

    Posted by Brian at 10:51 PM

    September 5, 2005

    Speeding Up Mxmlc

    Since this page is still very popular, I want to make clear that the change described below is for Flex 1.5 and does not work in Flex 2. The Java class for mxmlc in Flex 2 is "flex2.tools.Compiler", and Flex 2 has something like FastMxmlc built-in with the "incremental" compiler parameter.

    A few weeks ago I posted on flexcoders my thoughts on how to speed up compilations from the command-line. At the end of the post there was one unanswered question in my mind- why didn't class caching work from the command-line? Class caching, aka SWO caching, is a way to speed up compilations by storing information on classes between compiles. This should work by default, but for a simple reason this was only working when compiling from the web and not when running mxmlc. Since I wrote the SWO caching code, I was quite certain there wasn't a good reason for this not to be running, and since there was a simple way to turn this on without actually touching Flex code, I created a class that did this to provide to others. This code is not supported by Macromedia, your mileage may vary, etc.

    You can download here a jar file that contains one class, flex.tools.FastMxmlc. I've found using FastMxmlc speeds up compilations anywhere from 5% to 200%. This speedup only comes when you have a lot of classes that haven't changed after a previous compilation. It also depends on how many classes you have. If you have more than a couple hundred classes, you could see more than a 200% increase.

    The code in FastMxmlc is really trivial, and only has more than three lines in the main method because of a workaround needed to give the right error status on System.exit(). Because of this workaround, you do need to always specify the output file via "-o". Other than that, everything will work just as it does in mxmlc.

    Here's a sample Ant snippet for using this jar:

            <!-- location of webroot (and flexlib) -->
            <property name="compile.webroot" value="apps/dev.war" />
            <property name="compile.flexlib" value="${compile.webroot}/WEB-INF/flex" />
            <!-- the file to compile -->
            <property name="compile.file" value="${compile.webroot}/checkinTest.mxml" /> 
            <!-- location for SWF -->
            <property name="compile.swfloc" value="${compile.webroot}/checkinTest.swf" />
            <!-- location of fastmxmlc.jar -->
            <property name="compile.fastmxmlc"
                      value="${compile.flexlib}/lib/fastmxmlc.jar" />
    
            <!-- compile using FastMxmlc, a simple wrapper over flex.tools.Mxmlc -->
            <java classname="flex.tools.FastMxmlc" fork="true" failonerror="true">
              <classpath>
                  <pathelement location="${compile.fastmxmlc}"/>
                  <fileset dir="${compile.webroot}/WEB-INF/lib" includes="*.jar" />
                  <fileset dir="${compile.flexlib}/jars" includes="*.jar" />
              </classpath>
              <jvmarg line="-Xms32m -Xmx768m -Dsun.io.useCanonCaches=false"/>
              <arg line="-o ${compile.swfloc} -flexlib '${compile.flexlib}' 
                         -configuration ${compile.flexlib}/flex-config.xml 
                         -webroot ${compile.webroot} ${compile.file}" />
            </java>
    

    And now the summary, for those who skimmed the above: you can download here a jar file that contains the class flex.tools.FastMxmlc, a simple wrapper over flex.tools.Mxmlc. This is not a Macromedia-supported jar, but you can try it out for speeding up your command-line compilations. Enjoy!

    Posted by Brian at 1:38 PM

    Hello world

    Welcome to my home for occasional thoughts on Flex. I'm Brian Deitte, and after working on application servers for five years, I thought it was time for deitte.com to be more than an email address.

    I've been working on Allaire/Macromedia servers for quite awhile- two years on JRun and its servlet engine, a year tuning ColdFusion and CFCs, and nearly two years working on Flex and RemoteObject, the proxy, compc, and now the compiler in general.

    I can't talk about what I've been doing lately, the great amount of work being done for 2.0, but I do have a few things I'd still like to share about Flex 1.x if I can find the time- information on a faster mxmlc that should appear shortly, an apologia for the proxy, and some thoughts on developing on unsupported platforms.

    I've already read so many interesting things on Flex in blogland- Matt's early, where-the-hell-does-he-find-the-time posts, the neat IFRAME trick from Christophe, Scott's posts on CF and Flex, the ideas for building better RIAs from Sho, and of course much from the hard-drinking, hard-working folks at iteration::two. I can't promise anything like the above, but I should bring a few new Flex ideas into the mix. And yes this domain still serves its original purpose, as a permanent email home for me- you can contact me at brian (at deitte.com).

    Posted by Brian at 12:34 AM