My third pilgrimage to Toronto to attend FITC has come and gone. Knowing the routine of the conference made this the best one yet for me. I finished off my deck of old business cards from last year and filled my wallet with a stack of cards from others.

Here are few notes and links:

• For me, the conference kicked off with Alec Cove’s Beautiful Algorithms: Design from Nature and Mathematics, which fell in the thematic vein of sessions I’ve seen from Keith Peters and Grant Skinner, which described beautiful algorithms inspired by or mimicking nature.
• The Adobe keynote on day one was a tad disappointing as it was filled with what was (to me and those I talked to) old news. I did pick up one link from it when Justin Everett-Church demoed an interesting augmented reality piece by Goodby, Silverstein & Partners for GE—a piece which later won at the FITC award show. See it here (use FireFox, I had issues in Safari). A great interactive piece, though for a site promoting more environmentally friendly energy practices, the requirement to print out a piece of paper for the sole purpose of interacting with the site seemed disappointingly off message.
• Another Adobe session covering Adobe Flash Catalyst was an interesting introduction to this product, which I’m sure I’ve not seen the last of. Some features, such as the four pre-defined states of a button and existence of a timeline (though time, not frame, based thankfully) were reminiscent of the Flash IDE.
• Check out SourceBinder, a node-based programming environment. Build programs visually by linking nodes of functionality together. Also, VizualPV3D, a GUI interface for laying out PaperVision3D scenes.
• Grant Skinner’s Things Every Flash Developer Should Know was one of my favorite sessions of the conference. Well prepared and refined, as I’ve come to expect from Grant’s presentations. Check it out online here.
• There were a number of frameworks shown this year, two I hadn’t previously heard of:
  • Gaia Flash Framework, for quickly building mini-sites (showcase-style sites was my impression)
  • Moccasin – “Flex framework for visual object-based editor applications.”

  Additionally, there was a session on PureMVC, which was to be presented by its inventor, Cliff Hall, but was instead covered by someone else whose name I failed to jot down.

• The final general session was an engaging presentation by Jared Ficklin of Frog Design, who taught much about sound and sound visualization through his hour talk/flame-and-smoke-machine-laden-sine-wave-surfin-act. A very fun session . Within his presentation, Jared showcased the work of the talented Annika Hamann at Das Plankton, creator of some remarkable sound visualization work housed at foulowl.com.

The Singleton design pattern is a development approach that ensures only a single instance of a particular class is available in a system. Imagine building the game of chess, you would only want there to be one instance of the board floating around—say an instance of a class called ChessBoard. The Singleton pattern ensures that there will only ever be one ChessBoard object available in your game.

Often the implementation of a Singleton looks something like this:

function Singleton()
{
}
 
Singleton.getInstance = function( )
{
	if (Singleton.instance == undefined) Singleton.instance = new Singleton();
	return Singleton.instance;
}

However, this is a port to JavaScript from other languages and it doesn’t offer a very robust implementation of the Singleton. For example, this design relies on calling Singleton.getInstance() to retrieve the single instance. However, nothing prevents calling…

var instance1 = new Singleton();
var instance2 = new Singleton();
alert( instance1 == instance2 ); // outputs false because these are two object instances

…to create two instances, defeating the pattern. A better approach is to encapsulate the Singleton constructor function in a variable and return a reference to the function rather than the instance, and then provide access to the instance via a getInstance method as above.

var Singleton = new function Singleton() 
{
	var instance = this;
	Singleton.getInstance = function()
	{
		return instance;
	}
}

In this case, the code shown earlier does not break the pattern:

var instance1 = new Singleton();
var instance2 = new Singleton();
alert( instance1 == instance2 ); // outputs true because these refer to the same constructor function

However, this just prevents circumvention of the pattern, the same object instance has not yet been retrieved. To do this the static getInstance() method is called on the constructor reference variable.

var instance1 = Singleton.getInstance();
var instance2 = Singleton.getInstance();
alert( instance1 == instance2 ); // outputs true because these refer to the same object instance

