Check out our new video for HTML 5 at: http://www.youtube.com/watch?v=hhTQPcqLWTI

You can find all our free video tutorials on our YouTube Channel. Feel free to subscribe to keep up-to-date with our future video releases!

http://www.youtube.com/DNDigital

Feel free to ask questions, leave comments or request further material.

Enjoy!

I’d love to hear about your own experiences in regards to object oriented programming in AS3 – please leave a comment!

The material in this blog post and in the video is an excerpt from our Advanced Actionscript 3 (Object Oriented Programming and Design Patterns) training course.

You can watch the video and read up on the details after the break.

Making Choices

The Abstract Factory Design Pattern is all about choice. Not any kind of choice mind you – but very specifically choosing which class to instantiate given certain conditions. Whether you realise it or not, you are probably making these choices numerous times in your own programming code. Here are some examples:

• Which type of menu to display based on the admin privileges of the current user
• Which type of skin to apply to your game characters, based on the selections made at the beginning of the game – and subsequently which types of weapons are available for that character
• Which type of button graphic to use based on the size of a banner
• Which type of XML parser to use based on the type of feed the user has loaded in

and so on. Once you’re dealing with object oriented programming, most of those choices are going to result in a class being instantiated and the trick is to choose the correct class based on a set of circumstances.

No problem, right? You just whack an if-statement in there:

if( user.isAdmin ){
    menu = new AdminMenu();
}else{
    menu = new NormalMenu();
}

Weeds Everywhere

Of course, using if-statements will work fine, however it spreads the choices throughout your application, like a weed taking a strong-hold in your garden, then your front lawn, then your walls…you get the picture. Suppose you introduce a third user privilege level? Time to revisit all those many if-statements (of course you’ll remember where they are!). The more complex your project, the more difficult, time-consuming and error prone such a change becomes.

Factory Pattern to the Rescue

It is in these cases that the Factory Design Pattern comes to your rescue, by moving the choice into a single, isolated piece of code. The resulting class that is instantiated – the factory – will then provide the application with the correct class instances. As a result, you only need to change the single point-of-choice and create a new factory class in order to make wide-ranging changes to your entire application.

In practice, it looks something like this:

// isolated choice code (eg. after user logs in)
if( user.isAdmin )
{
    factory = new AdminUserFactory();
}else{
    factory = new NormalUserFactory();
}
 
// and in the AdminUserFactory class:
function getMenu():Menu
{
    return new AdminMenu();
}
 
// and in the NormalUserFactory class:
function getMenu():Menu
{
    return new NormalMenu();
}
 
// much later, in a remote location in your code-tree
menu = factory.getMenu();

Can you see how you would add a third user level – and how much more manageable it has become compared to the previous example?

Let’s follow the example code through to its logical conclusion. Say we have 10 user levels. Then we’ll end up with 10 different factory classes (AdminUserFactory, NormalUserFactory, SuperUserFactory, etc). So far so good. But how does the code that is actually using the factory to retrieve the menu know how to deal with all those 10 different classes without using another if-statement? Surely that will lead to type-errors if we don’t know the exact data-type?

Interfacing with the Factory

In order to allow code throughout your application to use different factory classes, we’re going to use an interface to define what methods a factory class provides. This interface will be used as the data-type when passing the factory around to other pieces of code. So in practice it doesn’t matter which factory class is used behind the scenes and dependencies within your code are reduced to a single interface class, which is what we like to see!

Our user-menu example seems to use factory to create its user-interface elements, so let’s create an interface called IUIFactory. We start with just a single function – we can always add to it later on:

// in the IUIFactory.as file
public interface IUIFactory {
    function getMenu():Menu;
}

As a rule, you’d start with your interface first, then create your first factory class and then create your choice code – otherwise you’ll end up in a bit of a pickle.

Here is the sample code from earlier, with the interface thrown in.

// we start with an interface
var factory:IUIFactory;
if( user.isAdmin )
{
    factory = new AdminUserFactory();
}else{
    factory = new NormalUserFactory();
}
 
