AS3

AS3 — No Comments
24
Jan 12

SmoothBitmap – How to enforce pixel smoothing on a Bitmap

A common oversight when using Bitmaps with loaded content is that Flash will revert a Bitmap’s smoothing parameter to false when you replace its bitmapData. It’s simple enough to fix, but since you may not know if someone is going to replace the bitmapData of a Bitmap you have created – then it’s often better to code defensively around it.

This little SmoothBitmap class is for just such an occassion. Instantiate it like a regular Bitmap and, no matter what another developer does with it, smooth pixels when scaling/rotating will be ensured.

AS3 / Testing — No Comments
10
Jan 12

Object pooling utility updated

Having just got back from an awesome break in Thailand and Taiwan, I just updated my object pooling utility. Thanks to Ostra Ceruzka for raising an issue with its strict mode functionality with me – all fixed now! Serves me right for not writing enough tests, huh?

AS3 — No Comments
31
Aug 11

TextField.getRawText() what it does

I was recently creating an API that required extending TextField and happened across the getRawText() method. I assumed this returned the text from the field without formatting or something – so I looked up the AS3 docs for flash.text.TextField.

Nothing there – gee thanks Adobe. A quick search turned up this which, it turns out, isn’t quite accurate.

So, with a tad of testing, it appears that getRawText() returns the text, stripped of any HTML tags (if you had set htmlText). I now wonder if this is faster than using a RegEx to strip the tags and why Adobe didn’t document it?

AS3 — No Comments
29
Aug 11

Loan Shark – fast object pooling

Loan Shark AS3 object pooling utilityA couple of years ago, I created an AS3 object pooling utility for a games project I was building. Since then, I've used it quite a few times, in order to speed up apps and improve resource management, easing the load on the garbage collector by reusing objects instead of recreating them.

While object pooling isn't a magic bullet to speed up every use case, it works especially well with custom classes that are heavy to continually contruct and destroy. A good example is my History of the World project, which uses an object pool for item renderers, instead of creating and destroying them as you navigate around - press ALT+CTRL to bring up the resource debugger, which shows a little information on its usage.

I recently updated the utility, improving its performance, adding features and putting loads of unit tests around it. It's now hosted it over at GoogleCode. Using it is a simple as:

import org.kissmyas.utils.loanshark.LoanShark;

var pool:LoanShark = new LoanShark(SomeClass);
var someInstance:SomeClass = pool.borrowObject();
someInstance.doStuff();

// Instead of nullifying an object, check it back into the pool
pool.returnObject(someInstance);

Apps / AS3 — No Comments
9
Aug 11

How the hell do I build this?

I had a conversation yesterday with a friend and colleague about how his company should standardise their development environment for all Flashers - be they contract or perm, junior to senior.

He, like many of us, was sick of contractors building projects and leaving them in various states of repair. Required libraries or fonts are often missing, bits of code never even get checked into source control and, frustratingly, it is often unclear how to build a project. The makeup of Flash projects can vary from an FLA file/s full of timeline based code, to source code set up to compile under one specific, mystery environment.

The problem:
You need to set some kind of reasonable standards, so that ActionScript projects can be easily verified, maintained and recompiled, not necessarily by someone with intimate knowledge of the OS, environment and the project - ideally even a developer without intimate knowledge of ActionScript or a copy of Flash CS5 and Flash Builder to hand.

The solution/s:
There are obviously many ways to skin this cat. But, the way I see it, the best solution needs also to be reasonable, achievable by everyone and cost-effective for a typical digital agency. As such, the 'best' solution may not be the 'ideal' solution - by which, I mean an idealistic solution based purely on software development 'ideals'.

Flash IDE
We have to start somewhere and, at the risk of a flaming, I'll act as its advocate for a bit. There will often be a need for those FLA files knocking around and you won't get designers building their banner's with the Flex SDK. However, since the Flash IDE isn't free, open source, understood by non Flashers and (with the exception of CS5) creates nasty binary balls of mud (namely FLA files), we'll assume from here on in that we're talking about compiling project with the Flex SDK.

Flash Builder
Adobe's own latest development environment for Flash/Flex, built on the very popular and mature Eclipse is certainly feature-packed and already industry standard. But is it the sanest choice to enforce that everyone use this particular environment, just so projects are more maintainable? Will it work and, since it's not free software, is it even cost-effective? Personally, I think perhaps not. Since Flash Builder isn't free, requiring its use for all Flash projects within a company will probably solve one problem and create all new ones.

FlashDevelop
FlashDevelop is my favoured editor and, without getting into the FDT vs FlashDevelop vs Flash Builder debate - I favour it primarily because, whereever I work, I can always get IT to install a copy on my machine, without having to wait for budget approval, bring my laptop instead, etc. However, FlashDevelop is currently for Windows only and is still just one development environment. Even though it's free and open source, we want to abstract away a project's configuration and setup from any software that isn't also cross-platform and industry standard.

Maven
So why not enforce that everyone builds and configures their projects so that they can compile under Maven from a POM? I think it's a little unrealistic to expect every calibre of ActionScripter to even know what Maven is. At very least, it would create a rather high barrier to entry for prospective developers, making recruitment even more difficult for any company. I agree that it's a bonus for many, larger projects that may need to pull in dependencies from other projects.

Ant
Ant is a cross-platform solution for software automation, built on Java. Since it's open source, free, industry standard and pretty easy to set up and use, I'd say its the best choice for configuring the building of projects in a standardised way, without tying anyone to a particular code editor, platform or requiring expensive any software.

Ant can be integrated into most development environments and provides a sensible 'how the hell am I supposed to build this?' answer to any project. This also means that, for those people that use it, the Ant script can be used for building with Maven/Hudson, for automatically ensuring all projects will build - even if you only use this to ensure a contractor has left the project in a buildable state.

