I effectively gave up Flash when I came to Public and it’s now a whole year since I did any significant Flash work. In this short time AS3 has really come of age, there are tonnes of serious libraries, from fractals to physics, and PaperVision 3D seems almost omnipresent. The prospect of going back to the ActionScript freelance circuit after a year on the wagon would be quite daunting.

The reasons I’ve done little Flash since I’ve been at Public are perfectly sound: I work with two brilliant Flash developers who make up 50% of our development team, and rather than everyone doing a bit of everything, we all specialize quite specifically. I cover all the back end work, and do a lot of server admin; so ActionScript in my personal world is now just a fond legacy of my freelance career.

ActionScript is still of great interest to me – JASPA is closely modelled on AS3, and at Public Flash makes up the majority of our projects, so I obviously stay up to date on its progress. But I’ve spent so many hours writing ActionScript that it seems a shame I won’t be so directly involved in its future. I started using Flash in version 3 and so I’ve seen ActionScript develop from nothing in real time. I remember when Flash 5 came out and we could finally write real code. I made a concious decision there and then to ditch Lingo, because it was starting to become obvious that Flash had a brighter future on the web. This turned out to be a very good decision.

As usual with my blog posts I feel I need to write some kind of conclusion (recalls GCSE English lessons), but I don’t have one; except I miss Flash, it’s awesome. The end.

Write robust object-orientated applications in a strongly-typed language (modelled on AS3) and compile it into regular JavaScript to run in a web page, or any other environment that implements a JavaScript engine.

Download JASPA from SourceForge
https://sourceforge.net/project/showfiles.php?group_id=243463

The JASPA project is split into two main components:

1. The compiler
2. The cross-browser abstraction API

1. The compiler

The compiler is API-neutral; Its job is to compile object-orientated code written in the JAS syntax, and convert it to regular, clean JavaScript suitable for running in any ECMAScript-compliant host program, such as a web browser. The compiler comes in two flavours: A command line compiler, which is the most useful; and also a web-based compiler which is handy in development and testing, or when a command line is not available.

The compiler is largely complete, but there is still some work to do to support some outstanding language features.

 2. The cross-browser abstraction API

If you want to build web applications with JASPA, the compiler needs to know about all the objects and methods exposed by the browser. This is easily achieved by writing native class interfaces, much like intrinsic classes in ActionScript. However, browser scripting today poses the same huge problem that it did 10 years ago; Vendors don’t all provide the same API. Hence a comprehensive abstraction layer is required to provide a single, standardized interface that works across all modern browsers.

Although the JASPA compiler is largely complete and pretty stable, work on this API is still very much in progress.
More about all of these topics will be organized into further blogs. In the mean time, please have a go with the compiler and let me know what you think of it.

So in this spirit of pedanticalness I’ve been playing around with the various changes to the null, and undefined types in AS3 and how they relate to the new concept of untyped objects. Having been writing JavaScript and ActionScript for years these notions are taking some getting used to. That’s fine, but I have noticed some nuances that I’m not happy with.

I’m fine with the notion that a typed object cannot contain the value undefined. It makes sense that it should adopt a native value of its own. I do find it strange though that a Number defaults to NaN, whereas int, and uint default to 0, but I think I’ll just about sleep at night.

I also find it odd that some typed objects may be set to null, while some cannot. (var s:String = null;) holds null and is still a String, and yet: (var n:Number = null;) raises an error. Although I don’t really get this, being aware of it is the important thing when it comes to avoiding bugs.

Here are some more weird things I discovered today:
Setting a Number to null via a function call prevents the error you get when setting it directly.

1. function getNull():* { 
2.     return null; 
3. } 
4. trace( getNull() === null); // prints ”true” 
5. var x:Number = null; // raises error 
6. var y:Number = getNull(); // no error   

Setting a Number to undefined via a void function call raises an error

1. function getUndefined():void{ 
2.     // no return value. 
3. } 
4. trace( getUndefined() === undefined ); // prints ”true” 
5. var x:Number = undefined; // sets to NaN as expected 
6. var n:Number = getUndefined(); // raises error, halts execution

Hmm..

The South Park Chin balls Flash app required that the user drag and zoom a loaded photo. Anyone who’s ever done this will know that you can’t just scale the picture around it’s registration point when you zoom. Why? because the centre point changes as you pan the image around. So the requirement in a nutshell is – to be able to scale a MovieClip around an arbitrary centre.

Sure, you could take the Russian doll approach with multiple clips inside clips, but that just ain’t cool! I thought I’d share the way I did it as it’s pretty concise.

First of all here’s the principal in action. Scaling and rotation, both performed around an arbitrary centre point that you can alter by dragging that little marker around. Go on, have a go.

[ Update: due to a nasty server crash some of these files are missing.. sorry. This source was rescued though ]

Loading example SWF…

Download the source files for this example

Most of the source files just serve to create the example interface. The only class we need to discuss is the one with the scale and rotating logic. The class VirtualCentreSprite is an extension of the Sprite class. In AS2 it would have to be an extension of the MovieClip class, but we don’t need a timeline. You could use this as a base class for sprites across your project to ensure they all have this capability.

