Tag Archives: Adobe Flex

I read an interesting post on official Flex blog few days ago. Flex: Where we are headed tries to summarise Adobe’s view on Flex framework and it’s future. Unfortunately my comment has not been approved for about two weeks now (holidays?) so I decided to post in on my blog. Hopefully some of these concerns will be addressed. Here we go:

Dear Adobe,

It’s great to read that you treat your platform seriously. You are positioning yourself as enterprise platform provider, but the reality shows you are not there yet. Several improvements to Flex and Flash need to be made for that duo to become truly useful in the enterprise world. I have worked on a number of large scale Flex projects for major financial institutions and would like to share some of my observations. I know this is an ultimate wish-list, but all these things really matter:

  • Flash runtime needs to be made more efficient. Really big budgets are required to make large modular applications work smoothly. Drop some backwards compatibility baggage if you need to. Virtual machines can be really fast (JVM).
  • AS3 needs to be updated (it’s 5 years old already) to have proper collections library, support for generics and decimal type. You need to make it even more expressive and powerful.
  • Better reflection and code instrumentation capabilities are needed.
  • Better support for modularisation and runtime dependencies is needed – make RSLs even more powerful and controllable by developers.
  • General quality of code across Flex SDK needs to be improved considerably. Having so many bugs and regressions is not acceptable in mature enterprise framework.
  • Performance of Flex SDK components needs to be improved. Hundreds of components and tons of data on the screen should not be a problem. That’s how enterprise applications usually look like.
  • Styling engine in Flex needs to be replaced with one that is more powerful, efficient and less buggy.
  • Flex compiler needs to be faster. Compile time in any larger project are so high, that may seriously hurt productivity.
  • Flash Builder needs to become world class IDE – some third party IDEs are ahead (IntelliJ).
  • Proper profiler is a must. Current solution is not powerful enough, doesn’t visualise results well and is way too slow.
  • Better support is needed for tools that are widely used in enterprise, such as maven. Contrary to some opinions, flex-mojos is not good enough yet.

Flex developers spend too much time fighting their tools. That makes building Flex platforms rather expensive and risky investments. If this perception will get instilled in minds of managers and directors, then enterprise Flex is dead and lots of Flex developers will need to start looking for new job. Keep us informed about your plans.


Atry pointed me to latest release (0.8.7) of his protoc-gen-as3 library. I re-ran my tests to see if it brings any performance improvements – and it does!

Deserialization times are very similar to 0.8.4 which I used previously. I would assume any differences are statistical errors.

AMF 3 Protocol Buffers
Class: Small Medium Large Small Medium Large
445.96 962.16 1313.68 326.26 962.00 1435.76
Std dev:
25.23 24.35 15.96 4.69 4.38 9.96

Serialization times are greatly reduced – PB library is now 3.5 times faster then before for small messages, over 4 times faster for medium and 4.5 times faster for large. It is still slower then AMF3, but I for most use cases the difference is now negligible.

AMF 3 Protocol Buffers
Class: Small Medium Large Small Medium Large
137.68 214.08 317.76 237.84 563.08 814.70
Std dev:
13.11 14.88 16.45 11.52 15.83 17.37

Very good news!

Note: Tests were ran on MacBook Pro, 2.26GHz Core 2 Duo, 2GB RAM.

Update: I ran tests again using newer version of protoc-gen-as3. They can be found here.

For last couple of days I have been investigating Google’s Protocol Buffers with intention to use it in Flex application. While in Flex world such idea instantly raises at least a couple of questions, let me explain our situation a little bit more.

We are looking into using Kaazing, which is quite low level and data format agnostic solution, to provide us with streaming capability. This means we have a choice of format we want to use for our messages (and streaming protocol, but that’s a topic for another post). We have never really considered XML because of message size, performance and Flash Player bugs (apparently fixed in version 10.1). Using AMF3 would give us a lot of developer friendliness and client-side performance, thanks to native FP support, but in our case would also add additional (and probably not insignificant) load on the server. As Protocol Buffers are already used to communicate between deeper layers of backend, we decided we could try to push PB messages up to the client, without having to translate them into another format. As that solution would also tick a couple of boxes on our nice-to-have list, we decided to give it a go.

During my investigation I concentrated on performance as this is very important factor for us. Our application will need to receive more than hundred messages per second and update view with minimal latency. As outbound traffic will not ever be as high, I was mostly interested in deserialization performance. To have some point of reference, I decided to test Protocol Buffers against AMF3, which in Flex world is a synonym for “as fast as you can get”. I used protoc-gen-as3 project, which seems to be most complete and is continuously maintained by it’s author.

Test application ran in total 150 tests per each format, 50 per each of three test classes. All tests classes have different size, so trend could be observed. Following listing shows definition for test class I refer to as Small in results section below. In terms of number of fields Medium is twice the size and Large thrice.

