Managing the development of a Flash RIA: better practices

I'm currently involved in the development of an ambitious RIA that is coded in Flash. I've brought new engineers into the project at various stages. I've found that I can get an experienced Java engineer productive developing client-side Actionscript in about 2 weeks, if the project is structured a particular way. Since real Flash uber-coders are as rare as hen's teeth, this is a serious advantage.

What follows are the "better practices" that we have evolved over time (I have no proof they are "best", but they seem to work for us). Together, these practices make the flash world more accessible to "vanilla" developers, and minimize some of the problems that crop up in a large-scale Flash development effort.

1)One frame to rule them all (i.e. no Timelines)
This is really key. Timelines are essentially spaghetti code, and are totally incompatible with any rational development process. The more complex the project, the more convoluted the timeline (as it grows in 2 dimensions, increasing layers and frames) until it collapses under it's own weight.

Timelines make it difficult or impossible to locate resources for developers that are new to the project. The only time that timelines are used in our project is when something is legitimately an animation (by which I mean a short cartoon that runs in linear fashion from beginning to end).

I started a conversation on this topic on the flashcoders mailing list since I found the "best practice" documentation to be ambiguous ( Chattyfig wiki advocates using frames as states,
while devx.com argues against the practice). I was impressed by the unanimity of the response. Not a single member of the flashcoder list advocated for using frames in the context of application development.

2)Use real development processes:
This means automated, daily, command-line driven builds, bugtracking software, and a source-control system. Most flash development seems to be done using a very casual process of "generate the swf from the IDE and upload it to the server". That's fine for one-man projects, but if you're working with a team you need to be checking files into a source control system (like subversion or cvs) so that others can work on them. And if you're checking both fla files and swf files into source control, you're setting yourself up for a world of hurt. Someday (maybe not today and maybe not tomorrow, but soon!), you'll end up with a skew between the fla and the swf file, and the system will behave differently on different developers machines, and you'll spend hours troubleshooting it before you figure out what the problem was.

The solution for this is to not check in your compiled swf files. Do what every other flavor of developer does and check in your source (fla) files, and let the system build the swf files at compile time. If there's only one version of the file in the source control system, there's no potential for skew.

We use the ant task from the good folks at bits and pixels.We think it's pretty keen. If you use ant for doing your builds, you might want to do the same. If you use make instead of ant, you can probably hack something together yourself by making a direct call to the command line.

Keep track of current bugs and requested feature using software like mantis (which we use), or commercial software like fogbugz

3) Don't castrate your designers
Software engineers, once they get a taste for the MovieClip object and Robert Penner's easing equasions, naturally want to build a UI framework from the group up, using the Drawing API. The advantage: an empty fla file! No fla file contention! Everything is pure actionscript code! Sounds great, right? The problem with that approach is the following: to the extent the UI appearance is specified in code, it is inaccessible to designers. Programmers won't think that's a problem. But programmers don't have an eye for color and form, and your UI is going to end up looking butt-ugly if you take this approach. In my experience, anytime you embed the look and feel in code, you cut yourself off from using professional visual communicators to make your software better. And someone who hasn't done that will make a prettier product than you, and steal all your customers.

A "middle path" is the better approach: Build up screens, screen sections, and widgets as MovieClips using the IDE, and link them to actionscript classes that add logic and behaviour.

4) Use the patterns God gave you
Model-View-Controller, Publish-Subscribe, Singletons, and Command objects are just as useful in the actionscript world as they are in the java world. Just do it. 'Nuff said.

5)Code functionality before appearance
Flash has origins as a design tool, and there can be a real tendency to geek out over visual look and feel. If you're talking about the mechanics of the UI (dragging and dropping, panels moving around) then there's a lot of value in putting in the up-front effort to make sure that you can in fact do what the spec calls for. But if you're simply talking about the appearance, it's more appropriate for the later stages of a project. One of the primary management problems with flash projects is "Fla File Contention": if your designer is working on a fla file, it means your developer isn't. Get a functioning UI structure together as a placeholder first, so your developers aren't sitting on their hands waiting for a fla file to test against!

6)Don't allow more than 1 line of Actionscript code in your FLA file
This is pretty obvious, but I'm listing it anyway. The more logic is externalized into text files with a proper package structure, the easier development and maintenance will be. Code that's embedded in a FLA file is simply not findable or maintainable. I've harped on this issue before, so read earlier posts if you're looking for a full-blown rant on this topic! Suffice it to say: being a hard-ass on this topic will pay big dividends over time.

7)Don't build what you can buy, borrow, or steal
Software development is such a pain in the ass that the only way you can get anywhere is by standing on the shoulders of the developers who came before you. A former boss of mine once told me "one point for doing it, two points for stealing it". Code that's already been tested is bound to be more reliable than whatever you've hacked together last night.

I'm obviously talking about components here, but more importantly, I'm talking about code libraries. For example, you shouldn't bother writing your own data structure classes: use the ASLib library.

This is just an initial list ... that's why I've called them "better practices" rather than "best practices". Feel free to continue the discussion in the space below!

Subscribe to or Bookmark this site

Add to del.icio.us
Digg this
Post to Furl
Add to reddit
Add to myYahoo!