As many of you know, I am the project lead for FlexUnit 4.x. The technical side of the project is in great shape with new features, releases and tests forthcoming, however, the place we are really lagging is good documentation.

Right now the FlexUnit team is quite small and 120% of our time is occupied with development and user support. Unfortunately this means that the best engineered plans for good documentation seem to get farther behind as the days go on.

We are looking for a few people who would be willing to own large chunks of the documentation. We would arrange conference calls as needed with the developers of key sections to talk through approach, technical details and future plans. The goal would be to ensure you have a full understanding and access to anyone you need when writing. Ultimately, it would also give you a few things.

First, you would have unlimited access to learn FlexUnit at a very, very deep level. Second, you could help create a volume of work (I am hoping we can produce both wiki content and eventually a comprehensive PDF book) which will continue to be attributed to you. Third, that attribution plus future recommendations from myself and others on the team and in this industry are guaranteed (and very helpful for future interviews).

Anyone who is seriously interested should leave a comment on this post and I will reach out to you immediately.

If you want to take a look at our current efforts, head over to docs.flexunit.org

Thanks,
Labriola

For months now the core FlexUnit team and contributors have been working diligently to move the next release of FlexUnit forward. The 4.0 release was a success but we always knew there were many optimization and enhancement still to come. Today, we are happy to announce some of those are available as the 4.1 public beta begins.

You can download the latest bits from the flexunit.org download site.

Here are a few feature descriptions and bullet points of some of the new features in the FlexUnit 4.1 world.

Parameterized Testing

There are times when you need to repeat a test across a series of data points. Imagine a class that does a complex calculation based on input values. It is likely that you would want to test hundreds or thousands of different input values, checking each of their expected outputs to feel comfortable that this class was behaving properly. Or, perhaps you have a whole series of components which implement an interface and you wish to verify that setting the 'x' property on each of those objects dispatches and expected event or updates a given property. These are both cases where Parameterized testing can simplify your life.

[More]

First, let me say I am sorry. A year or so ago, I wrote these VectorCollection classes. They are not spectacular works of art, they are very basic implementations required to use Vector inside of Flex components which are looking for IList and ICollectionView for their dataProviders.

Vector has some performance advantages in some cases (for more details, take a look here. ) but overall, the big advantage to me is type safety. I know what should be in the Vector and flash knows if I mess that up.

On the whole, these are simple implementations that don't solve every problem I would love to solve if I had the Flash Player source and some time, but they will allow you to use Vectors more directly in Flex. So, if you find them useful, then enjoy.

Files available from Download link below post.

Cheers,
Mike

March is shaping up to be a busy month for speaking, and I am pretty happy about it. I have the opportunity to deliver two distinct talks on topics where I feel, let's just say, a lot of passion.

First up in the 360|Flex Conference in San Jose on March 7th-10th. Here I am delivering a talk about the Flex Framework and its relationship to the component development in the Flex 4 methodology. There will actually be quite a few Flex 4 talks (and even component talks) available at 360|Flex this year; however, I think this will come across differently. I intend on tearing apart the framework again along the lines of my Dense and Hot presentation a few years back. The intent of this presentation is less about what and more about why. I want you to know things like the order that nested components have their commitProperties called versus their measure when you leave. More importantly though, I want you to walk away knowing that it's because of priority queues and nest-levels. I want you to feel comfortable explaining it to that poor guy back at the office that couldn't make it to San Jose for the conference. That guys deserves some love to. You want to help him, right? I digress.

In either case, I hope you can make it out to 360|Flex. It is always a good event. It is chocked full of great content and I don't know that there is a better value in the Flex conference space. If you want to be extra-nice to me, you can register with this link. Apparently if enough people register that way, John Wilker is going to carry me from place to place in some type of litter. All said though, try to make it if you can. Even if I wasn't speaking, I would still be there learning from a great community willing to spread a lot of knowledge.

Right on the heels of 360 is the WorldWare conference in Santa Clara on March 16th-18th. WorldWare is a conference dedicated to those developing applications for an international market. I will be doing a pre-conference workshop on the benefits of using the Flex Framework, with all of its UI swapping, layout object goodness, to the benefit of those wishing to write an i18n application in a reasonable amount of time and with a reasonable expectation of maintaining it (without sleeping at the office for the rest of their lives). This year's theme at WorldWare is the ROI of Software Internationalization and I am honored to even be considered near the profound list of speakers. If your application or company is targeting the international world this is the place to be in March.

Hope to see you at one (or both )of these events,
Cheers,
Labriola

