“If everyone is moving forward together, then success takes care of itself.” – Henry Ford

The HTML5 Family has been receiving a good deal of coverage lately, and rightfully so as many next generation browsers – specifically those in the Mobile arena based on WebKit: Android, iPhone, Blackberry etc. are now beginning to implement it’s specification, or parts thereof. On the Desktop more HTML5 support is also being seen in the latest versions of Safari, Chrome, Firefox and IE9.

Now its obvious there are some rather strong opinions regarding HTML5; some quite positive while others more negative. And while I certainly believe the notion that HTML5 will be a so-called “Flash Killer” is rather ridiculous – especially when considering the typical enterprise is far from installing the next generation of any HTML5 compatible browser – I do believe that once everyone gets passed all of the hype the HTML5 Family will certainly play an important role in the future of the web; and currently, in the mobile Web space, that future is now.

However, and perhaps more importantly, while some developers building RIAs targeting the Flash Platform often criticize or condemn what could be perceived as a rival technology, personally, I tend to see things quite differently. In fact, I believe Flash Applications running in the browser will ultimately benefit from the HTML5 family of technologies as they can leverage them and work in tandem to provide some very interesting possibilities. So with that being said I thought I would share my seemingly unique point of view as I feel the HTML5 Family brings complimentary potential to the RIA space, but more importantly in the Mobile market, and that is certainly a context many of us will be developing for.

To a certain extent, I consider myself technology agnostic, that is, I consider myself to be a software developer with a focus on the disciplines of the User Interface Layer of what could be considered a traditional Desktop or Mobile Software Stack. To that end the Flash Platform has always been a choice platform for delivering highly scalable and maintainable RIAs. In addition to this, the HTML5 Family and it’s associated mobile frameworks, Sencha Touch in particular, present some rather compelling and exciting possibilities in the Mobile Web Space in general, and within the context of Android, iPhone and iPad specifically.

Its important to understand that every technology has its place and any technology that presents practical and exciting new possibilities within both an existing (Desktop/Web) and somewhat new (Mobile Web) paradigm is worthy of exploration or at least an informed understanding. As with the Flash Platform, the HTML5 Family of technologies presents potential for pushing the boundaries of the Web and Mobile Web. Likewise, as with Flash, the HTML5 Family has its own strengths and weaknesses. However, both technologies are quite unique in their own right. So if you are reading this and develop RIAs primarily targeting the Flash Platform, but also enjoy working with other RIA technologies, then by all means please read on, otherwise feel free to read one my many Flash Platform related posts, or stay tuned for many more to come.

A Brief Overview of the HTML5 Family

For anyone who is unfamiliar with the HTML5 Family, let me first give you a brief overview of the technologies I feel encompass what is already a rather overloaded term. In general, on a very high level, I would summarize the HTML5 Family simply as follows:

• HTML5
• CSS3
• JavaScript

However, there are certainly more associated technologies which themselves further make up what could be considered the HTML5 Family, some of which are (based on current specification status):

• Microdata
• Geolocation API
• Device APIs
• Web Storage (localStorage, sessionStorage) APIs
• Web SQL Database API
• Web Workers API
• Web Sockets API

HTML5

First, HTML5. HTML5 is the next major revision of HTML which aims to advance the open Web through web standards and semantically rich content. In general, HTML5 provides a content model which can be broadly defined into the following categories: Metadata content, Flow content, Sectioning content, Heading content, Phrasing content, Embedded content and Interactive content as well as form-associated elements etc.. HTML5 defines new tags such as canvas, audio, video, keygen, header, footer, nav, article, aside, datalist and more.

CSS3

CSS3 has been broken out into a collection of modules, each of which have their own specifications and are currently in various states of completion. These modules include such examples as Selectors, Transitions, Animations, Namespaces, Color, Fonts, Advanced Layout, Multi-Backround and more. Some rather amazing designs can now be created purely in CSS3.

JavaScript

Explaining what JavaScript is may seem like a moot point, however it is important to outline some key underlying specifics of the language. In particular, JavaScript is a weakly typed, dynamic, prototypal, object-oriented scripting language. Its prototypal nature is quite different from the classical concepts of traditional object oriented languages and, in order to get the most out of the language one needs to understand and embrace prototypalism and dynamism; otherwise it’s easy to (mistakenly) denigrate the language due to it’s lack of type safety and classical OO constructs.

