Tag Archives: Flex

Tutorial – Understanding Classes in AS3 Part 4

In this tutorial, you’ll learn about the OOP (Object-Oriented Programming) concept of encapsulation, and how to break encapsulation to get stuff done in a decent amount of time.

Technical Correctness vs. Getting Sh*t Done

i’ve been really happy with the way this series has been received. If you’re like me, you’ve had a hard time understanding the big deal about OOP and Classes – you know it’s something you’ve got to bite the bullet and eventually learn, but it seems like a whole lot of extra typing for nothing.

Cat on keyboard

i’ve been typing for friggin’ HOURS!

But for those of us designers-turned-coders who have embraced Classes (or have been forced into using them for a paid project with a deadline), we’ll tell you that when written the “right” way, Classes can free you from writing a lot of code in your next project.

The trouble comes when you know so much about Classes that you write them too correctly. You can definitely spend too much time making a Class all things to all people and for all purposes. “It’s a MegaClass that can be an animated sprite AND a media player! It’s so VERSATILE!” Meanwhile, you either haven’t launched a game in a year, or your clients are calling every other hour wondering how their project is coming along.

Kids in back seat

Are we there yet? Are we there yet? Are we there yet? Are we there yet?

Let’s Recap

In Understanding Classes Part 1, you freed yourself from the timeline. In Part 2, you took a little detour and learned how to piggyback your library to write custom MovieClip symbols using inheritance. In Part 3, you started looking at how code could be organized in separate files to keep your workspace light, and to better organize your work. Now let’s take a look at the next principle of OOP, encaspulation, to see if we can’t turn our Classes into true drag-and-drop Lego bricks.

OOP Encapsulation

Good encapsulation makes dinosaurs happen. Bad encapsulation makes the dinosaurs go crazy and kill people.

Lego, Ikea furniture, and Your Code

Once again, the three principles of Object-Oriented Programming are inheritance, encapsulation, and polymorphism.

Think of your Classes as Lego bricks. You want to build a Media Player brick that works in your current project, that you can lift out and snap into your next project that requires a Media Player, with no extra work required. That’s the dream, anyway.

Lego

You want your code to be less time-consuming. You know – like Lego.

Up to this point, i’ve recommended that you make all of your Classes’ fields (things that a Class is) and methods (things that a Class does) public. Public variables and methods can be accessed by anyone and anything outside the Class.

Let’s look at some code. We have an ImageGallery Class and our Main Class. Main creates an instance (stamp, version, print) of ImageGallery and draws it to the screen using addChild:

package
{
	import flash.display.MovieClip;
 
	public class ImageGallery extends MovieClip
	{
		public var numberOfImagesICanDisplay:int = 5;
		public function ImageGallery()
		{
			// Display numberOfImagesICanDisplay
		}
	}
}
package
{
	import flash.display.MovieClip;
 
	public class Main extends MovieClip
	{
		public function Main()
		{
			var imageGallery:ImageGallery = new ImageGallery();
			addChild(imageGallery);
		}
	}
}

So far so good. But take a close look at that variable on ImageGallery:

		public var numberOfImagesICanDisplay:int = 5;

That field is declared public. That means that any idiot (including YOU) can access that field and change it. Let’s be a total jackwad and, from Main, change it to eight million:

		imageGallery.numberOfImagesICanDisplay:int = 8000000;

This messes up ImageGallery’s pyjama party to the very limit. How is ImageGallery supposed to display eight million photos? It’s only really set up to handle five images. There HAS to be a way to protect important variables like numberOfImagesICanDisplay from other ass-hat Classes like Main.

Terminator

i recommend sending the Terminator back in time to prevent yourself from messing with that variable.

Stop Looking at My Privates

Fortunately, there is a better and less future-altering way. If we change public to private, only instances (copies, stamps) of the ImageGallery Class can read and write the value of that field. Hooray!

The way i suggested you write your Classes was completely backards. Public is the most permissive access modifier. Private is the least permissive access modifier.

The rule i’ve read is that you should always start out restrictive, declaring everything private, because once you go public it’s kinda hard to go back to private. (If you were an early bloomer in high school who “went public”, you’ll know how difficult it is to regain your privacy)

Slutty schoolgirl

It’s hard to recover from going public

