public static function compareStrings ( firstString:String, secondString:String ):String
{
	firstString:String = tidySpace( firstString );
	...
}

You see that firstString:String = etc there? That’s the fella. DON’T EVER strongly type your vars more than once, unless you wanna lose an hour of dev like I have this morning.

[click the image to see a larger version]

This diagram outlines an XML load procedure. Complicated, no? That’s because it’s for an AIR app, and therefore has to cope with situations other Flash & Flex apps don’t. I’m showing it to make the case for planning AIR apps in advance as much as possible.

Let’s go through the diagram’s logic. There are only two possible outcomes, either ‘XML DOC!’ (bottom left) or ‘FATAL ERROR!’ (bottom right) There are ten possible routes, three failures, one restart and six successes. I’ll go through them all, from worst to best.

The first three steps always occur. The app queries a web service for new data, and if it finds some it asks the user if she wants it and saves her answer. The fourth step is the first query of the loop.

1. NEW DATA?
2. USER WANTS IT?
3. GET FIRST XML DOC
4. IN MEMORY?

Has the XML already been loaded? Every load starts with this question. Thereafter…

Scenario A: App offline on first run - FAIL

1. NO (not in memory). FIRST RUN?
2. YES. ONLINE?
3. NO. ALERT END -> FATAL ERROR!

The XML document is not in local memory, it’s the app’s first ever run and it’s not online. This is a fatal error because some of the app’s mandatory data lives necessarily online, and without it the app will break.

Scenario B: App online on first run - RESTART

1. NO (not in memory). FIRST RUN?
2. YES. ONLINE?
3. YES. ALERT START -> IN MEMORY?

The XML document is not in local memory, and it’s the app’s first ever run, but it is online, meaning it can obtain it’s mandatory data. We set FIRST RUN to ‘false’ and restart the loop.

Scenario C: App offline on subsequent run - FAIL

1. NO (not in memory). FIRST RUN?
2. NO. LOCAL VERSION?
3. NO. ONLINE?
4. NO -> FATAL ERROR!

The XML document is not stored locally, the app has run before, but there is no ‘local version’. If the app had previously downloaded the XML document it would have stored it locally, so that if in future it was offline, it would have a back-up copy. Being offline means it can’t obtain the document in the first place, and will therefore break.

Scenario D: App cannot load mandatory XML at first attempt - FAIL

1. NO (not in memory). FIRST RUN?
2. NO. LOCAL VERSION?
3. NO. ONLINE?
4. YES. LOAD TERR LANG
5. NO (load error). BACK UP DOC? (PROB. US-EN)
6. NO -> FATAL ERROR!

The XML document is not stored locally, the app has run before, and there is no local version, but we are online, meaning we can ‘LOAD TERR LANG’. This is shorthand for ‘Territory & Language’. When the user logs in they choose a global region (Europe, America, Africa) and a preferred language, and each XML document has different versions to reflect this. If the user’s preferred choice - European data in Spanish, say - fails we load a back-up document, usually American data in English. If this equally fails, again the app will break.

Scenario E: App loads back-up XML - SUCCESS

1. NO (not in memory). FIRST RUN?
2. NO. LOCAL VERSION?
3. NO. ONLINE?
4. YES. LOAD TERR LANG
5. NO (load error). BACK UP DOC? (PROB. US-EN)
6. YES. LOAD BACK UP DOC
7. YES -> XML DOC!

The XML document is not stored locally, the app has run before, and there is no local version, but we are online, meaning we can load ‘Territory & Language’. If that fails we load the back-up document. That loads successfully, meaning we at least have usable data.

This is the worst of the six successful outcomes.

Scenario F: App loads and stores requested XML - SUCCESS

1. NO (not in memory). FIRST RUN?
2. NO. LOCAL VERSION?
3. NO. ONLINE?
4. YES. LOAD TERR LANG
5. YES -> XML DOC!

The XML document is not stored locally, the app has run before, and there is no local version, but we are online, meaning we can load ‘Territory & Language’. And it loads! It’s then stored locally should it be needed it whilst offline in future.