I also found this helpful article on integrating Ant with FlashDevelop - so if you like that free, open-source feeling, then take a look.

AS3 — No Comments
7
Aug 11

Fastest way to add multiple elements to an Array / Vector

In a simple situation, where you wish to add many elements to an Array or Vector, you might just do:

var input:Array;
var output:Array;
while (input.length)
    output.push(input.shift());

However, the sizes of both Arrays are manipulated for each loop, which will have an adverse impact on speed and memory usage. So, we could cache the length of the input Array and not manipulate it:

var input:Array;
var output:Array;
var inputLength:uint = input.length;
for (var i:int = 0; i <inputLength; i++)
    output.push(input[i]);

But we're still growing the size of the output Array incrementally, which is very bad. Since we know input.length in advance, we could grow the output Array to its new size just once, before the loop:

var input:Array;
var inputLength:uint = input.length;
var output:Array;
var outputLength:uint = output.length;
var newOutputLength:uint = outputLength + inputLength;
output.length = newOutputLength;
for (var i:int = 0; i <inputLength; i++)
    output[i + outputLength] = input[i]);

This is OK, but still involves a loop. If only we could push multiple elements into the push method in one go. Well, we can - enter the apply method. Since Array.push accepts multiple arguments (something rarely used) and apply allows us to pass an Array of arguments to any Function, one line and we're done:

var input:Array;
var output:Array;
output.push.apply(null, input);

This works out faster and more memory efficient than the other methods. It works nicely for Vectors, too. If anyone has a faster method of doing this, do let me know.

AS3 — No Comments
10
Jul 11

SWFIdle – simple flash idling utility

I created this simple utility, called SWFIdle, to enable the Flash Player to lower its CPU usage while the user is not interacting with it. Since it's possible to have multiple Flash instances embedded in one page (for example, a game and a couple of banners), I recommend that everyone uses this in their projects, so that SWFs needn't fight for CPU and give Flash a bad name.

AS3 / Testing — No Comments
9
Jul 11

Dependency Injection by Extension pattern

Since I'm not sure whether I have indeed invented a new design pattern here. So, alternative titles for this post include:

  • Dependency Injection without a Dependency Injection framework
  • Why misuse of the default namespace for tests is pure evil
  • How to make your code more testable without completely messing it up

The problem:
You need to use some kind of Dependency Injection (DI for short) to provision some System Under Test (SUT for short) in tests you're writing, but can't or don't want to use a DI framework to do so.

Of course, the simplest form of DI is simply passing things to a constructor. But you probably don't want to code every class to be handed every dependency at construction. And you definitely don't want to expose the private parts of your implementation through some unnecessary interface. No, you really don't!

I've seen scary examples of what I call 'keyhole surgery' on classes, either by abuse of the internal namespace to allow poking into otherwise private implementation, or just by making too many things public. Although the internal namespace (AKA the default namespace) is perceived to retain a sufficient level of encapsulation, it really doesn't. Anything in the same package can jump all over it, so it's somewhat of a loose interface. As such, you should never leave methods unscoped, letting them default to the internal namespace. You should also reserve the internal namespace only for when you are in control of all classes that will exist in the same package, such as when creating utility classes.

Loose interfaces are bad practice for a few reasons:

  • Clarity - anyone using the class will be confused as to the intentions of its interface
  • Stability - a class with such a loose interface is open to misuse and a recipe for failure
  • Cleanliness - code for tests does not belong in your production code
  • Testability - you should test a class through its interface, not its implementation
  • Flexibility - it is hard to refactor classes that leak implementation detail in such a way

The solution:
Well, this is one possible solution and ultimately just my suggestion. It's especially useful when needing to refactor classes with overuse of the internal namespace, since you won't need to change much test or production code. I call it the Dependency Injection by Extension pattern.

How it works:
You provide DI helpers as protected methods in your SUT and subclass it from within your test case, as a script-level class, to expose the DI helpers as public and/or use the constructor to do some of the DI work - allowing you to inject mocked dependencies for your tests. This has the advantage of not allowing anything else to meddle with your SUT, other than through its interface, of course. And, if anything in your production code wishes to extend your SUT, potentially overriding and messing up the interface, then that class should have its own tests anyway.

Example:
The following example shows a very basic class (SystemUnderTest) being extended from within its testcase (SomeTest) to allow injection and access to its dependencies, for the purpose of verifying its behaviour under given conditions.

class SystemUnderTest
{
    protected var someDependency : Dependency;
    private var _someThing : Thing;

    public function SystemUnderTest()
    {
        someDependency = new Dependency();
        _someThing = new Thing();
    }

    public function doSomething() : void
    {
        _someThing.callSomething( someDependency.getSomething() );
    }

    protected function get someThing() : Thing
    {
        return _someThing;
    }
}

package
{
    public class SomeTest
    {
        private var sut : SystemUnderTestWithDI;
        private var someThing : Thing;
        private var mockDependency : Dependency;

        public function setUp()
        {
            mockDependency = mock(Dependency);
            sut = new SystemUnderTestWithDI(mockDependency);
            someThing = sut._someThing;
        }

        [Test]
        public function testSomething():void
        {
            var testValue : String = 'foo';
            given( mockDependency.getSomething() ).willReturn( testValue );

            sut.doSomething();

            verify().that( someThing.callSomething( eq(testValue) ) );
        }
    }
}

class SystemUnderTestWithDI extends SystemUnderTest
{
    public function SystemUnderTestWithDI(dependency : Dependency)
    {
        super();
        someDependency = dependency;
    }

    public function get _someThing() : Thing
    {
        return someThing;
    }
}

← Older Entries