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.

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.

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

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.

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

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.

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

For those that attended my 360|Flex session on Array/DataStructure performance, here is an updated version of the code I was using to demo. A few things:

1. The timing method I am using only has millisecond resolution. So, the difference between 0 and 1 millisecond could change in subsequent calls. I would pay more attention to the difference between 1 and 100, which is what we really care about.
2. Right not the default number of items being created in each structure is set to 5000. You can change this and the insert/delete numbers by changing the constants in the main MXML file
3. Playing with the aforementioned numbers will really help you get a sense of how these things work. For instance, it is really interesting to see the difference between sorting the ArrayCollection up front or later as the array size grows.
4. There are (n) more variations of each of these.. using push() instead of direct addressing. Telling the vectors to be fixed size instead of dynamic. I kept this open enough that you should be able to add those cases and explore as you see fit, but I didn't cover every permutation in this code
5. I added some filters on the main page so that you can easily lose/add tests or datapoints to get a better view of the data
6. I didn't include the LinkedListCollection code in this package. I will get that out soon, but I want to clean it up and comment it. It is confusing to me right now and I wrote it

Okay, so, that's it. Have fun and play. In the end, this is all about finding the best tool for any particular job.

About a year back I remember reading a blog post called JUnit in 60 seconds. At the time I pondered how great it would be to have these features in Flex. Little did I know that today I would be writing this post introducing the Flex world to FlexUnit 4.

So, first a little background. FlexUnit 4 is the name for an upcoming release of FlexUnit. It represents the best features of the FlexUnit project combined with the best features of the Fluint project. It is built on top of a newly created foundation designed to support the latest techniques used in the JUnit testing community, but written for the specific requirements and needs of the Flash Player. Top all that off with an extensibility layer that encourages developers to create new types of test runners and extensions while simplify the process of integrating the results into IDEs and continuous integration environments, and it should give you an idea why I am excited about this release.

If it sounds interesting to you as well, the public alpha of this upcoming release is now available as a turnkey test project you can download from the adobe open source site. I hope you will use it to learn and explore the new features, and to provide feedback about any bugs you find along the way. However, it is an alpha, so locations and names of classes, signatures of methods and even which features are supported are all subject to change before release. It is not be advisable to use this as your production testing system.

Speaking of features, let's jump in. There is a bit more content to go through than the original 60 second tutorial, so, I think you will need 4-6 minutes to get through it all. To keep things consistent, many of these examples are adapted right from the JUnit in 60 seconds site referenced above.

[More]

Okay, it has been way to long since I have had the opportunity to post anything of value. So, here are a few classes I wrote called Constructor, Field, Method and Klass. They also use one additional class named MetaData tools. These classes roughly mirror the java.lang.reflect classes. They aren't quite as thorough, but there is some good stuff in here.

In the next few weeks these will be released as part of a larger project, but I thought I would take the opportunity to throw these early versions online as I have found them extremely useful over the last month. In addition to the 'normal' stuff you would expect in introspection, these also take care of a few gotchas that you might run into if you are used to Java and now play in the AS sandbox.

First, the default describeType method of the flash.utils package doesn't actually know how to get constructor parameters from the metadata until the class has been constructed, in some capacity, once. This is really frustrating but can be handled by doing a behind the scenes instantiation and capture. Not gorgeous, but it works and gets me the parameters I wanted.

Second, DescribeTypeCache has a few issues regarding when a description is cached. If you cache it for the first time before the first instance is built, you will forever get that version back. This means that the cached record may look different dependent upon the order you called it... so not cool.

Third, pre-flash player 10, you can't specify that an array will contain a given type of data. Flex has a metadata tag called ArrayElementType, which MXML will respect (in some cases) but overall it is mostly useless. This library will actually look at that ArrayElementType at runtime and at least tell you what data you expected to go into the array. This is actually quite useful in a number of situations ( however, you need to ensure you instruct your project to keep the ArrayElementType metadata.

Fourth, you can fake out having a constructor.apply() at least for a limited set of arguments.

Fifth, actually, I'm not sure what's fifth, so just grab these classes and give them a whirl if you are interested. I promise they will be documented and have some asdocs by the time they are released, but these are a start.

Also, in the next month I will be presenting at both 360|Flex Indianapolis and webDU (within a few days of each other). These are two of my favorite conferences. They both have a unique message and a great crew behind them. I hope to post more about these soon, but if you can make either of these conferences, I would love to sit down and explain the bigger picture of where these classes come from, and, hopefully, get you playing with some very interesting new code.