Joa Ebert discussed this in his presentation at Flash on the Beach. I already use specific object pooling in Flint particles, but while Joa was talking I had an idea and wrote a class for generic object pooling of all object types. I finally had time to test the class, and it works as expected, so I’ve added it to my open code repository.

The object pool class manages pooling of all objects through two simple methods. You can obtain an object from it like this

var obj:SomeClass = ObjectPool.getObject( SomeClass );

If there are any such objects in the pool, one of them will be returned. If there are no such objects in the pool, a new one will be created and returned to you.

When you no longer need an object, you can add it to the pool for later reuse like this

ObjectPool.disposeObject( obj );

The object doesn’t have to have been created through the pool – any object can be dropped into the pool with the disposeObject method.

The source code is available in my GitHub code repository.

Download the source code

The source code is in two parts – an engine, which does the game part, and a sample game that uses the engine. Have fun.

The code is in a single class called RadialPerlin, used like this

var perlin:RadialPerlin = new RadialPerlin( 100, 3, 
        Math.random() * 100000, false, 15, false, true );
perlin.draw( 0, 0 );
var bmp:Bitmap = new Bitmap( perlin.bitmapData );
addChild( bmp );

Download the RadialPerlin class and demo.

The RadialPerlin object is initialised with some values (details of the parameters are in the class file) then drawn into a BitmapData object using its draw method. The draw method takes a couple of offset parameters – one for the distance from the centre and the other for the rotation. You can then grab the BitmapData object from the RadialPerlin object via its bitmapData property and do what you like with it.

The code is licenced under the MIT license. Have fun, and if you make something interesting with it let me know.

No data is entirely secure, and if anyone else has access to your webserver (the company managing the server for you?) or your database (the company storing the backups?) then you don’t have total control over the security anyway. So there’s always a chance your database could be stolen. So, the simple rule is to hash your passwords.

Hashing

A hash is a string derived from the original password via a one-way algorithm. In other words, it’s easy to create the hash from the original, but harder (when used for security, ideally impossible) to create the original from the hash. You store the hash in the database, and when the user signs-in you hash the password they sign-in with and compare it to the hash in the database. Something like this

if( $user->passwordhash == sha1( $_POST['password'] ) )

That way, you never store the user’s password.

There are a number of hashing algorithms in PHP, of which md5 and sha1 are the most commonly used. Unfortunately, neither is as secure as they were once thought to be. It would be better to use a more secure hash, and if you have the Hash engine in your PHP installation (included by default since PHP 5.1.2) then you have access to many more algorithms. So a better example would be

if( $user->passwordhash == hash( 'whirlpool', $_POST['password'] ) )

Rainbow tables

But there’s another problem. Once your database is stolen, the thief has plenty of time to crack the passwords using a simple Rainbow Table attack. This involves creating a large selection of hashes based on likely passwords (e.g. every word in the dictionary) and then comparing the hashes with the hashes in your database. Within an hour or so, half the passwords in your database will probably have been cracked.

To prevent this you should salt each password by adding a random string to it (called a salt or nonce). The time consuming part of a rainbow table attack is building the dictionary of hashes. Adding a random salt to the password means the thief has to build a whole new dictionary of hashes for each salt, making a rainbow table attack too time consuming to be viable. Each password should have a different salt, and the salt doesn’t even need to be secret.

The Code bit

So, for secure passwords you need code that looks something like this

// get a new salt - 8 hexadecimal characters long
// current PHP installations should not exceed 8 characters
// on dechex( mt_rand() )
// but we future proof it anyway with substr()
function getPasswordSalt()
{
    return substr( str_pad( dechex( mt_rand() ), 8, '0',
                                           STR_PAD_LEFT ), -8 );
}

// calculate the hash from a salt and a password
function getPasswordHash( $salt, $password )
{
    return $salt . ( hash( 'whirlpool', $salt . $password ) );
}

// compare a password to a hash
function comparePassword( $password, $hash )
{
    $salt = substr( $hash, 0, 8 );
    return $hash == getPasswordHash( $salt, $password );
}

