★ bcdef.org ★

Whether you shun or embrace Macromedia’s V2 component architecture, you’ve undoubtedly hit some headaches trying to tame them. I’ve always felt it was remarkable how complicated it was to reskin them, for example. Other parties, both for profit and not-for-profit, have been offering alternatives for at least five years now, but there’s not really any standout leader. I stand behind Patrick Mineault’s observations on the matter from two months ago.

One of the better alternatives for its emphasis on a lightweight replacement that mimics the V2 API (at a hefty $399 price tag) is the mCom set from Grant Skinner and Metaliq. You would think you’d get decent documentation and support for such a price, but both are abysmal. And after wrestling with the smallest of details, I began to wonder if the true problem was the fact that mCom was attempting to be interchangeable with the built-in V2 components. Its potential is mainly limited by the same weaknesses that hamper what already comes OOTB from Macromedia. Ever try to export classes on another frame besides 1 (so that your preloader actually works) in the same project that you reskin components? Well mCom blows up just as gloriously as V2 does. In fact, I’d say that since mCom requires relies upon the Flash IDE and attachMovie() to instantiate from Actionscript, it’s sadly just a glorified patch-up to a foundation that needs to be rebuilt.

It’s really not fair to be so critical, building components is not easy territory. I’ve been checking in once in a while to see what the OSFlash community has put together. We’ve been hearing about ActionStep for a while; it’s been in development since April. Much of its approach is beyond my expertise, but in summary, it’s an ActionScript 2.0 implementation of the OpenStep AppKit, using a Responder architecture.

From the frontpage:

There are many component frameworks that have been written over the years, but the framework that I am most fond of is the NextStep/OpenStep/GNUStep/Cocoa “Application Kit”. Because the AppKit has been implemented many times and is well documented (in books, online, etc) there is a strong base of code and designs to work from.

This is exciting because it has the potential to be just the foundational component replacement the Flash community needs.

A few days ago, the team developing ActionStep released an “Alpha 1″ release. I took a gander, and it’s still a little early to get a solid grasp of the project; documentation is pretty sparse yet. Some elements are more polished than others, and if you haven’t yet explored MTASC you’ll have a second learning curve to juggle, but the exploration piqued my curiosity. They’ve certainly completed a number of key milestones already.

You can read more about it, or snatch the alpha, right off the front page. A beta release is scheduled for January 31st, and the 1.0 is slated for (should we take a hint?) February 31st.

Note: Another component set from David Karam is also looking pretty sharp. It’s looking for help to finish off development. *nudge nudge*

It may be true that I’m the last Flash developer to learn of this trick, but just in case: here’s a shorthand fix to prevent “undefined” from showing up in text fields when loading in data that may or may not be null – for instance, while developing Flappr, I would sometimes see “undefined” on the user’s profile strip for the location they may or may not have entered into their Flickr account.

Although it can aid in debugging, it’s more often a nuisance, particularly for professional work – when geekspeak like “undefined” inappropriately shows up, it’s surprising how uncomfortable a client can be with the quality of your work. Also, if I had incorporated code from the days of publishing for Flash Player 6 / Actionscript 1.0, where previously no text had shown up, the more explicit Player 7 or higher would insert “undefined” into the text field.

Since I frequently work with external data sources, I had to protect against this so often that I had created a nullCheck function along the lines of:

class org.bcdef.util.StringTools {

  private function StringTools() {}  // singleton class

  public static function nullCheck(txt:String):String {    
    if(txt==undefined) {
      return " ";
    }
    else if(txt.indexOf("undefined")!=-1) {
      return " ";
    }
    else if(txt.indexOf("NaN")!=-1) {
      return " ";
    }
    else return txt;
  }  
}

I would then usually wrap a nullcheck around every text assignment that came from an external data source, a la myTextField.text = StringTools.nullCheck(stringFromXMLFeed). This worked fine, but as I began to make more and more robust applications, the tedium of this structure, combined with the processing drag (in one case over 100 tf’s were updating every four seconds) of sending through this 3 segment loop made me wonder if there was a better way.

Well naturally, there is: just assign your text within a conditional against a string of a one character space. If the variable is null, it will print the space instead.

var someText:String = "Huzzah!";
var emptyText:String = "";
var nullText:String;

myTextField1.text = (someText || " "); 
myTextField2.text = (emptyText || " "); 
myTextField3.text = (nullText || " "); 

This cleans up my code significantly, and avoids the need for importing or pasting in an extraneous nullCheck function into each class that I use. The downside is that this code isn’t as bulletproof as my nullCheck() function; if someText had passed through some previous logic, it’s possible that it had already been assigned the string: “undefined”, in which case it would not be null and hence would still print to the screen. This means that relying on this check requires using it whenever assigning a string, not only when it is used to set a text field.

Is one way better than the other? Does anyone else know of a trimmer / more reliable method?

It’s been a long time coming, through spurts and starts… but looking at it this afternoon, I just couldn’t see any major reason why not to offiicially declare my pet project version 1.0. A lot of late night endeavors attempting to merge Flash amicably with Flickr have finally brought about the point where I’m ready to let someone else kick the tires for a while. So have at it while it’s piping hot! You can read about it on the project page or, for the interminably impatient, try it here.

And while I was at it I figured it was long overdue for me to kick start the blog all over again. So here you have this as well. Whee. I’ll tidy it up a bit later.