GeoWeb – Map Based RIA Development Using Adobe Flex and AIR with Duane Nickull

OSCON – Flex: the Open Source SDK for RIAs also with Duane

LinuxWorld – Building Rich Internet Applications with an Open Source Stack

I hope to see some of you at those conferences.

The mobile space has been heating up lately with Apple’s iPhone, Google’s Android, and Sun’s JavaFX Mobile. But what about all of us developing with JavaScript 2.0 / ActionScript 3.0 / ES4? While we have been able to build for Flash Lite with Flash CS3, those of us developing with Flex haven’t had an easy way to use our existing programming knowledge to build mobile applications. Part of the reason for this is that the core language of Flex (AS3 / ES4) isn’t yet supported on mobile devices. The good news is that Adobe has just contributed a new VM targeted at mobile devices, to the Mozilla Tamarin project. Tamarin is the open source core of Flash Player 9 and will at some point be the VM in Firefox that executes JavaScript 2.0. More specifically AVM2 is the VM piece of Tamarin which executes ActionScript Byte Code (ABC). ABC can be created using the soon to be open source Flex SDK’s ASC compiler which turns AS3 (or ES4) into ABC. Unfortunately AVM2 wasn’t written to work well on mobile devices. So Adobe built Tamarin-Tracing – a new VM in Tamarin which is much better suited for non-pc devices. This is very exciting stuff!

To run the benchmarks yourself, go to:
http://www.jamesward.org/census/

I have tried to be as fair as possible with these tests. Still, I encourage you to use these results only as an initial guide. You should always do your own benchmarks that more closely resemble your actual use case.

You can find more details explaining the tests and the results inside the “Guide Me” mode of the application, so I won’t go into depth here. Also, the code is Open Source (GPL) on SourceForge. If you feel that a test should be done differently or you find other things that you think should be changed, get the code, fix it, and send me a patch file. Please don’t just tell me I did something wrong. In the spirit of Open Source, help me fix it. I want this application to be as fair and accurate as possible.

While these results may be eye-opening to some, once you understand some fundamental differences between Flex and Ajax, they end up making a lot of sense. Flex applications run within the Mozilla Tamarin VM inside Flash 9. Tamarin does JIT compilation which makes code execution 10 to 1000 times faster than interpreted JavaScript in the browser. Also Tamarin can be very efficient when dealing with typed objects.

In addition, Flex supports a compact binary object serialization protocol, called AMF3, which is extremely fast. There are numerous Open Source implementations using various backend technologies for AMF3, as well as a commercial / supported Adobe product, called Flex Data Services. If you control both sides of the wire in your application, then there is rarely a good reason to serialize and deserialize text. Objects are blazing fast as you can tell by this benchmark. AMF3 is also typically much more efficient across the wire (even without compression) and consumes much less client side memory. JIT compilation and binary object serialization are the primary reasons why Flex AMF3 is so fast, even in the test with the full 20,000 rows. And, it’s not just faster for loading – it also speeds client side sorting and filtering. (Try client-side sorting in the Dojo benchmark and the Flex AMF benchmark.)

A quick note on compression: I did not include compression support in this version because its value really depends on many application-specific factors. For instance, if most of your users have slow connections then compression can help speed things up, but if most have fast connections the added latency can actually make things slower. However, I do want to add a Gzip option to this benchmark for the next release.

This is really a version 0.1 release. There are many improvements I have on the to-do list. And I’d love the community’s help. Here are some things I want to do for the 0.2 release:
– Add Gzip option on tests
– Add a Laszlo test
– Implement more Ajax frameworks that have DataGrids and that support paging and sorting
– Add a server side sorting option
– Add Ajax client side memory usage metrics (don’t know if this is possible)
– Improve the UI for use on projectors (I use this demo in every presentation I give)
– Integrate feedback I get from the initial version
– Maybe add a WPF/E test (which I won’t be able to do because I run Linux)

I sincerely hope that you find this demo useful. I built it as a tool to help people learn more about the various methods of data loading in RIAs. I did not in any way build this to attack Ajax, Dojo, and SOAP. Please help me improve this application so that we all continue to learn more about the technologies available to us.

More information is available in the FAQ. Come join us! Together we will revolutionize the now-more-sexy “Open Web”! :)

Bruce and I have a few more eSeminars coming up, find out more info here:
http://www.adobe.com/cfusion/event/index.cfm?event=detail&id=462539&loc=en_us

Also yesterday the Open Source Buni Meldware Communication Suite joined the Java.net community. This is a great step forward for the project, which uses Flex for it’s Webmail client. More info from Andy Oliver:
http://blog.buni.org/blog/acoliver/meldware/2007/02/28/Meldware-joins-Java-net

And lastly, while at the Adobe Engage conference, I gained a Twitter addiction. Please help me indulge my addiction and add me as a friend:
http://twitter.com/jlward4th

