In the grand scheme of things, this may not seem like a big question. However, as a developer who likes to reference the API documentation frequently, it seems significant. The question is this: Why does the Flex 3 Help feature bury the API documentation when the Flex 2 Help feature made it so readily available?

Here is what I mean. In Flex Builder 2, if I typed “Canvas” in the search field, the first entry in the list was mx.containers.Canvas - Perfect! Exactly what I wanted!

However, if I type “Canvas” in the Flex Builder 3 Help search field, mx.containers.Canvas is way down in the list. It’s number 25 to be precise.

What is even more puzzling is that if I type in “mx.containers.Canvas” the first item that comes up in the list is mx.containers.utiltyClasses.IConstraintLayout. Why does this happen? What cosmic forces are at play here? You may ask, “Where is mx.containers.Canvas in this scenario?” Well, I will tell you: It is number 10 on the list.

While this question may not be up there with “What is the meaning of life?” it is nonetheless a nagging question in my little mind. Perhaps the answer lay somewhere out there in the vastness of the blogosphere, but as yet I am still in search of it. But the pursuit of truth is a grand adventure, and I will not tire of it!

One of the great advantages that Flash (and by extension Flex) has over Ajax is that you don’t have to worry about browser idiosyncrasies or versions: If your application heavily depends on JavaScript and/or CSS, you could find major issues whenever a new browser version comes out. By contrast, Flash 4 movies that I built 8 years ago still run in the Flash 9 player without issue.

However, that is no longer true for all developers or all applications. There is a significant difference in the way that the Flash 9 player handles swf’s that are loaded in at runtime. Grant Skinner details it thoroughly in this excellent blog post, but to put it succinctly: When you attempt to unload a dynamically loaded swf, the Flash player probably won’t release it from memory.

(more…)

I have written favorably about both Cairngorm and PureMVC, and this has led a number of people to ask which framework I prefer. Rather than make a blanket statement that one framework is better than the other, it seems more profitable to take a few moments to discuss some of the strengths and weaknesses of each.

Let’s start by emphasizing that the two frameworks share a number of strengths. Both of them provide conventions that, once learned, enable you to build complex applications faster. Both of them lend themselves (in varying degrees) to team development. Both of them promote some level of code reuse. Both of them help you make applications that are easy to maintain and extend. Both of them will enable you to build applications that any experienced Object-Oriented developer will be able to get up to speed on very quickly. Both of them give you complete control over event flows. (When using native Flex events, you need to be aware of bubbling, and whether there is any native Flex code that is also listening for the event you’re dispatching, but each of these frameworks addresses this issue - PureMVC implements a publish/subscribe system with its notifications, and Cairngorm uses CairngormEvent/CairngormEventDispatcher.)

Having looked at what the two frameworks have in common, let’s now take a look at what makes them different. Since we’re talking about Flex frameworks, I thought it would be fun to put the comparison matrix in an AdvancedDataGrid component:

You can open and interact with the matrix here. (Building it wasn’t as much fun as it should have been, but I’ll address that in a future post.)

I’m sure there’s much more that could be said, and I hope that you’ll add your thoughts to this discussion. If you don’t want to post your comments/questions here in the blog, feel free to contact me directly.