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

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.

Cheers,
Labriola

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.

Cheers,
Labriola

At the end of last week Fluint 1.1.0 was released. For those of you that don't know, Fluint is a unit and integration testing framework that was originally developed as an internal tool here at digital primates. We decided to open it up to the world as we thought there was some benefit. Turns out that others thought so too.

The greatest thing about this new release is that almost all of the code was written and submitted by community members using the product. Here at DP we have been making some changes internally that we intend to offer back to the project (if the community wants to incorporate them) but in the meantime, the new build offers:

• Better differentiation of errors and failures
• Compliant XML output that can be used with JUnitReport and Surefire
• A method of running Fluint on a headless CI server
• Improved ant tasks
• Improved separation of the test runner and tests with modules
• Bug fixes and a menagerie of other features

At the end of the day, I am just proud to be a part of the project and want to offer a thank you to those who helped on the forums, submitted code or even just complained to bring things to our attention. So, thank you.

Soon we will begin active dialog on the next round of features, so if you are interested, please join the discussion.

Cheers,
Labriola

Okay, I haven't blogged about anything of value in a while, yet I am still here to ask a favor. Right now Adobe has a big decision to make. They need to decide whether or not to prefix all of their classes for the Flex 4 release. Simply put, developers in Flex today are used to writing a line of code that looks like this:

<mx:Button/>

The mx namespace is mapped somewhere in your MXML document to a URI. That URI indicates you mean the Flex 2 or 3 component set, affectionately called Halo. Flex 4 is going to introduce a new set of components with a different organization, but Adobe is struggling with how to allow their interoperability. Right now, the proposal is to prefix the name of each of these classes with an Fx, meaning that from now on there would be

<Button/> which means the old Halo component and
<FxButton/> which means the new Flex 4 component

Now, the idea of two separate button classes is a given, it is the only way that progress can be made developing a new flex framework while maintaining any compatibility, but it is the Fx prefix that seems problematic. What happens when we go to the next version of Flex, will it be

<NewFXButton/> or <NewerFXButton/>

Overtime, people will use fewer and fewer Flex 3 components as Flex 4 evolves, but we will forever be caught with this naming convention. The alternative, and, imo, preferable way is to continue to use namespaces as we do today. So:

<mx:Button/> would mean the old Halo component and
<fx:Button/> would mean the new Flex 4 component

Effectively, you are simply indicating a Button and the namespace indicates which one you would like. To me, this makes a bit more sense as we are already familiar with this concept today. If you make a custom component or a custom library, you are likely already mapping a namespace to get your specific version. If you are not intermingling the two types of components (which will eventually be possible) you could simply map the namespace differently and type <Button/> again.

While there are some CSS complications that need to be addressed in either case, the primary reason for this prefix discussion seems to be Adobe's belief that new users won't be able to grasp the concept of mx:Button versus fx:Button. Now there are plenty of challenges a new developer faces while learning Flex, not the least of which are likely caused by the belief by some that Flex is supposed to be trivial to learn, but in my years of training and mentoring, I have never had a pupil so confused by namespaces that a minute long explanation didn't suffice.

I am just against making every developer from this point on always have to retype a prefix. I am against deviating from what seems like a sane plan of continuing to use namespaces as we do today, and I am generally worried that the decision is being made for the wrong reasons.

So, if you have an opinion, let someone know. Please don't just take my opinion but read about this thread on the Adobe SDK Forum and form your own. If you feel that the Fx prefix to all components is a bad idea once you understand all the viewpoints, then consider voting for this bug on Jira, which is to eliminate the prefix (and to use namespaces as we do now).

Flex is a great product that may become a great open source product. Let's all take that seriously and take some ownership of the issues, bugs and direction.

Happy reading,
Labriola

