One of the big arguments against heavily using flash on your site was that it certainly wouldn’t help you in Google. Now, many will see that argument as being gone. We can now look forward to more annoying flash content, and maybe even some flash that is used correctly.

With great power comes great responsibility

-Stan Lee

If you think you can now cheat and use flash content instead of HTML, you’re probably wrong. There are many questions that have now been raised (some have been answered):

• Does each flash file count as a page?
• Do links to and from flash content count for PageRank?
• Do you really want ALL of the text in your flash files indexed?
• Does the SWF get executed in any way, so that the generated text can be indexed?

It’s going to take a while before Google gets good at indexing flash files. It’s also going to take some time for people to really understand how the process is working. I wouldn’t be too quick to convert something to flash just because Google can see it now.

Only use flash when it makes sense to your users. For example, Choice Shirts has an HTML website, but their shirt designer is flash (Flex actually). If their designer doesn’t get indexed, it’s not a big deal. The designer is there for usability, not for the search engines.

var snapshot:ImageSnapshot =  ImageSnapshot.captureImage(backgroundCanvas);

By default, it uses PNG encoding.

If you want to then send this image to the server, use this code:

var req:URLRequest = new URLRequest();
req.method = URLRequestMethod.POST;
req.data = snapshot.data;
req.contentType="application/octet-stream";
req.url = "snapshotuploadhandler.aspx";
var loader:URLLoader = new URLLoader;
loader.load(req);

Reading the uploaded file is easy using ASP.NET:

private byte[] readPostedFile()
{
   if (Request.ContentLength > 0)
   {
       byte[] buffer = new byte[Request.ContentLength];
       using (BinaryReader br = new BinaryReader(Request.InputStream))
           br.Read(buffer, 0, buffer.Length);
       return buffer;
   }
   else
   {
       return null;
   }
}

var req:URLRequest = new URLRequest();
req.method = URLRequestMethod.POST;
req.data = snapshot.data;
req.contentType="application/octet-stream";
req.url = "snapshotuploadhandler.aspx";

var loader:URLLoader = new URLLoader;
loader.load(req);

I assumed this code was incorrect, but it was actually the code in the receiving page. Instead of checking the "Files" property on the request object, I needed to read the InputStream on the request. Here is the working code:

if (Request.ContentLength > 0)
{
    byte[] buffer = new byte[Request.ContentLength];
    using (BinaryReader br = new BinaryReader(Request.InputStream))
        br.Read(buffer, 0, buffer.Length);
    return buffer;
}

What’s wrong with this ActionScript code? This was a block of code that I fixed while tracking down a nasty bug. c# would have never let me do this.

Basically, the "j" variable starts out at 0 in the method. That’s fine, because it’s what I would normally expect. The problem is that I have it declared inside another loop, so this loop initializer is run multiple times. The second time around, "j" maintains it’s value. It could start at 5 next time. The loop still partially works, if the length of the arrays get longer each time. It’s a bit odd that the "j" variable is never created more than once. I’m guessing it’s a compiler optimization.

This loop was used in a drawing routine for images. If you had an image in the first drawing area, the first image in the consecutive drawing areas would never be drawn.

It should be obvious, but please don’t forget to initialize your "for" loop variables.