Scenario G: App has locally stored XML - SUCCESS

1. NO (not in memory). FIRST RUN?
2. NO. LOCAL VERSION?
3. YES. OUT OF DATE? USER WANTS NEW DATA? ONLINE?
4. NO. USE EXISTING LOCAL VERSION -> XML DOC!

The XML document is stored locally! It must have been downloaded before. But is the online version newer? And has the user signaled that she wants the latest data (see step 2 above)? And are we online? If the answer to any of these questions is ‘no’ we should use the local version.

Scenario H: App falls back on locally stored XML - SUCCESS

1. NO (not in memory). FIRST RUN?
2. NO. LOCAL VERSION?
3. YES. OUT OF DATE? USER WANTS NEW DATA? ONLINE?
4. YES. LOAD TERR LANG
5. NO (load error). USE EXISTING LOCAL VERSION -> XML DOC!

The XML document is stored locally, but newer data is available, the user wants it, and we are online, meaning we should load ‘Territory & Language’. That fails though, so we use the old back-up version.

Scenario I: App loads and stores updated XML - SUCCESS

1. NO (not in memory). FIRST RUN?
2. NO. LOCAL VERSION?
3. YES. OUT OF DATE? USER WANTS NEW DATA? ONLINE?
4. YES. LOAD TERR LANG
5. YES -> XML DOC!

The XML document is stored locally, but newer data is available, the user wants it, and we are online, meaning we should load ‘Territory & Language’. And we get it!

Scenario J: App already has XML in memory - SUCCESS

1. YES (in memory) -> XML DOC!

The XML document exists in the app’s runtime memory! This happens if the user has logged in, loaded her XML, logged out, and then logged in again without closing the app.

This is the best of the six successful outcomes.

————————————————————————————————-

Scenario K: Post-load assessment

1. XML DOC!
2. MORE XML TO LOAD?
3. YES. IN MEMORY?

After every successful journey through the loop we check for further XML documents, and load them if required.

1. NO (no more XML documents to load). START APP…

Or if not, we just start the app.

————————————————————————————————-

Conclusion

The above procedure is only about loading XML documents. Getting data, one of the simplest aspects of any app. If something so straightforward can become so complex, imagine how other parts of your app will end up if you don’t think them through in advance.

If you are building AIR apps: plan, plan, plan!

ps: There is a logical error in the diagram. I’m offering £1 to anyone who can tell me what it is.

As it’s basically just a slightly jazzier way of selecting a single item, I made it in the same way one would create a List component: with properties like selectedIndex, selectedItem, dataProvider, itemRenderer etc. etc. Basically, just hand it a dataProvider and it’ll lay it all out for you. ‘Should play ball, but hasn’t been exhaustively tested so you might get some bugs, dunno.

The Carousel can be controlled in various ways. Clicking the slider will tween it to that position. Dragging the slider point will tween it to the slider’s current position. Clicking a renderer will tween that renderer into the centre.

I’ll explain further down this post how to use it but first some documentation. I haven’t had - and probably won’t get - the time to document it properly, with ASDocs or whatever, so here is a scrappily thrown together lists of it’s various properties.

CONSTANTS

MIN_DIAMETER:int = 1024;
The minimum width of the circle the renderers sit on.

MAX_DIAMETER:int = 8192;
The maximum width of the circle the renderers sit on.

PROPERTIES

container:Canvas
The bounding box that contains the renderers (read-only).

dataProvider:Object
The data for the component. Currently only Arrays are accepted.

diameter:int
The width of the circle. Value must be between MIN_DIAMETER and MAX_DIAMETER. The default is half MAX_DIAMETER.

focusFrame:CarouselFocusFrame
The grey box that frames the selected renderer. The value of this property must be a DisplayObject that extends CarouselFocusFrame and implements ICarouselFocusFrame.

focusFrameDisplaysConstantly:Boolean
A flag that indicates whether the focusFrame should display permanently (true) or disappears whilst the Carousel is spinning (false). The default is true.

itemRenderer:IFactory
The itemRenderer for the Carousel. The ‘generator’ for this property must implement ICarouselRenderer.

