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

Flash programming confidential, wednesday

My week att the to-remain-unnamed web production company continues. Today I was asked to help with a website that stopped working when the developer updated it last night. This morning he went to holidays and was completely unavailable, there was panic in the project manager’s eyes, but the problem turned out to be quite easy to fix. However, a closer look revealed some other fascinating, or perhaps horrifying details.

Opening up the .fla I expected the usual mess of symbols with names like tmpVw_4 and code scattered all over. Not this time. This developer had actually understood that it’s quite bad to have code in so many places, the solution? to have everything in the same place, naturally!

The first frame was empty, save for some ActionScript — 2300 lines of it. The main initialization function was a single 500+ line function with a switch containing 34 cases, each case initializing a different view. All over there was code duplication and other fun stuff.

I counted 29 places where text fields were initialized, with about ten properties set in the same way each time (embedFonts, antiAliasType, gridFitType, sharpness, etc.). That’s almost 300 lines that could easily be replaced with a single helper function of about 15. At least the text formats used with these text fields were initialized at the top and used throughout.

Another classic Flash programming idiom found was this (actual code!):

itemChildren_arr[i].childNodes[4].childNodes[3].childNodes[1].childNodes[0].nodeValue

Fair enough, most developers have not heard of XPath, or can’t write a getAllEmentsByTagName implementation to save their lives (it involves recursion, the horror!), but the odd thing is that XPath was used in other places. The third-child-of-the-fourth-grandchild idom is extremely fragile and so hard to debug that I’m amazed that anyone in their right mind would ever use it. Still, most Flash programmers I’ve worked with defend it.

The project communicated with a web service to retrieve all content, and the server side must have used only numbers to identify the different views, because there wasn’t, in the whole 2300 lines of code, any variable names, string literals or even more than one or two comments that identified which view the code related to. In the initialization function, the only clue to which view that was initialized was the number of the case statement, which were not visible in any way on the site or had any relation to the structure. All variables were called things like rub_txt (for “rubrik”, which is Swedish for “header”) and “fld_txt” (for “field” I presume).

To find the view I was to fix I had to sniff the network traffic between the Flash application and the server and look for familiar strings, then looking if there was anything looking lika a view ID in the vicinity and hope that that was the number of the case block I was looking for. In short, another example where the structure was more or less only in the head of the developer.

Let’s see what the end of the week has in store. I’ve heard rumors that there is another project that needs fixing, and with the current trend I’m pretty sure there will be another post in this series.

One Response to “Flash programming confidential, wednesday”

  1. Iconara » Flash programming confidential, resolutions Says:

    [...] staff was away. I reported my findings in a series called Flash programming confidential (monday, wednesday, weekend). This is a summary of the state of the Flash programming trade, and resolutions to what I [...]

Leave a Reply