Okay, so I haven't managed to post anything of value in a while but I am hoping that is about to change. Over the coming weeks and months, I plan to start posting ad hoc classes I have found useful or just little snippets that might save you some time. Hopefully, that will give you a reason to come back and visit.
In the meantime though, voting has opened up for 360 Flex Indy. Votes are being tallied for each session and, as I understand it. The top ones get presented. So, for any of you that enjoyed 'Dense and Hot' and 'The Ties that Bind Us' (aka Diving in the Data Binding Waters) you may want to log in and vote for my latest session 'Any Which Array but Loose'. Continuing the trend of ridiculous deep dives on Flex topics, I decided to tackle the various array types available with Flash Player 10. I am at a bit of a disadvantage though. Since I updated my description after the site launched, I seem to have lost any initial votes on my topic. If you vote, I do promise that there will be much more information presented then you could possibly want.

Also, Thursday and Friday, I will be at Flex Camp Chicago. A sold out event in Chicago with a lot of great speakers. For anyone who is attending, I will be hanging around for the balance of the days, so feel free to come up, introduce yourself and talk Flex. I will be happy to answer any questions I can or help you around a problem in code.
Cheers,
Labriola

It's election day here in the United States. Perhaps it is in that spirit of change that I write this post. More likely it is a rant in frustration to developments I am seeing within the Flex community, but here it goes.

Here is my fundamental assertion: Anyone who thinks that every problem can be solved in the exact same way is someone you should ignore. Problems are unique and hence solutions need to be unique.

Within the Flex community it is popular to either be pro or anti Cairngorm. I myself have pointed out frustrations with it in the past, but I would like to take a broader point here as this post is not about technology, it is about people.

Cairngorm is a way to solve a problem. Actually, it is a good way to solve a very specific problem. The issue is that it is not the best way to solve every problem. I have no issue with Cairngorm but I do have a problem with Cairngorm evangelists.

I have worked on many projects where Cairngorm is an appropriate solution and I have found no desire to remove it, but I have also worked on a plethora of projects where it is the wrong solution. Unfortunately, many times this technology decision persists to the detriment of the project. Since some of you aren't you going to believe that there is a project where Cairngorm isn't the right solution, let me provide an example.

We have a new client attempting to develop a component framework (effectively an extension of Flex). Those components will be reused by other customers in the field to build applications. They were trying to use Cairngorm to build their component framework, meaning they were calling Cairngorm events from inside of List controls, etc. This is not the right use for Cairngorm, yet they are adamant to continue. Why? Well, because Adobe said so.

<EDIT> When I say "Adobe said so" in the previous paragraph, I am not attempting to say that they declared to this customer a specific engineering solution. My point is more about how the collection of Adobe's offerings and words are perceived by people learning Flex. Sorry for any miscommunication on that point. </EDIT>

At WebDU earlier this year Robin Hilliard of Rocket Boots asked me, 'why is it the world versus Cairngorm.' I answered at the time that Adobe advocates it so strongly, but I didn't really have an eloquent answer. I do think the answer it correct. Right now, the only 'advanced' Flex curriculum from Adobe is about Cairngorm. The only framework I can find mentioned on Adobe's site is Cairngorm. Peter Martin of Adobe Consulting announced a Cairngorm plugin for Flex Builder, and Adobe consulting was kind enough to tell this client that every single Adobe consulting customer uses Cairngorm and given their wild success, it is clearly the right way to go.

Wrapped up in that final statement is my core issue: First, unless you truly understand the problem a customer is facing you can't possibly recommend a solution. At least you can't do so and still call yourself an engineer in my book. However, does anyone truly believe that Cairngorm was the perfect solution to every single problem ever encountered? That there was never a better approach to be had? I personally have trouble with that.

I have had this discussion with others in the Flex community and likely used this analogy but here it is again for good measure. Software is a strange version of reality. In the real world you might admire a beautiful piece of sculpture. It is unlikely that your opinion of it would change drastically when you learned the brand of chisel used to create it. In the software world, I hear this ridiculousness all the time. The tool used has become more important than the end result. That is sad.

I know this post sounds like a bashing of Cairngorm and the people who use it. This is not my intent. I have a lot of respect for a lot of these people. The point of this post is simple. Problems require solutions. Sometimes you can start with an existing framework and work from there. There are several valid ones in the Flex world, but if you close your mind to possibilities outside of a single choice, you are harming yourself and the project.