So declare everything – methods and fields/variables – private. If you find that any outside Classes need to access those methods and fields later, you can open them up by making them public.

What Should I Make Public?

Object-oriented programming eggheads are pretty particular about the kinds of things that should be public, and those that should be private. The example i’ve heard is to think of a device like a vending machine. There are certain client-facing input methods that need to be accessible to the outside world:

  • insert coin
  • push snack button
  • push coin return button

And there are certain things the vending machine is going to return to the person using it:

  • snacks
  • coins
  • error messages (“SOLD OUT”, INCORRECT CHANGE”, “NO CANDY FOR YOU, FATTY”, etc)

So the vending machine accepts input and dispenses output. Everything else is private. The user does not need to be able to control the coils that turn to dispense the snacks. The user has no business figuring out how to make change inside the machine, or managing the vending machine’s inventory of goodies. That’s all internal stuff. That’s private.

Vending Machine

None shall know the labyrinthine secrets of the vending machine! MWA HA HA HA HA!!

Dispatching Events

We already know how to write a public method on a Class, and we learned how to pass a parameter through to the Class. Here’s a snippet from an imaginary vending machine Class:

public function insertCoin(coin:Coin):void
{
	// Tally up the value of the coin that has been inserted
	switch (coin.type)
	{
		case "quarter":
			coinValue += 25;
			break;
		case "dime":
			coinValue += 10;
			break;
		case "nickel":
			coinValue += 5;
			break;
		case "penny":
			// No pennies!
			return coin(coin);
			break;
		default:
			break;
	}
}

And here’s an example of how you might call that function from outside the Class:

vendingMachine.insertCoin(new Quarter());

In Actionscript 3, the proper way to signal to the outside world that something important has happened inside a Class is to fire an even dispatcher. Here’s what that looks like in our imaginary vending machine Class:

// This line goes at the top of the Class where you declare your fields:
public static const RETURN_SNACK:String = "returnSnack";
 
// And then later, when you declare your methods:
private function returnSnack():void
{
	dispatchEvent(new Event(RETURN_SNACK));
}

And here’s how you listen for that event in the Main Class (or from whichever Class instantiates [makes a copy of] the vending machine):

// Make sure you import the generic Event stuff near the top of the file:
import flash.Events.event;
 
// This is what your instantiation and listener definition look like:
var vendingMachine:VendingMachine = new VendingMachine();
vendingMachine.addEventListener(VendingMachine.RETURN_SNACK, getASnack);
 
// And elsewhere, you define the method to respond to the event:
private function getASnack(e:Event)
{
	// HOORAY FOAR SNAKZ!!!
}

Anyone see a problem yet? i do. We’re not really able to pass a parameter back to Main through our dispatchEvent command. So how does Main know what kind of snack it received?

There are a few ways around this. We can store a variable on Main called requestedSnack and take it on faith that vendingMachine returns the correct snack. Or, we can create a public variable on VendingMachine to store the returnedSnack, and in Main’s getASnack method, we refer to vendingMachine.returnedSnack. And then there are super egghead ways to do it that remain mysterious to me.

Nerd

i am not well-versed in the Way of the Nerd.

Let’s Get Ready to Fudge It

But here’s the CHEATERPANTS way of doing things. Using dispatchEvent is nice, because we can plop this vending machine down in any other game or app and it WORKS. It’s encapsulated. There are no dependancies. We just need to listen to all of its dispatched events in the new file, and we’re gold. But to be honest, that’s a whole lot more typing, and i’ve got things to do.

The cheaty way to do it is to pass a reference to Main as a parameter to the VendingMachine Class:

// From Main:
var vendingMachine:VendingMachine = new VendingMachine(this);
// From VendingMachine:
public function VendingMachine(main:MovieClip)
{
}
 
// And then later in VendingMachine:
private function dispenseSnack(snack:Snack):void
{
	main.getASnack(snack);
}

Hooray! No need to listen for an event, dispatch an event, declare a constant, or tapdance around the return value problem. The vendingMachine instance knows who its daddy is, and can invoke any of Main’s public methods.

Who's Your Daddy

(um … i can’t actually tell, ’cause his head is cut off)

Of course, the drawback is that this breaks encapsulation. You can no longer pick up your VendingMachine Class and move it to a new project, because VendingMachine is dependant on receiving a reference to a Class that has a public method called getASnack() on it.

