FlexibleFactory

We’re developing a fairly complex application that requires communication between Flash players on the same page.

Initially, we went for a solution that uses LocalConnection. At seemingly random times, the browser crashed. I won’t even go into what the problem might be here. I simply ask the user to search the internet and/or the Flash bugbase for “LocalConnection crash”. It’s unusable.

So now we’ve opted for an ExternalInterface based solution. Once again, the browser crashes. Digging around the internet turns up this beauty of a page:

http://riafiles.googlepages.com/ExternalCrashDemo.html
(this is deliberately not a link, as using this page WILL crash your browser. If you do visit the page, just make sure you don’t have anything important open in your browser when you hit the magic button!)

Frankly, this is a fucking joke. I want to make my anger at this situation completely clear, hence the strong language. Apologies if this offends.

So off we go again, trying to establish the cause of these crashes. More time. More money.

It looks like polling SharedObject () might be an option. I wonder how much time we’ll have to invest in this before it all goes horribly wrong again. I’m already eyeballing this search with weary eyes.

If there were any choice here, we’d abandon Flash altogether on this project.

Maybe it’s just the kind of work we do at Flexible Factory that ekes out these kinds of problems, but we now seriously have to budget for working around bugs in the Flash platform. I’d say at least 10-20% of our Flash development time is spent on these sorts of issues. On this project, that moves up to around 80%.

Sorry, Adobe… if we filed all the bugs we found, we’d never have any time to work. I’ve seen the line:

“Comments on blogs, other web sites or 3rd party bug databases are not tracked by our quality assurance team.”

Well maybe, for the sake of hanging on to developers, it’s time Adobe did.

Wouldn’t it be great if Flash Player 11 was exactly the same as Flash Player 10, except without the bugs? Instead of running to cram more features into a buggy platform, wouldn’t Adobe’s time be better spent fixing what they’ve got?

Which leads me on to the big question:

As a business, can we afford offer Flash development in our product portfolio?

I posted this on StackOverflow.com, but maybe one of out readers knows the answer…

Quite simple really:

var req:URLRequest=new URLRequest();
req.url="http://somesite.com";
var header:URLRequestHeader=new URLRequestHeader("my-bespoke-header","1");
req.requestHeaders.push(header);
req.method=URLRequestMethod.GET;
stream.load(req);

Yet, if I inspect the traffic with WireShark, the my-bespoke-header is not being sent. If I change to URLRequestMethod.POST and append some data to req.data, then the header is sent, but the receiving application requires a GET not a POST.

The documentation mentions a blacklist of headers that will not get sent. my-bespoke-header is not one of these. It’s possibly worth mentioning that the originating request is from a different port on the same domain. Nothing is reported in the policyfile log, so it seems unlikely, but is this something that can be remedied by force loading a crossdomain.xml with a allow-http-request-headers-from despite the fact that this is not a crossdomain issue? Or is it simply an undocumented feature of the Flash Player that it can only send custom headers with a POST request?

We’ve been looking into some inconsistent behaviour across platforms when making socket connections. An application that works fine in Windows and OSX fails for no apparent reason when running on Linux platforms. After running a WireShark network capture, we established that, after correctly fetching a socket policy from port 843 of the remote host, the data sent to the target port was corrupted when using Linux Flash Player.

It turns out that the culprit is the Linux implementation of Socket.writeMultiByte, at least certainly when using the “us-ascii” encoding (it’s late and we can’t be bothered to test other encodings).

So, the line:

socket.writeMultiByte("GET somepath HTTP/1.0 \r\n","us-ascii");

fails completely, with garbage getting written to the socket.

We’ve written a naive (and appropriately named) replacement which works for what we’re doing, but doesn’t handle encodings.

private function writeBetterMultiByte2(msg:String):void
{
 for(var i:int=0;i<msg.length;++i)
 {
  socket.writeByte(msg.charCodeAt(i));
 }
}

It appears that we’re not the only ones having trouble with writeMultiByte, but this time it’s with ByteArray.writeMultiByte . Something seems quite broken here.