Barklund.org » API

Why events suck in ActionScript 3

Barklund — Thu, 06 May 2010 22:04:45 +0000

I actually took this from production code!

I’ve had it with events in ActionScript 3! They are annoying to structure, annoying to extend, annoying to dispatch but most importantly annoying to consume – and I consume events a lot more than write or dispatch my own.

But! The idea of listening for stuff I really do like. I have some ideas about how this could be done a lot easier. Oh, and please stick around until the very end of this post.

Background

For those who can’t remember exactly, events in AS3 are consumed by listening for certain events and passing a function, that will be called when this event occurs. The function will always be invoked with the event type, that you listen for – and only that argument will be given to the callback. You cannot define extra arguments in any way or not accept the event argument. Let’s for example listen for when the use clicks a button – which is the MouseEvent.CLICK event (of type MouseEvent of course):

public function init():void {
  var myButton:Sprite = new Sprite();
  ...
  myButton.addEventListener(MouseEvent.CLICK, buttonPressed);
  ...
}
private function buttonPressed(me:MouseEvent):void {
  trace("the button has been pressed, hurray");
}

We abidingly accept the me:MouseEvent argument even though we don’t intend to use it.

The event object has information about the event, about who sent it, information related to the bubbling nature of events (that very few people ever use in ActionScript 3) and additional specific attributes only relevant for specific events. For instance, if we have several buttons representing different related actions, we can examine the event.target

private var selectRed:ColorButton;
private var selectGreen:ColorButton ;
private var selectBlue:ColorButton;
public function init():void {
  ...
  selectRed.addEventListener(MouseEvent.CLICK, selectColor);
  selectGreen.addEventListener(MouseEvent.CLICK, selectColor);
  selectBlue.addEventListener(MouseEvent.CLICK, selectColor);
  ...
}
private function selectColor(me:MouseEvent):void {
  var color:ColorButton = me.target as ColorButton;
  if (!color) {
    throw new Error("color selected was not actually a color");
  }
  switch (color) {
    case selectRed: trace("you chose a red Papa Smurf"); break;
    case selectGreen: trace("you chose a green Papa Smurf"); break;
    case selectBlue: trace("you chose a blue Papa Smurf"); break;
  }
}