// get a new hash for a password
$hash = getPasswordHash( getPasswordSalt(), $password );

You don’t have to attach the salt to the hash, you can instead store them separately within the database, but I like keeping them together in a single string. Equally, the salt needn’t be in hexadecimal, but I like the symmetry with the hexadecimal hash.

Finally, as Thomas Ptacek points out, you don’t want the fastest hash algorithm in the world for this – a fast algorithm is more useful to an attacker than it is to you.

In Actionscript 2 this was a simple matter of calling Key.isDown() with the appropriate key code. But in Actionscript 3 Key.isDown no longer exists and the only intrinsic way to react to the keyboard is via the key up and key down events.

To rectify this I created the KeyPoll class, which has isDown and isUp methods, each taking a key code as a parameter and returning a Boolean. The class is in my GitHub code repository.

Using the class looks like this

package
{
  import flash.display.Sprite;
  import flash.events.Event;
  import flash.ui.Keyboard;
  import net.richardlord.input.KeyPoll;

  public class Test extends Sprite {
    var key:KeyPoll;

    public function Test() {
      key = new KeyPoll( this.stage );
      addEventListener( Event.ENTER_FRAME, enterFrame );
    }

    public function enterFrame( ev:Event ):void {
      if( key.isDown( Keyboard.LEFT ) ) {
        trace( "left down" );
      }
      if( key.isDown( Keyboard.RIGHT ) ) {
        trace( "right down" );
      }
    }
  }
}

The constructor for the KeyPoll class takes a single parameter which is a DisplayObject on which the KeyPoll object should listen to keyboard events. To listen globally to all keyboard input this should be the stage, as in the example.

The class uses a ByteArray to hold the current keyboard state, which is updated in response to Keyboard events and queried by the public methods, isDown and isUp. Using a ByteArray is more compact than using an Array of Booleans, and in tests it also turned out to be marginally faster, although the difference in speed was not significant enough to matter.

Further, the class clears the key state array when the deactivate event occurs, so key state is not retained if the Flash Player loses focus and stops receiving keyboard input.

Basically it implements almost all the features in the Actionscript 3 event model, but with all the functionallity contained within the event class itself. This way events are identified as properties of the object rather than by Strings (or by static properties containing those strings).

A simple example of its use would be this clicked event

package
{
   import bigroom.BrEvent;
   import flash.display.*;
   import flash.events.MouseEvent;
   
   class Listenable extends Sprite
   {
      public var clicked:BrEvent;
      
      public function Listenable() {
         clicked = new BrEvent( this );
         graphics.beginFill( 0xFF0000 );
         graphics.drawCircle( 50, 50, 50 );
         addEventListener( MouseEvent.MOUSE_DOWN, mouseListener );
      }
      
      public function mouseListener( ev:MouseEvent ):void {
         clicked.notify();
      }
   }
}

package
{
   import flash.display.*;
   
   public class Test extends Sprite
   {
      public function Test() {
         var listen:Listenable = new Listenable();
         addChild( listen );
         listen.clicked.addListener( doClick );
      }
      
      public function doClick( ev:BrEvent ):void {
         trace( "clicked" );
      }
   }
}

Download the BrEvent classes.

I first tried to implement this using entirely custom code, and everything worked fine except the weak references. I used the weak references as described in this post, and came across the problem described here. This implementation is BrEvent1 in the download. It’s great if you don’t use the weak references, and interesting anyway.

So then I implemented it utilising the existing Event and EventDispatcher classes and that works fine. This implementation is BrEvent2 in the download. There’s a couple of redundant methods calling methods in the super class but they’re there to make the point about the overriden methods.

The one feature of the Actionscript 3 event model this class doesn’t implement is the capture and bubbling phases of events on display objects. The reason is, it’s not clear what events should be called in the various display objects up the chain. Unless I somehow hack the chosen events into the DisplayObject class itself, the events will only exists on selected display objects. So I didn’t implement this.

Having done this, I still don’t expect to use it. Although I prefer it to the built-in event handling in Actionscript 3, the built in event handling is good enough so I will use that for consistency.

