Event-based architectures for Adobe Flex

I had a number of interesting conversations in the last few weeks with developers who were experiencing life-cycle issues in their Flex applications, especially when their apps were run on slower machines…or even smart phones. They eventually had figured out that there were certain places in their apps where they had hardcoded properties into Classes. And, when those properties weren’t initialized in the right order…the code block which requested those properties failed with null exception errors.

Since Flex doesn’t have threads we are dependant on the linear execution of the code, which just so happens to include MXML, ActionScript and occasionally JavaScript. That means, for the most part, that your code is executed one line at a time, in the order in which it was written. 

To give you an example of how this can go wrong: if you are expecting an MXML custom component to be initialized with all its properties populated, you’ll get null value exceptions if this hasn’t occurred when you try and display that custom component. And, when you look at in the debugger you’ll be astonished to see all your properties are null or uninitialized in some way.

The bottom-line is if you don’t understand the life-cycle of your app you could end up severely beating your head against a wall for hours (or days) trying to figure out what’s going wrong. I don’t know why, but Adobe doesn’t talk much about life-cycle. To me, it’s mission critical to understand it. If you want to build anything more than very simple applications, I gaurantee you’ll eventually have to deal with it. Now fortunately there are some excellent articles out there. I highly recommend this excellent PDF by DevelopmentArc. Read it!

I also recommend making your architectures more loosely coupled, and event-based, rather than expecting immediate results. It may seem counter-intuitive at first. What it means is you can tie your code together based on something that happens in the future. And, your app will wait until that event occurs, then it will proceed as directed and not a moment sooner. 

So what am I talking about? For example, if you make a request to a REST Web Service, you can assign an event dispatcher to fire off when the response payload has been received and an event listener somewhere else in your app will wait for that event to occur. Sometimes servers take a while to respond, or maybe the internet was slow, or maybe the smartphone temporarily had a bad cell connection. When that happens, it will delay when your app recieves the payload. Or if you don’t receive a payload back after a certain period of time, you can throw an error event. All these types of scenarios can be gracefully handled with built-in ActionScript events as well as custom events that you build.

What’s the alternative? If your application immediately asks for a result and the response payload got delayed, guess what? You’re app will fail or throw an error.

I also want to throw one more bone of caution your way. Events themselves are subject to what’s called propogation. You may not want to, but you really do need to read as much about propogation as you can! Once you have a basic understanding of both application life-cycle and propogation you will be able to build much more robust applications. And in the long run that translates to more time you can dedicate to watching basketball, football, or whatever else you want to do with your new found “free” time.

So, my suggestion is make judicious use of custom events. Here’s a short article from Adobe on how to do it.


DevelopmentArc – Understanding the Adobe Flex® 3 Component and Framework Lifecycle

Adobe – Dispatching Custom Events

Adobe – Event Propogation

Improving Browser performance and stability – will web workers help?

The single-threaded nature of JavaScript is an old tradition that needs to go away. It was great in the wild-west, internet days of the 20th century. But, today we have more complex needs that are being driven by the advancements that are happening around good old JavaScript as we know it, such as…on-going advancements in HTML 5.  

The reason I bring this up is because I’ve been watching the discussion on Web Workers as it has evolved.  It’s a brave attempt to bring a standard for implementing some sanity on this ancient notion of single threading. Now, I do want to say that this post isn’t about debating the merits of web workers, per se. It’s about giving developers better tools on which to build web applications for end users. I’ll be the first to agree that many developers (but not all!), for a variety of reasons, build apps like factories, but without many quality checks.

One argument the pro-single threaded parties claim is that doing away with single-threading will make things even more complicated for the companies that develop browsers and the developers that build apps on them. And, in effect, you’d be giving them (web app developers) free license to create even more terribly built web pages that crash browsers.  For brevity sake, I’m only picking this one out of many possible arguments, as the one that comes up most often in discussions.

I also don’t ever recall seeing a browser vendor themselves saying something like this publicly, but it’s possible.  This is a very weak argument that won’t stand the test of time. Sure, as we build more complex apps then there will be more of both good and bad apps. That’s just the way things work. There’s no way we would ever have a single authority that reviews all web apps before they are published. Perhaps, similar to what Apple does with iPhone apps. Not only would it be impractical, but it certainly seems like it goes against the spirit of the internet and WWW.

I fall into the camp of evolving the tools to better to fit the ever-changing and growing needs of the end users. End users don’t understand the limitations of the browser technology.  They don’t need to and shouldn’t be expected to. All they know is that they want to see ever more visually stunning applications that run well and don’t crash all the time.