Microdata

HTML5 Microdata provides a mechanism which allows machine-readable data to be embedded in HTML documents in the form of annotations, with an unambiguous parsing model. Microdata is compatible with numerous data formats such as JSON. Micro-data is intended to provide a standard to replace other similar concepts such as RDFa, from which browsers and other applications can discover relevant content based on the context of an applications markup. Such examples include markup for contact information, calendar events and more. This markup is understood by HTML5 compatible browsers which can then automatically offer to add the relevant content to the appropriate application. At an implementation level, microdata simply consists of a group of name-value pairs; with the groups being called items, and each name-value pair is a property.

Geolocation API

The HTML5 Geolocation API is rather straightforward; it simply provides a means by which the location of a device can be determined via a native API (as opposed to say, determining the clients IP address). The Geolocation spec is currently in last call status in the W3C.

Device APIs

Device APIs are client-side APIs which allow for direct interaction with native device services such as a device Camera, Calendar, Contacts etc.

Web Storage API

The Web Storage API allows for the persistence of local (permanent) and session based (browser session) data on the client. The API for Web Storage is extremely simple as it is based upon simple Key / Value pairs; with which Keys are simply Strings. Each site contains its own separate storage area.

Web SQL Database

While not a part of the actual HTML5 specification, the Web SQL Database presents some extremely interesting possibilities within Web Applications. The Web SQL Database provides a set of APIs which allow for the manipulation of client-side databases using SQL. The Web SQL Database is based upon SQLite (3.1.19) thus supporting the features as specified therein.

Web Workers API

Web Workers provide a mechanism by which web content can execute scripts in background threads. Web Workers allow for a much needed multi-threaded implementation for web based applications executing in a browser. While somewhat similar, Web Workers are different from threads in that they are primarily intended for executing long running, expensive computations and algorithms so as to facilitate non-blocking UI background processes. One specific aspect of Web Workers which has considerable positive implications for the web moving forward is that they run in native threads as opposed to Green Threads; as is the case in VM architectures. This is quite significant as it essentially means Web Workers can scale vertically. Considering the inevitable proliferation of multi-core desktop and mobile devices, this is certainly something that will prove advantageous.

Web Sockets API

Web Sockets provide native, full-duplex communications channels which operate over a single socket that enables HTML5 compliant browsers to use the WebSocket protocol (exposed via a JavaScript API) for two-way communication with a remote host.

If you are interested in learning more about each of these technologies I recommend the following resources:

• HTML5 Specification
• An Introduction to CSS3
• Microdata
• Geolocation API
• Device APIs
• Web Storage API
• Web SQL Database
• Web Workers
• Web Sockets

In the weeks to come I plan to go into further detail for each of these associated HTML5 Family technologies, providing working examples, specifically from a Mobile context. Where applicable, I will contrast each technology with similar Flash Platform APIs and concepts, as well as show how they can be utilized together to create some interesting possibilities.

Often I come across what I like to call “Misplaced Code”, that is, code which should be refactored to a specific, independent concern rather than mistakenly being defined in an incorrect context.

For instance, consider the following example to get a better idea of what I mean:

Taking the above example into a broader context, it is quite common to see code such as this scattered throughout a codebase; particularly in the context of view concerns. At best this could become hard to maintain and, at worst, it will result in unexpected bugs down the road. In most cases (as in the above example) the actual code itself is not necessarily bad, however it is the context in which it is placed which is what I would like to highlight as it will almost certainly cause technical debt to some extent.

Considering the above example, should code such as this become redundantly implemented throughout a codebase it is quite easy to see how it can become a maintenance issue as, something as simple as a change to a hostname would require multiple refactorings. A much more appropriate solution would be to encapsulate this logic within a specific class whose purpose is to provide a facility from which this information can be determined. In this manner unnecessary redundancy would be eliminated (as well as risk) and valuable development time would be regained as the code would need only be tested and written once – in one place.

So again, using the above example, this could be refactored to a specific API and client code would leverage the API as in the following:

This may appear quite straightforward, however, I have seen examples (this one in particular) in numerous projects over the years and it is worth pointing out. Always take the context to which code is placed into consideration and you will reap the maintenance benefits in the long run.

As you may be aware, Adobe currently has a private beta of AIR for the Android Operating System.