It has two methods as follows:

void scaleAround( offsetX:Number, offsetY:Number, absScaleX:Number, absScaleY:Number )
void rotateAround( offsetX:Number, offsetY:Number, toDegrees:Number )

The scaling method is the simplest. It’s basically GCSE vector maths. We calculate the position that the clip should be at after scaling, do the scaling (which will move the clip according to the centre that Flash knows about) and then we simply reposition it to where it should be.
Click to see source of method scaleAround

The rotating method is a bit more complex, because it uses a transformation matrix. But thanks to the flash.geom package this is short and sweet. Again the principal is that we let Flash rotate the sprite and then adjust the position.
Click to see source of method rotateAround

I was quick to upgrade to AS2 when it came out in Flash MX 2004, and never looked back, so why so late? Well, as usual, because I’m busy. Busy on a PHP project at that, so I haven’t really had the chance. Plus, if I do have to write some AS on the job it’s too big a risk to start learning something new. Pressures demand that I get on with it as I know how. That’s why this Facebook application has it’s main Flash app (Chin Balls) written in AS2. Also, I view the upgrading of a programming language as a one-way process. I didn’t upgrade to PHP5 until I was confident I would never have to write PHP4 again. And with AS3 this is an even bigger deal.

I anticipated that AS3 was going to be stricter, less forgiving, and that I’d have to get used to a few things, but I have to confess to being quite surprised at how different it is. There’s so much material on AS3 available to you that there’s no point me banging on about things you can get better information on else where. However, as an AS2 developer here’s a quick list in no particular order of the things that either surprised or pleased me in my first couple of hours of AS3 writing:

• The MovieClip’s inheritance chain has 5 other classes between itself and the Object class. This abstracts out various types of functionality and means you don’t have to use a fully loaded MovieClip just to display a blob.
• Small, but caught me out – Void must be lower case as a return type, e.g. function():void{ } My bad.
• Watch out; Ctrl-t only checks syntax.
  This is more profound than it sounds. I suspect the reason that AS2 compiles the script and checks all references and types is because that’s the best chance you’ve got of catching an error. AS3 actually has the ability to do this at run time, so don’t think “This script contains no errors” means you’re in the clear!
• At last; percentage properties like alpha are now 0-1, instead of 0-100. Another design interface legacy bites the dust. – and say goodbye to underscores in property names too :)
• A new override keyword must be used to redefine a parent class method of the same name
• MovieClips do not have implicit onEnterFrame, onRelease, or any such handlers invoked by default. You have to explicitly define all event handling via the thoroughly standardized Event mechanism.
• Looking for onLoad? You won’t find it, see above;
• Declaring child clips as member variables in classes was raising conflicts with members of the same name placed physically on the stage. It took me a while to find the publish setting “Automatically declare stage instances”. If you’re used to declaring all your physical members switch this off. If you’re normally lazy, switch it on!
• No more prototype hacking. Not even if it’s 10pm and you really want to go home.

The casual and flexible nature of ActionScript has lent itself very well to the creative industries in particular over the years. In short, it gets the job done! And unfortunately that’s what this business is all about most of the time. But ActionScript has really grown up this time. Of course you can still publish Flash movies in AS2, and even AS1, but if you want to grow up too you’re going to have to get a bit more serious – again. This means more planning and less hacking. Generally you are going to spend longer doing pretty much everything.

I know plenty of creative developers who have been writing ActionScript for years and many of them eventually embraced AS2, even if a little reluctantly. AS2 was an important step in the maturing of the language, but a step that was in fact a bit of an illusion. The structure and strictness that it appears to impose is really rather superficial and the list of hacks and compiler workarounds is endless. Under the hood AS2 is pretty much the same deal as AS1. i.e. it’s JavaScript. JavaScript was purposefully designed for non-programmers. How often have you done this to create a button action:

myBtn.onRelease = function(){ /* do stuff */ }

What you are doing is creating a function object and assigning it as a property of another object. You can do this because the prototype architecture of JavaScript allows you to – a concept foreign to pretty much all class-based languages.
Well you can’t do it any more. – not in AS3.

This time around Adobe has based the language on the draft specification of ECMAScript Edition 4 (ES4). AS1 & 2 (along with most implementations of JavaScript that you’ll encounter) are based on ES3 which is nearly ten years old now. So under the hood AS3 is genuinely a different beast and a more grown up one at that.

So with the ever-stricter, and more robust stature of ActionScript, how long can this designer/developer melting pot survive? And how narrow can the margin remain between the developer and the designer? I don’t mean to suggest that designers can’t code or that coders can’t design, but there are only so many hours in the day, and only so much you can fit into one person’s job description. Perhaps the distinction of merely two roles isn’t sufficient anymore. We don’t talk about Flash development in terms of front and back ends, but perhaps we should. As the gap widens perhaps we can identify multiple roles for specialists across multiple layers of development just as we do with HTML based web apps.