I just signed up for Flash Camp Atlanta! It’s been a while since my last conference, the Adobe onAir Tour, so I’m very excited to spend another day geeking out with fellow Flash developers. Although I’d like to see more Adobe employees, the guests, speakers, and sessions do look like they’ll be interesting.
The networking opportunities are what’s really gotten me excited though. Most of the people I work with are all much more experienced than I am and have been around the block a few times, so they know all the names around the interactive industry in Atlanta. I want to put some faces with those names, as well as spread my own around a bit.
The Flash Player doesn’t allow you to load and use data from other domains, even a subdomain of where you SWF is being served from. Normally this can be worked around by editing the policy file, crossdomain.xml, of the domain where the data is located, but what can you do when the data you want to load is owned by someone like Facebook or Twitter? Chances are that you don’t have the kind of pull it would take to get them to change their policy files, so it’s time to implement a web service on the domain where the SWF is hosted.
I ran into this problem while working with the Twitter and Facebook APIs on my site. Their APIs allow you to get names, URLs, and other interesting data points, but I wanted to load images, which aren’t delivered through the API. To solve this problem, I wrote this dead-simple PHP script which simply forwards GET requests to a URL specified in the “url” parameter and displays the result back to the requester:
<?php$content=file_get_contents($_GET['url']);if($content!==false){echo($content);}else{// there was an error}?>
Of course this is the most simple of examples of a web service that you can get, and is really only useful for simple content like XML, HTML and images. Anything more complicated than this and you would want to create a proper web service with input validation, caching, etc., but this is a quick way to get up and running.
Note that your browser won’t render the proxy-ed image correctly because it doesn’t receive the correct content-type header, which tells the browser to expect an image. What you’re seeing is actually the ASCII representation of the image’s binary data, known as BitmapData to the AS3 world.
Bonus! It can be slow to go through your proxy when not needed, so I use this simple class to create URLRequests with the proper URL as determined by the SWF’s security sandbox:
A Flash application that loads images at runtime and uses them over and over won’t attempt to reuse any previously downloaded assets. Instead, the Flash Player will download a new image from the server over and over, wasting time and bandwidth. The additive effect of this can create a real noticeable difference in performance on a large scale.
For example, we ran into this problem on the leaderboard of the PGA Tour Shot Tracker. The leaderboard displays the player’s name and the flag of the country they’re from. There can be hundreds of players in the tournament, but they all come from about 2 dozen countries or so. This setup is a perfect use case for caching images internally.
With about an hour’s worth of free time I created a fully functioning ActionScript image cache of my own. There are only 2 parts:
CachedImage.as – A subclass of the Image control. A CachedImage adds itself to the cache when its COMPLETE event is fired.
ImageCache.as – Stores the BitMapData of the CachedImages in a dictionary and provides a small set of static methods for querying, adding, and retrieving from the cache.
package com.bdement.imagecache{import flash.display.Bitmap;
import flash.display.BitmapData;
import flash.utils.Dictionary;
/**
*
* @author bdement
*
* This class reduces the amount of HTTP requests your application has to make
* by storing the BitMapData of CachedImage objects in memory for reuse
* by images created after the first one completes.
*/publicclass ImageCache
{/**
* The internal representation of the cache
*/privatestaticvar cache:Dictionary = new Dictionary(false);
/**
* All the methods of ImageCache are static, so the constructor shouldn't be called.
*
*/publicfunction ImageCache(){thrownewError("You don't need to instantiate the ImageCache!");
}/**
*
* @param imageSource The source of an image
* @return Whether the cache already contains the image indicated by imageSource
*
*/publicstaticfunction contains(imageSource:Object) : Boolean{return cache[imageSource]!= null;
}/**
* Retrieves the image
*
* @param imageSource The source of an image
* @return Either: The image if it exists in the cache, OR the default
* source that was passed in via imageSource.
*
*/publicstaticfunctionget(imageSource:Object) : Object{if(contains(imageSource)){trace("using '" + imageSource + "' from cache!");
returnnew Bitmap(cache[imageSource] as BitmapData);
}return imageSource; // String or Object}/**
* Adds an image to the cache
* @param image The image to be cached
*
*/publicstaticfunctionadd(image:CachedImage) : void{if(!contains(image.source)){trace("adding '" + image.source + "' to cache!");
var bitmapData:BitmapData =
new BitmapData( image.content.width,
image.content.height,
true,
0x00000000);
bitmapData.draw(image.content);
cache[image.source] = bitmapData;
}}}}
Finally, you leverage the ImageCache and CachedImage in your application. You can set the source of your CachedImages in all the ways you normally would, and the ImageCache will be used automatically. Note that our ImageCache doesn’t cache embedded images. This is because embedded images don’t fire the COMPLETE event, which is OK because they’re already cached in memory and they can be reused without using our ImageCache.
And finally, here’s the working example. To doublecheck that it’s actually using the cache, reload this page with a web debugging proxy on, like Charles. You’ll notice a request for “rooster.gif,” which is the flash movie downloading the image on the left. (There will probably be two, since there are two example files) But notice that when you click the buttons below, no more requests are made. Success!
And here, just for comparison’s sake, is the example using normal mx:Images without caching built in. With Charles on you’ll notice that every time the image source is changed from null, a new request is made!