// and in the AdminUserFactory class - which implements IUIFactory
public function getMenu():Menu
{
    return new AdminMenu();
}
 
// and in the NormalUserFactory class - which also implements IUIFactory
public function getMenu():Menu
{
    return new NormalMenu();
}
 
// much later, in a remote location in your code-tree
var factory:IUIFactory;
menu = factory.getMenu();

Splendid.

Another beneficial side-effect of using an interface in this way comes into play when adding new features to your factory. Any new feature requires a new method in your factory interface. That new method will immediately result in compiler errors because none of your factory classes has implemented it yet. You have no option but to implement the new method in every single factory class – hence automatically making sure that your code is properly maintained.

Doesn’t that sound better than finding a long-lost if-statement deep down in the murky depths of your code-tree that your colleague forgot to change when they added a new user-group?

YouTube Tutorial and Source Code

The YouTube tutorial steps through a different example of coding a user-interface that can change depending on the age-group of the viewer.

You can download the source-code as a FlashBuilder 4 project so that you can follow the tutorial and experiment further. There are a couple of extra images in the assets folder so you can produce a third factory class. Copyright / licensing info is included in each file, all images used are publicly available via sxc.hu.

Further Thoughts – Factory Pattern and Dependency Injection

The Factory Design Pattern’s strengths come from isolating choices in a single location. Furthermore, each factory class also encapsulates a very simple set of actions – it knows how to create the correct instances but doesn’t require knowledge of the surrounding application to do so – so we are adhering to the  ’one class – one responsibility’ concept.

Of course you still need to pass the actual factory instance around to the classes that require them and there are various ways of managing these dependencies. In the YouTube tutorial, I simply pass the factory instance to the view classes via their constructor and this is a perfectly valid way of handling it.

There are of course other options – and Dependency Injection (DI) is especially helpful when working with the factory pattern.

Since DI hinges in principal around matching interface data-types to concrete classes, switching factory classes becomes a doddle. You simply specify the appropriate factory class to be used when the DI container encounters the factory interface and your project can be dramatically changed by essentially touching only a single line of code. This is especially true when there is a fixed, pre-determined choice of factory class, for example when repurposing an entire project for a different market or target audience.

I’d love to hear your own experiences of the Factory Pattern and OOP in general – leave a note in the comments below.

Here are some of the points covered:

• loading an XML file in Actionscript 3
• extracting particular data from the XML file
• extracting lists of tags from the XML file
• working with namespaces
• using filtering expressions

It’s all pretty straightforward once you’ve mastered the technique – come and take a look.

View the videos after the break – or simply visit our YouTube channel.

The tutorial comes in 3 parts, it’s probably best to watch them back to back. Total viewing time comes to around 14 minutes.

The videos are available in full 720p HD format on YouTube – link underneath each embedded video.

Enjoy!

Part 1 – Available in HD on YouTube

Part 2 – Available in HD on YouTube

Enjoy – and please let us know in the comments what you’d like to learn next!

I really love these topics and it’s an area that at first leaves quite a few people stumped on our Introduction to Actionscript Training Course so it seemed like an excellent candidate for another training video.

We’d also love to hear about what kind of maths causes you difficulties when writing Actionscript  - please leave a comment.

View the video after the break, along with further tips and tricks.

Although it’s not exactly glamorous, writing code to position elements on screen is perhaps one of the most common tasks for Actionscript development. Pretty much every project requires it. That’s the same whether you are developing in the Flash IDE or creating a Flex application. More often than not you’ll also be required to adjust the layout relative to the width and height of the SWF – and this is where some simple mathematics work wonders.

Take a look at the YouTube tutorial – or view it on YouTube – and then read the rest of the post for a more in-depth look at the topic.

Remember the registration point

When you write positioning code, it’s vital to consider the registration point of your display object. You’ll need slightly different calculations depending on where it is. This is because setting the x and y values moves the display object so that the registration point is positioned at those coordinates.