Here’s how i go about it: if i’m writing something that i think is pretty handy, and it’s abstract enough that i’ll likely use it in future projects, i might do the extra work to write a nicely encaspulated Class. But if it’s sunny outside and all the other kids are playing in the park, and i can hear their joyous squeals through my opened window, i’ll break encapsulation and throw my Class a reference to the Class that instantiated it.

Splash Pad

Encapsulation be damned – the splash pad’s open!

Don’t Cry, Nerds

Dear Eggheads: i haven’t left you out this time. The concept of passing a variable to the constructor function of a Class was explained perfectly clearly here, i hope, but i know how you like to muck things up with big words and impressive terminology. Your term for this technique is “Dependency Injection”, and if you’d like to read a more serious article on it with fewer pictures and bigger words, check out Joel Hooks’s article AS3 Dependency Injection Demystified.

Here’s a solid step towards demystifying it: STOP CALLING IT DEPENDENCY INJECTION. Sheesh almighty.

To read the rest of the Understanding Classes series, or to see more tutorials, check out our Flash and Actionscript 911 feature.

Tutorial: Understanding Classes in AS3 Part 3

In this tutorial, learn how to identify when a chunk of code should be spun off into its own .as Class file.

Trial by Flash

This series of Understanding Classes tutorials chart my progress through unfamiliar Actionscript 3.0 territory. i am a designer-turned-coder, so everything i understand about code was learned in the School of Hard Knocks … most often while a producer breathed down my neck and i had two weeks to program a game using concepts i didn’t grok.

Sgt. Slaughter

Grokking is Half the Battle

i had already learned to avoid “spaghetti code”, a common newbie Flash developer habit where you stick little bits of code on various MovieClip symbol instances and frames throughout your Flash movie. The next step was to round up all of those little bits of spaghetti code and confine it all to the first frame of my Flash movie.

Baby w/ spaghetti

Don’t spaghetti code. Think of the children.

The next leg of the journey into Actionscript 3.0 was to escape the first frame, and to move all of that first-frame code into its own seprate .as Class file. That’s where Understanding Classes began. It seemed like a pointless step – whether the code was in its own frame or in its own Class file seemed like picky Egghead semantics.

The fuzzy picture came more clearly into focus with the next Understanding Classes tutorial, where we learned to write a custom Class to represent symbols in the Flash library. We used the less-than-helpful example of a Dog Class to explain how to pull this off.

Retarded Dog

Thanks for nothing, DOG.

But the time for theory is over. If we’re going to finally learn how to take full advantage of Object Oriented Programming, we need to look at some real-world examples. In this tutorial, we’ll pick through that glob of code in our Main.as file and find places where it makes sense to group chunks of functionality and split them off into their own Class files.

It’s Apparent You’re A Parent

In order to understand when and where to create new Classes, you almost have to think like a parent. All of the methods (things a Class can do) and properties (things a Class is) are your children. As your children grow older, you want them to learn how to take care of themselves. You (hopefully) don’t want to be changing your son’s diapers when he’s 17 years old.

Baby Huey

Worst. Cartoon character. Evar.

So when you look at that mess of code in your Main.as Class, start asking yourself this question: should this kid, this group of properties and methods, be taking care of himself? Is this stuff that me, the Main.as Class, should be doing, or is this something that this kid can go off and do by himself?

Huh?

Here’s a real-world example:

package
{
	import flash.display.MovieClip;
	import flash.events.Event;
	import flash.events.MouseEvent;
 
	public class Main extends MovieClip
	{
		public function Main()
		{
			var myButton:MovieClip = new MyButton();
			myButton.label_txt.text = "Play";
			myButton.addEventListener(MouseEvent.CLICK, clickMyButton);
			myButton.addEventListener(MouseEvent.MOUSE_OVER, rollOverMyButton);
			myButton.addEventListener(MouseEvent.MOUSE_OUT, rollOutMyButton);
			myButton.mouseChildren = false;
			addChild(myButton);
			myButton.x = 150;
			myButton.y = 89;
 
		}
 
		public function clickMyButton(e:Event = null):void
		{
			playGame();
		}
 
		public function rollOverMyButton(e:Event = null):void
		{
			var myButton:MovieClip = MovieClip(e.target);
			myButton.background.gotoAndStop("highlight");
		}
 
		public function rollOutMyButton(e:Event = null):void
		{
			var myButton:MovieClip = MovieClip(e.target);
			myButton.background.gotoAndStop("unhighlight");
		}
 
		public function playGame():void
		{
			// Do some stuff here
		}
	}
}