labelField:String
The name of the property on the dataProvider objects used to populate the text labels on the renderers. The default is ‘label’.

rendererGap:uint
The distance in pixels between each renderer. The default is 50.

rendererHeight:int
The height in pixels of each renderer. The default is 190.

rendererWidth:int
The width in pixels of each renderer. The default is 150.

selectedIndex:int
The index of the currently selected item. Setting selectedIndex moves the Carousel to that point directly, setting targetIndex tweens it there.

selectedItem:Object
The currently selected item.

slider:HSlider (read-only)
The HSlider instance that controls the Carousel (read-only).

sliderIntervalGap:int
The length in pixels to set the slider for every renderer it controls. The default is 50.

smoothing:Boolean
The smoothing to be used on the renderer images. The default is true.

sourceField:Object
The name of the property on the dataProvider objects used to populate the images in the renderers. The default is ’source’.

targetIndex:int
The currently requested index for the Carousel to tween to. Setting targetIndex tweens the Carousel to that point, setting selectedIndex moves it there directly.

STYLES

The component also has a couple of styles: ‘carouselColor’ and ‘carouselPaddingTop’.

carouselColor:int
Sets the colour of the container Canvas that holds the renderers.

carouselPaddingTop:Number
Sets the padding between the top of the component and the top of the container Canvas that holds the renderers.

Using the Carousel Component

This should be pretty straightforward.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application 
	xmlns:mx="http://www.adobe.com/2006/mxml" 
	xmlns:carousel="uk.co.richtextformat.flex.view.components.carousel.*"
	layout="absolute">
 
	<carousel:Carousel id="myCarousel" 
		width="100%" height="100%"
		focusFrameDisplaysConstantly="false"
		carouselPaddingTop="20"
	/>
 
</mx:Application>

Setting the dataProvider should be all you need to do to get it rolling.

var dataProvider:Array = [ 
	{label:'Tobias', source:'img1.jpg'},
	{label:'Cynthia', source:'img2.jpg'},
	{label:'Walter', source:'img3.jpg'}
];
myCarousel.dataProvider = dataProvider;

And if your data is bespoke and you needed to change the property names, that should be straightforward too.

myCarousel.labelField = 'name';
myCarousel.sourceField = 'imgURL';
var dataProvider:Array = [ 
	{name:'Tobias', imgURL:'img1.jpg'},
	{name:'Cynthia', imgURL:'img2.jpg'},
	{name:'Walter', imgURL:'img3.jpg'}
];
myCarousel.dataProvider = dataProvider;

The ’source’ property of your data objects can either be a valid URL to an image online (a default blue ‘No Image Available’ image will be used where the URL is invalid) or a Bitmap instance.

The component is free for use and can be downloaded here from my repo on Github. I think and hope so anyway. I’m new to Github (only signed up today) and am not really familiar with the way it works yet, so if you get any probs getting hold of it from there leave a message for me somewhere and I’ll see what I can do to help.

Signals is a new approach for AS3 events, inspired by C# events and signals/slots in Qt.

Put them together and you’ve got an elegant, simple & completely decoupled solution to the problem of Flex & AIR development.

I’ve thrown together a really quick example (which you can download below) based upon a couple of things I’ve seen recently; firstly Richard Lord’s framework comparison talk at FlashBrighton a couple of weeks ago, and secondly, Owen Bennett’s  blend of RobotLegs and Signals he showed me last week. Seeing what Owen had put together inspired me to have a go myself. I wondered whether it was possible to create a RobotLegs/Signals hybrid that was even more decoupled than the system Owen was working on. So I created a short (less then 100 lines) class called ‘SignalBox’, named after a similarly named class in Owen’s system.

RobotLegs & Signals are great bits of work but I won’t discuss them here, because you can either go here & here to do that, or if you’re feeling confident - or just plain impatient - download the RobotSignals example here and just have a play with it. It’s a FlexBuilder project that contains both the Robotlegs & Signals source code (from mid-December 2009), so should contain all you need.

The following swf is what the example project compiles down to:

As simple an example I could conceive of. This Flex app conatins two View elements - the TextInput & Button to the left, and the TextArea to the right - both of which are controlled by their own Mediators and an Actor based Proxy Model class in the background. These three elements are entirely decoupled from each other but communicate through the SignalBox class in the following way:

1. The TextSubmit component dispatches user input into the Signalbox;
2. The TextProxy Model instance hears the Signal and stores said user input, before dispatching it again into the SignalBox;
3. The TextDisplay component instance hears the signal and displays the user input in its TextArea component

The decoupling is extreme, to the point that the only public method they definitely require is the onRegister(); method they use to register with the RobotLegs framework. All communications go through the SignalBox. RobotLeg’s Context class injects the SignalBox into every class in you application, meaning they all have access to the same single instance of said SignalBox, meaning that it’s Signals can propigate through every part of the application at will. This is an example of a singleton-with-a-small-s pattern; as in a single instance and not a global property.

The ISignalBox interface defines the following seven, reasonably self-explanatory methods:

function addListener (signalName:String, listener:Function, valueClass:Class = null):void;
function addListenerOnce (signalName:String, listener:Function, valueClass:Class = null):void;
function deleteSignal (signalName:String):void;
function dispatchSignal (signalName:String, valueObject:Object, andDeleteIfLastListener:Boolean = true):void;
function hasSignal (signalName:String):Boolean;
function removeAllListeners (signalName:String, andDelete:Boolean = true):void;
function removeListener (signalName:String, listener:Function, andDeleteIfLastListener:Boolean = true):void;

SignalBox keeps a private collection of Signals, meaning that Robert Penner’s Signals themselves are abstracted away and you never interect with them. By calling addListener or addListenerOnce you can listen for a Signal, and calling dispatchSignal from elsewhere sends that listened for Signal. All seven methods in SignalBox take the following param as their first parameter:

signalName:String

Calling either addListener or addListenerOnce ensures that a Signal with the passed signalName is created, if it doesn’t already exist. Each signalName must be unique. Calling addListener or addListenerOnce multiple times with the same signal name results in additional listeners being added to a single Signal:

signalBox.addListener("UserInput", someMethodName);
signalBox.addListener("UserInput", anotherMethodName);

Once you’ve created a Signal like this, you can dispatch signals through it:

signalBox.dispatchSignal("UserInput", "A Message");

Calling dispatchSignal on a signal that has yet to be created results in an error being thrown.

Adding a Class as the optional third parameter of either addListener or addListenerOnce results in listeners to that Signal expecting instances of that type:

signalBox.addListener("LoginAttempt", handleLogin, Boolean);
signalBox.dispatchSignal("LoginAttempt", true);

If this third parameter is left undefined, the class String is used by default.

I want to keep this post as short and simple as possible so I’ll stop here and if you’ve got any questions please fire away. You can download the RobotSignals example here.

These days, with FlexBuilder, I don’t have that any longer. Which isn’t great but I’ve managed to concoct a  workaround using ‘Snippets’, comments and ‘dormant’ variables, which has sped things up for me and which could do the same for you.

Let me explain…

Snippets

These, for those of you that don’t know, are sections of reusable code that you can insert into a file. Putting your cursor in the place you want a snippet to appear and clicking on its name (in a ‘Snippets’ dialog box) will insert the snippet at that position. They’re simple to use and save time rewriting repetitious things like for loops. Insideria have a great little tutorial here that will show you how to install a ‘Snippets’ plugin for FlexBuilder and I recommend you do just that. That link also details a little ‘ToDo’ FlexBuilder plugin that I’ve found really helps too. Go do that first then come back here and read on.

Comments and ‘Dormant’ Variables

When I say ‘dormant’ I mean variables that are added to your code but never instantiated. A class’ various properties appear in FlexBuilder’s ‘Outline’ dialog when FlexBuilder is focused on that file. Here’s a boilerplate ‘SomeClass’ example, followed by its representation in the ‘Outline’ dialog:

package
{
	public class SomeClass
	{
		private var _someVar:int;
 
		public function SomeClass() {}
	}
}

