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

Seems I’m not the only one with reservations.

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:

1. To access a method of your Flash file, you first need to create an instance of the FlashProxy JavaScript class which forwards the requests on to the included Flash gateway SWF. Create an instance according to the sample on OSFlash but disregard the parameters given by way of an example. The FlashProxy constructor takes two parameters only, the first is the unique id used to reference the Flash object, the second if the location of the gateway SWF. The Flash object id should not be included in the argument list.
2. The FlashTag JavaScript class provides the functionality to embed the player on the web page. Unfortunately, it simply doesn’t have the addFlashVars() method referred to on the site. Instead use the setFlashvars() method.

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.

Nintendo have confirmed that the forthcoming Wii console will support Flash via its embedded Opera Browser. There’s no news yet on which version of the Flash Player they’re planning to support, but this could open up some exciting opportunities for developers.

We’re currently working on a new web presence for Heavenly, scheduled for launch in October.