We’ve given Jonathan’s website a digital lick of paint in preparation for his second solo album release. The ex-G4 star’s “Forever” is due to hit the shops on 8th October 2008.
Check out the fruits of our endeavours at www.jonathanansell.com

This is our blog. You might want to check out our website too.
We’ve given Jonathan’s website a digital lick of paint in preparation for his second solo album release. The ex-G4 star’s “Forever” is due to hit the shops on 8th October 2008.
Check out the fruits of our endeavours at www.jonathanansell.com

By default, any custom class instances that are passed to a PHP method via AMFPHP are treated as associative arrays. Correct class mapping is essential if we want our PHP files to treat arguments as instances of a particular class.
You can download the sample files for this tutorial here. An introduction to AMFPHP 1.9 and Flash/AS3 is available here.
So class mapping is the process by which AS3 classes are associated with their server-side equivalents in PHP. It is actually remarkably easy to implement, although online information for AS3 implementations is rather scarce on the ground. All we really need is the flash.net.registerClassAlias class.
First, a description of the contents of the sample zip file. There are three directories:
classes – contains the document class specified in the FLA
deploy – this is the publish directory specified in the publish settings of Application.fla
fla – contains the FLA file with ‘../classes’ added to the classpath
The files are all commented, so take a look through each one to get an idea of what’s going on. The key to successful class mapping is the registration of Flash’s PersonVo class to the “vo.PersonVO” PHP class in the Application constructor.
Here are the steps you should follow to get the sample files up and running:
Clicking the ‘Register’ button creates a PersonVO object in Flash which is populated with the contents of the TextInput instances on stage and sends this to the specified service (PersonService.registerPerson). Here’s a screenshot of the sample file once the ‘Register’ button has been clicked:

In a real world situation, the registerPerson() PHP method would process the user data, probably adding the information to a database. In this example, for the sake of simplicity, we demonstrate the fact that the passed $person parameter is of type PersonVO by referencing a property of the class instance – $person->firstname is appended with the string “(Modified by PHP)”. We can also call methods on our PersonVO object, as demonstrated by the call to incrementAge() which adds 1 to the instance’s age property. The instance is then returned by registerPerson(), resulting in the modified PersonVO object being passed back to Flash.
Once a server response is received, the Responder’s onResult() handler displays text in the ‘result’ TextArea. By casting the received object to PersonVO, we can access all the typed properties of the PHP modified object. Notice the ‘firstname’ and ‘age’ properties contain the PHP modified content.
AMFPHP has been around for a number of years but has only recently captured my interest. It’s not that I’ve had any particular reason to dismiss it, it’s more that I’ve not found any compelling reason use it – I’ve always been an advocate of loading all site data content up-front rather than continually interrupting user flow with frequent data requests, and the majority of Flash websites I’ve worked on require minimal server interaction after the initial load (perhaps some form data submission, maybe some highscore-type database transactions for a game, but that’s about it). All in all, I’ve considered AMFPHP to be unnecessary.
However, the popularity of Flash RIAs has resulted in a more dynamic exchange of information between client and server. Requests are increasingly tailored to the client state, resulting in the need for more frequent, context sensitive communications. This is where AMFPHP comes into its own, both in terms of transaction speed and coding overhead.
For those not familiar with the AMFPHP, it is a data serialisation protocol that allows objects and data types to be sent from Flash to PHP (and vice versa) whilst retaining their data typing. See www.amfphp.org for more information on its design philosophy and an example of the process in action.
The most recent version, AMFPHP 1.9, has been updated to work with AS3 and boasts additional speed increases through compression of the serialised communication. As the product is currently in beta while work continues towards the version 2 release candidate, much of the online documentation is work-in-progress awaiting update, and whilst there is a plethora of Flex based tutorials online (search for ‘amfphp 1.9 flex’) there is relatively little information regarding Flash/AS3 implementations.
This tutorial shows you how to get up and running with AMFPHP and Flash/AS3, and perform some basic server transactions. It’s really pretty straight-forward so let’s get going:
So far, so good. AMFPHP is successfully installed and our sample files show that we can pass native data types (a String instance in this case) from Flash to PHP successfully. Passing custom objects (instances of custom classes) is a bit more fiddly, but if you’re interested, you can find out more here.
A group of rather talented russian flash developers have been working hard on version 5 of the Alernativa3D engine and have now reached their first milestone.
Our kettle of cool gives this a rather fabulous 1.6 liters which when converted to cups of tea is 5 out of 5!
Swedish – it’s all Greek to me, but this viral piece for Tele2 is outstanding.

This dude… he’s such… well… a dude!
The proprietor of the Yes Bar in Berlin has taken narcissism to a new level with this panoramic website, showing his bar filled with identikit punters, all of whom look suspiciously like him. Genius! Give that man a cigar and a vigorous handshake, he rocks my world more than Rocky’s I to VI.



There’s a new Flex tutorial for beginners over at onlamp.com. They rarely cover Flash/Flex (which is fair enough given that it’s a LAMP-based site), but the article is well written and serves as a nice little introduction to the technology.
Poo: love it or hate it, you’re sure to release it now and then. If you’re a big fan of poo you’re sure to enjoy Poo Warrior, the incredibly odd poo-themed Flash game. It’s arguably the best poo game on the ‘net, although Catch a Shit is a strong contender.


Monkey Kick Off features both a monkey and a football – genius! Try and use your primate soccer skills to beat the Include Digital personal best by clicking here.