In this piece of code, the Main.as file adds an instance of the MyButton Class to the stage. When the player clicks the button, we fire the playGame method.

There are some things here that the Main.as Class should probably do, and a bunch of things that the LabelButton Class should do for itself. Let me ask you this: why on God’s green Earth should Main.as care about how the MyButton Class implements all of its MouseEvent code? Making the button highlight on rollOver is MyButton’s responsibility, not Main.as’s responsibility.

Rollover

Take care of your own rollover.

Let’s imagine a not-too-distant future. Robots rule the Earth. Gary Coleman is in the White House. And you’re writing a new Actionscript project where you need a MyButton. The way you’ve written it here, can you easily pluck your MyButton Class out of this old project, and plunk it into your new project and expect it to work? No! That’s because you have code that is crucial to the functioning of your MyButton class outside your MyButton Class.

Do the clickMyButton, rollOverMyButton, and rollOutMyButton methods belong to Main, or do they belong to MyButton? Let’s go back to our semi-useless Dog example. Do bark, sniff and peeOnLeg belong to Main, or do they belong to Dog? They belong to Dog. So let’s put them in Dog.

Fat Dog

Stuff everything concerning Dog IN Dog.

Here’s the above script with the MyButton-specific methods removed:

package
{
	import flash.display.MovieClip;
	import flash.events.Event;
 
	public class Main extends MovieClip
	{
		public function Main()
		{
			var myButton:MovieClip = new MyButton();
			myButton.label_txt.text = "Play";
			addChild(myButton);
			myButton.x = 150;
			myButton.y = 89;
 
		}
 
	}
}

Wow! We really cleaned up our Main Class, didn’t we?

Here’s what our MyButton Class looks like. We’ve just plucked the methods out of our Main Class and put them where they belong, in MyButton. MyButton changes its own diapers.

package
{
	import flash.display.MovieClip;
	import flash.events.Event;
	import flash.events.MouseEvent;
 
	public class MyButton extends MovieClip
	{
		public function MyButton()
		{
			addEventListener(MouseEvent.CLICK, clickMyButton);
			addEventListener(MouseEvent.MOUSE_OVER, rollOverMyButton);
			addEventListener(MouseEvent.MOUSE_OUT, rollOutMyButton);
 
		}
 
		public function clickMyButton(e:Event = null):void
		{
			playGame();
		}
 
		public function rollOverMyButton(e:Event = null):void
		{
			background.gotoAndStop("highlight");
		}
 
		public function rollOutMyButton(e:Event = null):void
		{
			background.gotoAndStop("unhighlight");
		}
 
		public function playGame():void
		{
			// Do some stuff here
		}
 
	}
}

If you’re keen-eyed, you’ll notice that we were even able to cut down the code when we moved it to the MyButton Class. Instead of saying myButton.addEventListener(MouseEvent.CLICK, clickMyButton);, we can drop the “myButton” part and just say addEventListener(MouseEvent.CLICK, clickMyButton);. That’s essentially the same as saying this.addEventListener(MouseEvent.CLICK, clickMyButton);. The “this” keyword is like saying “me”. We’re inside the MyButton world, so we’re referring to ourselves. While we are writing code inside the MyButton class, we are MyButton.

Starting an Argumemt

Now what about that line in Main.as where we label the button?

myButton.label_txt.text = "Play";

Is labelling the button a responsibility of Main.as, or a responsibility of MyButton.as? The answer is slightly tricky.

MyButton might not always be labelled “Play”. We could (and should) think generically, so that MyButton could be labelled “Play” or “New Game” or “Change Character” or whatever. So Main.as should be responsible for labelling the button, right?

Not exactly. MyButton should still be responsible for labelling itself. But Main.as should be responsible for deciding what that label says. That way, Main could create buttons that say “Play”, “New Game” and “Change Character”,all using the same MyButton Class. The MyButton Class takes care of all the logic of actually displaying that text on itself.

To pull this off, we pass a parameter to our MyButton Class from Main.as.

