Flex Architecture and Design Patterns

A lot of my readers and clients have been asking for advice and help around getting Flex application architecture right. In some cases, these capable developers are struggling to morph their initial fancy toys into robust applications.

If you have seriously dabbled with Flex, you probably can empathise with them. However, if you haven’t delved into Flex at all or have minimally glanced at its surface, you are probably stunned in amazement and possibly ridiculing the indiscipline and lack of knowledge of these developers. Interestingly though, the shortcoming isn’t of the developers alone and the problems aren’t because the framework is flaky. Its just that you can code yourself into a corner despite your proficiency in MXML and AS3 and this problem is not new. The fact that: “fluency in a language and the core framework != fluency in building an application effectively using it” is well established across multiple languages. We have all seen similar problems surface with C++, Java, .Net, PHP, Python, Perl, Ruby, JavaScript and pretty much any other widely used language.

Over the years the community of software developers have questioned, theorized and debated over the root causes of failures emerging from bad application design and inappropriate architecture.  The viewpoints and thoughts are varied (An illustration of which is beyond the scope of this post. I may write about it in a separate post in future.) and there is no consensus on the right solution yet. However, there are some points of agreement and universal appreciation. One such topic of agreement, is the notion of leveraging design patterns. 

Design patterns have existed from the time the discipline of software development was a toddler back in the 70s, when it learnt to avoid its initial mistakes. Back then though, these patterns were not cataloged or adapted for specific areas of applicability. Now as the discipline is maturing into a teenager towards the end of the first decade of the 21st century, design patterns are entering the standard vocabulary of an average developer.

So, a Flex/AIR developer today can learn a lot of the theory about essential design patterns from the Gang of Four book or browse through the useful bunch of patterns applicable to enterprise application architecture. In addition, he or she could pick up one of the two design patterns books that pertains to AS3, namely:

Armed with all this knowledge, a Flex/AIR developer can hypothetically apply these gainfully to a real project. However, at this last link in the chain the story often breaks. Developers are left with tons of open questions around how to exactly use all their learning in the context of the core Flex framework features.

Its not a trivial effort to wire design patterns in conjunction with the existing framework classes. Using structural patterns with existing class heirarchies is not automatic and implementing behavioural patterns on top of the default flow is not intutive. In addition, you are left guessing on what could be implemented with AS3 alone and what could also rope MXML in.

At this stage, some developers just give up and some others seek refuge under any of the existing aggregations, especially if it seems to have official endorsement (read “Cairngorm”). Now, “giving up” can lead to code spaghetti and “seeking refuge” blindly can leave you in an obfuscated labyrinth, especially when you are deep into transforming your toy into a serious business application.

What then is a solution to the problem? How can one get Flex application architecture right?

To answer these questions to an extent, I wrote a chapter titled : “Leveraging Architectural and Design Patterns” in my book — Advanced Flex 3. That chapter neither addressed all the issues not did it include details on implementing these patterns in Flex. It merely discussed the topic at a very high level. Even then, many found it immensely useful. Going by the positive feedback and the following questions from the readers, I could guess that the thirst to learn more about Flex design patterns remains unquenched.

Therefore, I am starting on 3 related yet distinct initiatives, which might help you all. These are:

  • Thorough hands-on Flex architecture mentoring sessions
  • Three chapters instead of one on architecture and design patterns in Advanced Flex 4 (the next version of Advanced Flex 3)
  • A free book — “Flex Design Patterns” — on all aspects of architectural and design patterns in Flex. Chapters from which will be available for download right after they are written

In addition I am working actively on getting Fireclay ready for prime-time. I hope Fireclay will be a compelling and unique Flex framework when its version 1.0 is released.

If you would like to learn a lot by doing and want to gain substantial mastery in 3 days flat, then join me at the Flex Architecture BootCamp, the first of which is coming to New York between March 23 and March 25, 2009. Find out the details about this event at the Flex Design Patterns Eventbrite site

At the Flex Architecture BootCamp, you will — 

  • Learn how to build enterprise grade Flex applications
  • Learn to leverage the common design patterns in Flex and ActionScript 3 applications
  • Understand what Cairngorm, PureMVC, Mate, Prana and Fireclay are all about
  • Learn to preempt problems involved in building complex enterprise grade Flex applications. Build applications reliable, scalable and performant from the beginning.

More information online at the Flex Architecture BootCamp eventbrite site. In a few days I will announce the schedule for this BootCamp at other cities, which include Chicago, Atlanta, Dallas and Seattle.

When you register for the bootcamp at New York, don’t forget to avail a $75 discount using shanky_org as the discount code.

