martijndevisser.com

Just a quick note to let you know that I updated my Timer class to version 0.3. Most important update is loop progress reporting. This is now off by default, as that feature may get quite CPU intensive.

In order to report progress, the Timer needs to send events on each internal loop check, which, obviously causes a lot of events to be fired.

You can switch this back on with:

[as]myTimer.reportProgress = true;[/as]

Besides this change, I also made sure the Timer class now extends a base Dispatcher class.

I placed a preview online, as well as the source files. I also wrote some documentation for this class, which can be found here.

When developing Flash based sites, you’ll quickly discover that the regular visitor statistics tools don’t work, as Flash doesn’t request plain HTML pages, but dynamically loads .swf and .xml files, depending on user interaction.

In order to be able to track what your visitors are doing in your Flash site, you need to call stats-triggers from within your Flash application. This can be as simple as calling a Javascript statement in the containing HTML file, which in turn sends a statistics ping to your reporting server.

But often, that’s not enough. We want to be able to track not only what users are doing inside the app we built, but also how users that originate from different websites behave. For example, perhaps Banner A is clicked 5000 times, but only 0.5% of those people actually make a transaction, once in the site, whereas Banner B is clicked only 1000 times, but 12% of those visitors are buying stuff in the Flash app.

So, it’s not only important to know how people behave, but what conversion ratios are realized from each banner, emailing or DM campaign. So we teamed up with a company named OneStat, as they are also interested in improving measurement of user behaviour in Flash sites.

As a result, we’ve been implementing a statistics ActionScript class for some time now that handles all reporting to the OneStat server through LoadVars (thus eliminating the need for the Flash > Javascript > Image object refresh trick).

The main event management code in our application can be instructed to send each and every mouse click if needed, but usually we measure visiting certain sections of an app and subscribing to newsletters, making transactions and the like. Below, I have represented our current stats reporting flow (in this case for the Hi Bling Bling campaign):

As you can see, when a user clicks a banner or link in a newsletter, he or she is first forwarded to the OneStat server, which records the click-in and retrieves the correct campaign ID the clicked link belongs to. This happens in a split second, visitors don’t notice this at all. Next, the actual Flash site is launched and the campaign ID is transmitted as one of the initial variables. All consequent clicks and conversion / transaction points we want measured are then reported to the OneStat server, including the initial campaign ID.

This setup enables us to get a very detailed impression of what banners work and which don’t, so we can help our clients in choosing the right sites to place banners on etcetera. It also gives us a great insight in the usability of a Flash based site. Do people just land on the main page, get confused and leave? Or do they really interact and visit multiple sections of the application? Are there steps in the application where many people tend to drop out? That’s interesting information.

A few days ago Macromedia released their Flash / JavaScript Integration Kit (currently in beta). I’ve been working on reliable and flexible Javascript to Flash events and vice versa myself. I already developed a way of queueing getURL calls from Flash to Javascript. Today I’m releasing a method of queueing calls from JavaScript to Flash.

So what’s this queueing all about? It all comes down to the speed of the DOM (or lack thereof) and thus the need of giving the browser enough time to catch its breath in between calls. And this not only applies to calls from Flash to the outside world, but also to calls made by Javascript to your Flash application.

In short, these are possible solutions to the issues described above:

• Queue getURL calls from Flash to the browser.
• Queue calls from Javascript to Flash.

I already posted a solution for the first issue, namely in the form of the PostCenter class. Read that blog entry for more information on how to implement getURL queueing in your applications.

With that issue tackled, lets move over to the next problem, queueing calls from JS to Flash. To be honest, I didn’t know that those calls made are also dropped when they’re made quickly in succession, but one of my blog visitors, Cosmin Cimpoi, brought the issue to my attention.

So I’ve been working on a way to make Javascript wait a certain number of milliseconds before sending the next event to Flash. I quickly discovered that using setInterval in Javascript is quite a different story from setInterval in Flash (in JS, you’re loosing local scope), but a coworker of mine, who fluently speaks JS, came up with a nice solution (thanks ReD!). Apart from surprises such as this, I managed to put together a cross browser (successfully tested in WinXP IE and Firefox, as well as Mac OS X Safar, that is) piece of Javascript that manages calls to your Flash application. After some testing, I settled for a delay of 500 milliseconds, quite a long timeout, but that seems to give the best results.

I’m not sure how often one is going to send a lot of simultaneous events from Javascript to Flash, but if you do, this may be a solution worth trying.

I have posted an example online here. You can also download the source files. Please note that the source files use my ExternalFunction class to receive and manage Javascript events in Flash. Read the related blog entry if you’re not sure what the ExternalFunction class is all about.

One final remark: I know this is not a perfect solution. Especially on very slow machines, the delay may be too short, resulting in dropped events. The best solution would be a confirmation event from Flash back to Javascript, indicating the event was received successfully, so JS can send the next event.

When building Flash applications that quickly call getURL in succession (for state updates, statistics reports, opening HTML popups), Internet Explorer sometimes tends to completely drop some calls or even clear its own loading queue. Other browsers like Firefox and Safari don’t seem to share this behaviour.

For example, when your Flash application is embedded in an HTML environment, this can result in not loading parts of the HTML page, after Flash issues a getURL command to the browser.

Another issue you may encounter is the fact that only the last getURL action is actually executed. All previous calls in the same frame are ignored.