package
{
	import flash.display.MovieClip;
	import flash.events.Event;
 
	public class Main extends MovieClip
	{
		public function Main()
		{
			var myButton:MovieClip = new MyButton("Play"); // Check it out!!!
			addChild(myButton);
			myButton.x = 150;
			myButton.y = 89;
 
		}
 
	}
}

Main.as creates a new MyButton instance (stamp, copy), and passes something called a parameter to the MyButton Class. MyButton grabs that parameter and uses it to label itself.

Note: if you’re fuzzy on the concept of datatypes (String, Number, Int, Boolean, etc), you may already be in over your head. Go read a basic tutorial on datatypes, and come on back.

Here’s the MyButton Class, now modified to grab that parameter from Main.as (or whatever Class instantiates [makes a stamp of, makes a copy of] the MyButton class).

package
{
	import flash.display.MovieClip;
	import flash.events.Event;
	import flash.events.MouseEvent;
 
	public class MyButton extends MovieClip
	{
		public function MyButton(labelName:String)
		{
			label_txt.text = labelName; // Grab that parameter and label myself!
 
			addEventListener(MouseEvent.CLICK, clickMyButton);
			addEventListener(MouseEvent.MOUSE_OVER, rollOverMyButton);
			addEventListener(MouseEvent.MOUSE_OUT, rollOutMyButton);
 
		}
 
		public function clickMyButton(e:Event = null):void
		{
			playGame();
		}
 
		public function rollOverMyButton(e:Event = null):void
		{
			background.gotoAndStop("highlight");
		}
 
		public function rollOutMyButton(e:Event = null):void
		{
			background.gotoAndStop("unhighlight");
		}
 
		public function playGame():void
		{
			// Do some stuff here
		}
 
	}
}

Beautiful! In this line, we accept a parameter:

public function MyButton(labelName:String)

And in this line, we grab that parameter and use it to label ourselves:

label_txt.text = labelName; // Grab that parameter and label myself!

Jockeying for Position

Finally, we’ll talk about the x/y lines in the Main Class:

myButton.x = 150;
myButton.y = 89;

Is that something that Main should be responsible for, or something that MyButton should be responsible for? x and y are properties of MyButton, so MyButton should handle them, right?

Not so fast! While we could let MyButton position itself, it wouldn’t make sense to. The Class that needs a MyButton should decide where on the screen the button should go. Otherwise, every time we create a new MyButton instance, it’ll appear in the same place on the screen. Not so hot. Main.as should take care of positioning the button instance.

Real Ultimate Power

Et voila! We’re in good shape now. We’ve:

  1. Identified a chunk of code that should change its own diapers
  2. Moved that code to its own .as Class file
  3. Thought generically about how an instance (stamp, copy) of that Class should be treated

Now, check out the glorious wonderland we can experience and enjoy:

package
{
	import flash.display.MovieClip;
	import flash.events.Event;
 
	public class Main extends MovieClip
	{
		public function Main()
		{
			// Instantiate a new play button:
			var myPlayButton:MovieClip = new MyButton("Play");
			addChild(myPlayButton);
			myPlayButton.x = 150;
			myPlayButton.y = 89;
 
			// Instantiate a new instructions button:
			var myInstructionsButton:MovieClip = new MyButton("Instructions");
			addChild(myInstructionsButton);
			myInstructionsButton.x = 210;
			myInstructionsButton.y = 89;
 
			// Instantiate a new credits button:
			var myCreditsButton:MovieClip = new MyButton("Credits");
			addChild(myCreditsButton);
			myCreditsButton.x = 340;
			myCreditsButton.y = 89;
 
		}
 
	}
}

Wowee! THREE new button instances in half the code it took to have ONE button when we first started out.

We’re almost out of the woods. But there’s one nagging thing remaining. Notice that we have a method in the MyButton Class that looks like this:

public function clickMyButton(e:Event = null):void
{
	playGame();
}

Should MyButton decide what happens when it gets clicked? We saw that the Main.as Class can quickly create three instances of MyButton – a Play button, an Instructions button, and a Credits button. These three buttons are all going to do different things when the player clicks them. So the generic MyButton Class cannot possibly define its own click behaviour. Main.as is going to have to decide.

Let’s yank that click code right out of the MyButton Class:

package
{
	import flash.display.MovieClip;
	import flash.events.Event;
	import flash.events.MouseEvent;
 
	public class MyButton extends MovieClip
	{
		public function MyButton(labelName:String)
		{
			label_txt.text = labelName; // Grab that parameter and label myself!
 
			// this is where the MouseEvent.CLICK listener used to be
 
			addEventListener(MouseEvent.MOUSE_OVER, rollOverMyButton);
			addEventListener(MouseEvent.MOUSE_OUT, rollOutMyButton);
 
		}
 
 
		public function rollOverMyButton(e:Event = null):void
		{
			background.gotoAndStop("highlight");
		}
 
		public function rollOutMyButton(e:Event = null):void
		{
			background.gotoAndStop("unhighlight");
		}
 
	}
}

And instead, we’ll write the listener for each button’s MouseEvent.CLICK in the Main.as Class:

package
{
	import flash.display.MovieClip;
	import flash.events.Event;
	import flash.events.MouseEvent;
 
	public class Main extends MovieClip
	{
		public function Main()
		{
			// Instantiate a new play button:
			var myPlayButton:MovieClip = new MyButton("Play");
			myPlayButton.addEventListener(MouseEvent.CLICK, clickBtnPlay); // new line!
			addChild(myPlayButton);
			myPlayButton.x = 150;
			myPlayButton.y = 89;
 
			// Instantiate a new instructions button:
			var myInstructionsButton:MovieClip = new MyButton("Instructions");
			myInstructionsButton.addEventListener(MouseEvent.CLICK, clickBtnInstructions); // new line!
			addChild(myInstructionsButton);
			myInstructionsButton.x = 210;
			myInstructionsButton.y = 89;
 
			// Instantiate a new credits button:
			var myCreditsButton:MovieClip = new MyButton("Credits");
			myCreditsButton.addEventListener(MouseEvent.CLICK, clickBtnCredits); // new line!
			addChild(myCreditsButton);
			myCreditsButton.x = 340;
			myCreditsButton.y = 89;
 
		}
 
		public function clickBtnPlay(e:Event = null):void
		{
			// Play the game
		}
 
		public function clickBtnInstructions(e:Event = null):void
		{
			// Show the instructions
		}
 
		public function clickBtnCredits(e:Event = null):void
		{
			// Show the credits
		}
 
	}
}

And there you have it. The MyButton Class takes care of its own diapers. It labels itself based on a parameter that’s passed to it. It handles its own rollOver and rollOut events. Main.as takes care of creating instances (stamps, copies) of the MyButton Class. Main.as decides:

  • What the button label will say
  • How the button will be positioned on the screen
  • What the button does when clicked

The First of Many

That’s a real-world example of where and when it makes sense to collect your code in a separate Actionscript Class file. Of course, this is just one example in an endless sea of possiblilities. The general rule is that if the code should be changing its own diapers, it should be in its own Class file. And if the code can be written generally so that it can be re-used, you’re ahead of the game.

The mystery that springs up from all of this is the OOP rule of Encapsulation, which states that you should write your Classes so that they’re self-contained and self-reliant. Not only do they change their own diapers, but they rent their own apartment and cook meals for themselves, with no reliance on outside Classes whatsoever to live.

There are advantages and disadvantages to Encapsulation, which we can look at in our next Understanding Classes tutorial. The biggest disadvantage is that to create a truly encapsulated Class, you have to write an ASSLOAD of repetetive Actionscript 3 code. i’ll show you a cheat that’ll break the encapsulation rule, but will save you HOURS of coding. The Eggheads will have my head for it, so let’s just keep it between you and me.

For more tips, tricks and tutorials on Flash and Actionscript, check out our Flash and Actionscript 911 feature.

Toronto Flex Camp 2

Flex Camp 2

That tattoo’s gonna look pretty silly when Adobe redesigns their Flex logo.

The TorontoFlex.org user group has announced its second Flex Camp:

