• Adobe Edge: Object Relational Mapping for the AIR Developer – Part 1
• Adobe Edge: Object Relational Mapping for the AIR Developer – Part 2

Slides, Code Samples, and Resources

This particular session doesn’t have a great deal of slides – but, if they are helpful, I have included them here:

• Slides: ORM for AIR – PDF (953 kb)

I also presented two sample FlexORM applications. The first example uses a single VO with no complex relationships. The second uses some complex relationships to demonstrate how FlexORM stores data across tables. These two applications were created for a series I did in the Adobe Edge newsletter (which I will link to below). Only the first of these articles has been published yet (as of 11/13/09):

• Article: Object Relational Mapping for the AIR Developer
• Source Code: Both FlexORM Examples – ZIP (1.46 mb)

I am actually not releasing the code for the example with the CF9 AIR ORM just yet. I am still working on the primary key generation part of the ‘wrapper’ I referred to. I will let you guys know (here on the blog) when everything is ready. You can speed up the process for voting for the following bug: http://cfbugs.adobe.com/cfbugreport/flexbugui/cfbugtracker/main.html#bugId=80681.

First Generation Flex Frameworks

First, I want to state that the Flex landscape has evolved a great deal in the last two years. In reality, Cairngorm was an attempt to take design patterns from other languages and make them fit well into Flex. For the most part it succeeded, but it didn’t solve all of the problems (and in reality – it created a few more). With that stated, we generally refer to Cairngorm as a first-generation Flex framework.

I could go into further detail here – but, at this point I’ll move ahead.

Second Generation Flex Frameworks

Since then, several frameworks have been created that were written specifically for Flex – and specifically to solve the problems that occur in Flex development. These frameworks were crafted by Flex developers (as opposed to Java developers who started to work in Flex). Because of this, these frameworks solve problems in a way that makes sense for Flex. My two favorite examples of second generation frameworks (and the two I use on projects currently) are Swiz and Mate.

These two frameworks solve problems in different ways, but they both work well. One of my Universal Mind colleagues, Darron Schall, recently posted some slides that give a comparison of the two frameworks. These slides can hopefully assist those of you evaluating these two frameworks so that you can understand the strengths and weaknesses of each option. Darron is also the first person I heard use the first/second generation framework terminology.

How Do I Learn?

Learning a new framework can be daunting (especially if you haven’t worked with a framework before). I think this is reason my Cairngorm videos were so popular. Because of this, I am starting the process of producing a similar video series for Swiz. I am extremely busy – so, I cannot predict when these will be completed. However, I am going to start working on the code examples this week (that is the easy part – the videos and the articles take a good deal of time). That being said – if you have specific items you want me to address – let me know.

I don’t have any plans to develop a video series for Mate yet – but, we’ll see how things go with the Swiz series. One of the reasons I am covering Swiz first – is that the Mate project has great documentation (which makes it easier for new developers to jump into it). The Swiz team is currently working on their documentation – and hopefully this series can be a part of that.

But What About Cairngorm 3?

Undoubtedly, many developers feel that they are expected to migrate to Cairngorm 3 as it is the ‘official’ framework. I would advise against this, mainly because of the architecture it implements. In reality, it is a collection of techniques taken from other frameworks – and yet again, it doesn’t solve all of the problems that Flex developers will encounter.

Development rate and development communities are also extremely important when it comes to a framework. The other established frameworks (such as Mate and Swiz) are further along in development, and have some great plans for the future. Both Mate and Swiz also have vibrant development communities which are eager to assist developers. I think the Adobe Consulting team has shown that Cairngorm development will be slow and official support will be non-existent.

Summary

I want to be clear on one thing – if you (and your team) know Cairngorm, there is no immediate need to stop using Cairngorm. It still serves as a great framework for teams. I would advise teams to NOT work with the new Cairngorm 3 framework (which in reality is just a collection of techniques taken from other frameworks). I would recommend that as your teams investigate new techniques – that you move toward Swiz and Mate (second-generation Flex frameworks).

Additional Frameworks

In reality, these aren’t the only second generation Flex frameworks. I have chosen Mate and Swiz for a specific reason – but, if you want to investigate the other options, you can check out the following frameworks:

• PureMVC
• RobotLegs
• Parsley

I have provided a preview of the application below as well as a link where you can go to vote for this application in the 2009 Adobe Max Awards directly. Vote early – and you can vote as many times as you’d like (this year Adobe has said that there is no limit on voting!).