Rant complete,
Michael "MVC isn't always the right solution" Labriola

Some of you may know that Digital Primates released a beta-quality testing framework some time back called dpUInt ( digital primates unit and integration). This started an internal framework we developed for testing UIComponent derivatives. One day we decided it was useful enough to share with the world, so we started a google code project and sent it off into the wild.

Then, wow. More people than we initially expected were running into the same problems we had encountered when testing Flex applications. Soon we were receiving emails and calls from companies using dpUInt who were curious about support and the future of the project. As of this moment, I know of at least a dozen well-known and respected software firms using it for their testing framework and hundreds of developers who have written me with question and suggestions.

Well, I am happy to say that dpUInt has grown up a bit and finally reached the 1.0 stage of its life. Based strongly on the feedback of its users, it is also adopting a new project name, Fluint (pronounced Fluent).

The new google code project, which can be found at http://fluint.googlecode.com/ has been refactored a bit. Instead of acting as a single library project, the new repository has top level directories for each of the following sub-projects:

fluint - Library project used to build fluint.swc
fluint_FlexTestRunner - Simple Flex project with a sample test runner
fluint_AIRTestRunner - AIR project designed to run tests from an automated build environment of simply via command line
fluint_AntTask - Ant Tasks that facilitate running the AIRTestRunner from ANT
fluint_Samples - Samples project that will grow to contain samples uses and modules

The source for all component, including the AIR test runner and ant tasks are now included. Further, a few new features have made the jump to the new project as well:

• Ant tasks / AIR testing modules now supported (No need to recompile the test runner for new tests)
• AIR Test Runner with full source for command line and ANT invocation
• Improved performance
• Tests can now be marked by [Test] metadata which allows the inclusion of descriptions and additional metadata carried through to the testing UI
• And of course, bug fixes

While the code and the name are in better shape, we can still use help adding more documentation. So if you are up for helping improve the Wiki pages or for providing any additional forms of documentation including tutorials and videos, we are game.

The google code project has an issues tab for reporting any issues found during use. So, please report bugs or simply file enhancement requests. Planning for the 1.1 release is soon to be under way. We are already committed to simplifying the syntax and readability of testing sequences, but we need help to define what else is going to be on that list.

Thanks,
Labriola

September 6th and 7th I am headed down to BFlex in Bloomington Indiana. This is a great FREE two day conference that covers ColdFusion and Flex. There is a planned beginner and advanced track with good sessions and speakers. And, disproving the no-free-lunch theory, lunch is also provided each day, but advanced registration is required and limited to 200 people. Slots are going quickly so, if you are interested, do not delay.

This event takes place Saturday and Sunday, September 6 and 7, from 8:00 a.m. - 6:00 p.m. at the Kelley School of Business Graduate and Executive Education Center on the IU Bloomington campus. Bloomington is one hour south of Indianapolis and within easy driving distance of Chicago, St. Louis, Columbus, Nashville and other Midwest cities.

Labriola

I am back in Chicago after a red-eye from San Jose this morning where I was attending 360 Flex. It was yet another wonderful conference put on by Tom and John featuring great presentation and fantastically inquisitive attendees. For my part, I ended up doing two back to back sessions on Drag and Drop with AIR and a deep dive into Flex Data Binding.

The AIR session was originally Jeff Tapper's to do, but he selflessly agreed to hang back when a client emergency kept him working during conference hours. I did my best to fill in for him and hopefully the audience gained some tips and tricks when moving between these technologies.

The data binding session is one I have been looking forward to for quite some time. It is another of my 'Flex from the Inside Out' style presentations where I attack a narrow topic and try to bring light to the darkness. It seemed well received and the crowd seemed to very interested, which makes it worth the effort.

The slides for both of these presentations can be found at SlideShare. The download URLs for these presentations are as follows:

• Unraveling the hassle of Drag and Drop in AIR
• Diving in the Data Binding Waters

Please send any feedback you have so I can make these better for the next time around.

Thanks,
Labriola