Developer tools and technology are much, much more advanced now than when the venerable Mosaic Web Browser hit the scene back in 1993. As an example, all eyes are on HTML 5 (more on that at a later date), and certainly we have the well-known browser plug-ins: Flash and Silverlight, and each has their own development kits. These technologies enable the building of some of the most eye-catching websites, and they really opened people’s eyes on what the web experience should be more like.

Now, I am eyes-wide-open about this. There are some well-documented, but not well understood existing limitations related to the web surfing/development experience as I blogged about here. But, merely saying things should not change because it will become too complicated isn’t a good enough reason to, well…not change.  There are lots of smart people out there that love solving these types of problems.

So, I have a few suggestions of my own for the browser vendors and others to debate and work on. I think web workers are huge step in the right direction. But I also think there’s some other more strategic things that browser vendors could be doing that I think would also help. To me these are just as important as evolving the web standards, perhaps even more so. This is about browser vendors officially providing guidelines for us on how to do our job better:

  • Best Practices Document. All the major vendors should publish web development best practices for HTML and JavaScript development. And, I’m not talking about the W3C standard. That is what’s expect, but not actually what’s implemented. For example, I did a quick search of “web development best practices” using Google and Bing and the very first result I found was a short, not-really-so-helpful article on the Apple web site that was written in 2008!
  • Online HTML/JavaScript Validation engine(s). Each browser vendor should publish their own online HTML/JavaScript validation engine. Or better yet would be if someone builds one site that checks all major browsers in one shot and provides actionable feedback. I’m aware of other types of validators such as this one by W3C for HTML and the like. But, in general right now it’s just a hodgepodge of 3-rd party tools and guesswork as to whether a web app is working right. And, if you are like me and running the web debugger all the time, you’d know how many broken web pages there really are.


The pace of technological change: Do Android’s really dream of electric sheep?*

Google’s Android v1.5 (Rev 1) was released in April 2009. In 2010, there were three major dot-X releases of the 2.x platform: v2.1, v2.3 and finally v2.3 in December 2010. According to Gartner in a February 2011 report, Android grew from 3.9% of the worldwide smartphone market, to almost 23% in the span of one year, from 2009 to 2010. That’s roughly 888% growth.

As a developer, I’m awed by the pace of change and the rate of adoption. I like being on the cutting, and now the consumer competition is furious for mindshare, and the mad push is on for developers to build applications that take advantage of the latest software and hardware technology. It’s a developers dream. Cool new toys, ever better functionality and hardware with new releases just six months away!

And while I like to simply pay attention to the technology and ignore everything else, I’ve been asked a number of questions recently by other developers who work in a variety of industries from around the world, and to which I have no answer. If you read this please share your thoughts:

  • How do we plan software development cycles around mobile phone system(s) that change dramatically every six months? We are talking about both hardware and software.
  • If I build an application now, will it still work on the next generation of hardware which will come out in one year or less?
  • Will applications that were built on the latest mobile OS still be backward compatible in one year?

What’s interesting is we have been faced with similar questions before when Adobe Flex, Microsoft Silverlight and even HTML 5 were announced. And, yes, they are changing the way we build applications and to a large extent changing what our users expect to experience. However, internet browsers have been around for a while, web development technologies in general aren’t exactly new, and all computers these days come with a pre-installed browser. But, all the sudden we could more quickly develop beautiful applications in days and weeks that used to take many months, or years. And, it’s been an eye-opener as far as our surfing experiences go.

Many commercial applications have never been more powerful with built-in charting and dynamic access to data with very graceful interfaces. These applications opened our eyes to what’s possible by letting us build applications independent of the machine they ran on. And, in a sense it was liberating. The idea of building one version of the software and then deploying it across many machines and devices became true. I, for one, touted that I no longer had to worry about esoteric items such as pointers and garbage collection. The browser took care of all that for the most part, even though it still had a few issues.

Maybe I celebrated too soon. What’s changing now is the pace of adoption which is in the form device that fits in your hand, and you can carry with you anywhere even when you hike, that accesses the internet, and that has similar functionality to a desktop/laptop system. Smart phone access is changing how people communicate: live, work and play. It’s becoming the primary connection to the internet in many parts of the world. It’s becoming a primary work tool while on the road.

We, as developers, are at the heart of this change and with a front row seat.

Our use cases are changing to accommodate people accessing our applications while they are standing in line ordering their morning coffee. We’re back to looking at native applications which don’t run in the browser and are subject to all sorts of interesting limitations and challenges. We are back to adapting code to different devices, limited battery life, testy internet connections, varying processor power, and dealing again with problems related to device drivers.

It’s funny that I caught myself thinking how nice it would be to have a software framework that would let me abstract away all these pesty problems that low-level code development entails: a sort of Flash Player environment for low-level code on a mobile phone. I mused about how easy it was to use FlashBuilder “Burrito” to convert my Adobe Flex applications directly to Android without having to deal with Java code (which works very nicely by the way). Or, do I build a rich functionality web app?