[UPDATE: Thanks to all who voted. While this application didn't win - it was truly an honor to be among the finalists. I am always amazed at the great applications that the Adobe development community comes up with.]

Video Sample

Colorado Growth Model from David Tucker on Vimeo.

I must admit that my session is going to be pretty awesome. While some people get to speak for an hour – or maybe an hour and a half, I will be speaking for 8 hours (with some breaks of course). I will be presenting on Building ColdFusion Powered Flex and AIR Applications (see all of the labs here). While the preconference sessions are an extra cost ($595), you get an entire day of training from some amazing developers. If you look around at rates for a one-day training, you will see that this is a huge bargain. Normal sessions give you a taste of certain functionality, but at a preconference lab you can really learn it and take it back to your job.

In my session you can be sure that I will be covering:

• Utilizing the new Data-Centric Development Features in Flash Builder 4 (with ColdFusion)
• Working with the Proxy ActionScript classes that were introduced in ColdFusion 9
• Configuring and Using the ColdFusion 9 AIR Offline Sync functionality
• Working with ColdFusion Builder and configuring it to work with your development server
• Defining a Complex Domain Model using the new Hibernate ORM Support in ColdFusion 9
• Using the Hibernate ORM and its ColdFusion Builder Extension to create remote CRUD services
• Creating new Script-style CFC’s (with annotations)

All in all – you won’t want to miss this session! If you have any questions – feel free to leave a comment!

After rummaging through the remoting config files, I discovered the issue. My bean CFC was using ColdFusion 9's new implicit getters/setters. To get this to work properly, you have to change a setting in the remoting config( specifically in services-config.xml):

By setting use-implicit-accessors to true, ColdFusion then uses the new implicit getters and setters in CF9 for your remoting calls. With that quick fix (and a restart) everything was working perfectly.

ORM for the AIR Developer

I will be speaking on ORM for the AIR Developer at Flash Camp Atlanta. I will be covering the different solutions that are available today - and how to develop and work with an actual domain model for your AIR application. Let me know if you have any questions on using an ORM solution - and I will be sure to cover them in my session.

The Adobe AIR 1.5 Cookbook from O'Reilly is now available for the Kindle. This book is great for anyone from beginning to advanced and covers Flex, Flash, and JavaScript/HTML AIR development:

The hands-on recipes in this cookbook help you solve a variety of tasks and scenarios often encountered when using Adobe AIR to build Rich Internet Applications for the desktop. Thoroughly vetted by Adobe's AIR development team, Adobe AIR 1.5 Cookbook addresses fundamentals, best practices, and more. If you want to learn the nuances of Adobe AIR to build innovative applications, this is the book you've been waiting for.

As you might guess, I am a bit biased - but, I think this book is the best source of AIR recipes available today.

We need an open honest discussion about HTML5 and what it means for the web. Unfortunately, you aren't going to get the truth from fanatics on either side, but instead we all need to examine all of the evidence and come to our own conclusions. I have spent a great deal of time analyzing the facts, and in the process I have made several observations.

DISCLAIMER: In full disclosure, I must mention that currently I am Flash Platform developer (primarily Flex/AIR). I also write a regular column for the Adobe NewsFlash newsletter. However, before I became a full-time Flash Platform developer, I was a traditional web developer who spent all day dealing with HTML, CSS, JavaScript, and PHP. I feel that I have an understanding of both sides of the discussion (but obviously am open to any input anyone has on the matter).

The Present

After much effort by many dedicated developers, HTML5 is just about ready for prime time. This process started about a decade ago, and gone through many iterations. Today, HTML5 is available and ready to go on a few platforms/browsers. However, not all browsers implement all of the standards, and some browsers haven't even announced when they expect to have full HTML5 support⁶. In reality, version 3 of the iPhone OS is the only solid platform that has full HTML5 support (as well as some other fixed development platforms). What does this mean for developers? It means that HTML5 is still very much in the future (and not the present) for a majority of developers.

I was struck when reading Jeff Croft's posting, Two Thousand and Twenty-Two, last September. It shed a lot of light on the frustration many developers are having with web standards as a whole. While, I haven't even talked with Jeff directly, I have always been a fan of his work. After learning of the bleak timeline¹ put forth for full HTML 5 browser adoption, Jeff stated: "it ultimately doesn’t matter if HTML 5 is available next month, next year, or fifty years from now. Those of us who do real work in this industry know that the only thing that really matters is what specs and technologies are supported by the browsers real people use".

Developers who have to build solutions for clients don't care about the theoretical, they care about the reality. On that same vein, a solution is not a solution if it only applies to 10% of the target audience. It isn't a solution if only applies to 90% (and leaves out 10%). Clients want sites/applications that work well for every member of the target audience - and they want it today. This brings me to my first observation:

Observation 1: Developers won't be able to use HTML 5 in solutions they build for their clients (unless they are on a fixed-platform as described above) until at least 2014. For full HTML 5 functionality, this will be much later even than this.¹

Developers could look at creating solutions that leverage both HTML5 and the current HTML/JS model. However, this would mean that for a single solution a developer would have to create:

1. Browser detection to determine if the user is HTML5 capable
2. A full HTML 4.1/XHTML 1 application for current and older browsers:
1. Multiple CSS files (including hacks) to support IE6, IE7, Firefox 3, Safari 3
2. JavaScript that is compatible with all browsers listed above
3. A full HTML5 application (which will have little code overlap from the HTML 4.1 application)

For developers who already have to deal with the CSS and JavaScript craziness, this would just add another layer of complexity. In reality, HTML5 won't be an option for traditional developers until 90%+ of the web is using an HTML5 capable browser. Keep in mind that most all sites still have to check for IE6 users, even though it was released eight years ago (2001).

The Truth About Plugins

At the heart of this discussion are the web plugings that we use today. Many articles⁵ have been written lately claiming that HTML5 will kill off traditional web plugins. In reality, this is far from the truth. Before I address that issue directly, we need to take a closer look at what is a web plugin.

When listing the common web plugins, most people realize that this includes the Adobe Flash Player, Microsoft Silverlight, and JavaFX. However, this also includes Google Gears, Google Native Client, the Google Earth plug-in, as well as the Google audio/video chat plug-in. In addition, to the Google plugins, there are countless plugins by other vendors. These plugins have been vilified due to the fact that they are 'closed source' projects. The truth is that the plugins have a rapid development cycle that leads to innovation. I am not saying that this can't happen with an open source project, but I develop cutting-edge solutions for real clients. I can't look to web standards for real innovation - only more of what has already been implemented:

Observation 2: Web standards will never innovate - they will only implement what plugins have already successfully included. This is due to the fact that the standards process is run by Microsoft, Google, Mozilla, and other companies that aren't going to invest in implementing a feature unless it already has a proven place in development. The term standardization implies that you are taking something that already exists and creating a uniform process for implementing it.

In addition, many developers fail to acknowledge the role plugins have played in the HTML5 standard. This brings me to an observation:

Observation 3: Every new feature in HTML 5 (except maybe 2) were added because developers wanted functionality already available in a plugin. This includes offline cache (Google Gears), canvas (Flash Player), media playback (Flash Player and others), drag and drop (Flash Player and others), etc...³

At the recent forefront of this debate has been Google Wave, recently announced by Google at the Google IO Conference. This rich Internet application has been hailed as a great example of what web standards can do. However, virtually no one has commented on the fact that it requires a plugin to function. Yes, the example of what HTML5 can do requires Google Gears for some of its functionality. In reality, it is only for a small portion of the functionality (drag and drop), but it brings to light an important observation.

Observation 4: Google had the option to go through the standards process and try to add the drag and drop functionality before releasing Wave, but they decided that the user experience would suffer without the functionality. Instead, they chose to use the plugin to provide the best overall user experience.²

The truth is that plugins can 'upgrade the web' in under a year. In reality, an idea can go through production, QA, released to users, and then pushed to 85%+ of the web within 16 months⁴. This is not the case with web standards:

Observation 5: Because of the major corporations and entities (as well as egos) that are involved, any major change (that requires browser creators to change functionality in a uniform manner), is guaranteed to take at least a decade from idea inception to actual implementation (across all browsers). The time required to allow for users of older browsers to upgrade, can add another 5+ years to the process.¹

If HTML5 were completely implemented by all major browsers today, and if all users had these upgraded browsers - the web plugins would take a serious beating from HTML5 (although even then - it wouldn't kill them). In reality, HTML5 can't even compete with the web plugins - because it is currently only viable on fixed-platform solutions (like the iPhone).

Quality vs. Standards

One of my major points of anger on this topic is that many developers are ignoring quality in pursuit of web standards. That is at the center of the video codec debate (and there are many examples of these types of issues around HTML5). Developers are choosing to evaluate solutions based on their relative openness rather than their actual functionality. What have the last five years taught us? We are finally entering an era where we understand that user experience is the key, and now some developers want to sacrifice quality for openness. This beings me to one of my most vehement observations:

Observation 6: Many open-source solutions are at the top of their respective field (Apache, MySQL, Linux, the Flex Framework, etc...). Inferior solutions (like the Ogg codecs) should not be tolerated just because they are 'open'. If you want all browsers to implement a video codec, make one that is better than h.264. Developers should never sacrifice the user experience for the warm feeling they get when using 'open' solutions.

When a potential client looks at my body of work (or my company's body of work) they will not care about web standards - they will care about the quality and functionality of the work. In addition, when a user uses my application, they won't care about 'openness' but only about the overall functionality and user experience. As a developer and an employee of a company - I cannot recommend an inferior solution. I have to evaluate all solutions based on functionality to stay competitive. This means that in the future, HTML5 will be a solution that I consider if it provides better functionality - but, I will not choose it simply because it is open. It will be on equal footing with the other solutions that are available.

The Future

I hope that these overall observations have shed some light on this issue. The crux of the issue is this: fixed-platform developers can enjoy HTML5 now - and they should embrace it and start learning / working with it now. Traditional developers will have to wait around 5 years before it is a real option for them. In that time, we will probably have Flash Player 13, Silverlight 5, and JavaFX 3. Who knows what these versions will include - but, we can assume that the functionality they will include will probably be included in a future version of HTML.

¹ HTML 5 Editor Ian Hickson discusses features, pain points, adoption rate, and more
² Google Wave (video described Wave's use of plugins)
³ HTML5 Versus Flash Versions
⁴ Adobe Flash Player Version Penetration
⁵ HTML 5: Could it kill Flash and Silverlight?, HTML 5: Could it kill Flash and Silverlight?
⁶ Compatibility tables for features in HTML5, CSS3, SVG and other upcoming web technologies, Implementations in Web Browsers