You can see that both the constructor method and the ‘_someVar’ variable appear in the dialog. Clicking on either of them will take you to that point in the code, so it really helps with navigating around.

What we can do with this is to create a snippet that contains only comments and some potentially ‘dormant’ variables and utilise this ‘Outline’ functionality to make the class easier and quicker to work with. Here’s the snippet we’ll use:

		// ------------------------------------------------------------------------------------------------------------------------------
		// INIT METHODS
		// ------------------------------------------------------------------------------------------------------------------------------
		private var ____________________initMethods:int;
 
		// ------------------------------------------------------------------------------------------------------------------------------
		// PUBLIC METHODS
		// ------------------------------------------------------------------------------------------------------------------------------
		private var ____________________publicMethods:int;
 
		// ------------------------------------------------------------------------------------------------------------------------------
		// PROTECTED METHODS
		// ------------------------------------------------------------------------------------------------------------------------------
		private var ____________________protectedMethods:int;
 
		// ------------------------------------------------------------------------------------------------------------------------------
		// PRIVATE METHODS
		// ------------------------------------------------------------------------------------------------------------------------------
		private var ____________________privateMethods:int;
 
		// ------------------------------------------------------------------------------------------------------------------------------
		// LISTENER METHODS
		// ------------------------------------------------------------------------------------------------------------------------------
		private var ____________________listenerMethods:int;
 
		// ------------------------------------------------------------------------------------------------------------------------------
		// GETTERS / SETTERS
		// ------------------------------------------------------------------------------------------------------------------------------
		private var ____________________gettersSetters:int;

Under each comment i’ve added an int variable whose name is formed of two distinct parts: a prefix made up of a whole line of underscore characters, and a suffix describing what each section contains. The comments are there for when you are looking at the file itself, the ‘dormant’ variables are there for the ‘Outline’ dialog. I’ll hereafter add my various properties and functions to the class in the relevant places. These two private methods, for instance, they’ll go directly under the ‘____________________privateMethods’ variable:

		// ------------------------------------------------------------------------------------------------------------------------------
		// PRIVATE METHODS
		// ------------------------------------------------------------------------------------------------------------------------------
		private var ____________________privateMethods:int;
 
		private function _doSomething ():void
		{
			trace("_doSomething");
		}
 
		private function _doSomethingElse ():void
		{
			trace("_doSomethingElse");
		}

You can see how i like to organise my methods. Under each ‘heading’ I list my various methods alphabetically, making them dead easy to navigate to. More importantly though, I split the methods up into ‘init’, ‘public’, ‘protected’, ‘private’, ‘listeners’ and ‘getters/setters’. This forms just five groups of methods and that guards against your classes becoming too bloated. Let me explain:

Sometimes a class can get so long and overloaded with methods that organising it becomes a case of grouping functionality instead of method types together. For instance, instead of saying ‘this group contains my private functions’ you might say ‘this group controls the appearance of textfields’. If that happens it’s a sure sign that your class is doing too much; you should just have a seperate, single class for the ‘control of the appearance of your textfields’. if you use the ‘public, ‘protected’ etc method of organisation and one of your five groups of methods starts to get too full up and slightly confusing, its a sure sign that what you need to do is move some of the functionality over to a new class. because:

one class = one job

Now that’s all fine and dandy, but why do this? If you look back at the ‘Outline’ dialog now, you’ll see why:

The ‘dormant’ variables and the two new methods have now appeared in the ‘Outline’ dialog and the ‘dormant’ variables have split the dialog up into small, manageable sections with their long, underscore-based prefixes serving visually to easily differentiate between them and genuine methods and properties. The only role of the ‘dormant’ variables is to act as headers and spacers for the ‘Outline’ dialog box.

I’ve also added a getter and a setter method so you can see how clearly this view separates out the whole thing and makes it much quicker and easier to work with.

So, using Jon’s method what you have to do is:

1. Create a fonts swc;
2. Ensure your compiler includes every font in your swc; and
3. That’s it! Use your embedded fonts

1. Create a fonts swc