Dependency injection with Flex UI components can be tricky business. Not just doing it, there are a lot of strategies for that, but to do it without causing performance degradation and unnecessary work on the part of the framework and ultimately flash player. To understand why, we need to discuss a bit about the whole component life cycle.

When a component is first instantiated, its constructor is executed and any local variables that might have been declared with initial values are set, etc., but the most important stuff... the stuff that makes a component a Flex component hasn't happened yet and it won't anytime soon. Properly written Flex components do the balance of their work after they are added to the display list. Back when I first started yapping about this stuff most of these life cycle methods weren't well known, but today there are a lot of great resources on them, so I am just going to stick to the basics.

The methods I care about are createChildren, measure, commitProperties and updateDisplayList. Each of these methods is called by the Flex framework after the component is on the display list. With the exception of createChildren, you can almost think of these methods as being scheduled. They get called by the framework, at an appropriate time for optimal Flash player performance, if the component itself or some outside force deems it necessary.

To take advantage of this scheduling and to ensure you don't have timing issues, a properly architected Flex component waits to create any static visual children until the createChildren method is called. It waits to make visual changes to the component until the updateDisplayList method. When a property is changed on the component that could affect one of the components children, i.e. the textinput inside of a datefield, the component saves off this change and applies it when commitProperties is called. Finally, the component aggregates information about its size and reports it (but never, ever changes it) during the measure method.

The reason I mention all of these things is that there is a fair amount of work that starts happening the moment the component is added to the display list. From that point on, all of these methods are called and changes to the component, especially those involving the amount of space it takes on the screen, can cause major amounts of rework. (If I change the size of a button in the middle of the page, I may need to size and layout the whole page again). You would never know this from the Adobe docs, but the creationComplete event is likely the worst place you can do many things and that is for this same reason. Everything is sized, positioned and ready to do... then you cause it all to change again.

[More]

If you are in the midwest this weekend, you should really, really consider dropping by BFusion & BFlex in Bloomington, Indiana. It is a bring your own laptop event full of hands-on tracks conducted by speakers from around the globe combined with optional full-day training sessions. The schedule is packed so full of content on Flex and ColdFusion topics that your only regret will be the inability to attend twice.

Here is a smathering of sessions from the Flex track (and remember, there is also a full day of fusion content too )

• Hooking up Flex and ColdFusion. An introduction to CFAAS
• Integrating BlazeDS and ColdFusion
• New Flash Builder 4 WSDL and HTTP Connectors
• Drag and Drop Image Manager with Flex & AIR
• Practical Cairngorm for Adobe Flex Applications
• Creating Your First HTML-Based Application for Adobe AIR with Dreamweaver CS4
• Building Flex Apps with Swiz: Simple, fast, flexible, powerful.
• Spark Components for Flex 4
• Component Development using the Flex 4 Model
• Using Merapi to tap into native code in your Flex application
• Flex Component Development from Scratch
• 90 Minutes + Flixel = 1 Game
• Creating Applications for the Flash Platform
• Flex Intro for Developers
• Introduction to Flash Catalyst

I am not sure how the folks at BFlex manage to provide this for a $10 price tag, but if you are close enough to even consider going to this event, it would be a mistake to miss it.

Hope to see you there,
Labriola

I just finished my presentation materials for my Test-driven development session at Adobe Max, and I am pretty excited how it turned out. It is a 90-minute BYOL (Bring your own laptop) lab, which is always challenging. Each person showing up with a diverse setup and (hopefully) our files installed.

So, if you are planning to head to Max, and you are interested in TDD, try to attend. I think it will be well worth the effort.

That said, there will also be two sessions at the 360|Flex Max unconference where we will be reviewing the FlexUnit 4 framework from the inside out. The goal here is to provide initial context for those interested in becoming committers on the project. FlexUnit 4 is a highly functional testing framework, but it is also complex. Until we have the chance to document every corner, this might be your best chance to learn the ins and outs of it.

Finally, working on this session has given me the opportunity to work with the FlexUnit plugin in Flash Builder. I must say I am very pleased with how this is evolving. Nonetheless, there are a few enhancements I would still like. If you are of a like mind, read through the bugs and cast your vote.

• Auto Refresh of the flex unit compiler application when deleting a test case or (minimally) re-running the wizard
  Right now deleting a test case causes a manualy compilation error that needs resolution. I think this could be more elegant.
• Uncheck Create Constructor by default in FU4 test case
  Just a minor inconvenience. You generally don't need constructors in FU4 test cases, so you uncheck a checkbox... often
• Generate Before/After in place of setup/teardown for FU4 testcases
  Right now the wizards don't know how to generate the FU4 equivalent of setUp() and tearDown(). Not a big deal, but I think it's low-hanging fruit.