As time passed my attitude changed from Flash is very cool, to all these ’skip into’ sites have gotten very annoying. I also gave up hope of learning to create Flash sites myself, due to my ever-growing ideology of Freedom, prompting me to switch to Linux on the desktop. And this meant running Flash Professional was no longer an option. Over the next few years hanging out on Slashdot led me to believe that since Flash was so abused, it really lacked value. When I first saw a simple web form built with Flash I laughed and said, “Why would anyone use Flash for these types of applications?”

Fast forward to 2005, my boss was a very creative person who wanted our corporate marketing website to be more like the Hidalgo movie site, than a static printed brochure. It was a fantastic vision that the executives liked, so we began researching technologies. I was against using Flash Professional for a number of reasons. I still was (and still am) using Linux on my desktop and I didn’t think Flash was the right tool for web applications. I am a programmer who likes to write code, not play with movie clips on timelines, and the site we were building also had to function as a customer service website with complex backend interaction, data editing and data visualization.

My boss came into work one morning after having been to a Flex briefing, jazzed that she had found the answer, “Let’s build it with Flex!” I responded by asking what was this Flex thing. I began looking around and I first saw the component explorer. Initially I thought everything looked great, but I was still unaware of how to build that kind of stuff and talk to the backend. I downloaded the trial, and dug in.

Within an hour I was pulling data from my backend and displaying it in a data grid that would have taken me weeks to build with HTML and a few days later I had built a POC for the portal we began building. I was extremely impressed with how quickly I learned Flex and built beautiful, functional stuff. I was pretty hooked, but still had all those lingering fears about using Flash. My main concerns were that Flash was proprietary, only used for annoyances, was not indexable by search engines, Macromedia had not been super Linux friendly, and Flash is a browser plug-in.

So how did I overcome my fears and jump head first into the Flash/Flex world, eventually becoming an evangelist for Flex? Before I begin, the following is not meant to be a point-by-point argument for why to use Flash and Flex. I save those for when I am confronted with specific use cases. The following is more about my specific use case, which may or may not apply to your use case. If you want to talk specifically about your use case please ping me. I’d love to hear what you are building and honestly talk about whether Flash and Flex is the best fit.

Fear #1: It’s proprietary

Being a Linux geek who compiles almost everything on my system from source, this was probably my biggest issue with using Flash as a platform. In my mind it comes down to three things: can I deconstruct Flash content without Macromedia (now Adobe) software? Can I construct Flash content without Adobe software? And, how tightly controlled is the innovation and direction of the Flash platform?

There are plenty of more religious reasons to fear Flash, but for my personal beliefs, those were the main three. As far as deconstructing Flash content, I was happy to learn that the SWF (Flash byte code) file spec is published and there are at least three open source Flash browser plug-ins. To construct SWF content numerous open source projects exist, including a Flex-like framework called Laszlo. And as far as community participation goes, I was pleased to learn that Flash and many other Macromedia/Adobe products are driven by Customer Advisory Boards and feedback received by the general public.

These facts were enough to satisfy Fear #1. I’m sure there are those out there like RMS, for whom these reasons are not enough. And let me make it clear that I firmly believe in the ideals that RMS believes. But in my mind there are people who are meant to fight for an ideal, bringing balance to the world and people who are meant to live in contradiction. Simply put, there are areas where I will sacrifice my ideals and there are areas I won’t. Flash is one of those areas where I have no problem living in a contradictory reality. Most of us live in such a reality. Is your Operating System Open Source? How about your video driver, your MP3 Player or the software behind the websites you use? I’m fine with Flash not being Open Source because ultimately I trust Adobe to continue doing the right thing and eventually make Flash more open. And I believe this for a few reasons. One, the PDF specification recently became an Open Standard with ISO. Two, Adobe recently open sourced the source behind the core of Flash Player, its virtual machine, with Mozilla. And three, I’ve never felt that Flash Player didn’t put my interests as a consumer ahead of Adobe’s corporate interests. For Flash Player to be successful, they must serve the consumers of the technology.

Fear #2: It’s only used for annoyances

Indisputably, the power of Flash has been abused. Pop-ups, pop-overs, skip intros and annoying ads run rampant across our screens. I’ve heard it said that one should never judge a religion by its abuse. The same adage applies to technology. Flash shouldn’t be avoided just because people use it for annoying things. After all, e-mail isn’t avoided just because spammers happen to abuse it.

We need to find creative ways to deal with the abuse. I personally would like to see a community-driven black list of Flash and DHTML abuses, similar to email RBLs. The more useful a technology is the more abused it will be. But that doesn’t mean we should stop using useful technologies.

Fear #3: It’s not indexable (or what I call “Integration with Web 1.0″)