Open Flash, create a new document, right-click on the Library panel and select ‘New Font…’

In the resulting ‘Font Properties’ dialog choose the font you want using the dropdown, uncheck all the checkboxes and ensure that the ‘Name’ field exactly matches the ‘Font’ dropdown. (just to explain: you don’t have to make them match but it makes things easier for you. FlexBuilder will take the name of the font from the ‘Font’ dropdown and not the ‘Name’, which is counter-intuitive and confusing, so making them both match avoids this confusion)

Repeat this process until you’ve got all the fonts you want in the library. Then ensure that ‘Export SWC’ is checked in your ‘Publish Settings’ and you’re good to go!

Export the swc to wherever you want it to live - which would be somewhere in your FlexBuilder project, ideally - and compile that puppy!

2. Ensure your compiler includes every font in your swc

Now, over in FlexBuilder open your project’s ‘Properties’ dialog, go to the ‘ActionScript Compiler’ tab and add something like the following to the ‘Additional compiler arguments:’ textfield:

-include-libraries path/to/your/fonts.swc

Where ‘path/to/your/fonts.swc’ is the actual path to the fonts swc you just created (this will always be a relative path, relative to your project’s source directory). ‘-include-libraries’ will ensure that you include every last font in the swc.

3. Use your embedded fonts

That’s all there is to it! You can now simply access your fonts by the name you gave them in the swc:

var textFormat:TextFormat = new TextFormat("BetonCross-Light", 12, 0x000000);

You can find my bad eCard here. The misspelling in it was a genuine mistake that I thought I’d keep. I hope it makes you smile and I wish you a merry Christmas and a happy new year.

See you in 2009!

I had just come back from BarCampBrighton, where I was inspired by Ollie Glass‘ workshop on writing genetic algorithms; something that turned out to be really simple. So I sat down, chucked some code together and produced this Tile Designer swf, built on a genetic algorithm:

And I was right, WE WON !!! It’s fantastic but I’m not going to say too much about it because Matt Pearson’s has already a great job of that here. Instead let me say this:

I was REALLY, REALLY pleased to see Matt Pearson pick the ‘Best Blog’ award for his zenbullets blog. I really admire good writing and zenbullets certainly has that. The delivery and content are excellent, and his documentation of the victimisation Sussex Police have only-just ceased to put him through is just captivating. For these reasons I also felt that Matt would be a shoe-in in his category, and was pleased to see that I was right again.

Obviously I had a hand in the FlashBrighton award but what might not be so obvious is that I also had a hand in a second award. Blast Theory were nominated in the “Digital Collaberation” category. Now, I thought that it was Blast Theory as a whole that was nominated but it turned out that it was specifically their ‘Rider Spoke’ project. In the words of Blast Theory, ‘Rider Spoke is a work for cyclists combining theatre with game play and state of the art technology’. Part of the work was a Flash front-end for a console cyclists had attached to the handlebars of their bikes (you can see some images of that in action here). Twas I wot made that Flash front-end.

And ‘Rider Spoke’ won too !!! So as Flash coder and copywriter, I came away from the night feeling like I had an important hand in not-one-but-two awards! I also came away from the night feeling quite drunk.

Finally, I would like to mention that Brightonian Flash agencies LittleLoud & Kerb, freelancer Sarah Bird and my former employer DigitalBrain were also nominated in other categories but sadly failed to pick up awards. FlashBrighton members were nominated in so many categories that it was inevitable that some of us weren’t going to get our just desserts. And anyway, LittleLoud are up for a BAFTA this weekend, so things aren’t really too bad for them. Maybe next year guys?

Designers

Charis Mystakidou: wiredportfolio.com
Kristen Akerman: sting.co.uk
Luke Hornsby: flamingpixels.co.uk
Tim Frost: bullandgate.com

Developers

Richard Willis: richtextformat.co.uk
Matt Pearson: actionscripter.co.uk
Matt Sayers: soplausable.com
Neil Manuell: revisual.co.uk
Nikos Chagialas: devgallery.com
Owen Bennett: steamboy.co.uk