Here, we do use the MouseEvent-object, but we cast the target property to the type we expect it to have and then we need to check, if the cast went well. Because, technically we could have used the same function as a listener for something else somewhere else (even though we know we didn't) and thus target could have been something entirely different.

Personal experiences

I've just checked a recent, larger project with 185 (home-made) classes. In general I try to minimize my event usage, but a lot of things I have to use events for event though I don't really need them, so I ran a simple script counting how many times I had a function that took an event as an argument, and how many of these actually used the event object. The result was 121 functions accepting an event as argument (10 of those had default null values), and in only 4 of those I actually used the event argument (one of them a KeyboardEvent, the others were all the same home-made PageEvent). 83 of the events accepted were MouseEvents (which is no surprise), and never was the me:MouseEvent variable used in the function body.

Then, I tested an even earlier project from before I started minimizing event usage (almost maximized it back then). It consisted of 50 (home-made) classes. It had 113 functions (a lot more per class than the above) accepting event arguments (16 of those defaulting to null) and 74 of those were MouseEvents. And this time around, I used the event argument 25 times, but 18 of these usages were accessing event.target or event.data and casting it to the right class. Thus, yes I did use the event argument in some cases (22% of the time I accepted an argument), but in most of them I still had to do manual casting of the event.target (or event.data) attribute to get the type I knew I was accessing. This leaves only 7 "true" usages or about 6%. Please see the background section about why using the event object for casting only just moves the problem around and makes the code even more verbose.

Dream scenario

So, what would I like instead? Something intelligent, that allows me to accept the arguments I need when I need them. For instance, take this snippet here:

private var close:CloseButton;
public function init():void {
  close.addEventListener(MouseEvent.CLICK, closeDialog);
}
private function closeDialog():void {
  someDialog.fadeToOblivion();
}

It is simple, I do not need any argument, so I do not expect one.

A often used situation is when you have several instances of the same type and attach the same listener to all of these, then you use the event argument's target attribute for switching on which instance was invoked and handling the result correspondingly:

private var downloadLowRes:DownloadButton;
private var downloadMediumRes:DownloadButton;
private var downloadHighRes:DownloadButton;
public function init():void {
  downloadLowRes.addEventListener(MouseEvent.CLICK, download);
  downloadMediumRes.addEventListener(MouseEvent.CLICK, download);
  downloadHighRes.addEventListener(MouseEvent.CLICK, download);
}
private function download(db:DownloadButton):void {
  switch (db) {
    case downloadLowRes: open("file_360p.avi"); break;
    case downloadMediumRes: open("file_720p.avi"); break;
    case downloadHighRes: open("file_1080p.avi"); break;
  }
}

The function expects a reference to the button clicked - not to an event, who references the button clicked, because only the actual button reference is necessary.

Finally, a more elaborate example of different other component listeners expecting just what they need and nothing else:

public function init():void {
  // listen for selections in a dropdown
  countryDropdown.addEventListener(Event.SELECT, selectCountry);
 
  // listen for checkbox changes
  acceptTermsCheckbox.addEventListener(Event.CHANGE, acceptTerms);
 
  // listen for focus changes between password input fields
  passwordInput.addEventListener(FocusEvent.FOCUS_OUT, checkPasswords);
  passwordConfirmInput.addEventListener(FocusEvent.FOCUS_OUT, checkPasswords);
 
  // listen for three different radio buttons changing
  languageDanish.addEventListener(Event.SELECT, selectLanguage);
  languageSwedish.addEventListener(Event.SELECT, selectLanguage);
  languageNorwegian.addEventListener(Event.SELECT, selectLanguage);
 
  // listen for submit button presses
  submitButton.addEventListener(MouseEvent.CLICK, submit):
}
private function selectCountry(country:String):void {
  selectedCountry = country;
}
private function acceptTerms(accepted:Boolean):void {
  termsAccepted = accepted;
}
private function checkPassword(fe:FocusEvent):void {
  if (!(fe.relatedObject in [passwordInput, passwordConfirmInput])) {
    // focus moved away from either input field
    // show mismatch alert if texts are not the same
    passwordMismatchAlert.visible = passwordInput.text !== passwordConfirmInput.text;
  }
}
private function selectLanguage(language:LanguageRadioButton):void {
  switch (language) {
    case languageDanish: load("texts_da.xml"); break;
    case languageSwedish: load("texts_se.xml"); break;
    case languageNorwegian: load("texts_no.xml"); break;
  }
}
private function submit():void {
  sendForm(withParameters);
}

One notable example among the above is, that if an event is needed, you can always have it. I only dislike events, when I don't need them but have to accept them anyway. When I actually need it, they do come quite handy - like the FocusEvent.relatedObject used in the above example.

Announcement

Actually, I have made the above work! It is a dirty, dirty triple-hack, but it feels quite sweet to use on both ends. I need to clean it up a lot, need to come up with a good name for it and need to benchmark it to see, that it doesn't kill performance (too much).

So please, stay tuned. But do not fear commenting on the above ideas anyway.

Link sharing spam on Facebook

Vimeo highly vulnerable to CSRF attacks – now fixed

Barklund — Fri, 12 Feb 2010 00:33:36 +0000

I recently found, that vimeo.com had a cross-domain policy, that allowed anyone to connect, which was an open invitation for CSRF attacks. I alerted them to the issue, and it has now been fixed.

As has been said over and over, allow-all cross-domain policy files should never be used on domains, where users log on. This leaves the site open for CSRF attacks from flash clients on different domains, that can load pages from the target domain utilizing the user’s automated log-in and thus the flash load’s the pages, like the user himself would. This not only allows the flash file to (without the user knowing it) load all his private information from the target site, but potentially also post data to the site, which could include updating the user’s password, email, profile or in worse circumstances add/remove content or even make purchases, if the target site has any feature like that.

This has been done against large sites like Facebook, MySpace, Adobe and Youtube – the latter was ironically documented via a video on Vimeo by Jeremiah Grossman.

In Vimeo’s case, you can “only” upload videos, but an attacker could actually perform any action on the user’s behalf, that the user himself could – including changing the user’s bio, add/remove videos, comment on/like other videos etc. I made a small, seemingly innocent page, that included a hidden flash element, which first loaded the user’s info from vimeo.com/settings/personal and then re-posted this info back to the same page adding an extra line to the bio – namely “You have been bwned”, as it can seen on my vimeo profile.

Someone at vimeo has clearly seen this demo, (Julia Quinn has indeed) and now the cross-domain policy only allows *.vimeo.com (the new file is served with a Last-Modified timestamp of Thu, 11 Feb 2010 23:32:05 GMT, so the change is only an hour old). The strange thing is, that if you go back via the Wayback Machine from archive.org, you can see, that they had much better security back in 2007 and 2008 (html render fails, but view source), so I have no idea how such a relaxed policy suddenly appeared on their site. Google’s cache still show the allow-all policy as it dates back to January 20th (again, view source to see contents).

I found this while playing around attempting to load videos from Vimeo directly in a custom FLV-player on a different host than vimeo.com and found that this was actually possible, as all videos from their site are hosted from av.vimeo.com and this has an allow-all cross-domain policy. And this makes sense, as this domain is only used for serving videos and nothing else – no cookies or authentication info shared to this domain.

I haven’t heard from Vimeo yet – neither stating that they are looking at the issue nor that it has been fixed. I only post this after now seeing, that it has been fixed.

Turn (Closed) Content Into an API – January 2010 Ideas

Barklund — Thu, 28 Jan 2010 08:00:56 +0000

The twenty-eighth idea for my 365 social ideas is about the open web and about “forcing” classic websites to export their data. Imagine sites with lots of useful information, that is frequently updated, but is hidden away behind forms, in PDF’s or in hard-to-scrape tables. Then imagine a website, where you could provide this address, and give it some guidance as to how to input data in forms and how to interpret the results. And then imagine, that this website would act as a proxy with this interaction described as a simple, queryable API and then behind the scenes would fetch data from the original website.

There are of course a lot of legal issues, and such a service should probably obey robots.txt. And there should be a very clear opt-out possibility for websites that have been targeted in user-contributed additions – maybe even moderation before the services are publicly available. It should not be seen as an attack vector, as a proxy method for illegal purposes or anything like that, but simply as a way of “helping” free information to be used freely.

Why?

A lot of data on the web is hidden in the so-called “deep web” behind forms or in inaccessible parts of websites. With a service like the above-mentioned, this would suddenly not only become visible and indexable, but even queryable.

What’s next?

Do with this idea whatever you like – expand, implement, trash or forget. Just remember, that if you use it in anyway make sure to attribute me according to the Creative Commons Attribution 3.0 License, that all these 365 Social Ideas are published under.

Infographic Charting Service – January 2010 Ideas

Barklund — Tue, 26 Jan 2010 08:00:28 +0000

The twenty-sixth idea for my 365 social ideas is a new brand of charting service: A service designed for infographics, but with sharing, collaboration and synergy as an added side-effect.

The idea is to create a site enabling users to create infographics of the simplest kind initially, but then expand this to even more complex ones. For starters, it could allow users to create tables of data defining row and column labels and then selecting icons, colors and values for cells and having this displayed as larger and smaller icons according to the values – like this chart of the “deadliest drugs”. And allowing people to color-code maps of countries, cities or states according to some data would be quite simple to do as well – like this map of the origins and relationships of European languages.

But more important than simply creating cool visualizations, each infographic has an input page. This page can only be edited by the original creator of the infographic, but it includes direct links to sources of information used. The site should use a simple url structure (inspired by bit.ly), where the short-code would give the actual image, but with a + added (like http://bit.ly/365ideas+) it would be a link to the page describing all this background data.

And now comes the collaborative part: While only the creator can edit the data for the published infographic, anyone can copy the data to branch it as their own new infographic. These relationships will then also be displayed on the about page, as in “this is a spin-off of X and has Y spin-offs of its own”. Somewhat like the very nice ActionScript-programming website wonderfl. Here you can e.g. see that this creation of 250,000 particles is a spin-off from another simulation and has itself spun off into new simulations.

In time, this could be extended heavily and should of course have a public API for creating infographics easily and freely. New types of infographics could be added along with more complex editors allowing you to play around with the data as you see fit. It should be free to do and should not require complex knowledge of Illustrator or Photoshop.

This idea about letting others built on your own ideas could actually be implemented by many sites. The new Firefox 3.6 has “personas”, which is a very light theme engine – that most importantly does not require restart! But why didn’t the developers add a very fast and quick branching mechanism? If you found a cool persona, but didn’t like the color of the top-bar – just branch it, change the top-bar color and publish as a new persona (with credit where credit is due of course linking back to the original).

Why?

Simply: Infographics to the people! I’m not suggesting, that the creators of the coolest infographics aren’t brilliant. But they’re in the business because they both know how to find the data, how to present it and how to use the programs needed to create them. Let’s take the software knowledge part out of the equation and allow anyone with ideas and info to visualize it. And let’s do it openly and collaborate, not just publish a PNG and kill innovation.

What’s next?

Facebook Notes and Images for Competition Results – January 2010 Ideas

Barklund — Mon, 25 Jan 2010 08:00:43 +0000

The twenty-fifth idea for my 365 social ideas is a small simple idea: use Facebook notes or images combined with tags to display results of games. For instance, imagine a chess game, post the result of the game as a note on the game’s page with the final board, all moves made during the game and both players tagged. Or simply post the final board as an image and tag both players as well.

It is a very simple idea, but the idea is to use profile tagging in a new way to indicate relationships to the displayed information in a way, that the users actually feel related to this. The great thing about using tagging is, that it can be done without the user has to accept it and it will be auto-posted to his friends’ news feeds. But given that it can be done without asking the user, it should only be done if it is actually relevant for the user and not done just to get a viral effect and annoy users.

Why?

It is a new way to use the Facebook platform for viral effects. It’s quite simple and does not require a lot of programming as it uses simple, existing features.

What’s next?

Open Data – January 2010 Ideas

Barklund — Mon, 18 Jan 2010 08:00:29 +0000

The eighteenth idea for my 365 social ideas is a social web principle, but it is not new in any way. It is just another voice in the choir of web enthusiasts screaming for open data. However, most people scream at public institutions all over the world to open up their data for their citizens to play around with. I would however like to extend this plea to corporations as well: if you have data, don’t know what to do with it and are allowed to share it, then please share it. Trust me, you’ll end up the winner in the long run, eventhough you’re giving assets away for free.

I could mention a few companies, that I would know have a lot of information that they aren’t sharing but have no idea what to do with. Or maybe they have thought of some small thing to do with it but miss out on the great huge possibilities it might contain. One such site is Endomondo, a very cool running (or any other moving sport) service for tracking your movement. It will gather information about who’s running where how fast etc – live! And they don’t even use it live – they only use it (currently) for calculating your distance and given you your previously run/driven routes on a map. I know a guy or two, who would love to play around with such live data.

Another example is location-based games like the kind of foursquare or gowalla. I recently read about a larger competitor, who actually currently have more users – namely mytown. But they I checked it out, they have no open API and you cannot use the data you give them for anything else. And I’d rather give my location data to someone, who will allow me to re-use this data in any other fun application, that any other company might think of.

There are many many other examples of public and private institutions as well as small and large corporations, who have gathered really interesting data either directly or through crowd-sourcing, but have kept it to themselves. Please, share it – we will all benefit including yourselves!

Why?

Because even though you might have thousand of employees who might be able to think up great stuff – the millions of developers world-wide can think up even more.

What’s next?

A Twitter Gaming Mechanic – January 2010 Ideas

Barklund — Fri, 15 Jan 2010 08:00:42 +0000

The fifteenth idea for my 365 social ideas is about bringing classic games to Twitter in a quite simple, straight-forward way. The same mechanic can be used for simple games like Rock-Paper-Scissor or more complex turn-based board games like Monopoly, Chess or similar.

But before actually taking about the idea, I might as well address the major concern many will respond with: Why even bring it to Twitter? And the short answer is, that is where many people spend a lot of time, so why not? (answering questions with questions is frowned upon, I know). Just like RSS-feeds are a great way of getting the news out and an easy way to follow what happens from small or large publishers, RSS has now been almost completely replaced with Twitter feeds and Facebook page statuses. And in that way, many external non-private interactions will be transferred to where people already are instead of other places, that users must also visit.

The idea is simple, have a central game master, that all participants must follow (to give the game master the possibility to direct message the participants), and then simply start the game by mentioning the game master, the other participants and the type of game. The game master will then mention all participants in return along with a game-specific hashtag, like #chess6f1G. If the game includes some private communications, this will be done in direct messages (like the faces of cards or chosen secret actions), but otherwise it will be done by the participants directly by simply tweeting what they do and add the game-specific hashtag. Every time any player does something, the game master replies with the current status as well as a link to an external site, where the current result/board can be seen.

If the game was Rock-Paper-Scissor for example, the game master starts the next round in a public tweet to all participants, the individual participants direct message the game master with their move, and when all moves are in, the game master announces the result, and then potentially starts the next round for the remaining participants. If the game was chess however, the players would simply tweet their moves publicly, and after each move, that game master will notify the opponent, that it is his move and provide a link to the current board. And if the game was Texas Hold’em No Limit Poker, the message flow would be different, but related.

Why?

Gaming is always fun, and casual games in which you can excel over your friends with nothing at stake is a popular time-waster on many social networks – but not on Twitter due to the limited interface possibilities. With the above idea, simple or complex gaming could easily be introduced on twitter.

What’s next?

Game Console Progress API for Social Connectivity – January 2010 Ideas

Barklund — Wed, 13 Jan 2010 08:00:11 +0000

The thirteenth idea for my 365 social ideas is about adding social connectivity to console games. But not straightforwardly, as in asking the developer of the Assassins Creed 3 to automatically tweet when you get a trophy on your PS3 (this will probably come soon, but is pretty boring). No, it should be possible to do some form of ping/trackback system, in which all games can “ping” your progress to any gaming progress ping recipients. And what happens with this ping is then out of the hands of the actual game. One obvious game progress ping recipient is a twitter bridge, that will tweet it as explained, but by building such a general system, it can be used for anything anyone else can think of, because you simply build a new website, that can receive pings and ask users to enter the url of your website in your game console’s settings.

I of course know it isn’t trivial to introduce things into gaming platforms, they are pretty tight and does not have to listen that much to community. But social connectivity will be coming, and I just hope it is an open model like the above describe instead of static “connections” that the developer decided would be good for you.

Why?

Gaming consoles will exist for a very long time to come, and many will spend a lot of time on them. Most consoles are online by now, so why not combine the user’s online life with his gaming life in an open way? Something like this will come very soon, so why not get out there and be the first?

What’s next?

Swell Wave – January 2010 Ideas

Barklund — Tue, 12 Jan 2010 08:00:28 +0000

The twelfth idea for my 365 social ideas is about Google Wave: Create a wave actor (a robot), that will create a nice, static, easily-printable, exportable view of the wave in it’s current state. Swell Waves are perfect, stable waves – and Swell Wave is thus a stable (but static) version of Google Wave

Google Wave is actually really nice. It is wonderful for collaborations and for chatting many persons. E.g. starting with a document like a brief, a concept or a pitch pasted into the wave, and then just expand and comment on everything a really delve into those interesting parts, trash-talk the bad parts, point out what needs to be clarified, and so on. But, it is very heavy, it does not print very well and you cannot in an easy way share the result with someone else (e.g. convert it to a pdf or link to a certain version of it).

If you created a robot, that when invited into a wave, and asked about it would provide you with a secure link to a static, flat version of the current contents of the wave. From this link, you should be able to easily share it with others, download as pdf and so on.

Why?

Google Wave is too heavy for many users – especially with very large waves where the collaborative, synergetic, creative juices really are flowing. Many times I’ve wanted to copy the current contents of a wave to a Word-document to store it in a more accessible way, but have so far managed to fight the urge. With a Swell Wave, this is now possible.

What’s next?

Coordinate-Proxy – January 2010 Ideas

Barklund — Mon, 11 Jan 2010 08:00:14 +0000

The eleventh idea for my 365 social ideas is another mobile application: An application relaying current position of users to services requiring them. The business model is, that lot’s of websites, competitions and campaigns would like to be able to track their users somehow for some purpose, but if it is just a small campaign or just a funny little gimmick, no-one would bother first making 5 different mobile applications for the different mobile platforms. So instead, they urge their user to download this Coordinate Proxy application from their respective app store, which is free, and then they enter the campaign name (and maybe password if closed) and now they can start relaying information about where they are to the service provider.

Imagine creating a dating website (yes, it is kind of 2005-ish, but they can still make money) and wanting to add some kind of foursquare-like integration with dating spots around town and if you check-in to certain spots, you will be notified about who is present. Or imagine creating a new campaign for some big brand where you every day have a competition where the first person to be at a certain location wins a price. Or image creating a website for geo-artists, allowing people to create paintings via their routes traveled (yes, that is a small bonus idea, might be expanded later in it’s own post). All these ideas are pretty hard to implement, if you want to target all of your target audience equipped with GPS-enabled smart-phones.

As explained, the business model should be between the application creator and service providers needing location tracking. It could be free to track up to say 5 users, but if more than 5 users should be able to be tracked and their positional data forwarded to your service, some payment model should be used. Users should not directly be burdened with this payment (but this could happen between the user and the service provider of course, if location-based tracking is part of a premium package or similar). All kinds of different licenses coudl be used depending on how much and how precise tracking is needed for how many users.

The API provided by the application backend to service providers should be thorough, fast and achieve the expected goals. It should be possible to listen for both real-time, callback-based or digested information as well as give feedback directly back to the users of the application. And it should be possible for the user to have several simultaneously running trackings enabled – e.g. if the user participates in both the dating foursquare and the brand competition mentioned earlier.

Why?

Having lots of users with mobile phones with the ability to report the location is fine, but having to create an application just to create the carrier is simply too much of a hassle. With one application providing a nice consistent (maybe even customizable) interface across GPS-equipped mobile phones along with a decent API, service providers would have a much lower entrance barrier to make their services location-based. And making location-integrated games and campaigns would be similarly easy.