public class InstrumentPriceSmall
    public var numeric1 : int;
    public var numeric2 : int;
    public var text1 : String;
    public var text2 : String;
    public var date1 : ValueDate;
    public var date2 : ValueDate;

public class ValueDate
    public var year : int;
    public var month : int;
    public var day : int;

During each test an object was created, filled with data, serialized 10 000 times and then deserialized 10 000 times. Test application was compiled in release mode so that Protocol Buffers serialization and deserialization logic, which is completely coded in Action Script, could run with maximum efficiency. To minimize impact of garbage collector, System.gc() was called before running each test.

In terms of over the wire size, PB is quite efficient for simple messages. However it’s advantage over AMF3 would quickly go away for objects that hold multiple references to the same value. This is fortunately not relevant for our use case, but could be for other scenarios.

AMF 3 Protocol Buffers
Class: Small Medium Large Small Medium Large
198 290 371 31 80 123

On average deserialization times for PB are very close to AMF3. It also seems to scale quite well (although curve is steeper than AMF3). One thing I found surprising was that PB times were more stable (standard deviation smaller by factor of 2 to 6, depending on test object size). This is very desired feature because sometimes (like in our case) not only average timing is important, but also how far off best and worse case timings are.

AMF 3 Protocol Buffers
Class: Small Medium Large Small Medium Large
444.92 955.06 1348.38 332.46 977.12 1457.12
Std dev:
18.19 20.88 16.32 3.10 6.77 7.42

Serialization times look much less promising. Protocol Buffers are much slower, even 5 to 10 times depending on test object size.

AMF 3 Protocol Buffers
Class: Small Medium Large Small Medium Large
165.30 235.08 320.66 835.82 2385.44 3619.78
Std dev:
22.22 17.15 16.57 17.89 63.02 81.80

I will keep my summary short. Small message size could mean short over the wire transfer time, deserialization times comparable with AMF3 could mean low processing overhead on the client. No need to translate each message to AMF3 could reduce server load. In our scenario Protocol Buffers could work.

EDIT: There’s one more thing that might be important. AMF3 serialization and deserialization is done by Flash Player on a separate thread while Protocol Buffers messages are processed by AVM on GUI thread. This means that large volumes of data might influence framerate and disrupt animations.

I’ve recently had to parse dates and it turned out that Flex is not very good at it. According to specs, Date.parse() only handle following formats:


Which is fine as long as you live in United States. Not all of us do so I needed to look further. There’s parseDateString method on mx.formatters.DateFormatter but it too does not provide required functionality.

So here is my implementation of date parser. It accepts specified format string and tries to parse given data accordingly. You can use D, M and Y to define this format string and any other character in it will be treated as separator and matched directly. You can refer to unit test provided together with source for usage examples. Please note that set of supported features matches my requirements and you can probably find more complete and feature rich solutions out there.

I’ve been recently working on a component that contained rotated label in it and I discovered that using width and height attributes (MXML) in such case might result in unexpected behaviour.

The problem occurs when you start using absolute values for these properties. If for example you set height to be 100% then actual height of the component will be influenced. However if you set height to be 500, width of the component will be changed instead.

It turns out, that percent size (which is calculated relative to parent and post-transform) would take component’s rotation into account while explicit size is calculated pre-transform (which is a change in Flex 4). While it is all working according to specification trying to use “proxy setters” like width/height might cause some confusion.

You can use this little app to try it.

Because the server where I was hosting the file was shut down, I created a gist on You can access it here.

I am using SourceMate with latest prerelase build of Adobe Flash Builder. It still has some issues but otherwise it’s quite cool. It adds features that most Java developers can expect in either IDE they choose. Personally I like refactoring features, implement/override and code assist for metadata the most. Since we extensively use Parsley in our projects, I thought it would be useful to add it’s metadata tags to SourceMate configuration. If you find any mistakes please let me know.

Follow these instructions to make it work:

  1. Download this file and unpack it.
  2. Run Flash Builder, choose Window > Preferences > SourceMate > Metadata and click “Import…” button.
  3. Choose downloaded XML file
  4. Click “Open”. You’re done!

I can’t upload small XML/ZIP, not even paid upgrades allow that. How uncool is that, WordPress?

Big thanks for Espen for hosting that file for me.

Anyway, I hope that helps!

You may encounter some problems with code autocompletion when switching to one of the latest builds of Adobe Flex SDK, especially if you are using Flash Builder Beta 2 and not one of the latest prerelease builds. Flash Builder will be unable to complete class names and add imports from flash.* package. This is because Adobe is getting ready to include playerglobal.swc for version 10.1 of Flash Player.

To make autocompletion work again, you need to:

  1. Rename folder <sdk install dir>/frameworks/libs/player/10.0 to 10
  2. Remove all occurences of “.{targetPlayerMinorVersion}” from flex-config.xml file located in <sdk install dir>/frameworks.
  3. If SDK you are currently modifying is your current one – restart Flash Builder. If not, you may just switch to it without restarting.

Hope that helps!


Get every new post delivered to your Inbox.