• Remember Last Selected Type when creating test cases from the wizard
  Just a minor inconvenience. You always need to re-select the radio button when using the wizard with FU4.

If you agree, vote away.

Hope to see you at Max,
Mike

So after a very welcomed summer lull in travel, I am gearing up for the fall speaking season. A good portion of my time this fall will be spent discussing, encouraging the use of, and getting Feedback on the FlexUnit 4 project. The rest will be spent teaching about the early architecture and internals of the future Flex 4 product.

If you have tried either of these and want to discuss, or if you haven't had the time and want to learn more first, please come and support one of the following great events where I will be presenting.

September 5th, Rimini, Italy at Flash Camp on the Beach

Testing with Flex and Flash Builder

October 5th - 7th, Los Angeles, CA at Adobe Max, Los Angeles, CA

5th - Test Driven Development with Flash Builder
5th - Creating Custom Components in Flex 4
5th - Book Signing and Meet the Authors Event

6th - Creating Custom Components in Flex 4
6th - Battle of the Flex Frameworks Panel

7th - Creating Custom Components in Flex 4- Twice

Also, in the next couple of days we will be announcing the details of a special event on the 6th and 7th in coordination with the 360|Max unconference for individuals interested in becoming contributors to the FlexUnit 4 project.

October 15th and 16th in Omaha, NE at the Heartland Developers Conference

15th - From Concept to Concrete: Programming a Designer's Vision
16th - Reanimating Dead Data with Flex

October 17th and 18th in Raleigh, North Carolina at CFinNC

Next Generation Testing

I hope you have the opportunity to participate and engage with the Flex community at some of these community events.

Cheers,
Mike

Alright, it has been an insane few months but we are ready. FlexUnit 4 Beta 2 is now available on the adobe open source site. You can download the turnkey project to play with built libraries quickly or follow the directions on the Source page to grab the source yourself.

There are a huge number of fixes and enhancements in this version, all of which you can find for yourself on the release notes page but the largest change of note is the availability of CI tasks and a CI listener to allow easy hooks into the continuous integration system of your choice. A lot of hard work went into building and vetting these out on different platforms but I wanted to call out a few names in particular.

First, thanks to Peter Martin, because all of this was based on his original work for the FlexUnit .9 tasks. Second, thanks to Joe Adkins, Conrad Winchester, Brian LeGros, Xavi Beumala and Simeon Bateman all of who contributed to development, testing and/or generally being good spirits despite inevitable development slow-downs and hiccups. This is beta code, so there are a couple of caveats and to-do items still on the list, so please be sure to check out the README file in the sample project, or read it on the wiki.

So, take a few minutes, grab the bits and play around. If you have any questions or comments, in particular around the new CI tasks, head over to the FlexUnit forums. If you believe we mutually disagree on the definition of a functional feature, then please log it into the bug database.

This is a completely community run project and your help and support are always welcome.

Cheers,
Labriola

So, suppose you are the kind of person who has downloaded the FlexUnit 4 turnkey beta from opensource.adobe.com. Suppose you are also the type of person who downloaded the new Flash Builder 4 beta from labs.adobe.com. Well then perhaps you are thinking to yourself, "Self, I would really like to see the results from my FlexUnit 4 tests right inside of the FlexUnit Result view in Flash Builder. I wonder how I would do that."

Well, I would personally suggest you add the following import to your FlexUnit4Turnkey.mxml file:

And then add the following line before your call to the run method of the FlexUnit 4 core.

Ideally, it will look something like this:

Where the string "FlexUnit4Turnkey" represents the name of the project where this MXML file resides. If you open the FlexUnit Results view in Flash Builder and execute this MXML file, you will see the results in Flash Builder.

Unfortunately, you need to be aware of some of limitations. First, Flash Builder doesn't know how to generate these tests yet and will currently fail if you click any of the buttons such as Run All Completed Tests, Run All Failed Tests, etc. We can just give it back information about the success and failure, Flash Builder doesn't yet know how to choose, run or specify FlexUnit 4 tests. Also, and perhaps more severely, Flash Builder considers any Ignored tests a pseudo-failure. Truthfully, it just doesn't understand what we mean, so, in some cases, it looks like a failure, but in others it doesn't.

Right now, FlexUnit 4 beta still also outputs to the console, which means Flash Builder will try to keep switching you over to the console view, but this will be a little cleaner in our (FlexUnit's) next beta drop. In either case, it is perhaps a bit of a novelty for the moment, but it demonstrates the power of the listener model that FlexUnit 4 uses. Wait till you see the stuff coming for Continuous Integration :)

Cheers and have fun,
Labriola