Although still in it’s early stages, the core platform is quite stable and support from the AIR engineering team has been very good while the pre-release forums have also been quite active with lots of useful information being shared daily. In just a little under an hour I was able to have two POCs demonstrating the Accelerometer and MultiTouch Gesture capabilities running flawlessly on my Droid. Additionally, I was also able to develop a very basic Geolocation prototype in next to no time at all which accurately conveyed latitude / longitude, altitude and even speed. In the time since I have been focusing on real world applications and the results have been excellent for such early stages of the platform.

Some notable features I have been working with are: GPS, Accelerometer, Multitouch / Gestures, SMS/TEL URI Schemes, IME, S/W Keyboard, Screen Orientation, Screen Dimming, Menu/Back keys and more.

As the pre-release and my applications built on AIR for Android progress I will share my findings as well as provide open source APIs, code examples, videos and / or screen shots of the apps I am working on, so stay tuned for more information.

Rather than going into any detail regarding my thoughts surrounding Apple’s updated iPhone developer license clause last week, I instead prefer to focus on the more exciting and positive developments the future has to hold for the Flash Platform in the mobile space; and at the moment, it’s Android

As you may be aware, beginning with Adobe Flash Player 10.1, the AIR 2.5 for Android SDK and Android, the Flash Platform will now begin to close the gap in terms of developing and deploying Web, Desktop and Mobile applications. Thus it appears this could open up some very exciting possibilities in the RIA space as, a write-once, deploy-anywhere solution for Mobile, Web and Desktop applications is obviously highly desirable.

For those of you unfamiliar with Android, it is a premiere software stack for mobile devices which provides an Operating System built on the Linux kernal, a very well designed middleware layer and core applications including an E-mail client, SMS program, calendar, maps, browser, contacts and more. Android also provides an Application framework, a Dalvik virtual machine which is optimized for Mobile Devices, an integrated web browser based on the widely known WebKit engine, SQLite storage, common Media support, hardware dependent Bluetooth, EDGE, 3G, WiFi, Camera, GPS, Compass, and Accelerometer support as well as many other features.

Originally developed by Android Inc., which was later acquired by Google, Android is now governed by the Open Handset Alliance; a consortium devoted to advancing open standards for mobile devices. Currently, over 50 mobile phones are expected to come shipped with Android in 2010. Moreover, Google and their hardware partners are now shipping 60,000 Android handset units each day! If this trend continues (which it certainly appears will be the case) this equates to over 21.9 million devices shipping with Android per year.

Traditionally, getting started with Android has been quite simple for developers who have experience with Java as one need only download and unpack the Android SDK distribution and install the Android Development Tools (ADT) Eclipse plugin. Managing different Android platforms as well as other SDK components is accomplished via AVD Manager which come with the SDK. As expected, the Android SDK also comes with a very high quality device emulator which feels similar to the BlackBerry JDEs device Simulators.

While developing applications for Android with ADT is certainly convenient (and quite fun), from a Flash Platform development perspective it is much more desirable (as well as economical) for developers to leverage their existing skill-set and APIs to develop a single application targeting Flash Player or the AIR runtime that will work with any device shipped with Android. And with Flash Player 10.1 and the current private beta of Android AIR 2.0, the Flash Platforms reach will now include the Android platform. The most significant of these new possibilities is the ability to develop a single application which supports both Web and Mobile devices alike. Thus considerably simplifying the development and deployment process. Of particular interest is the ability to leverage Mobile Device specific features such as Accelerometer, GPS, multi-touch, gestures screen orientation etc. from an AIR application.

Flash Player 10.1 will support devices running on Android that meet the minimum software and hardware requirements, which at the moment appear to be devices with an ARM v7 (Cortex) processor. Both Droid and Nexus One carry ARM v7. Architecturally, I am quite interested in seeing how this all comes together in terms of memory and cpu optimization.

Working in conjunction with Adobe, as part of the Open Screen Project, Motorola is helping to develop Flash Player 10.1 so it works on Android. Motorola will also be deploying the Flash Player broadly across its Android product portfolio going forward; releasing Flash Player updates for existing devices such as the Droid (which I happen be actively developing for).

Adobe is targeting the end of July 2010 to have the Android AIR 2.0 Beta and Flash 10.1 for Android available. For updates sign up for:

Throughout my career I have always been drawn to books which provide a practical way of thinking about software. Books of this nature have an emphasis on the fundamental principles which apply to all software engineering disciplines; and form much of the basis of the Agile methodologies many of us have come to appreciate.

From time to time I find myself going back to the seminal text The Pragmatic Programmer as it provides a great source of what should be kept in mind from day to day. I thought I would share some tips from the book with my readers that I find of particular value, and would be happy to explain them at length; in the context of real world software challenges.

Care About Your Craft
Why spend your life developing software unless you care about doing it well?

Provide Options, Don’t Make Lame Excuses
Instead of excuses, provide options. Don’t say it can’t be done; explain what can be done.

Critically Analyze What You Read and Hear
Don’t be swayed by vendors, media hype, or dogma. Analyze information in terms of you and your project.

Design with Contracts
Use contracts to document and verify that code does no more and no less than it claims to do.

Refactor Early, Refactor Often
Just as you might weed and rearrange a garden, rewrite, rework, and re-architect code when it needs it. Fix the root of the problem.

Costly Tools Don’t Produce Better Designs
Beware of vendor hype, industry dogma, and the aura of the price tag. Judge tools on their merits.

Start When You’re Ready
You’ve been building experience all your life. Don’t ignore niggling doubts.

Don’t Be a Slave to Formal Methods
Don’t blindly adopt any technique without putting it into the context of your development practices and capabilities.

It’s Both What You Say and the Way You Say It
There’s no point in having great ideas if you don’t communicate them effectively.

You Can’t Write Perfect Software
Software can’t be perfect. Protect your code and users from the inevitable errors.

Build Documentation In, Don’t Bolt It On
Documentation created separately from code is less likely to be correct and up to date.

Put Abstractions in Code, Details in Metadata
Program for the general case, and put the specifics outside the compiled code base.

Work with a User to Think Like a User
It’s the best way to gain insight into how the system will really be used.

Program Close to the Problem Domain
Design and code in your user’s language.

Use a Project Glossary
Create and maintain a single source of all the specific terms and vocabulary for a project.

Be a Catalyst for Change
You can’t force change on people. Instead, show them how the future might be and help them participate in creating it.

DRY – Don’t Repeat Yourself
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

Eliminate Effects Between Unrelated Things
Design components that are self-contained, independent, and have a single, well-defined purpose.

Iterate the Schedule with the Code
Use experience you gain as you implement to refine the project time scales.

Use the Power of Command Shells
Use the shell when graphical user interfaces don’t cut it.

Don’t Panic When Debugging
Take a deep breath and THINK! about what could be causing the bug.

Don’t Assume It – Prove It
Prove your assumptions in the actual environment—with real data and boundary conditions.

Write Code That Writes Code
Code generators increase your productivity and help avoid duplication.

Test Your Software, or Your Users Will
Test ruthlessly. Don’t make your users find bugs for you.

Don’t Gather Requirements—Dig for Them
Requirements rarely lie on the surface. They’re buried deep beneath layers of assumptions, misconceptions, and politics.

Abstractions Live Longer than Details
Invest in the abstraction, not the implementation. Abstractions can survive the barrage of changes from different implementations and new technologies.

Don’t Think Outside the Box—Find the Box
When faced with an impossible problem, identify the real constraints. Ask yourself: “Does it have to be done this way? Does it have to be done at all?”;

Some Things Are Better Done than Described
Don’t fall into the specification spiral—at some point you need to start coding.

Don’t Use Manual Procedures
A shell script or batch file will execute the same instructions, in the same order, time after time.

Test State Coverage, Not Code Coverage
Identify and test significant program states. Just testing lines of code isn’t enough.

Gently Exceed Your Users’ Expectations
Come to understand your users’ expectations, then deliver just that little bit more.

Don’t Live with Broken Windows
Fix bad designs, wrong decisions, and poor code when you see them.

Remember the Big Picture
Don’t get so engrossed in the details that you forget to check what’s happening around you.

Make It Easy to Reuse
If it’s easy to reuse, people will. Create an environment that supports reuse.

There Are No Final Decisions
No decision is cast in stone. Instead, consider each as being written in the sand at the beach, and plan for change.

Estimate to Avoid Surprises
Estimate before you start. You’ll spot potential problems up front.