In future posts, you will hear from me on when I may start writing Advanced Flex 4 (its definitely not happening till Flex 4 beta is out and that I think isn’t happening until May 2009).

Information on the free book — Flex Design Patterns — will be available soon.  I am currently trying to setup a repository and a methodology to manage the writing process. I am keen to use the docbook format and may use the GitHub to host all content and code. If you have any suggestions or recommendations on any alternative tools, then please chime in.

That it for now, but you know a lot’s coming, so stay tuned!

friendsofed.com Hosed!

Unfortunately, friendsofed.com is unavailable!

Where you could normally see tons of information on books they had published, code downloads associated with those books and more, stands a page advertising domain renewal services. This is what the page looks like today —

friendsofed.com Hosed!

friendsofed.com Hosed!

I was made aware of this rather awkward situation by readers of my book Advanced Flex 3. The site is down means they can’t get hold of the code for the examples in the book anymore. Oops! that no good.

So I am writing to inform all my readers of the following:

  • I don’t know why the site is down but my guess is that it relates to some administrative goof-up. If you read the top right corner of the current page, it says — “friendsofed.com expired on 2/15/2009 and is pending renewal or deletion“. Don’t worry I am hopeful normalcy will be restored soon. I sent a mail out to the publishers asking what happened. If I get to know why this has happened and when things will be back, then I will share that information with you for sure.
  • I have setup a GitHub repository for the Advanced Flex 3 source code. The URL to the repository is: http://github.com/tshanky/advancedflex3. Its empty now but things should be there soon. In the near future I will co-ordinate with my co-authors and publishers and try and get the entire code up there. Then not only will you have an alternative place to grab the code  from but it would also be possible for that code to continue to evolve.

That’s all for now. Thanks for your patience.

Prefixing Fx

Adobe’s Flex team seems inclined to move away from clean design.

Flex framework’s current stable version is 3.x and the Flex team at Adobe is actively working on getting the version 4.x ready this year. At this time, the core SDK of Flex 4, codenamed Gumbo, is evolving through an open source process. From peeking into its initial version, it looks promising as there are serious attempts to create a clean separation of behavior and presentation in the components, apart from the tons of nifty enhancements throughout the framework. (I promise to write about some of the forthcoming features soon)

However, one design decision in the midst of all this goodness seems rather odd and alarming. The Flex team is proposing to prefix Gumbo component names with the letters “Fx”. Lets try and understand what this means.

In Flex 3.x and 2.x you have a button component, which you access within a flex application using <mx:Button>. Here the name of the component is Button and mx is the namespace within which this component resides. Now in 4.x you still have the Button component but it deviates majorly from the component by the same name in the 3.x or the 2.x version of the framework. Its possible developers may like to use both versions concurrently and that’s where there is a need for the two entities, i.e. buttons, (with the same name) to be identified distinctly.

Simply said, how do you make sure the two versions of Button work together without causing confusion in the program. The answer to this question is simple and time tested: Put them in different logical buckets. 

This solution of putting things with same names into logically diferent partitions seems to work well in many situations. This is how two classes by the same name are differentiated — they are put under different package structures. For example a.b.c.Foo and x.y.z.Foo can co-exist as far as they are referred with their fully qualified names. This is how XML elements with the same name but from different schemas are reconciled. This is how variables with the same name but within different scopes are resolved.

However, this simple solution seems to evade the Flex team’s considerations. They believe logical partitioning (which translates to namespaces in the case of Flex components acessed by their XML tags) can be confusing for the beginners.


Common Sense Reasoning

Common Sense Reasoning

So they propose instead that we prefix the names of all components whoes names clash with existing ones with the letters “Fx”. In other words our <mx:Button> in Flex 3.x or 2.x, which by the way is affectionately now called “Halo”,  becomes <FxButton> in Flex 4, which is also referred to as “Gumbo”.

If you use namespaces instead then this same Button in Gumbo will be <fx:Button>.

If we follow Adobe’s suggestion we may land up with something like this —

  • Halo — mx:Button
  • Gumbo — FxButton
  • Mumbo (or whatever they choose to affectionately call the next version) — Fx2Button or FxFxButton or MumboFxButton
  • Jumbo (possibly the following evolutionary version) —  Fx3Button or FxFxFxButton or JumboFxButton

Would you not just call a button a Button and have the namespaces decide weather its from the Halo, Gumbo, Mumbo or Jumbo clan?

If you would like to help Adobe make a sensible decision in favor of namespaces (i.e. using fx:Button instead of FxButton for now) then please go ahead and vote for this bug on the Flex JIRA.