First off, I need to thank Ricky Bacon for bringing this to the attention of the Flashcoders list. Click on the image below to see the full-size screen shot, and you’ll see what happens at this particular AOL page when you visit it using the Debug version of the Flash Player. Make sure to read the error message carefully.

Pretty funny, no? In any case, this should serve as a lesson to all of us: Write useful and professional error messages! It was always a good idea anyway, but now that anyone with the Debug version of the player can see what you wrote, it’s an even better idea. Otherwise, one day the joke may be on you…

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

There’s a room in my house that has a pair of old-fashioned wingback chairs set in front of a large Scandinavian bookshelf unit. I like the way this arrangement looks; the graceful curves of the Queen Anne style chairs contrast nicely with the hard, sleek lines of the bookcase. And it would seem that I’m not alone; lots of people like to juxtapose classic older styles with contemporary ones. In order to do this successfully, of course, the older item often needs a bit of work: hardware replacement, scratches and dings filled in, or perhaps a complete refinishing job. But the result is often more than worth the effort. And this exercise is not only aesthetically pleasing, it helps to minimize waste by putting an old item to use that might otherwise have been destined for the rubbish pile.

We now have a somewhat analogous situation in the Flash development world - especially those of us who have been working with the technology for several years. We all have old Flash assets lying around that are potentially useful, but they don’t have all of the functionality we need, and they can’t be imported into ActionScript 3 projects. So what do we do with them?

One answer is to use the LocalConnection class to enable these antiques to communicate with our current projects. With LocalConnection, any two (or more) SWFs running in the end user’s Flash player can send messages to each other regardless of what version the SWFs are compiled to or which version of ActionScript they use.

Suppose, for example, that you are asked to build an application that has a clickable U.S. map. When the user selects a state, a pie chart displays the relative amounts spent on various types of candy bar in that state. Flex Charting can take care of the pie chart pretty easily, but what about the map? Suppose you have an old interactive map built in Flash 5 laying around, and you want to use that rather than building a new one from scratch. Well, that is precisely what was done here:

This application uses a Flash 5 map of the U.S. loaded into a Flex 2.0 application. Just a few lines of LocalConnection code added to the version 5 FLA were sufficient to enable this perfectly useful old asset to communicate with its ActionScript 3 host. Apart from the developer, the only people who could tell the difference between this application and one built completely from scratch are the people who pay the bill - they could see it in the money they save.

As an aside, you’ll also notice that the Flex project included in this application illustrates a few interesting things in addition to the LocalConnection code:

• The use of a custom renderer component to build a custom legend
• Using a custom color palette with a Flex chart
• Using the interpolate effect to animate a pie chart
• An AS3 helper class to read, manipulate, and generate XML data

You can run the complete application here. When the application opens, right-click on it to view and download the source.

Note: The XML data file used for this application is a work of fiction. Any resemblance to actual sales figures or percentages, living or dead, is entirely coincidental.

Enjoy!

I’ve completed the first iteration of a Flex-on-Rails application, and had a lot of fun doing so. The application is called Index Cards, and it’s designed to be a generic study aid. The metaphor is simple: on one side of the index card, you write the name of a concept that you wish to learn, and on the back you write a definition and/or description of that concept. Of course, you’ll have a separate set of index cards for each subject that you study, and within each subject you will further divide your index cards based on topics or categories. You put all of the cards for each topic or category in a rubber band to keep your cards from becoming disorganized. For example, if the subject you’re studying is elementary statistics, you might have one rubber band to hold cards with descriptive analysis concepts, another rubber band for probability, and so on.

Unfortunately, I haven’t lined up Rails hosting as yet, so I don’t have an online demo to play with. However, you can download the source code here. Please let me know if you have any feedback (criticisms, suggestions, kudos, etc.). Most of the code is still uncommented, so feel free to ping me with any questions as well.

In addition to being my first significant Rails application, this is also my first use of the PureMVC framework. I will admit that this slowed me down much more than expected, as I had some trouble wrapping my mind around PureMVC. However, now that I’m starting to get the hang of it, I think I like it. I will have a better idea of how much I like it when I start adding functionality. I’ll be posting comments here as I build out the app, so stay tuned.

As it stands, the application has the basic required functionality: you can create, update, and delete index cards, and you can flip through the cards to study them. However, I plan to add (at bare minimum) the ability to study only one rubber band at a time. I also hope to add user management and login functionality so that there could be multiple users of the same instance, as well as different ways of studying with the index cards (multiple choice etc.).

Below is a list of resources that were instrumental in getting me to this point.

Rails:
Agile Web Development with Rails (of course) by Dave Thomas, David Heinemeier Hansson, et al
Rolling with Ruby on Rails Revisited by Bill Walton and Curt Hibbs
Integrating Flex 2 and Ruby on Rails by Derek Wischusen

PureMVC:
PureMVC Best Practices by Cliff Hall
Cafe Townsend demo by Michael Ramirez (This is an adaptation of the Cairngorm demo for PureMVC)

After attending my Cairngorm presentation at the 2007 FlexManiacs conference, a co-worker (who happens to be an ardent Rails developer) expressed some concern that Cairngorm seems to be overly complex. He thought that perhaps there was too much abstraction for the sake of abstraction, and mentioned that there seemed to be a lot of small files, some of which perform parallel tasks. I took his concerns to heart, and decided to re-analyze Cairngorm with a more critical eye.

