Code Slinger: A DP Blog
360|Flex is officially over and my slides are finally available. It was another great conference but I am officially wiped out. Three full days of content and wonderfully geeky discussion have left me looking forward to the weekend.
For any who asked for my slides, they are included below. Thanks so much for the great feedback and being a wonderful audience. I really enjoy doing these deep-dive style talks and so long as 360|Flex keeps inviting me back and all of you keep attending, I promise to try to keep them fresh and interesting.
P.S. If you didn’t get a chance, check out my featured opening over at http://www.weheartdoug.org for Nate’s masterful prank.
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
Parameterized TestingThere 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
Posted At: May 18, 2010 2:05 PM | Posted By: Michael Labriola
Related Categories: Adobe Flex
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.
private var source:Vector.<uint>; source = new Vector.<uint>;
private var vc:VectorListCollection; vc = new VectorListCollection( source );
var sort:Sort = new Sort(); var field:SortField = new SortField( null, false, false, true ); sort.fields = [field]; vc.sort = sort; vc.refresh(); File Available Here 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,
Posted At: December 28, 2009 8:12 PM | Posted By: Michael Labriola
Related Categories: Adobe Flex
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,
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.