Note that the registration point only really comes to bear in Flash – when you’re working with external code-editors and graphics that are loaded or created with code, your registration point is generally in the top-left corner.

It’s easy to see the effect the registration point:

• Create a MovieClip from any kind of shape, place it on the stage and give it an instance name (‘mc’ will do for now).
• Write a line of code that positions the MovieClip instance at a certain location:

mc.x = 200;
mc.y = 200;

• Publish and see where the MovieClip ends up.
• Now go back into the MovieClip symbol (double-click on it on the stage) and simply move the graphics around a little. This in effect changes the registration point.
• Re-publish and compare the different positions.

Once you are aware of the importance of the registration point, everything else suddenly becomes very straightforward.

Calculating stage dimensions

To do any kind of relative positioning or centring, you’ll need to be able to retrieve the width and height of the SWF. This is straightforward via the stage object:

trace("The stage width is: ", stage.stageWidth);
trace("The stage height is: ", stage.stageHeight);

That is actually pretty easy, isn’t it?

stage.stageWidth and stage.stageHeight also work in Flex and Actionscript-only projects – but you must make sure that your code is in a DisplayObject which has already been added to the stage, otherwise you’ll get a null object exception. There are events for that kind of thing but that’s another story.

Right-aligned objects

So now you know the dimensions of the stage – how do you align an object to the right-hand edge? This is done in three easy steps – and we’ll assume that the registration point is in the top-left hand corner for now.

We’ll continue with the ‘mc’ MovieClip instance from the previous example:

mc.x = stage.stageWidth - mc.width - 10; // 10px margin

Not sure why that works? Well, either consider the little diagram below or grab a pencil and try to sketch it.

I find that visualising this scenario in my head or scribbling on a bit of paper works wonders for finding the right positioning code.

Centring

Never mind writing Actionscript – finding the right spelling for that word was a whole different ball-game! If you’re reading this from the USA, you might prefer “Centering”…

Anyway, one of the most frequent positioning tasks is to centre objects either relative to one another or relative to the entire SWF. The same techniques we used for relative positioning above also work here!

Centring with a top-left registration point looks like this:

mc.x = ( stage.stageWidth - mc.width ) / 2;
mc.y = ( stage.stageHeight - mc.height ) / 2;

Not sure how it works? Again, scribble on a piece of paper or consider the following diagram:

Centring with a middle registration point looks like this. It’s a little more straightforward, so if you know the object will be centred, you can choose your registration point accordingly.

mc.x = stage.stageWidth / 2;
mc.y = stage.stageHeight / 2;

And, finally, if you need to centre one object relative to another, you can use exactly the same technique – just replace the stage object with another MovieClip!

mc.x = otherMc.x + ( otherMc.width - mc.width ) / 2;
mc.y = otherMc.y + ( otherMc.height - mc.height ) / 2;

And, as a final little twist, if you need to ensure that the resulting position will always sit on a full pixel, you can simply round the result:

mc.x = otherMc.x + Math.round( ( otherMc.width - mc.width ) / 2 );
mc.y = otherMc.y + Math.round( ( otherMc.height - mc.height ) / 2 );

No more diagrams for this one – hopefully you’ll have worked it out by now!

Conclusion

These techniques should give you all the tools you need to create a wide range of dynamically calculated layouts. I can’t stress enough how much easier it is if you work everything out on paper first – I’ve even been known to cut little squares out and move them around to see the effect it has.

Still not sure what it’s all about? Leave a comment and I’ll try to help.

There’s more coming soon, happy coding in the meantime!

The video covers essential Actionscript 3 skills, such as external classes, event listeners and of course drag and drop and uses object-oriented techniques.

View the videos after the break – or simply visit our YouTube channel.

The tutorial comes in 3 parts, it’s probably best to watch them back to back. Total viewing time comes to around 24 minutes.

The videos are actually available in full 720p HD format on YouTube – link underneath each embedded video.

Enjoy!

Part 1 – Available in HD on YouTube

Part 2 – Available in HD on YouTube

Part 3 – Available in HD on YouTube