But, you know, I chuckled as soon as I had a requirement that asked for closer access to the smart phone hardware and operating system: things related to power management, and getting more information from the device GPS. Do I wait until the functionality I need is built into an abstraction library…or do I build a native application today? Which applications do I build for the web, and which application should be native?

These are all business question that many of you will also face. I’m certain it’s being asked thousands of times around the world. And ultimately, whatever the answer is… it will change the way we all do business.

*I pay full respect to Philip K. Dick’s 1968 science fiction novel, Do Androids Dream of Electric Sheep?, that served as the primary motivator for the movie Blade Runner which was first released in 1982.

The browser as an operating system

Having a basic understanding of how our web applications affect browser performance is the key to determining whether the apps you build will be great, and which apps will be a miserable experience for your users. You can have the worlds’ best looking app with the nicest user-interface ever, but if it runs horribly on most visitors machines or phones then you’ve done your end users a massive disservice.

I contend that the browser as a web application programming environment should be treated as its own operating system with its own well defined dependencies. If you have a basic understanding of how these dependencies work, you’ll be able to build better, more stable, faster applications.

We are constrained in what we can build because browsers provide a finite environment in which to play in. To make things even more fun and challenging, in just the last five years we have gained access to some very powerful tools to build even more complex applications, such as Microsoft’s Silverlight API, and Adobe’s Flex/ActionScript API. Now we can build applications with very rich graphics in days or weeks that would have taken many months or even years before these tools became available. And, web applications until only recently gained the ability to semi-directly interact with the operating system to perform operations such as save or retrieve files from local hard drives. In the ‘dark ages’ we had to bounce files off a proxy server before being able to download them to the local machine. How we interact with the local machine is ultimately controlled by what the browser will allow.

The browser sandbox

Browsers provide us with a well-defined sandbox in which our apps can run, and from a developer’s perspective it includes the following:

  • A JavaScript engine
  • An HTML parser
  • User Interface rendering engine
  • Add-ins/Plug-ins (e.g. Flash Player, Silverlight, etc)
  • Cache space (includes cookies and local stores like in FlashPlayer)
  • Access to the internet
  • Access to local resources

It’s also important note, and if you’ve been building web apps for a while now you’ll know, that browser vendors don’t implement the various proposed standards exactly the same. For example, Internet Explorer may display a certain CSS tag different. Here’s an interesting comparison chart.

What about hardware?

I’m also not saying we don’t need to pay attention to the underlying operating system. In fact, we absolutely do need to pay attention to the following. However, we interact with them only indirectly, and because of that we tend to forget just how important they are:

  • CPU
  • Memory
  • Graphics card
  • Internet connection

Mobile devices are a great example. Mobile devices are getting more powerful all the time, but when they try and chug through a fully decked out web page, it takes them longer than a typical desktop or laptop. I’ve had developers tell me an app that’s running slow on everyone else’s machine was running just fine on theirs. What the developer forgot was he had the latest, greatest, hottest laptop out there with 8 GB’s of memory and an excellent internet connection! By way of example, I posted a screenshot at the bottom of this post of another website that even my quad-core laptop used between 50 – 80% of its resources to  load the page.

Simple Tests

Here are some simple tests to tell if you web app is a good one that will meet the needs of your end users:

  1. How much CPU does it consume? Test it on a moderately configured machine, typical of what your users might have.
  2. How much memory does it use? And, how much memory over time? Browsers can be notoriously leaky, but your program may be contributing to it.
  3. Is everything in the correct locations in the user interface at various common browser sizes? (e.g. 1024×768, 1280×800, etc.)
  4. Does it cause temporary slowdowns or lockups?
  5. Does it crash the browser or browser panel?
  6. Does key functionality and layout work consistently across the major browsers?
  7. Does your app work consistently across all the devices you wish to support, including mobile?

A Few References

Here are a few articles and websites for that are handy to have as references:








CPU Usage loading web site with quad-core laptop
Loading an unnamed website using a quad-core laptop

From 56K Baud to FiOS – how far have really come?

While searching for a connector in some boxes of long forgotten electronics detritus, I came across a 56K PC Card modem from 3Com. I immediately grabbed the card and thumbed it over in my hands and wondered how far have we really come since then? For those of you that never had dial-up access to the internet, this was the hottest ticket back in the ancient days of 1999. 56K was smoking back then! My conclusion: we’ve come far, but we also have taken many steps backwards. We have, in many respects, become victims of our own success.

Let me explain. Yes, first let me acknowledge that there are companies like Verizon that sell FiOS with download speeds of 15Mb/second or greater depending on how much money you want to pay. And, there are plenty of DSL and Cable internet vendors that offer 3MB/second (or more) download speeds. Oh, and I can’t forget the promise of 4G cell phone speeds.