Use a Single Editor Well
The editor should be an extension of your hand; make sure your editor is configurable, extensible, and programmable.

Fix the Problem, Not the Blame
It doesn’t really matter whether the bug is your fault or someone else’s—it is still your problem, and it still needs to be fixed.

“select” Isn’t Broken
It is rare to find a bug in the OS or the compiler, or even a third-party product or library. The bug is most likely in the application.

Learn a Text Manipulation Language
You spend a large part of each day working with text. Why not have the computer do some of it for you?

Use Exceptions for Exceptional Problems
Exceptions can suffer from all the readability and maintainability problems of classic spaghetti code. Reserve exceptions for exceptional things.

Minimize Coupling Between Modules
Avoid coupling by writing “shy” code and applying the Law of Demeter.

Design Using Services
Design in terms of services: independent, concurrent objects behind well-defined, consistent interfaces.

Don’t Program by Coincidence
Rely only on reliable things. Beware of accidental complexity, and don’t confuse a happy coincidence with a purposeful plan.

Organize Teams Around Functionality
Don’t separate designers from coders, testers from data modelers. Build teams the way you build code.

Test Early. Test Often. Test Automatically.
Tests that run with every build are much more effective than test plans that sit on a shelf.

Find Bugs Once
Once a human tester finds a bug, it should be the last time a human tester finds that bug. Automatic tests should check for it from then on.

Sign Your Work
Craftsmen of an earlier age were proud to sign their work. You should be, too.

I suggest keeping these tips, or a subset of them, as well as some of your own, somewhere visible; even if some appear rather obvious, as it will serve as a good general reminder of the things you should always keep in mind.

For the past 4 years or so I have provided quite a few AS3 APIs as Open Source to the Flex Community, via my blog. These APIs can typically be found at the Open Source AS3 APIs page however, the page is basically just a URI to a series of arbitrarily added AS3 source classes. It was originally intended to simply serve as a convenient location to access the source, and it had always been my intention to eventually break out all of these APIs into seperate SVN projects.

So with that being said I am finally in the process of making the structural changes I had originally envisioned. Moving forward I will begin the process of creating seperate SVN projects for these Open Source APIs; with the primary goal being to provide practical APIs that only require minimal (if any) dependencies on additional libraries, complete test coverage via Flex Unit 4 and Mavenized builds.

The first project to move over to the new project structure will be the AS3 collections project as the classes in this package, specifically HashMap, have proven to provide the most value according to community feedback.

So stayed tuned!

Just recently while going through some old files I rediscovered a quote I found a long time ago that is rather inspiring.

The quote is an extract from the book “The Mythical Man-Month”, and while the book was originally published in 1974 before being republished in 1995, I feel it will always remain relevant:

Why is programming fun? What delights may its practitioner expect as his reward?

First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. I think this delight must be an image of God’s delight in making things, a delight shown in the distinctness and newness of each leaf and each snowflake.

Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful. In this respect the programming system is not essentially different from the child’s first clay pencil holder “for Daddy’s office.”

Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning. The programmed computer has all the fascination of the pinball machine or the jukebox mechanism, carried to the ultimate.

Fourth is the joy of always learning, which springs from the non-repeating nature of the task. In one way or another the problem is ever new, and its solver learns something: sometimes practical, sometimes theoretical, and sometimes both.

Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.

Yet the program construct, unlike the poet’s words, is real in the sense that it moves and works, producing visible outputs separately from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.

Programming then is fun because it gratifies creative longings built deep within us and delights sensibilities we have in common with all men.

This quote really hits home with me, so I shared it with my team and felt I should also share it with the community, as I imagine it will also inspire all of you as well.

On occasion developers may find a need to quickly measure the time it takes for a request to a remote service to return a response back to the client without the need to employ an automated testing tool to perform the instrumentation. This information can prove quite valuable for performing application diagnostics on the client and, when measured in terms of code execution, monitoring at the execution level will always be a bit more precise than that which can be measured by using a Network proxy alone, such as Charles or Fiddler, etc.

Obviously there are numerous solutions which can be implemented to monitor the elapsed time of a service invocation, however it was my goal to provide a unified solution which could easily be implemented into existing client code without significant refactorings being required.

In order to achieve this I first needed to consider what the typical implementation of a service invocation is in order to isolate the
commonality. From there it is only a matter of determining a solution that meets the objective in the most non intrusive manner possible.

