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.

I set up our simple FMS application, which merely streams video from a three-directory-deep file structure. This means our Flash front end must,
a. connect to an instance of the application, say: rtmp://mydomain.com/myApp/_definst_
b. request the stream of an FLV resource, such as:
flv:ab/cd/ef/vwxyz.

Note the explicit use of the default application instance _definst_, and also the odd reshuffling of the FLV path. This is how you’re supposed to do it [apparently] and it worked just fine. Hoorah.

After running some successful tests with a simple front end using NetConnection, I am told that our Flash front end (actually Flex) will be using a skinned FLVPlayback component. This component doesn’t ask you to split the resource into these two pieces; it takes a single, complete stream URL. The above example would mean passing in: rtmp://mydomain.com/myApp/_definst_/ab/cd/ef/vwxyz.flv
Note we still keep the instance name, and the flv extension is optional.
This worked just fine on our dev server, and when we deployed to a live server it seemed to be ok too. Hoorah x 2!

Anyhow, I’ll get to the “but”.

After gong live, we received reports of videos not playing, and were unable to replicate the problem at will. Eventually I noticed in the log files that FMS was throwing 404s. On closer inspection, the 404s were for resources prefixed with our application instance name _definst_. The successful 200 responses were requested correctly as ab/cd/ef/vwxyz, but the failures were referenced as _definst_/ab/cd/ef/vwxyz. Most alarmingly these were sometimes for the same resources, and even from the same client.

It looks like under certain [unknown] circumstances, the application and the resource are not getting correctly split out of the full URL. I do not know at what point this error creeps in. I also don’t know what FLVPlayback does internally to make the stream request from the full URL you pass in. All I know is that the error appears arbitrarily, and has proved impossible to raise on purpose. Possibly a bug in FLVPlayback, or a bug in Flash Media Server?

Solution

A real solution I have not found, so I did a very dirty hack.
As I have failed to avoid the 404s, I turned the bad paths into valid paths by sym-linking the FLV directory back to itself with the name _definst_, as follows:

cd /path/to/flvs
ln -s . _definst_

Job done, but I’m not happy about it. Anyone able to offer a real solution, please post a comment!

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.

You can see the South Park Down and Dirty application in action here. This link is my public Down and Dirty profile and does not require you to add the app, although you can add it here in the usual fashion.

Pick up Campaign or some such publication and no doubt you’ll be able to read all about the strategy, the creative, the design, even the metrics. Less likely you’ll read about the technical execution, which is where I come in…

I joined the team once the creative and design had been signed off, and from that point I was sole developer on the project. This meant developing the back end, (PHP/MySQL), and front end (FBML/CSS) and quite a bit of non-trivial Flash content (AS2). The total development time from briefing to launch was 13 days – 13 long, hard days.

This project threw up some interesting technical points worth mentioning. If you are interested in any of these topics, let me know and I’ll write a more in depth article on each;

First up was the seemingly trivial problem of linking to parts of the app from within Flash content. Something even the least technical Flashers have been doing for years. However, this was until Adobe implemented this security feature in the Flash Player. This led me to implement all Flash content across the app within iframes, as opposed to using Facebook’s fb:swf tag.

The good old Flash security model came into play on this project too. Loading images directly from Facebook’s servers into a third party Flash app is not a problem if all you want to do is display the image. This is all I needed to do in my first ever Facebook app FBPlayer. This can be achieved simply with the MovieClipLoader, but as advanced Flashers will know, if you want to do anything remotely cool you need to use the wonderful BitmapData class. Take note: an image that has been loaded into Flash from outside your sandbox is subject to the same security lockdown as an external SWF. In a nutshell – it is not scriptable! Therefore BitmapData.draw() does not work on the image data. The obvious solution is an image proxy. Not difficult in the least and one has to wonder what the point in this security feature really is when it is so easily circumvented with a perfectly legitimate technique. The image proxy I implemented in PHP was about 12 lines long [excluding library code], and took all of 5 minutes to write and test.

Another surprise was related to Facebook privacy. Accessing friends’ photo albums via the API was yielding empty results in some cases – It transpires that plenty of punters are aware they can block applications from accessing their data. This is obviously not the default setting, but as more people become aware of these capabilities the functionality of apps like Chin Balls become more restricted because users’ friends have to be more willing participants. Although I support this approach in sentiment, it unfortunately increases applications’ need to persuade people to add in order to function, which makes apps more irritating and ‘spammy‘.

This does not necessarily mean you must add an application to interact with it at all. A little known fact [it seems] is that a Facebook canvas page is viewable by anyone logged into a Facebook account. The only reason you see immediate ‘add application‘ prompts is that the app authors are being pushy and lazy. The South Park app has a public profile page where you can see the same content that I can see. You do not need to add the app to see my profile. – Why? - Because this functionality does not require the app to know who you are. In fact it cannot know even your user id until you authorize it. When you view this page the app is using my authorization for you to see the content. Why not give new users an experience up front and let them decide if thy like the app before being coerced into adding it? There are privacy issues at stake here too of course, but I am blithering on enough as it is. Let me know your thoughts!