Adobe’s Mike Chambers has released more information on his blog about the forthcoming alpha release of Apollo.
Now, call me sceptical, but I’m finding it very hard to be enthused about Apollo. A downloadable runtime that allows programmers to leverage existing skills to develop RIAs sounds jolly exciting on paper, but, in reality, I expect this product to be another white elephant like Generator or Flex*.
* What??!! You don’t agree that Flex is a dud? Just look at Adobe’s Site of the Day entries for Flex. The Monfort College of Business Virtual Tour is particularly bad, embodying everything that is irritating about the web. If Flex doesn’t go the way of Generator within two years I’ll eat my hat: a bold statement, given that my headgear of choice happens to be a 4ft wide sombrero made of lead.
UPDATE
Rumours from MacRumors‘ forums suggest that the Safari browser on Apple’s forthcoming iPhone will have both Flash and Java plugins installed.
More developer-focused information on the iPhone is available at slashdot.org.
Feeling short on festive spirit? Why not play our new viral game Santa Sorter at santasorter.com!
Whilst working on a Flash website recently, I was surprised to note that all Javascript-executed new window commands were being caught by my browser’s pop-up blocker. This happened in both Firefox 2.0 and Internet Explorer 6 (I’ve so far resisted Microsoft’s attempts to force IE7 on me, although I don’t think I can hold out for long).
I’ve always used the Flash-calls-javascript-function-on-HTML-page approach before. Here’s an example of the code I might use to assign the getURL() event to my button click in Flash:
myBtn.onPress = function() {
getURL("javascript:openNewWindow('http:www.bbc.co.uk', 'bbc', 'width=400,height=200')");
}
where openNewWindow() is a Javascript function defined in the holding HTML page which simply calls the open() method of the document.window object.
Logically, I thought this approach would work, as the Javascript function is being executed as a result of user-interaction. However, this proved not to be the case, despite the fact that other sites that seemingly deploying the same solution successfully circumnavigated my over-zealous pop-up blockers.
Macromedia (ok, Adobe – some habits die hard…) themselves seemed also to advocate this as a valid approach. Where was I going wrong?
Eventually I downloaded the sample files (availabled for Mac or PC) and examined the code – all three lines of it! There was only one difference – the assignment of the getURL() method to the onRelease() event, rather than the onPress() event in my example above. Unconvinced this would make a difference, I duly updated my code so as to eliminate the possibility and guess what? It worked! My pop-ups were now being allowed to open.
There doesn’t seem to be much in the way of online documentation for this phenomenon. Brian’s post over at Midwest Macromedia Studio Users Group comes near the mark, but rather than the method of assigning the event to the button, it is actually the event type itself that plays the significant role in deciding whether a blocker will be triggered or not. onPress() events will always trigger a pop-up blocker while onRelease() events escape undetected.
So given that I’m happy to use an onRelease() event rather than on onPress() event, is everything now rosy? Unfortunately not. I also needed to include links opened in new windows using inline anchor tags within HTML formatted textfields. Here’s an example of how the code would be assigned to the textfield:
myTf.htmlText = 'Click <a target="_blank" xhref="http://www.bbc.co.uk/" mce_href="http://www.bbc.co.uk/">here</a> to view';
This will invariably result in the new window being blocked.
If anyone has a workaround for this, please let me know!
Adobe have updated Flash Player 9 to support full-screen playback in both the standalone and browser-based players.
Full-screen playback is subject to a number of security restrictions: keyboard entry is disabled when this mode is active, presumably to prevent covert logging using transparent Flash content. Thankfully, full-screen mode can only be initiated by user interaction.
This new feature is bound to be popular on sites hosting video content – YouTube and its many imitators are sure to make use of this feature in the coming months.
More information is available over at Adobe Labs.
For a recent project, I needed to make a call to a Flash function from a link in the HTML page in which it was embedded. In the past I’ve done this many times but, as circumstance would have it, not for a couple of years or so. To refresh my distinctly blurred recollection of the methodology, I decided to consult Google.
I quickly found an example of the code with which I was familiar. The approach uses JavaScript to access the the Flash object’s id attribute and then calls its SetVariable() method, passing a string variable name followed by a value. Within the Flash file, a constantly looping script (or a ‘Watch’ed variable for those of you with a more CPU-sympathetic outlook) is used to detect changes in the value of the variable. It is then simple to map values to functions and all’s good.
Except it was buggy at best. For non-IE browsers, this method required the ’swliveconnect=true’ attribute to be added to the EMBED tag, and this provided reasonable compatibility across PC browsers. Sadly however, Mac IE users were left wondering if their mouse button had broken.
So what are the alternatives? If you’re publishing for Flash player 8 (or having fun with AS3 and Flash player 9) the ExternalInterface class is the way to go, providing a native API which makes player to container communication a breeze.
In this instance, however, I was publishing for Flash player 7 and the overwhelming weight of public opinion seemed to favour OSFlash’s Flash Javascript Integration Kit. It looked good; it works “across all major browsers and operating systems” and it’s also open source. So I downloaded the latest release, and set about making JavaScript and Flash the best of friends. I just wasn’t ready for the hours of frustration that followed.
It turned out that two errors in the online sample code were the source of my frustrations:
I’ve since found that the documentation included with the download describes the deployment process correctly. It’s a little late for me, but if you’re having install troubles, ditch the web instructions and update your code with the above and all should work a treat.