When the web consisted primarily of documents, indexing worked really well. Spiders could easily crawl through URLs to obtain all documents in existence. As the web has become more of an application platform this method has begun to break down. Whether it’s Ajax, Flash or XUL, when an application moves state and code execution to the client, it becomes harder and harder for the search engines to index.

For the site that I built with Flex this was a critical issue, but it was resolved by creating a boring Lynx compatible version of our site. Since a content management system contained all of the content for the site it was a simple task and our problem was solved. However, I think there is still more work to be done. Search engines need to innovate in this area, perhaps by creating a web services interface to allow for application indexing. Since modern search engines rely on the interconnectedness of pages, creating a different, indexable version of your site will reduce your search engine ranking. However, by looking at sites like Digg and Delicious it would be easy to conceive some way to rate and moderate the usefulness and integrity of the new “application index”.

What about back button support? In Flex, back button support is built in and easily customizable so this was never an issue. Flex also provides an easy way to do hashmark urls (or named anchors) so the url changes as application state changes. Another Web 1.0 integration problem solved.

Fear #4: Macromedia has not been super Linux friendly

Flash Player for Linux releases have historically lagged behind the Windows releases, and there have been very few ways to build SWFs on Linux systems. For some the lack of a native 64bit Linux Flash Player has also been a big problem. These factors have long contributed to many Linux users feeling that they are second-class citizens in the Flash world, myself included.

Before I joined Macromedia, plans were in the works for Flash Player 9. I had a heart-to-heart with Emmy Huang about Macromedia’s Linux support and she assured me that Flash Player 9 on Linux was of the utmost priority. She also said one main hold-up was filling the open positions for a few great Linux programmers to port/build Flash Player 9 on Linux. Finally Mike Melanson found the job posting and relocated to SF to join the Flash Player team. He and many others fiendishly worked on Flash Player 9 for Linux and did a fantastic job! Public betas for Flash Player 9 on Linux began a few months after the Windows and Mac releases, and Flash Player 9 for Linux was officially released on January 17, 2007. And for those on 64bit Linux, using the nspluginwrapper, you can run the 32bit Flash plug-in.

Adobe now has numerous full time engineers building and testing Flash Player 9 on Linux. Also, it’s important to consider how committed Adobe has been to Adobe Reader working on Linux. In my opinion Reader support on Linux is fantastic. Adobe is extremely committed to making sure that platform technologies not only work on Linux, but also work the same way on Linux as they do on Windows and Mac.

Adobe is also committed to making sure that Linux users can not only view Flash content, but also create it. With tools like the free Flex 2 SDK, which I use daily on Linux, I am able to build Flash-based applications that take advantage of all the innovative features of Flash and run the same way on Linux, Mac and Windows. The free Flex 2 SDK provides a set of reusable components, a compiler and debugger that allows me to build web applications that are faster, more usable, and more aesthetically appealing than anything I could build with HTML and JavaScript.

Fear #5: It’s a browser plug-in

This was only a short-lived issue for me, so I’ll save the verbosity for a future blog. I believe that the concept of Browser Plug-ins was added to allow innovation outside of a snail’s pace seen in the browsers themselves. This gives web users the ability to go beyond the realm of HTML and experience amazing things within the context of a page accessed via HTTP. Flash provided just this, a consistent, innovative experience inside the browser, yet outside the limitations of HTML. Now 98 percent of the world’s PC users have Flash 6 or greater installed.

So why is there such an aversion to relying on a browser plug-in? Last time I checked more users have Flash enabled than JavaScript. Should we never rely on JavaScript either? And what about browser compatibility? Plug-ins, like Flash, do a great job of shielding web developers from the pains of cross-browser and cross-OS incompatibilities. From a web developer perspective I’m much happier when I can write once, debug once and run anywhere, than having to test on three different OS’s and over 20 different browser permutations. Many say that frameworks shield us from these cross-X issues. I don’t think they do, because almost every piece of software I write ends up being about 80 percent framework and 20 percent hand coded. People always end up having to deal with a slice of the application that falls outside what the frameworks does.

Also, a side note on Flex. The Flex programming model was conceived as a component framework where components are extensible and include properties, methods, styles and events. In my experiences by encapsulating these elements into a framework I rarely have to go outside the bounds of the Flex framework. With HTML and Ajax frameworks I frequently have to drop down to lower level code, outside the framework. Usually at first the framework gives me everything I need. Then the designers hand me something that looks nothing like what the framework provides out-of-the-box and I have to start hacking around the framework or even modifying the framework itself. This is not a maintainable way to code! With Flex I simply tell designers to use a designer friendly tool to create the design elements. Then I import those elements into my Flex application as skins.

