Another embedded test

Flash: Constructing a Dynamic Function Call

Sometimes I don't know which function needs to be called until runtime. A good example is callback functions. If I have a function that takes the name of a callback function to execute I need a way to dynamically construct that call. Here's how:

theObject["theFunctionName"](param1,param2);

This is equivalent to:

theObject.theFunctionName(param1,param2);

Flash: Programming Asynchronously

Flash has a lot of built in asynchronous events, but there is no clear way to write your own code asynchronously. In Javascript a good way is to use the setTimeout(functionname,0) call to execute a method asynchronously. Unfortunately, Flash does not have setTimeout().

Luckily, a combination of setInterval(), clearInterval() and nested functions can be used to the same end.

In my particular application I am using the Observer design pattern for my event architecture. When an event method is called, it needs to execute asynchronously and then notify all registered observers when it is finished. Here's how I accomplished the asynchronous portion. This particular example echoes the argument back to the screen, asynchronously:

public function myEventFunction(param1:String):Void {
  var interval = setInterval(asynchBlock,0,this);

  /* All code you want to be asynchronous
   * should go in this nested function 
   */
  function asynchBlock(parentObj) {
    // Clear the interval so we never execute
    // this block more than once.
    clearInterval(interval);
        
    // We can reference the original function params directly
    trace(param1);

    // We have to use parentObj to reference any variables
    // declared outside of myEventFunction.
    trace(parentObj.externalVariable);
  }
}

Flash: Casting an Object to an Array

In Flash, it's impossible to cast an Object to an Array because of the existence of the global Array() function. Instead the Array has to be recreated manually:

var myArray:Array = new Array();

for(var i=0;i < myObj.length;i++) {
  myArray[i] = myObj[i];
}

Lessons Learned

We launched the new YP Contracting system on Monday, so that now all counselors and faculty can accept, decline and sign their contracts online--no more paper. I felt that I did a better job than I ever had before on this project, in terms of planning, communication, design and implementation. However, there are still a ton of things that I've learned could be done better next project.

1. Better help and training - Even though the system really works pretty well, people have a bad impression of it if they don't understand how to use it. It gets dismissed pretty quickly as another bad program if they don't know what to do. They also start reporting "bugs" that really just turn out to be a new way of doing things, because they haven't been instructed on how to do things the new way.
   
2. Insistence on more testing before release - YP is not used to testing. I asked them to help test the system and showed them how to test, etc. but they really didn't start testing until they had to actually start using the live system. THEN is when they started telling me stuff that had disappeared, didn't work, etc. I would formulate a better test plan including longer testing periods.
   
3. Better requirements lockdown - Dicksy in particular expressed that she wanted to be more involved in the new Counselor Hiring piece, perhaps realizing her lack of involvement on contracting and how that affected her. I would make it more clear in the future to everyone what the program would and (perhaps especially) what it wouldn't do. That way it would be hard for someone to later say that they didn't know that such and such feature was going away or being changed.
4. Don't forget we're creatures of habit - There will always be some initial frustration over having to change from doing things one way to doing another. It's natural, and perhaps inevitable. It's important to just relax and not take anything personally.