Our second iteration of Flex Camp is coming on May 15, 2008 at the MaRS Centre (http://www.marsdd.com/Contact-MaRS.html).

This one promises to be even better than our premier event last fall. Along with Adobe’s Mike Potter, we’re privileged to have Ben Forta, the most well-known Adobe evangelist in the world. If you’ve never heard Ben speak before you’re in for a real treat!

Flex Camp, contrary to what you might think, is not a wilderness retreat for junior highschoolers where you go to experiment with homosexuality. No – it’s an event where you show up five minutes late and the promised meal has been completely devoured, and then at half-time when the organizers announce there are cookies in the next room and you charge out ahead of everyone because you missed dinner and have just sat through three hours of tech talk, only to find that a large group of attendees got bored and wandered into the cookie room hours earlier, decimating the cookie platters before the snack could even be announced.

Flex Camp is not so much a user group event, but a technologically-themed soup kitchen for Toronto’s college students.

The subject matter of the first Flex Camp flew right over my head, i’ll admit. It had something to do with using a programming paradigm called Loch Loman or Gormenghast or something to organize your code. Event organizer Oliver Merk spoke too abstractly for my liking, and it was especially difficult to concentrate with hunger gurgles gnawing away at my stomach lining.

Gormenghast

What this place has to do with web apps i’ll never know.

i appreciate that a user group should be able to focus on in-depth topics that go beyond a mere “introduction to Flex” idea, but i think the organizers went a touch too far. Flex is still so new that people seem to have a hard time understanding what it even is, let alone how to apply a programming paradigm to it.

If you’re a student looking for some free food, you’re bound to attend this event. In that case, the least you could do is to read up on Flex so that you can hold your own in a conversation while filling your pockets with little triangular egg salad sandwiches. Regard:

What the Heck is Flex?

Up until the release of Actionscript 3, people who programmed in Flash were not considered “real” programmers. Actionscript was derided by so-called “real” programmers as a “scripting language” rather than a programming language, which is like the difference between a community college and a university.

i always despised this viewpoint, because learning a programming language was very difficult for me, and i felt immensely satisfied that i was able to actually code things that functioned like honest-to-goodness real-live games and applications.

It wasn’t until i tried programming in C#, a “real” programming language, that i understood the comparison.

Mr. Fontsy Ponts

Flash is a tool that does a lot of stuff for you. You can just grab the Text tool, click on the screen and start typing. When you compile your movie, that text appears on the screen, in any outline you choose, and at any size in any colour you so desire.

If you’d like to do the same thing with C#, you have to make what’s called a font, or character, map:

Character Map

A character map. No bloody fun.

Then you have to train your program how to pick through and slice out a letter. So when you want to display the word “hello”, you tell your font rendering routine to go grab chunks of your character map at “h”, “e”, “l”, “l”, and “o”, and display those bitmaps on the screen.

That is, assuming you’ve programmed your game or app to display graphics on the screen. If not, you’ll have to code that or find a graphics renderer that someone else has coded.

It’s all part of what i like to call a Merry Pain in the Ass. But when so-called “real” programmers took a look at Flash, they said “What what what?? It draws the graphics for you?? But … but you lose so much control! And it could never render as quickly as something i wrote myself! And it’s … it’s not … hardcore enough!

Very well. So be it. You write your fast graphics engine while i bang out an entire game in a weekend.

Flex was created for these so-called “real” programmers to feel more at home. There are no drawing tools, no movieclips, and no shape tween drop-downs. In fact, there’s no actual program. Technically speaking, Flex is an Actionscript framework. The product name is used almost synonymously with “Flex Builder”, which is a plugin for a free programming IDE called Eclipse.

So you’re free to write in Flex, but if you want a tool to make it somewhat easier, you can buy Flex Builder for a few hundred bucks and extend the functionality of Eclipse. Flex has a few unique code libraries that Flash doesn’t have, and vice versa. You can’t create any graphics or animations with Flex or Flex Builder (except, technically, with the drawing API), so you still need some other creative authoring program like Flash, Photoshop, Fireworks, etc to create graphics, sounds, animations and movies.

Frex

Does that clear it up a little? i’m a very visual person myself, and i prefer having my graphics and animations right in front of me while i code. Although i am trying to warm up to FlashDevelop (more on that tool in another post), Flex isn’t really for me.

The thing that struck me most about the last Flex Camp, aside from wanting to gnaw my own leg off from sheer starvation, is that Flex coders are in high, high demand … possibly more than Flash people. Every presenter, every staffer and every attendee i spoke to was looking for a Flex coder. The drawback is that you usually have to build some kind of online accounting software or phramaceutical inventory system with it. But if that doesn’t bother you, give Flex – and Flex Camp 2 – a shot.

Just be sure to eat before you show up.