Obviously there are things that Flash can do very well that the browser can’t do, or can’t do well. People are working to change this. But how long will it be before new standards are created, how long before browsers implement those standards and a majority of users upgrade to those browsers? I’d prefer not to hold my breath, because by the time that is all done the web will be nothing like it is today. Plug-ins are a harbor for innovation, stability and consistency. So why do we treat them as if they aren’t just as important as the browser? And with free products like the Flex Ajax Bridge it’s easy to communicate between Flash and the browser, as illustrated by Google Finance.

Fears Relieved

Here’s the point, Flash Player IS a ubiquitous, cross-browser, cross-OS virtual machine enabling next generation web experiences. Flex is a simple tool for developers to build applications that execute in the Flash virtual machine. In most use cases Flex applications take less time to build and result in better user experiences. Flex isn’t for everyone, or for every use case, but I hope my experiences have shed light on the whether or not Flex and Flash are a good fit for you.

So despite the caveats, I still think this hack is sufficient enough for many applications. Flex engineering is really working hard to make this work for everyone. In the mean time what is outlined here may likely help you to dramatically reduce SWF size. Read on to find out how.

Quick Start

I’ve created 3 RSLs, a small one, with just the dependencies of mx.core.Application and a medium one with what I guessed were the 20 or so most commonly used components, and then a large one with over 30 other components. Each RSL does not include the contents of the smaller RSLs. So if you want to take advantage of this technique using the medium RSL, then you will need to use the medium AND the small RSL. Here is table with the information about the RSLs:

Once you have decided which RSL to use, follow these instructions:
1) Download the SWC for the RSL(s) you want to use from ws.jamesward.org
2) Fix your build path
2.1) If you are compiling via Ant or the command line, then specify your external-library-path and runtime-shared-libraries like:

2.2) If you are using Flex Builder then go to Project -> Properties -> Flex Build Path -> Library Path -> Add SWC -> [Enter or browse to the first SWC] -> Add all the SWCs you will be using. Then select a SWC’s RSL URL and select the Edit button. Change the Link Type to “Runtime shard library (RSL)”, set the RSL URL to the correct swf url on ws.jamesward.org, deselect the “Auto extract checkbox”, and then select the OK button. Repeat this for each SWC. When done, select the OK button to exit the Project Properties. Here is what my Build Path looks like:

2.3) If you are using FDS, then just add the SWC(s) to your flex/user_classes dir and update the runtime-shared-libraries accordingly in the flex-config.xml file.

3) Recompile your Flex app (if Flex Builder didn’t do this for you automatically) and the file size should be significantly lower!

4) One more caveat… You have to actually load your application from a web server for it to work. This is due to the Flash local OR network sandbox. Maybe someone can suggest a better workaround.

How It Works

This all starts with the Preloader. The out of the box preloader doesn’t support cross domain loaded RSLs. If you use my hosted RSL(s) then you don’t need to worry about this since it includes the patched Preloader. However, if you are interested in really knowing how this all works, or if you want to download the source code and play with it, then here is what you need to do. In order for your application to be able to use the classes in the crossdomain loaded RSL, the Preloader needs to specify the securityDomain for the loaderContext of the RSLs. So in the loadRSL function of my patched mx/preloaders/Preloader.as file I have:

The source code I use to build the RSLs is available on Source Forge. If you want to play with the code, then you will need to copy the Preloader.as from the Flex SDK’s source code, update the RSL loaderContext as noted above, and add the import for the flash.system.SecurityDomain class.

You can also see that I have a wildcard crossdomain.xml policy file on ws.jamesward.org which allows Flash player to load the RSLs no matter what domain the requesting application is hosted on. One quick note on crossdomain policy files, since I don’t think it is said clearly enough, and often enough…
DO NOT EVER PUT A WILDCARD CROSSDOMAIN POLICY FILE ON A DOMAIN IF EITHER OF THE FOLLOWING APPLY:
– THE DOMAIN IS USED FOR COOKIE BASED OR BASIC AUTHENTICATION
– THE DOMAIN IS ON AN INTERNAL NETWORK

Now about the small, medium, and large RSLs… For now I opted to use just three RSLs to keep it simple. I am using just simple linker classes and compc to create the SWCs, then expanding the SWCs to get the SWF, which is the RSL. You can see all this in the source code, specifically, the build.sh file. I have also guessed at the best way to organize the RSLs (as far as what classes go where), but definitely want to hear what others think.

Now the fun part… To prove this all works, first go to the test app on www.jamesward.org and watch as the RSLs are loaded from ws.jamesward.org. You should now have all 3 RSLs in your browser cache and if you now go to another test app on a different domain the application should load much faster since it only needs to load 72K instead of what would have been over 400K (my test app doesn’t use all the classes in the three RSLs).

The Future?

I’d really like to hear feedback if this is a viable hack for those looking to reduce Flex app size. Let me know if you plan to use this technique, or if you don’t, why? What should be different? Also, I think someone could further hack the preloader to support failover and md5 checksums. Any takers?

Thanks in advance for your feedback!