agitcraft

This isn’t technically a bug, but it is a strange quirk in ActionScript 3. I’ve discussed the Capabilities class before. I still like it. I still think it’s very useful.

I have one problem.

The Capabilities class has no public string constants. I was looking for an article or document explaining why you should use string constants, but I couldn’t find one so I suppose I’ll write my own later.

Anyway, most every other class that passes string values around uses constants to store those values. The Capabilities class does not. This results in code like the following:

if (pt == "ActiveX" || pt == "PlugIn") {
  //...
} else if (pt == "External" || pt == "StandAlone") {
  //...
}

Remember, it should be “PlugIn,” not “Plugin,” “plugin,” or “plugIn.” If you use any of the latter three your SWF will publish just fine without any compile errors to let you know something is amiss. It won’t be until your conditional fails to select either option that you start scratching your head wondering what went wrong.

I propose that adobe add a PlayerType class to the flash.system package. The class would simply contain four static values:

public static const ACTIVEX:String = “ActiveX”;

public static const PLUGIN:String = “PlugIn”;

public static const EXTERNAL:String = “External”;

public static const STANDALONE:String = “StandAlone”;

The benefit of having such a class is that as long as you used those values, if you committed a typo or some other minor error the compiler would let you know. Wouldn’t that be nice? I’ve submitted this as an issue in the Flash Player Bug management system. Go vote on it.

Until you refer to the 3D properties of a DisplayObject, the matrix3D property of its transform object will return null.

The same is true of the DisplayObject’s transform property itself.

This seems, on the one hand to be silly, and on the other hand to be a source of potential bugs and confusion during development. Generally speaking I expect things like this to have a default value other than null or undefined.

Perhaps it’s meant to control memory usage? A noble cause, undoubtedly, but perhaps misguided in its application. You have to assume that people are going to misuse classes, but when they do hopefully the class either fails gracefully or adapts.

In the case of this issue, I would resolve it by rewriting the accessors for both properties like so:

public function get transform():Transform {
     if (transform == null)
          return new Transform();
     return transform;
}

This way, the transform property isn’t instantiated until it’s needed, but at the same time when it’s requested there’s something there. Isn’t that nice?

Earlier today I posted about a strange bug I was encountering while trying to parse an RSS feed of my foursquare check-ins. I posted a complaint about the issue and received a prompt reply:

bauserdotcom replied 44 minutes ago

The dates in the RSS feed aren’t wrong, technically. They’re just not formatted according to best practices.

Foursquare’s RSS feed is using 2-digit numbers for years (which is valid, but not recommended, according to the RSS 2.0 Specification). How the RSS-reading agent interprets a 2-digit year is up to the agent. Whatever software you’re using decided to interpret it as 1910, which an interesting choice, since RSS didn’t exist in 1910.

So what we have is a case of two legal-but-unwise programming approaches creating a mess. Hard to say who’s most wrong, you know?

Fair enough. This is all well and good, and if I were simply reading the items one by one I would be quite able to understand that a year of “10″ actually means 2010. The problem rears its ugly head when I try to parse these dates in Flash. Consider this selection from the constructor for Flash’s built in Date class:

yearOrTimevalue:Object — If other parameters are specified, this number represents a year (such as 1965); otherwise, it represents a time value. If the number represents a year, a value of 0 to 99 indicates 1900 through 1999; otherwise all four digits of the year must be specified. If the number represents a time value (no other parameters are specified), it is the number of milliseconds before or after 0:00:00 GMT January 1, 1970; a negative values represents a time before 0:00:00 GMT January 1, 1970, and a positive value represents a time after.

As you can see, two digit dates in the constructor for Flash’s date class are interpreted as years since 1900, not 2000. The only fix available to me is to inspect every item of the feed I’m loading (since these are being aggregated into one giant list of items) to see if the publication date is sometime in the 20th century. Great.

Of course, I’m not all sour grapes. I just posted an “idea” on Foursquare’s “Get Satisfaction” page.