/customers/iconara.net/iconara.net/httpd.www/blog/wp-content/plugins/wp-super-cache/wp-cache-phase1.php Iconara » Flash programming confidential, weekend

Flash programming confidential, weekend

I write this, the friday’s entry to the series, on monday morning because the weekend has been all work. It began on thursday when a customer decided that a campaign site that had been ok’ed before now suddenly was not ok. It had to have the client’s header and footer, something the ok’ed design documents didn’t have, and definitely not something the ok’ed Flash site had. But the clients word is law, so we had no choice.

Before I continue, I should clarify the background of the Flash programming confidential series: I’m a freelance developer and for two weeks I’m at a web production company as a fix-all while the staff is on a “business trip” (quotation marks theirs). I do what needs to be done to make things run smoothly, fixing errors in web sites that have recently been released and such. During the past week I’ve encountered many forms of Flash programming madness, badness and horror, which I’m now sharing with you.

Back to the weekend.

The developer who had put together the campaign site had as little programming expertise as the other Flash programmers at the company, which came as no surprise. What could have been a day’s work ended up as four and a half day, including 16 hours of overtime friday night and saturday. 

The site consisted of one loader .swf per language and one main, language independent, .swf. Once the main .swf was loaded it loaded all it’s content from XML files, but in order to keep size to a minimum it had been decided that the loader would be hard coded for each language. Thus, the loaders contained the expected texts and some graphics, and the completely unexpected: the layout code for the main elements of the site.

Let me say this again so that it is clear: the code that positioned the main elements of the site, was inside the language-specific loaders. If you wanted to change the positioning you had to go inside and change code inside each loader .fla. What madman would ever think of this scheme? It’s bad on so many levels that I almost cried when I realised (it was late and I was tired, which didn’t help). It would have been so simple to avoid the mess it created, but no.

Going throught the code was a nightmare, inconspicuous functions like validateEmail had side effects like submitting a form (but only when it was called the third time if there were three e-mail addresses in the form, the second time if there were two addresses, and so on).

But that’s not all, inside the validateEmail function I found a webservice call. E-mail addresses were apparently validated on the server side. Curious as to what rigorous testing was being done I asked the server side developer about it. He said that he had added the method because the Flash developer didn’t know how else to validate e-mail addresses. All the service did was check it against something like /^[a-zA-Z0-9_-.]+?@[a-zA-Z0-9_-.]+.\w{2,4}$/. Even without regular expressions, that should be a no-brainer.

The rest of the code was almost equally bad. The control of flow went in and out everywhere, and there were side effects beyond my imagination. Most of the code was located in two large blocks (but not external .as files, that would have been to easy), but there were of course triggers for things scattered a little bit of everywhere on the time line of symbols with non-informative names.

The main code block (1450 lines) showed serious lack of understanding of basic programming concepts like references and how to write maintainable code. Have a look at these three lines, they are quite representative as there were a couple of hundred of them:

eval("pick_mc.phoneTxtLink" + i).txt.htmlText = _xml.firstChild.childNodes[2].childNodes[4].childNodes[0].nodeValue;
eval("pick_mc.phoneTxtLink" + i).url = _xml.firstChild.childNodes[2].childNodes[this.id].childNodes[1].childNodes[0].nodeValue;
eval("pick_mc.phoneTxtLink" + i).onRelease = ...

How many serious issues can you find in these three lines? I don’t know where to begin. Just look at the XML “parsing”, what happens if you move even one node in the document? Why not use a reference, instead of duplicating the eval call for each line? Why use eval at all?

The irony of it all is that on the desk of the developer who wrote this mess lies a copy of Essential ActionScript 2.0, one of the most pedagogical books on programming I’ve ever read.

I’ve now finished my first week at this company, and I’m seriously worried about how they handle things. They specialise in CMS-driven websites, mainly in Flash, but their Flash developers are so clueless that they can’t even write the code to validate an e-mail address (see above). I can’t see how the management can be so blind and let this go on. It wouldn’t be much hassle to send them on some programming classes, any improvement would save loads in the end. Their server side developers seem to be as good as any, though.

Two other things I learned in the wee hours of this weekend: The “Save as” command in Flash CS3 is seriously broken. If I, on my Mac, save as Flash 8, the .fla can’t be opened by Flash 8 on Windows (it says something about “address violation” or something similar). Flash 8 on a Mac can open it though. The other thing is that ExternalInterface doesn’t work in IE7 when the Flash movie is embedded inside a form element (a quick google confirmed this, it’s apparently a known bug).

2 Responses to “Flash programming confidential, weekend”

  1. TomH Says:

    This all sounds so familiar from my days of hacking around with Flash. Then I picked up a copy of “Object-Orientated ActionScript for Flash 8″ (http://www.friendsofed.com/book.html?isbn=1590596196) and saw the light.

    At the moment it must feel like you’ve been teleported to the dark ages!

  2. Theo Says:

    Good to hear!

    Yes, it’s been the dark ages for almost two weeks now. But tomorrow I’m free again. It’s going to feel good to work on my own, with my own code, again.

Leave a Reply