So it was really just a short learning experience. It didn’t take long and I got to play meaninglessly with Actionscript for a morning. If you have any suggestions or you find the class(es) useful, let me know below.

Also, if you can think of a better name, let me know that too. I wanted to simply call the class Event but that would be too confusing with the built-in Event class.

package
{
   import flash.display.*;
   import flash.utils.Dictionary;
   import flash.events.MouseEvent;
   
   public class Test extends Sprite
   {
      private var dic:Dictionary;
      private var store:Function;
      
      public function Test() {
         var listen:Sprite = new Sprite();
         listen.graphics.beginFill( 0xFF0000 );
         listen.graphics.drawCircle( 50, 50, 50 );
         addChild( listen );

         dic = new Dictionary( true );
         dic[inDictionary] = 1;
         dic[inDictionaryAndProperty] = 1;
         store = inDictionaryAndProperty;
         
         listen.addEventListener( MouseEvent.CLICK, doClick );
         listen.addEventListener( MouseEvent.CLICK, 
                             inEventListeners, false, 0, true );
      }
        
      public function doClick( ev:MouseEvent ):void {
         for( var fn:Object in dic ) {
            fn( ev );
         }
      }

      public function inDictionary( ev:MouseEvent ):void {
         trace( "method in dictionary" );
      }

      public function inDictionaryAndProperty( ev:MouseEvent ):void {
         trace( "method in dictionary and property" );
      }
        
      public function inEventListeners( ev:MouseEvent ):void {
         trace( "method in event listeners" );
      }
   }
}

The output is

method in dictionary and property
method in event listeners

The EventDispatcher retains the weak reference to the method closure (inEventListeners) because the object it’s bound to still exists. It will drop its reference to the method closure when the bound object no longer exists.

The Dictionary, however, doesn’t retain the weak reference to the method closure (inDictionary), despite the fact that the method still exists (it exists in the class) and the object it is bound to still exists.

If, however, you have another, strong, reference to the same method closure (inDictionaryAndProperty), then it isn’t garbage collected and the Dictionary retains its reference to it.

So the EventDispatcher and Dictionary treat weak references to method closures differently.

It seems to me that the Dictionary takes a purist view – it holds the only reference to the method closure so it can be garbage collected – while the EventDispatcher takes a practical view – the method and the bound object both exist so the method closure should be retained.

Why the difference? I’d love to know.

var weak:WeakRef = new WeakRef( someObject );

Well, there is a way. It’s a bit of a hack, and unfortunately uses a full Dictionary object for each weak reference, but it works. The source code is on my public GitHub repository.

To use the class

// Create a weak reference
var weak:Weakref = new WeakRef( obj );

// Later use the referenced object
var strong = weak.get();
if( strong != null )
{
    // use strong here
}
else
{
    // garbage collector has disposed of the object
}

If the get method returns null then the object has been garbage collected.

The source is free under the terms of the MIT licence.

• Both are mixins, with all the disadvantages that entails.
• Both require the listening object to define functions with specific names in order to handle the events.
• With ASBroadcaster, all events are broadcast to all listeners. There is no way for the listener to select only specific events to listen too.
• With EventDispatcher, events must be specified by name as a String, which means there is no compile time checking that the event exists.

So a couple of years ago I devised a new option. This technique uses a single Event class. You set-up events on an object by creating a public property that is an Event. Other objects may then listen to this event and the object dispatches the event when it wishes. For example

import BigRoom.Event; class SimpleButton { public var click:Event; public function SimpleButton() { click = new Event(); } public function onRelease():Void { click.notify( this ); } }

The notify call dispatches the event to all the listeners along with any parameters passed to the notify method. Listeners subscribe to the event via a call to the addListener method of the event, as in the following example

class ButtonListener { public function ButtonListener( btn:SimpleButton ) { btn.click.addlistener( this, buttonClick ); } public function buttonClick( obj:SimpleButton ):Void { // do something here… } }

No mixins, no Strings, no fixed method names, and listeners subscribe to receive specific events. The technique isn’t without its flaws, but I consider it far better than ASBroadcaster or EventDispatcher.

Download the Event class.