But, reality is a far, far different animal than promises. There are plenty of times when you may not get anywhere near the download speeds promised due to a variety of technical issues. In my experience, it’s actually rare that I get to benefit the full capabilities of the cutting edge, 21st Century internet technology at my disposal. For example, if you have a 15Mb/second FiOS connection it doesn’t guarantee that every website you go to will download at 15Mb/second everytime. That’s a fact.

On any given day, we are all dependent on many factors that affect internet download speeds. The list is huge and is by no means limited to the following. Let me roughly say that all these items affect how fast something will download:

  • Number of users hitting a particular website
  • That websites hardware and bandwidth capabilities
  • General internet backbone traffic
  • Your own internet/cable modem
  • General packet collisions/losses/overhead
  • The wire or wireless connection you are using
  • Your own network card or wireless card on your computer.
  • Background processes running on your computer
  • Cell phone tower signal strength and number of users
  • And so, so many more…

I could go on for several pages, but you get the idea. Since I’m a web application developer, I have to pay attention to how fast pages load. And I often monitor and test internet connections to try and figure out where the performance problems are. Perhaps, this makes me more sensitive and less patient when I don’t receive the full benefit of the connection to the internet when it’s offered to me at my home, at work, or when traveling and using a conference or hotel wireless connection.

This is the internet age right? I have come to expect instantaneous downloads and hiccup free streaming video, but it’s very rare that I can watch a YouTube video without it stuttering and pausing to re-buffer every 15 seconds. Or, how many of you have continuously fast access to the internet via your AT&T iPhone? If you never have any problems you’re either lucky and live in a less congested area, or you aren’t a power user and are okay with downloads occasionally taking longer than expected.

There’s an immutable law that we always forget about it and it says “bandwidth is finite”.  We are very capable of building applications that consume more and more bandwidth every day.  There are millions of videos added to the interent every hour and ever larger files being downloaded. And, as tens of millions of more people buy smarthpones, they too are continuously consuming internet bandwidth 24 hours a day. And, so on and so forth the argument goes on.

In conclusion, as web developers we can do our part for improving people’s internet experience by optimize your web applications as much as possible. Make your web applications file sizes as small as possible, use lazy loading, run code optimizers, consider binary formats for moving large data back and forth, and optimize images were possible. In the end, we will all benefit from a better internet experience.

IE 8 Developer Tools – A great step in the right direction.

Even though IE 8 Developer Tools have been around for a while, since Internet Explorer 8 Beta 1 (circa 2008), there are still a lot of developers out there who aren’t familiar with it. And, it’s well worth the time learning about it. Some of you may be wondering who develops against IE? Well, before I dive into the details, I wanted to say a word about that. According to w3schools as of October 2010, IE represents 29% of all browsers, and IE 8 browsers make up more than half of that number.

You should research your own website stats, and companies such as w3counter provide developer tools for that. In general, it’s fair to say that most consumer sites get a lot of IE-based traffic, and testing your app against IE is a good idea. If you don’t, there’s a strong chance you’ll frustrate a bunch of potential users and they may not come back, ever. If you run an internal site for an organization then you may have more control over which browsers (and browser versions) are used, and your life is probably easier than the rest of us.

I know I personally didn’t like testing against IE because with IE 6 and 7 the tools were pretty much non-existent and extremely unfriendly to web developers. I have to say that IE 8 made a huge step forward in my eyes when they included Developer Tools. Sure I have plenty of gripes, but all-in-all my job got much easier. Instead of blindly making changes and then reloading the page to see the results, I now do the majority of my testing and prototyping right in the Developer Tools.

Here just a few of the tools I find particularly useful:

  • Built-in Script debugger. Yep, it includes console, breakpoints, locals, watch and call stack.
  • Edit on-the-fly.
  • Inspect CSS.
  • Select element by click (Ctrl + B).
  • Clear cookies for domain
  • Tools > Resize (on-the-fly)
  • Show ruler.
  • Save HTML or CSS changes to a file.

I still have a wish list of things I’d like to see added, here’s my top five:

  1. Built-in HTTP transaction viewer. I mean they have Fiddler, why not bolt key pieces of it into the browser tools rather than having to launch Fiddler separately?
  2. DOM attribute inspector for those times when you have to dig deep; for example, when there are differences between content attributes and DOM attributes.
  3. Cookie Manager – including the ability to inspect/delete individual cookies.
  4. Automatically associate a selected element with its DOM index. Don’t make me have to hunt for it in a different view and then compare.
  5. Continuous hover and select item on page, without needing to click Ctrl + B every time. Sometimes I want to scan multiple items quickly.

So that’s it. This tool should save you a ton of time. Are there any items that are your favorites, and what do you want added to the wish list?