Recently I began learning Ruby and Rails myself, and I have been very impressed with what I’ve seen. So far, Ruby does indeed appear to be an exceedingly attractive language, and Rails is a massive labor-saver. However, I have learned some things that make my co-worker’s concerns about Cairngorm appear to be a little ironic.

When you tell Rails to create a new application, it creates an application directory with no less than 37 subdirectories (using RubyStack, which runs on Ruby 1.8.6 and Rails 2.0). Scattered among these directories are 49 files - all before you write a single line of code. At this stage, the application does absolutely nothing except display an HTML page welcoming you to Rails. This is far more than is required by Cairngorm. In fact, here’s an example of a complete, fully-functional, and non-trivial Cairngorm application that has only 67 files and 21 subdirectories:

At first you may think that I am comparing apples to oranges, and I will readily acknowledge that Rails does some things that Cairngorm doesn’t (most notably, Rails helps you to manage your database tasks). However, Rails and Cairngorm are both MVC-based frameworks for building Web applications, so in principle their reasons for being are really pretty similar.

In fact, the Rails workflow is in some ways similar to the Cairngorm workflow. For example, adding new functionality in either framework often involves creating a few simple files (and perhaps adding a line or two to some existing files) with the result that both frameworks lead to multiple files performing parallel tasks. In either framework, modifying the existing functionality is frequently a matter of making simple changes to several related files (e.g., a Controller file, a Model file, a View file, and a Test file). While jumping from file to file may seem inefficient to the uninitiated, in reality this workflow is great for productivity. For one thing, it’s much easier to place and track a few simple pieces of code located in a few small, intuitively named, and logically organized files than to manage a single complex piece of code in one monolithic file - especially with modern IDEs and text editors, which make it a snap to work with multiple open files simultaneously.

There are other benefits in addition to the productivity boost, of course. In either framework, for example, you can usually modify or even remove an existing piece of functionality without having any impact on the rest of your application, because the change only affects the files that are directly involved.

Anyway, what’s the point of this comparison? The point is simply this: having lots of small, well-named files with very specific functionality organized logically in several directories is not necessarily a bad idea. While at first blush it may seem daunting, in the long run it can help to save a lot of time and promote higher-quality software.

I thought I’d start the new year off right by offering my fellow Flex coders a useful component. It’s a highly configurable, customizable, extensible, and slightly fun login panel for Flex applications:

Click on the screen shot above to see a sample application that uses the login panel. Enter the following to test it:

user name: user@name.com
password: chocolatemacshake

Right-click on the application to view and download the source, or get the zip here.

Besides being a useful component in its own right, it also provides an instructive example of how to write and use a custom component.

Enjoy!

I’ve been using Cairngorm for well over a year now. Why Cairngorm? Well, it’s not because I think that Cairngorm is the only good way to build Flex apps. It may not even be the best way; at least two reviewers have concluded that Cliff Hall’s PureMVC is the best Flex application framework around. In fact, I’ve mentioned some of my own misgivings about the framework in a previous post.

Having said that, I do think Cairngorm is a very effective way to build maintainable applications. Cairngorm apps are very easy to modify - whether you’re adding, changing, or removing functionality. Cairngorm also lends itself to use by multidisciplinary development teams, and is sufficiently intuitive that new team members can to get up to speed fairly quickly.

Let me give you a case in point. I recently had to hand one of my Cairngorm applications over to another developer. He’s a sharp programmer, and has lots of experience with Java and JavaScript (among other things) but he had never even smelled Flex before. He spent a few days reading up about Flex and Cairngorm and looking through my application. At that point, he was able to be productive immediately. Without any coaching from me, he implemented no less than three new pieces of functionality in a very short time - which is testimony to how intuitive Cairngorm is.

Another point to be made is that while the other developer was adding new functionality to the application, I was debugging some existing functionality. The fact that the application was built using Cairngorm made it very easy for us to work concurrently without getting in each other’s way.

And that’s what’s really cool about Cairngorm: for all of its warts, it does make applications very easy to maintain and extend.

But as cool as it is, I’m still not ready to commit to using it exclusively. I’m going to be taking a deeper look at the other frameworks - particularly PureMVC - and see how they compare. Stay tuned.

One of the things experienced developers usually ask when they begin working with Flex is: How do I reuse code? Well, my answer is that there are at least three ways of creating reusable libraries for Flex applications.

The most common (and oldest) is probably Runtime Shared Libraries (RSL). These are groups of ActionScript classes that are compiled into SWCs and loaded into your SWF at runtime. However, unless you use the same RSL for more than one SWF within a single browser session, RSLs inflict a performance hit. There are two reasons for this: 1. The RSL of necessity includes all of the Flex framework code required to make its classes compile. Most of this Flex framework code also exists in your SWF. As a result, you’re loading the same code twice. 2. When you load a SWC, you load the entire SWC, whether you actually use all of the classes it contains or not.

(more…)

Jason has posted a very useful list of Flex Builder tips & tricks. He doesn’t just list them, however; he takes the trouble to show us how to implement them, even including screen shots. Check them out.