To begin let us consider what a “typical” service invocation might look like for the three most common services available in the Flex Framework; HTTPService, RemoteObject and WebService.

Based on the 3 above implementations we can deduce that the common API used when performing a service invocation is AsyncToken. So to provide a unified solution for all three common Services we could either extend AsyncToken or provider an API which wraps AsyncToken. For my needs I chose to implement an API which simply monitors an AsyncToken from which the duration of an invocation can be determined, thus I wrote an RPCDiagnostics API which can be “plugged” into an AsyncToken client implementation.

RPCDiagnostics provides basic performance analysis of a Remote Procedure Call by providing a message which displays information about the operation duration via a standard trace call. In addition, an event listener of type RPCDiagnosticsEvent can be added to facilitate custom diagnostics and Logging.

RPCDiagnostics can easily be implemented as an addition to an existing AsyncToken or in place of an AsyncToken. The following examples demonstrate both implementations.

Implementing RPCDiagnostics onto an existing AsyncToken:

Implementing RPCDiagnostics in place of an AsyncToken:

Implementing a listener to an RPCDiagnostics instance:

The RPCDiagnostics API and dependencies can be downloaded via the Open Source AS3 APIs page or from the below links:

RPCDiagnostics
RPCDiagnosticsEvent
Execution

One of the many welcome additions to the Flex 3.4 SDK is the inclusion of the Vector class. Vectors in particular are especially welcome as they provide compile time type safety over what would otherwise not be available when implementing custom solutions, such as a typed collection.

Essentially, Vectors are just typed Arrays. And while not as robust or powerful, Vectors are similar to Generics in C# and Java. When it is known at design time that a collection will only ever need to work with a single type, Vectors can be utilized to provide type safety and also to allow for significant performance gains over using other collection types in Flex.

I recently wanted to convert quite a few typed Array implementations to Vectors, however, the Arrays were being traversed with an Iterator. In order to reduce the amount of client code which needed to be refactored I simply implemented a Vector specific Iterator implementation.

If you are familiar with Iterator Pattern in general, and the Iterator interface in particular, then usage will prove to be very straight forward. You can use the Vector Iterator to perform standard iterations over a Vector. Below is an example of a typical client implementation:

Using an Iterator with a Vector ensures only a linear search can be performed, which proves useful with Vectors as they are dense Arrays. However, one consideration that must be made when using an Iterator with a Vector is that you loose type safety when accessing items in the Vector via iterator.next(). It is because of this I would suggest only using Iterator’s with Vectors to support backwards compatibility when refactoring existing Arrays which are being used with existing Iterators.

The VectorIterator and it’s associated test are available below:
VectorIterator
VectorIteratorTest

A week or so prior to MAX, the Cairngorm committee had a rather interesting discussion, during which Alex outlined what the team at Adobe Technical Services had been considering for Cairngorm 3. The meeting was focused on providing everyone with an overview of the collective ideas which Adobe had been gathering internally for some time now, and to also inquire feedback prior to the public announcement of Cairngorm 3.

Prior to the meeting I had anticipated the discussion would be based around a few new patterns and best practices which are currently being advocated, and possibly some additional libraries which help to address recent challenges in RIA development. However, what we discussed was actually quite different – in a good way.

As you are probably aware by now, Cairngorm 3 is focused around tried and tested best practices and guidelines which aid Flex developers in providing solutions to their day to day RIA challenges. These guidelines are primarily based upon that which has been realized by Adobe Technical Services, and also from the Flex community at large. Teams can leverage these guidelines where applicable to help deliver successful RIAs using frameworks of their choosing. While there may be specific frameworks and libraries recommended in Cairngorm 3, these are just that – recommendations. There is generally a framework agnostic approach which I must emphasize is highly preferable to that of suggesting one framework over another. This is precisely what I think is needed in the Flex community, for there is rarely a one size fits all approach to software architecture, especially in terms of specific framework implementations. This is a pretty easy concept to comprehend, as, what works for one team, in one context, may not always be appropriate for another team, or in another context.

Cairngorm 3 is a step forward towards what (IMHO) should be a general consensus in the Flex community at large; there are many existing frameworks out there which help address specific problems, with each providing unique qualities and solutions in their own right. This is the kind of thought leadership which helps a community progress and grow; it should be encouraged, as allowing for the shared knowledge of fundamental design principles and guidelines is something which provides value to all Flex developers, regardless of which framework they happen to prefer.

