Archive for the ‘Architecture’ Category

IDisplayObject? – Getting around the lack of an interface for the DisplayObject in Flash

Sunday, March 14th, 2010

Interfaces are amazing things. When I was young and green, I didn’t understand their purpose, but after working with them for a while, I will defend their use to the end. I try to create lots of interfaces early on in my projects and I find that by keeping things flexible, it saves more time despite the extra typing, pardon the double entendre.

But this is not an article about why interfaces are so great. No, this is an article about the mysterious gap in the Flash Player API with regards to an interface for DisplayObjects. If you have a class typed as something like IView, there’s no way to enure that IView can be a parameter of display list functions like addChild().

(more…)

MVC cheat sheet

Wednesday, March 18th, 2009

Sometimes I forget the details of whether my Model should know about my Controller and that sort of thing. I found this little MVC cheat sheet on the internet that got me straightened out in a jiffy with step-by-step instructions. The page is actually the lecture notes from one of Colin Moock’s presentations circa the Essential AS 2.0 days but it’s still very useful. Those of you struggling with the lingo, replace Observer with EventDispatcher and ignore the junk about attachMovie. God, how did we ever write AS2!?

Q&A – is, as, and type conversion

Tuesday, January 27th, 2009

A question from a reader gave me an excuse to write a huge rant about type conversions:

I’m doing a little exercise in a book that makes a textfield in which each letter can only be entered once. Not very useful, more of a teaching thing really. However there’s a bit of code that says:

var tf:TextField = event.target as TextField;

I don’t understand this at all! What the hell is event.target as TextField? Anyway here’s the full code for context’s sake:

package com.FoundationAS3.ch6 {

	import flash.display.Sprite;
	import flash.text.TextField;
	import flash.text.TextFieldType;
	import flash.events.TextEvent;

	public class PreventDefaultTest extends Sprite {

		public function PreventDefaultTest() {
			var tf:TextField = new TextField();
			addChild(tf);

			tf.width = stage.stageWidth;
			tf.height = stage.stageHeight;
			tf.type = TextFieldType.INPUT;
			tf.wordWrap = true;

			tf.addEventListener(TextEvent.TEXT_INPUT, onTextFieldTextInput);
		}

		private function onTextFieldTextInput(event:TextEvent):void {
			var tf:TextField = event.target as TextField;
			if (tf.text.indexOf(event.text) > -1) {
				event.preventDefault();
			}
		}
	}
}

Thanks,
-Neal

My response after the jump.
(more…)

Tip: Adding version checking to your external code library

Friday, October 24th, 2008

Since version 1.0 of a code library that I’m sure you’re tired of me talking about came out, I have been making steady updates, some of which break legacy code. I was also having trouble keeping track of which version of the library a particular demo was written for. In order to make sure that the new code library doesn’t cause unpredictable results for the old implementations I added a version check to the main class.

This version check is very simple. It checks a version number in the client code against a version number of the library (or external classes) when the main class of the library is initialized. It is also completely optional (so average users don’t need to mark up their code with version numbers).

Here’s an example:

Say you normally initialize your library using:

MyLibrary.initialize();

Which calls the initialize method:

public static function initialize():void {
   // initialize library here
}

If the external code changes unexpectedly (say through an SVN update) this could cause problems that are difficult to trace. The solution is to modify the initializer to match the client code version with the initializer version.

public static const VERSION:String = "1.6";
public static function initialize(versionCheck:String = VERSION):void {
   if (versionCheck != VERSION) {
       throw new Error ("The version check failed! This library is version " + VERSION + ". Update your code or GTFO!");
   }
   // initialize library here
}

And when you run the initializer, use the version number you’re expecting.

MyLibrary.initialize("1.6");

Some things to notice with this approach:

  • I used a string instead of a number for the version number so that it would allow for sub-sub version numbers and other markers, e.g. “1.6.24 beta r545″
  • Because there is a default value for versionCheck in the initializer, providing a version number is optional. Using MyLibrary.initialize() will still work and throw no errors.
  • Unfortunately, there is not much you can do if the version numbers don’t match except to warn the client that the external code has changed. Still, I’ve found this to be very useful.

The code for my initializer in its entirety after the jump…
(more…)

See Mims present KitchenSync at Singularity <head> web conference!

Thursday, September 11th, 2008

I’m honored to announce that I will be presenting at the <head> web conference (formerly called Singularity) this October 24-26th!  I’ll be talking about the basics of KitchenSync and what makes it so special. I’m very excited, not only to be a speaker (it will be my first time to speak at a conference), but also to be an attendee. This is the first(?) ever web conference to be presented exclusively online… so I expect you to be there!

<head> web conference: October 24-26, 2008

+
KitchenSync