Aurigma Flash/Flex experiments

Recently we have decided to widen our experience (and maybe products line) and to investigate new Flash/Flex platform. The task was to create file-upload solution with some client-side image processing. This post contains a summary of our experiments. However, I'm a full newbie in Flash/Flex, so feel free to add your notes and comments.

The beginning was great - I have just opened FlexBuilder and found many cool things. Stable and fast visual forms designer, easy-to-learn syntax, all major OOP concepts and even compile-time type checks. Oh, and of course - shaders! Really amazing stuff. However, after few days my impressions were not so bright. Why? Here the whole list of reasons.

Security restrictions

It is really a problem number one. As I was interested in upload functionality, I started with URLLoader class. It cannot post anything to server if this action is not initiated by user directly. Very reasonable. So, each time when you call URLLoader.load() you should have something like button click handler higher in stack. It prevents malicious apps from stealing user data. But...

There is another thing about Flash/Flex which you should know. It is event-driven platform with many asynchronous calls. E.g. if you want to load file - you should call FileReference.load() and wait for "complete" event fired by this object. If you want to load SWF movie or JPEG image - you should create Loader object, ask it to start processing and just wait for the event. Very simple! If you are not going to upload an image you have, to go to fullscreen or do anything else from the list of restricted actions. But if you are - you are in a big trouble. By the reason of the fact that "complete" event fired from another thread - there is no UIA (user-initiated-action) handler in stack and, hence, you have no permission.

Adobe docs says - "you should show message and ask user again". You have to ask, even if a user just clicked "Do this" button just because you have asynchronous call in the middle of your operation. Really annoying. Actually, I don't understand why a bad guy cannot show message and ask user some innocent question? User will give him a permit (why not, if question is innocent?) - and he will do his dirty business...

And there is also another bug with URLLoader - it doesn't fire progress event while uploading data from binary buffer. It is a known issue (http://bugs.adobe.com/jira/browse/SDK-19416) and I even voted for it. I would recommend you to do the same if you experience a similar problem.

So, URLLoader was evidently not the best choice. Next thing I tried to use was Socket. Yeap, it is not so easy to use, however, from the other hand it gives much more flexibility. Nevertheless, a few hours later it was evident that Socket is not the option at all because even if you are going to make uploads to the same domain where you host your SWF file you should have special policy server installed on the server. You cannot obtain permission policy from your HTTP server, no, only via special policy server...

Threads & Asynchronous calls

As I mentioned before - Flash/Flex is an event-driven asynchronous platform. But it doesn't support multithreading. Sounds strange, yeap? As far as I understand from blogs and forums - all ActionScript code is executed in a single thread. And asynchronous calls are just enqueued in some internal dispatcher. What does that mean? That it is simple to develop, it is hard to make a hardly-debuggable synchronization error. And this means, that you cannot run anything in background. There are workarounds which emulate "background processing", but they were not applicable in my case. Oh, I forgot to mention that shaders engine works in another thread, so if your task can be expressed in shaders programming language - you will be able to do it asynchronously and very-very fast. ;) Unfortunately, it isn't my case as well.

Summary

What do we have at the end? A very strange feeling. Get me right, I like Flash/Flex - it provides a bunch of great features, it allows to develop really fast, it works in a stable way... But sometimes it stalemates you, and you cannot do anything. Users will have nothing to do than bear user interface freezing or answer useless questions shown because of security restrictions in Flash.

It would be great to have the following things in the future:

  • Signed SWFs or any other mechanism to use instead of UIA concept. Or some mechanism which will allow passing UIA-permission via event chains.
  • Multithreading or at least something like yield() method.
  • Ability to work via sockets. At least with native domain. Without any "special server on XXX port", because it is not usable in real world with hosting providers, firewalls, and proxies.