If there is one suggestion I would propose, it would be to have an entirely new name for these collections of best practices, guidelines and general Flex specific solutions. Personally, I would like to see the name Cairngorm (which, after all these years, I still pronounce as Care-in-gorm) refer to the original MVC framework, i.e. the framework implementation itself, as keeping the name the same while undergoing a different direction is bound to cause confusion to some extent. Whatever the new name would be is insignificant as long as the original name of Cairngorm applied to that of the actual framework implementation. This would perhaps be more intuitive as it would allow for the name Cairngorm to be used to describe a concrete framework as a potential solution, just as one could describe other frameworks; e.g. Spring ActionScript, Mate, Swiz, Parsley, Penne, Model-Glue, PureMVC, Flicc etc.

Most importantly, however, is the prospect of choice, as choice is always a good thing. Moreover, an initiative being lead by Adobe in this area sends a very good message to the Flex community as a whole. I happen to leverage a number of different frameworks and patterns which address different problems. As new problems arise, I employ new solutions where existing solutions may not suffice, or develop custom solutions where none are currently available; never blindly choosing one solution over another. However, in every case, there are typically some basic, fundamental guidelines which hold true and can be followed to help drive a design in the right direction. Regular readers of this blog have probably noticed that the basis of the majority of my posts are heavily rooted within these fundamental design principles, as it is from these fundamental design principles and guidelines that developers can utilize the frameworks which work best for them in order to and meet their specific challenges.

Essentially, Software Architecture is all about managing complexity, and there are many fundamental patterns and guidelines which can help developers mange this complexity. The specific framework implementations are of less concern, for it is the understanding of these patterns and principles – and more importantly, when to apply them, which will ultimately drive the decisions to leverage a one framework over another. In my experience, I have found that the only constant in software architecture is that a pragmatic approach should be taken whenever possible, whereby context is always key, and simplicity is favored as much as possible. Cairngorm 3, I feel, is a nice illustration of this principle.

Ever need to determine what versions of a specific Maven dependency are available in a public repository? Or more importantly, determine if a dependency even exists in a public repository? If so, then javacio.us, a free, subscription based service available to anyone with a Google account can be used to help quickly and easily resolve maven dependencies.

Usage is simple:

1. Search Google for the name of the dependency (e.g. concurrent pom) and you will get a list of all groups in which the dependency is under a public repository.
2. Select the specific group you require
3. Select the version you require

And that’s it! Now you can simply copy the coordinates and the dependency has been resolved.

While there are certainly other services available which do more or less the same thing (e.g. Maven Repository Browser, etc.), the simplicity of being able to just search from Google is rather convenient.

A few years back I had the need to write a global exception management framework in order to provide a means from which unhandled errors could be handled gracefully throughout an application. Initially, I assumed there must be a listener available which could be added to SystemManager or Application, and from there all unhandled errors could be caught; however, after spending many hours trying to find a solution, it seemed this wasn’t possible to achieve in the Flash Player API at the time.

Just recently I found myself once again in need of such an API, and thought there may be something new in Flash Player 10 that I wasn’t aware of. However, as it turns out the only thing I was able to find actually happened to be in the Adobe Bug database; specifically, issue FP-444. It was then that I referenced the feature set for the next revision of Flash Player – version 10.1, and learned that in addition to many other significant new enhancements Flash Player 10.1 will finally introduce the ability to manage exceptions globally!

This is an invaluable feature for all Flash based applications as it will allow for the ability to add a global listener from which you can catch any and all uncaught RTEs. The ability to provide a global exception management mechanism will undoubtedly improve Flash applications significantly as uncaught RTEs can then be handled gracefully by responding to the user accordingly.

This may be one of those new features that isn’t necessarily the main focal point in marketing campaigns. However, it is APIs like this that make life for developers (and QA) much easier and, equally as important, ultimateky have huge payoffs for users.

Coincidentally, this also just so happens to coincide with an open source Exception Framework I am planning to release. The framework will provide a foundation from which more robust exceptions can be defined (in comparison to the generic Error class), as well as common exception types which implement the framework. So if you are interested, check back soon as I plan to publish the framework this month.