Additionally, a toString method, as well as static and instance methods (though both are functionally identically in this case since there’s only one instance available) can be built into the Singleton definition, like so:

var Singleton = new function Singleton() 
{
	var instance = this;
	Singleton.getInstance = function()
	{
		return instance;
	}
	this.toString = function()
	{
		return "[object Singleton]";
	}
 
	this.instanceMethod = function()
	{
		alert( "instance method called!" );		
	}
 
	Singleton.staticMethod = function()
	{
		alert( "static method called!" );
	}
	return Singleton;
}

Try these out:

Singleton.staticMethod();
Singleton.getInstance().instanceMethod();

Since JavaScript is a prototype-based language (not actually having classes), additional functionality can be added through the Singleton’s prototype, as in:

Singleton.prototype.custFunct = function(){ alert( "A custom method" ); } // add instance method
Singleton.getInstance().custFunct(); // call new instance method

Custom JavaScript objects can have instance methods (function that are associated with a particular JavaScript object), but like other Object-Oriented languages, they can also have static methods, that is functions that are associated with the JavaScript class that created an object, as opposed to the object itself. This is useful in cases where a function (a.k.a. a method) will not be different in different object instances. Let’s look at an example…

Suppose you created a class to handle simple arithmetic calculations:

function Calculator()
{
 
}

To begin with, an instance method could be added to this class in one of two ways, either inside the constructor or through the class prototype. In this example, one method called multiply will be created, which returns the product of two values multiplied together. First, implemented in the constructor it looks like:

function Calculator()
{
	this.multiply = function(val1 , val2)
	{
		return (val1*val2);
	}
}

Via the class prototype, which is a more readable solution in my opinion, it would look like:

function Calculator()
{
}
 
Calculator.prototype.multiply = function(val1 , val2)
{
	return (val1*val2);
}

Use of this method would then occur through instances of the Calculator class, like so:

var calc = new Calculator();
alert( calc.multiply(4,3) ); //pop-up alert with product of 4 times 3

However, it shouldn’t really be necessary to create an object to use the multiply method, since the method isn’t dependent on the state of the object for its execution. The method can be moved to the class to clean up this code a bit. First the class definition is created, which looks almost identical to the instance method declaration above, with the exception of the prototype keyword being removed:

function Calculator()
{
}
 
Calculator.multiply = function(val1 , val2)
{
	return (val1*val2);
}

Now the multiply method can be called through the class itself, instead of an instance of the class, like so:

alert( Calculator.multiply(4,3) ); //pop-up alert with product of 4 times 3

JavaScript has a core Object class that contains a toString() method that is called whenever a request is made to convert an object to a string (like related ECMAScript-based ActionScript). This is often done during debugging to check that a variable actually contains a reference to a certain object.

Most likely alert(myObj) or console.log(myObj) would be used, for example:

var myObj = new Object()
alert(myObj); // popup displays [object Object]

The problem is if you create a custom object. In this case it would be ideal to adjust the string representation to reflect the fact that the custom object is different from the core object. By default there is no difference, as the following example demonstrates:

// custom Foo class
function Foo() 
{	
}
 
// new Foo object instance
var f = new Foo();
alert(f);  // popup displays [object Object]

To make this more readable, add a toString() method to the prototype of the object:

function Foo() 
{
}
 
// toString override added to prototype of Foo class
Foo.prototype.toString = function()
{
	return "[object Foo]";
}
 
var f = new Foo();
alert(f);  // popup displays [object Foo]

In this case, because of the presence of the toString() method, which overrides the default, a custom string can be displayed for the object that is more applicable to what it is. Additionally, information about the properties of the object could be included in this method as well, as in:

function Foo() 
{
	this.message = "Hello World!";
}
Foo.prototype.toString = function()
{
	return "[object Foo <" + this.message + ">]";
}
 
var f = new Foo();
alert(f);  // popup displays [object Foo <Hello World!>]