Flash development: Can your company afford it?
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?
Entries (RSS)
October 2nd, 2009 at 6:04 pm
This hits home for me.
I, too, have spent more time working around the Flash player than actually programming lately, and it’s actually becoming a real problem — especially when “debugging the internet and/or user’s operating environment” has never before been a part of the Flash development cycle (or its billing). The whole beauty of Flash was that you could expect your work to function correctly on any browser with the plugin (or standalone player)… period. I realize we’re asking it to do more than ever these days, but while we once managed to find ways to make it do things it was never designed to do, it now seems impossible to make it do the things it’s SUPPOSED to do.
I spent hours last month trying to figure out why a simple video player failed sometimes, but not others; turns out it had to do with a bug in my player plugin, and I just had to write code around it if I wanted to ensure others didn’t experience the same problem.
These days, I actually have pages that can ONLY run within the latest third-decimal-place version of the Flash Player — or else they’ll crash. So much for universal.
Recently, I’ve found myself suggesting Ajax/jQuery solutions over Flash versions of simple interfaces… and that kills me!
I think it’s time for Adobe to calm down with the new development features, and return to take a good long look at the player itself — making it a solid, dependable platform on which to build again. Otherwise, more old fans like me are just going to start suggesting other technologies before we encourage our clients to look into rich apps again.
October 2nd, 2009 at 6:31 pm
i’m ok with you, there is a lot of bugs in the flash platform, but do see any other solution ? maybe webGL will be great in the future, but for now ?
October 2nd, 2009 at 7:52 pm
Some of these mechanisms go through the browser… LiveConnect and the later externalInterface. These browser/plugin communication protocols were designed for simple messaging, and have caused problems in various browsers when used for very fast messaging, or for fat data-passing.
LocalConnection is Flash-based, SWF instance to SWF instance. It has fewer dependencies.
What types of messages are you passing to make it fail? We’re still subject to the various browsers’ imposed memory and CPU constraints, but this shouldn’t be an issue unless the project’s mechanisms are outside the normal uses…?
jd/adobe
October 2nd, 2009 at 7:58 pm
With the addition of Silverlight its a feature race now. Adobe has to implement new features if it wants to stay in the game.
October 2nd, 2009 at 10:10 pm
LocalConnection is most certainly not specific to each swf instance. LocalConnection uses a shared memory object which is accessed through a mutex. It’s not even a “connection” in any sense of the word. It’s a poorly documented feature with really unpredictable beahviour.
LocalConnection has always been flaky, as has ExternalInterface (and fscommand before it). This isn’t something that has changed recently. There are just some features of the Flash Player that have never been properly stabilized since they were first introduced.
October 2nd, 2009 at 11:12 pm
@Andrew: I think your last statement is the most pertinent to what I am trying to say. There seem to be rather a few features that have never been properly stabilized, and consequently a whole community treading over the same old bugs, littering forums with the same old problems, making useful information very difficult to locate.
I accept the need for Flash to be a competitive product in a marketplace where previously, competition was a little thin. However, when this comes at the expense of player stability and developer satisfaction then the benefit of feature expansion must be weighed against the platform’s most important asset… the loyalty of those who develop on it. A platform full of bugs does not lend itself to this kind of loyalty.
The list of items that don’t quite work as advertised is vast. It extends well beyond the few items mentioned here.
A quick read through our blog demonstrates that we’re not the kind of developers who are ruffled by a few speedbumps on the road to a solution, but it rather takes the fun out of development when you are spending more time working through poorly documented bugs rather than realising the vision.
I code primarily for fun. That I can make money out of it is a nice side effect. Flash isn’t proving much fun for me at the moment.
Funnily, the reason we are forced to communicate between players on the page is due to the disparity of features and reliabilty of the Sound implementation of AVM1 vs AVM2. So the reason we’re here is because we’re actually already working around a bug. When that workaround is also found to be unreliable, and the next workaround also breaks, it tests my loyalty to the very limit.
We’ll get this working reliably in the end. We always do
However, it’s proving very trying.
@John: I don’t believe that we are doing anything that would either qualify as fast or large message passing. It’s difficult to know if our mechanism is “outside of normal uses”. We’re not trying to do anything that isn’t advertised in the docs, so I’d say we’re pretty normal. Messages are short (i.e. hundreds of characters) and infrequent (perhaps 10 every 30 seconds or so). It strikes me that this issue might in some way be related to the superb crash demo I posted. I will check that the registered callbacks are not garbage collected. A full browser crash, however doesn’t look good. Ever.
October 3rd, 2009 at 10:06 pm
Thanks for that info of “hundreds of characters” about every three seconds. I agree with you, that isn’t like the passing of a few megabytes, or the rapidfire gaming commands, which have caused problems in various browsers in the past.
Most of the “full browser crash” situations I’ve come across recently seem to have been when requesting additional memory from the browser… some of them reportedly don’t fail gracefully right now. I don’t know of a good source of info on which browsers do so, however.
How does this example do on “the some-or-all browsers test”? I don’t see any browser brand/OS/version combinations listed above… any dependencies in environment?
tx, jd/adobe
October 4th, 2009 at 10:38 am
If the problem you’re experiencing with LocalConnection happens when opening multiple instances of the same swf file, then I think i’ve got a solution for you. You can mail me if you want me to send the code. It’s a wrapper for the LocalConnection class which uses a combination of tricks to ensure that 2 swf’s use a distinctly unique connection name, even when other instances of the same swf(’s) are opened.
October 5th, 2009 at 10:47 am
I will believe this when I see it. Please share the code that crashes browsers.
The demo at riafiles.googlepages.com/ExternalCrashDemo is done with “Flash 8″ and is closed source and therefore I have problems believing presented facts about flaws in ExternalInterface or LocalConnection.
When it comes to LocalConnection, I have previously used LocalConnection with Flash 8 to transfer more than 2MB of data in small chunks. If I remember correctly the limit is still 64KB. I didn’t face any issue with such usage of LocalConnection. I want somebody facing problems to share his code.
If it is really a bug that other can exploit and code is out for everyone to look at, only then it will send shivers down Adobe’s spine - people known for ignoring community requests and issues.
October 5th, 2009 at 1:25 pm
@sameer:
Have a play with this:
http://ticore.blogspot.com/2007/01/flash-8-externalinterfaceaddcallback.html
October 7th, 2009 at 3:45 am
Hi Chris,
I checked Ticore’s page. Ticore’s code is not written correctly.
One thing is that one has to assume he is using ActionScript 2.0 since usage of “import” statement is NOT available in ActionScript 1.0. I think he has mentioned in-correct version in his post. Another thing, I doubt even ExternalInterface is available in AS 1.0. Therefore I assume he ran his demo with AS 2.0.
Import Statement documentation: http://help.adobe.com/en_US/AS2LCR/Flash_10.0/help.html?content=00000712.html
Trying to compile his code with publish setting for ActionScript 1.0, return this compilation error: Syntax error. import flash.external.*; But the SWF did get created. One possibility is that he is too busy to look in the Error Console for errors and quickly uploads a new blog post.
Using this SWF (with compile error), and using his JS, I could not see my browser crash. IE8 simple said Object doesn’t support this property.
I changed Flash publish setting to AS 2.0 and things worked just as expected. No erors and External Interface rocks!
So I will have to wait for somebody to share a proper code to crash IE and Firebox - yes, with legitimate code and without any sort of nuisance.
I will soon upload demo somewhere, meanwhile if you’d like, you can see how we implemented ExternalInterface in a shopping site recently: http://www.roomsbyyou.com/products/decorative-pillow-cover-large.html#product-options-wrapper
Flash is Fun!
October 7th, 2009 at 6:04 am
Can my company afford it? yes because my clients pay for it.
Im sure you’ve been around since flash 6 and know flash has always been hacktacular, come on man, suck it up.
Your gonna get problems regardless of what you use.
October 7th, 2009 at 11:23 am
@sameer: I don’t buy your logic. There is plainly a Flash movie that receives ExternalInterface calls. If you can’t get your head round it, why not run it through a decompiler instead of taking Ticore’s word for it. http://www.nowrap.de/flare.html works nicely.
It’s definitely as described on his blog. Regardless of the implementation, he’s clearly managed to craft a situation using the Flash Player that causes a disastrous browser crash in every browser I have tried.
I don’t understand why in your mind this particular example doesn’t count. It’s crashing the browser FFS.
We’ve resolved our issues (I hope). They were very much related to the situation described by ticore in his blog, where ExternalInterface calls were resolving to objects that had been potentially garbage collected. I wouldn’t ever expect this to cause a browser crash. Ever. I’m not prepared to make excuses for the Flash Player and I’d suggest that the code was “legitimate code and without any sort of nuisance”, yet it still crashes the browser, despite following the Adobe documentation to the letter.
I wonder what would happen if I performed a little bit of heap-spraying ( http://en.wikipedia.org/wiki/Heap_spraying ) before causing the crash? I bet you that in the right hands, this could be exploited.
October 7th, 2009 at 11:36 am
@dylan: I cut my teeth as a pro developer with Flash after getting out of telcoms. I am eternally thankful for the opportunites it provided me with at a turning point in my career.
Yes it is hacktacular… Macromedia/Adobe have always been in an unrivalled position regarding Flash, which has historically meant that developers have to put up with the hacks because there’s no other choice. I have to say that from a developer’s POV, the competition is really rather strong. To my mind the warring webplayer parties are no different to each other, and relying on the passionate MS hate in your developer community rather than shoring up your product in light of a very strong offensive from the other team doesn’t stack up. Many of the reasons we all “hate” Microsoft could equally be applied to Adobe.
Sure you’re going to get problems wherever you turn, but without a shadow of a doubt, I get more using Flash than with any other technology I use. A lot more.
October 7th, 2009 at 8:47 pm
@chris, I am in agreement with you on everything you said about Flash or Adobe - code once, run anywhere is passe now.
But to be fair to Flash, it is still better than other options. No alternate programming language today guarantees less issues or less bugs and further reach. We are at least half-decade away from HTML5 takeover, if its really going to happen. Till then, no write once, run anywhere… just use ways to write code so our apps don’t crash browsers.
I wanted to talk about it because, yes, Ticore’s example crashed my browser but when I used his code myself, browser didnt crash - also, there is no ExternalInterface or ‘import statement’ in AS1.0 but .swf still gets generate.
If I will come across piece of code that is crashing browser I will share.
And, I will give Flare a shot. Thanks.
October 21st, 2009 at 3:48 am
Hi Guys, download source file here.
http://riafiles.googlepages.com/ExternalCrashDemo.zip
October 21st, 2009 at 4:15 am
Ticore has mentioned in his blog: creating a MovieClip, register ExternalInterface.addCallBack to some method in that movieclip, and remove that movieClip afterwards, call that “addCallBack”ed method, you will crash your browser.
So if this is your problem, you should re-architect your structure. Why should you use a MovieClip, not a Singletoned(I won’t debate singleton here) business logic controller, to be ‘addCallBack’ed? You have an architecture problem, if you know the cause.
October 21st, 2009 at 8:28 pm
This post really isn’t about the specific problem per se. I’m not looking for a fix from one of our readers (unless it’s Adobe, and the fix is fixing the Flash Player!).
The post is specifically to highlight the stability of the Flash Player when used in a somewhat average situation and how, IMO it’s getting worse with every new release.
A bunch of web hearsay and hocuspokery should not be required to prevent disastrous crashes that are caused from a situation where usage does not deviate from the documentation provided by the vendor.
Thanks for the advice, but we solved the problem already, and hey, it only cost us an extra 4 days. But that’s fine because it’s Flash, and we all know it’s buggy as f@@k, so we “suck it up” right everyone?
December 14th, 2009 at 7:11 am
hi, Ticore:
I’ve modify the example you provided, i believe that your example has a serious problem, you cannot write external call function in onClipEvent, to run the example correctly , i move the logic to first frame of main timeline:
import flash.external.*;
function callByJs () {
output.text = “callByJs called!”;
};
ExternalInterface.addCallback(”callByJs”,this,callByJs);
the output is a dynamic text texfield, i have successfully run my modified example in tomcat sever, visit from IE8, everything is OK!
December 14th, 2009 at 3:10 pm
@lwz7512 I’m not sure this should be a exercise in how best to avoid the crashing. The crashing should never happen in the first place. It should not be possible to write Flash content (however badly malformed it is) that crashes the browser.