I always thought it would be useful to be able to log in to my server from my phone; a BlackBerry Curve 8310. So the other day I did a quick search and found MidpSSH – an SSH1/2 and Telnet client (with VT320 terminal emulation) for MIDP 1.0 / 2.0 (J2ME) devices.

Since the Blackberry OS provides MIDP 1.0 support and OS 4 provides a subset of MIDP 2.0 support, MidpSSH seemed like it would be a good fit.

Installing MidpSSH is very straightforward – like most installers for Blackberry. UX is straightforward as well, and once installed you can simply start up the client, create a new session (which can be saved, imported etc.), enter the host name and log in. You’ll also probably want to increase the font size as the default is set to “Tiny”, which is a very small font size. I changed this setting to LCD 5×9 which works well.

All in all a simple, yet very useful free application.

Back in September 2008 I published a post on Class Annotations in Flex, through which I provided an API allowing for a unified approach for working with AS3 metadata. Just recently I intended to use the Metadata API in a Flex 4 project when I noticed it no longer seemed to work as expected. After a bit of debugging, I realized the bug appeared to be related to changes in the result returned from describeType; specifically, the addition of the “__go_to_definition_help” metadata. Considering the Metadata API leverages describeType in order to introspect metadata definitions, this made sense.

I made some simple modifications to the API to work with the new metadata returned from describeType and this resolved the issue. While I was in the process I also refactored operations to return Vectors as opposed to ArrayCollections, as was the case in the original design; effectively optimizing the API for Flex 4 (as well as Flex SDK 3.4).

You can download the source/tests/swc/docs dist here; all of which will be available soon via SVN and a public Maven repository, more on that once it’s ready.

Over the past few years the Presentation Model Pattern has picked up a lot of traction in the Flex world as it allows for an abstracted representation of a views model and state which can easily be tested. Core to it’s implementation is the facilitation of data bindings between a PMs model and a corresponding View’s controls. Implementing data bindings between a view and its associated PM is quite straightforward when leveraging data binding in Flex – simply annotate a property, getter or class with [Bindable] metadata. A basic example of which can be seen as follows:

Then a typical Flex data binding expression can be defined within a particular property of a control where the binding is to take place against the property of the Presentation Model instance:

As you can see this is quite simple and easy to implement. But how does one accomplish this without the use of Flex’s native data binding facility?

This may seem like a rather moot question as its hard to imagine why someone would choose to not take advantage of Flex data binding to accomplish synchronizing a view with its PM. However, just recently I found myself in need of a solution for this problem…

I have been experimenting with AS3 Signals lately as I find them to be a nice alternative to Flash Player Events. This especially makes sense in the context of Presentation Models as, at least in my experience, event Bubbling within the display list simply isn’t necessary when binding a component to a property of a PM. Furthermore, while I am not particularly biased against Flash Players event model, its implementation is very much a black-box, and AS3 Signals allows for a good level of abstraction and control of the Signaling mechanism. So I contemplated how this may improve a Presentation Models implementation and decided to see how Signals could be implemented with a PM; however I first needed to find a solution which would allow Signals to provide the same functionality as data binding.

Essentially, implementing “pseudo” data bindings with AS3 Signals can be accomplished much the same as can be seen in BindingUtils. I developed a SignalDataBinding API which will feel somewhat familiar to those who have worked with BindingUtils in the past. SignalDataBinding provides an API allowing for the creation of pseudo data bindings within a Signal against a property of a host object which is facilitated via the creation of runtime functions which are managed by the API.

For example, suppose you are using AS3Signals and wanted to bind a label’s text property to the value of another object. With the SignalDataBinding API this could be accomplished as follows:

Then, in the view from which the bindings are to be defined you would explicitly add bindings as follows:

And that’s basically it. Additional levels of abstraction could easily be defined in order to provide common base classes which encapsulate the SignalDataBinding instance etc. Additionally, I do not see any reason why the SignalDataBinding API could not be utilized in AS3 projects as well as Flash projects; for the underlying implementation has no dependencies on the Flex Framework. Thus the SignalDataBinding API could be leveraged in any AS3 project as is, or adapted to implement the Flash Player Event model to provide a BindingUtils implementation for AS3 and / or Flash Projects.

You can view a basic example as well as download the SignalDataBinding API source, docs and binary.