To prevent this from happening, you can use a class that queues all getURL calls and executes them one after the other with a slight delay. We settled for 200 milliseconds, a timeout that doesn’t notably disrupt the user experience.

In response to Kevin Lynch’ post on his blog, I hereby publish a getURL queueing class named PostCenter created by Arthur Clemens and myself for the company I work for, Lost Boys.

Usage:

[as]import PostCenter;

var msg1:String = “javascript:alert(’message one’);”;
var msg2:String = “javascript:alert(’message two’);”;
var msg3:String = “http://www.lostboys.nl”;

PostCenter.send(msg1);
PostCenter.send(msg2);
PostCenter.send(msg3, “_blank”);[/as]

Get the source files. As always, feedback much appreciated.

Two weeks ago I posted my ExternalFunction class, which allows you to generate EventDispatcher events in Flash through Javascript. As one of my visitors pointed out, this solution doesn’t work on Safari. So I wrote a different implementation, which also supports Safari on Mac OS X.

This new version is based on the method developed by Mustardlab.com, which uses a gateway.swf to pass Javascript variables to the main Flash application by means of a LocalConnection. This is necessary, as Safari on Mac OS X doesn’t support the setVariable method to, hence its name, set variables in Flash through Javascript. Unfortunately, the Mustardlab implementation sets the value of a variable directly in Flash and doesn’t support events.

I order to support EventDispatcher events in Flash, I have completely rewritten my original ExternalFunction class to support a LocalConnection to receive variables and then broadcast an event, its name being specified by Javascript. I have also upgraded the original gateway.swf to support ActionScript 2.

Like the previous implementation, this allows you to subscribe Flash objects to any JavaScript event you wish to pass to your Flash application by using a regular .addEventListener() call.

In ActionScript:

[as]import ExternalFunction;
import ExternalFunctionEvent;

var mExtFunc:ExternalFunction = ExternalFunction.getInstance();
mExtFunc.addEventListener(”onMyEvent”, this);

var onMyEvent:Function = function ( e:ExternalFunctionEvent ) {
// code goes here…
}[/as]

In HTML¹:

[html]

view image 1[/html]

There’s an online example available. Download the source code here. I also wrote some documentation for this class, which can be found here.

¹ Please note that you need to carefully name your main Flash application using the ‘id’ parameter in the object tag and also set the same name in the embed tag using the ‘name’ parameter. This id is used as the name of the LocalConnectin to setup and is passed to both the main Flash application and gateway.swf through FlashVars.

A few weeks ago, I blogged about the fact that FlashEurope was postponed once again. Today, Udo Thoennissen posted his reaction to that somewhat upset blog entry of mine. According to Udo, he has nothing to do with the conference and his name is being abused by Harold Angulo, who seems to be the source of all the confusion…

This is what Udo Thoennissen wrote:

Hi everyone,

I am Udo Thoennissen, the person you mentioned who apparently sent you invitations and called you in relation with Flasheurope. Friends adviced me that my name appears in this site and I am terrified to read your experiences with Harold Angulo and his conference. I lived with him in a flat in c/Comte Borrell 122 for a few months till october 2004, because I was studying a master course at UIC Barcelona. I left the flat because he stole me a big amount of money and other things but I can’t bring it to proof. I left Barcelona and returned to Germany.

I have to say you that I have NOTHING to do with Flasheurope. Harold is using my name for his fraudulent business.

Since weeks I am trying to get in contact with him per phone to recover some of my things, but without success. I guess that he is still living in c/Comte Borrell 122, 1.1a, that he mentions as registered office of Flasheurope. At the moment I’m not able to contact him neither.
I hope that this story will end up well and that all of you get your money back.

Udo

Does anyone know the whereabouts of this Harold Angulo? Looks like he should know more of what exactly is going on with the FlashEurope confence.

There are a number of full-blown solutions on the market that provide you with two-way JavaScript <> Flash communication. I needed something similar, but much simpler: translate JavaScript functions to EventDispatcher events in Flash.

I started of with some Googlin’, but I couldn’t really find what I needed. And although this ActionScript 1 implementation by Bokel got close, it is based on the fact that you must specify the exact location of the Flash function to trigger, _level0.anObject.itsMethod, for example.

I like an events based solution much better, as that gives you more flexibility and keeps your code clean, so I wrote an ExternalFunction class this afternoon that allows you to subscribe Flash objects to any JavaScript event you wish to pass to your Flash application by using a regular .addEventListener() call.

In ActionScript:

[as]import ExternalFunction;
import ExternalFunctionEvent;

var mExtFunc:ExternalFunction = ExternalFunction.getInstance();
mExtFunc.addEventListener(”myCutomEvent”, this);

var myCutomEvent:Function = function ( e:ExternalFunctionEvent ) {
// code goes here…
}[/as]

In HTML¹:

[html]

view image 1[/html]

There’s an online example available. Download the source code here. I also wrote some documentation for this class, which can be found here.

As I have just completed the code, there may be some unexpected rough edges, so be warned. If you encounter any weird stuff, let me know.

¹ Please note that you need to carefully name your main Flash application using the ‘id’ parameter in the object tag and also set the same name in the embed tag using the ‘name’ parameter. This id is used as the name of the LocalConnection to setup and is passed to both the main Flash application and the gateway.way through FlashVars.