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 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!

9 thoughts on “Managing the development of a Flash RIA: better practices

  1. Fred van Amstel August 11, 2004 / 1:50 pm

    Great article, Jon! I never worked in a RIA, but when I get some to do, I´ll comeback here.
    You said that frames doesn´t fit well for programmers and I confirm it for my programmers friends once said. But isn´t it adequate for containing the screens of the app? And what do you think about the new metaphor of Flash 2004, the “screens”?

  2. jon August 11, 2004 / 5:02 pm

    Thanks for your kind words!
    No, in fact we tried to use frames exactly that way the first iteration: It gets very confusing very quickly. The bigger your app gets, the bigger that 2-dimensional space (layers * frames) gets, until new developers can’t find anything! Also, the underlying Actionscript becomes very unwieldy using that approach (code typically hooks to design elements via subclassing MovieClips, _not_ linking to frames: using frames as the “screen” makes an “impedence mismatch”.
    I’ve heard from people I respect (including both hard-core Flash consultants and Macromedia VPs) that the “screens” are a joke, a half-baked first attempt to provide an RIA IDE. I’ve actually experimented with them and wrote a tutorial on them as one of my first blog posts. There were enough “gotchas” to confirm that they are not fully cooked (example: you have to explicitly write code to hide the screen that you’re leaving when you go to the next screen). Most people seem to agree: I haven’t seen many tutorials or books that mention using that feature.

  3. Owas August 12, 2004 / 11:05 am

    Nice blog Jon!
    I have a couple of observations to this. I agree to an extent design patterns dont work as well as they work in other languages but I’ve been using MVC for my applications for quite some time and they work fine. I feel most of the projects which run into rough weather are product of bad initial planning on part of development team. I have seen many good coders who commit mistake of creating one big class for the whole applications and thus making the whole project very water tight. Key is to break your application into various parts.
    Also on other issue of skinning and customizing graphics by developer, I personally try and have an interface for designers made by developers which they can use to customize UI

  4. jon August 12, 2004 / 11:13 am

    MVC is great. Design patterns are great. How’d you get the impression I think they don’t work as well? To the contrary, I think they may be _more_ useful than normal in the context of flash, since they force a certain discipline onto the project.
    Tell me more about the patterns/approaches you use for skinning interfaces … I’m intrigued.

  5. Owas August 12, 2004 / 9:22 pm

    First apologes ….. I kinda misread that “design approaches dont work well with AS”.
    The basic approach I use for creating themes or skinning is by developing a UI for designers. Also if you are using MVC, your View will be a separate class and Ideally should have all the methods of skinning in it.
    BTW I have posted some source file on my blog showing some very basic skinning examples.

  6. AJ August 14, 2004 / 12:47 am

    Fantastic article Jon!
    It more or less covers all the flaws developers end up with, developing RIA.
    I personally like points 1, 3 and 5. These are absolutely cruicial in a sceanrio where a larger team is working on a project.

  7. jon August 14, 2004 / 10:00 am

    I can’t believe I’ve hit “all the flaws” developers end up with. That’s a lot of flaws. ;->
    Anyone out there have other “better practices” of about the same scope (i.e. not tips and tricks about specific API issues) that they’d like to share?

  8. Pranav August 18, 2004 / 11:55 am

    hmm, Let me second you jon. You are going in the right direction, its really tough to get a decent Flash coder in Delhi region, in my last company I had enough experience of that.
    Anyways Currently I am working for this gigantic ERP app, coded in Flash ( close to 200,000 lines of pure AS2 ) with a team of 30 flash programmers and guess what 27 flash programmers were Java developers, We gave them a 2-3 weeks training and they were on. Though later the biggest challenge is to keep there interest alive in flash, after all they are coming from robust world of Java . This buggy player and full of work around coding normally doesn

  9. jon August 18, 2004 / 1:19 pm

    By a “centralized reporting system”, you mean a bug tracking system? Yeah, we’re doing that. I like your idea of a “A-team” of flash troubleshooters, and will look into using that.
    The idea of an engine is good as well, though it might be overkill for what I’m doing right now. The fact that you could take that engine with you to your next project is quite appealing. In the Flash world people seem used to writing everything from scratch every time, which prevents forward progress.
    I think in the next few years we will see the growth of “framework” APIs similar to the frameworks popular in the java world (struts, springframework, etc). Hopefully open source, though if MM released something similar it would be OK as well.

Comments are closed.