Adobe AIR data privacy and security slides, notes, and links (1 MB .zip)

As a side note for those who actually attended the presentation, in retrospect I think I over-emphasized the security concerns and didn’t emphasize enough that there are plenty of use cases for which AIR is definitely secure — especially in the case where you need to keep the user’s private data secure. Hopefully the notes that accompany the slides help to clarify this somewhat.

I also used and referred to a number of resources in my presentation, which are listed below. The download .zip with the slides also includes an html page with all these links.

Introduction

• "Maintaining security with Adobe AIR" by Ethan Malasky and Peleus Uhley (Adobe MAX 2008)

Background

• "AIR security" (Adobe AIR documentation)
• "Why Adobe AIR Doesn’t (Yet) Include the Feature You Most Want" by Oliver Goldman
• "Understanding the Flash Player Security Model" by Deneb Meketa (Adobe MAX 2008)
• "Considerations for using encryption with a database" (Adobe AIR documentation)
• "Using digital rights management" (Adobe AIR documentation)
• Operating system security (user and "admin" rights)
  • "What are Adminstrative Rights, Anyway?" by Oliver Goldman
  • "Does Installing an AIR Application Require Admin Rights?" by Oliver Goldman
• Source code visibility
  • Action Script Viewer (ASV)
  • "Ethical SWF Decompiling" by Lee Brimelow
  • Nitro-LM
• Encryption: ActionScript crypto libraries:
  • as3crypto
  • OpenSSL (partially) cross-compiled to ActionScript using Alchemy

AIR application installation

• Sign your app with a trusted cert
  • "Code Signing in Adobe AIR" by Oliver Goldman
  • "Digitally signing Adobe AIR applications" by Todd Prekaski
  • Promotion: get a free signing certificate (while supplies last) by submitting your app to the Adobe AIR marketplace
• Plan for updates
  • "Building AIR applications that can be easily updated" by David Deraedt
  • "Using the Adobe AIR update framework" Quick Start article by Jeff Swartz (Adobe AIR documentation)

Modular applications

• Sandbox bridge
  • "Scripting between content in different domains" (Adobe AIR documentation)
• XML signature validation
  • "Creating and validating XML signatures" by Joe Ward
  • "Using the XML signature validation classes" (Adobe AIR documentation)
  • "flash.security package" reference (Adobe AIR documentation)

Local shared objects

[No links]

Encrypted Local Store

• "Storing encrypted data" (Adobe AIR documentation)
• "EncryptedLocalStore class" reference (Adobe AIR documentation)

Local files

[No links]

Local SQL database (SQLite)

• SQL injection attack
  • "Using parameters in statements" (Adobe AIR documentation)
  • "SQLStatement.parameters property" reference (Adobe AIR documentation)
• Encrypted database
  • "Using encryption with SQL databases" (Adobe AIR documentation)
  • "Using the EncryptionKeyGenerator class to obtain a secure encryption key" (Adobe AIR documentation)
  • as3corelib project (includes the EncryptionKeyGenerator class and hashing algorithms

• FlexUnit 4. Wow. Big update. Very nice new features. Time to get (back) into it. (presentation by Michael Labriola)
• Renaun Erickson’s Structured Log Testing framework. Another great, unexpected surprise. I didn’t really have plans to go to this session except that Renaun’s such a smart, friendly guy. And frankly, I’ve never really had enough interest to take a look at his work on this project so far. Boy am I glad I changed my mind. This is definitely a testing approach I can get into — much less overhead than other approaches I’ve seen. Getting going with it is only barely more work than adding trace() calls. And the result is certainly infinitely more valuable.

Considering I didn’t come to Indianapolis with any real interest in hearing more about testing…I’m surprised to find myself so excited by what I saw today. Today is a great day for Flex testing, that’s for sure.

I also got to hear some interesting ideas and future plans from Jacob Wright and Tyler Wright. (They made me a bit jealous — I wish I had a Flex programmer brother that I could see at conferences.) If you’re in Indianapolis, I recommend checking out their “write-in” session on the Flight Framework at 10am Tuesday in the Illinois East room.

Other less code-centric, but interesting, tidbits:

• Joe Berkovitz is an avid mountain biker.
• Ben Stucki has a sweet five-year-old daughter who likes deep-fried calamari and pasta, although she wasn’t able to finish her macaroni and cheese at Buca di Beppo, where apparently even the child meals are sized to feed 3-4 people.

• SilvaFUG North (SF) May meeting (May 12): This is basically a pre-event for FlashCamp, with presentations on Flex-related designer concepts and designer/developer workflow. I’ve been away from the design world for a while, so I’m excited for the “refresher” course.
• 360|Flex Indianapolis (May 18-20): I’ll be there, speaking on “AIR data privacy and security”, and you’ll also find a host of the best and friendliest Flex developers I’ve ever met, including a healthy contingent from the Flex engineering and evangelism teams. If I had to choose one conference to go to (and I probably do, this year) 360|Flex is it for me.
• Bloomington, Indiana Adobe users’ groups (May 21): While I’m in Indiana, I’ll be heading down to Bloomington to speak to the users’ group(s). My presentation topic is still being finalized, but it looks like it’s going to be something around Flash/Flex Designer/Developer collaboration (notice a trend?). I’m also hoping to have a bit of time to catch up with friends, colleagues, professors, etc. — I went to grad school at Indiana University and worked for IU after graduation, living in Bloomington for just under six years total.
• FlashCamp San Francisco (May 29): Back in SF, at the Adobe office, this is the preview event that’s not to be missed, covering all things Flex 4/Flex Builder “Gumbo”/Flash Catalyst. I won’t be speaking at this one, but I’ll be hanging around learning more Flex 4 goodness, talking to developers (as part of the AIR team), etc.

As I mentioned briefly before, this week I presented at the 360|Flex San Jose (August 2008) conference. My presentation was titled “Adobe AIR SQLite: An optimization conversation.” As I mentioned in the presentation, the term “optimization” could mean a few different things — for example, optimization meaning improving performance, or optimization meaning improving developer productivity. While my presentation focused mostly on the first type of optimization, I included suggestions for tools, libraries, and strategies that fall in the “developer productivity” type of optimization as well.

Anyway, as always I’m happy to make my presentation materials available. Here are the slides (with some notes) from my presentation:

“Adobe AIR SQLite: An optimization conversation” slides (PDF in .zip - 504kb)

I don’t really have any specific code examples, apart from what’s in the slides, so there’s no “source code” download. However, I did link to a lot of external tools and resources (including a few of my own). To save you the trouble of digging into the PDF, here are the links:

Tools

• Cristophe Coenraets’ “SQLite Admin”
• My tool for testing queries
• “Lita” by David Deraedt (I learned about this one after the presentation, so it’s not discussed in my slides/video, but I thought it’d be worth mentioning anyway.)

Application architecture/patterns/libraries

• SQLite MXML wrapper classes (Peter Elst)
• Data access layer (Brandon Ellis)
• asqlib SQL statement generator (Miran Loncaric)
• “Command” classes (me) as demonstrated by my AddressBook sample application
• AIR ActiveRecord source and blog post explaining its usage (Jacob Wright)
• AIR SQLite Cairngorm services (Eric Feminella)
• Connection and statement pools, mentioned (with source code) in the article User experience considerations with SQLite operations (Daniel Rinehart)

Finally, as you may have heard, Adobe sponsored the recording of every presentation at 360|Flex, and they’re all going to be made available free of charge via a channel in Adobe Media Player. They’re rolling them out in phases, and mine isn’t available yet. When it is, I’ll update this post with the video as well. Update: the video is now available on Ted Patrick’s blog as well as in Adobe Media Player.

In the mean time, 360|Flex was full of awesome presentations. I wasn’t able to get to all the ones I wanted to see, due to conflicts and me trying to finish up preparation for my presentation. So I’m going to be spending some time watching many of those videos as well. If you’d like to see the videos, Ted Patrick has posted instructions on his blog:

How to view 360|Flex San Jose 8/08 session videos in Adobe Media Player

In all those presentations I promised to make my slides and code available. For those of you who attended my presentations these are a long time coming; for those who attended my session at Webmaniacs/Flexmaniacs, these are also somewhat overdue.

In any case, after deadlines, conference, and illness, here are the slides and files for my Webmaniacs session “Adobe AIR: Windows, Menus, and the System Tray” (and my two SilvaFUG presentations that were based on that session):

• “Adobe AIR: Windows, Menus, and the System Tray” slides and files (2.4 MB .zip)

The .zip file contains three files and a folder:

• Webmaniacs 2008 Slides for presentation.pdf: PDF “notes pages” printout of my presentation — each page contains one slide plus any notes that I added.
• Exercises.pdf: Since this is a “hands-on” presentation I created this document that contains step-by-step instructions for all the exercises. Using this plus the files below you should be able to work through all the exercises for the session.
• Code Snippets for exercises.txt: While all the code listings for the exercises are available in the PDF, a few of them are really long. In any case, if you’d rather copy and paste instead of type as you work through the exercises you can get the code from this file.
• Exercises_workspace_start/: A Flex Builder workspace with the “starting state” of some of the exercises for the session. Most of the exercises just start from a blank screen or continue a previous exercise, but for a few I set up the UI ahead of time to save time, and those files are in this folder.

Enjoy! As always, please leave comments and feedback.

My conclusion (not original by any means) was that unit testing is an important tool for ActionScript developers. I’ve tried a couple of ActionScript unit testing frameworks (ASUnit and FlexUnit). And finally getting to the point of this post, I was interested to learn today that the crew at Digital Primates is releasing an open source unit testing framework for Flex, known as “dpunit”.

(via Jesse Warden via Twitter)

And what nice details they are!

Here are a few highlights that stood out to me:

Flex applications however have gained a reputation for looking too similar to each other, as many developers choose to use the Flex default look and feel (known as Halo)…we have found that it remains too challenging to create a truly custom experience. It is therefore a priority for Gumbo to make easy customization of Flex application experiences the norm instead of the exception.

Major features…component and skinning architecture…make it easier to describe experience-oriented features such as states and transitions

Perhaps the most revealing part for existing Flex devs is the aptly named “Caveats and Reassurances” section:

Gumbo will remain compatible with Flex 3…Over multiple releases post-Gumbo we expect to deprecate the Halo model…Halo and new Gumbo components can co-exist…new MXML features may require some changes to your existing markup. However, you can make these decisions on a file-by-file basis

But my favorite line of all is in the “Related Work” section:

Provide a tool in which design-oriented users can easily customize the look of individual components or entire applications. Yes, this is Thermo. We’re not discussing it here.

Of course, this is all fairly in line with what’s been talked about previously, such as Thermo, MXML-G, Ely’s presentation about a new component structure with separation of model and view, etc. But it’s nice to see more information…and what’s not there but is hinted at is even more tantalizing.

I’ll definitely be watching that page for more information about “Design in Mind” and the other Flex 4 themes.

(via email from Matt Chotin — also see the announcement on the Flex team blog)

The current “favorite” is the Flex Visual Graph Library (FVGL) Open Source Project.

Their Visual Graph explorer sample gives a nice overview of the functionality that’s available.

Anyway, I forgot to note this earlier, so I’m adding it now, though there’s a good chance this isn’t news to anyone who’s interested in this sort of thing.

(via email from Ted Patrick)

For some reason, the final time that I saved this post before publishing it, my changes didn’t get saved. So if you saw this soon after it was posted, and wondered why it didn’t really talk about SQL changes, and why it had some messed up headings…that’s why. Sadly I’m sure I can’t recreate the text as well as I wrote it the first time. But here’s my best effort…

First of all, allow me to clear something up. I am aware that Adobe AIR 1.0 shipped almost exactly a month ago, so this shouldn’t be news to anyone who’s actually interested in it. I intentionally held off on publishing my thoughts (and a description of changes since beta 3). As a rule, I never post anything in the week or so following a big product announcement — there are so many “me too” posts about the product, and so little actual different thoughts or original ideas, that I don’t want to clog up the aggregaters by adding to the hubbub (the “MXNA firehose” as I’ve heard JD describe it).

That’s not a complete excuse, of course. The truth is also that I’ve just gotten busy with a lot of post-launch cleanup activities, and of course moving ahead on future projects (Flash Player 10 and AIR 2.0), so I’ve neglected this post for longer than it deserved.

And now, lest I postpone it any longer, here are a few bits of news and opinion from my corner of the Flex/AIR world:

• Local SQL database changes
• What does “finished” really mean?
• Go right to the source

Local SQL database feature changes

Wait a minute — didn’t I say a couple of months ago that as of beta 3 AIR is API frozen? Indeed that was the intention, and with one small exception it’s true. And that was the first thing that came to my mind when I read the notification (shortly after beta 3 was locked down) that some changes to the SQL functionality had been checked in to source control. But I was correct before — the API hasn’t changed — just one particular behavior has.

The specific change is with how the runtime treats column data types in database tables. In betas 1-3, AIR was consistent with the “default” SQLite behavior:

the type of a value is associated with the value itself, not with the column or variable in which the value is stored…. All other SQL databases engines that we are aware of use the more restrictive system of static typing where the type is associated with the container, not the value.

In order to maximize compatibility between SQLite and other database engines, SQLite support [sic] the concept of “type affinity” on columns. The type affinity of a column is the recommended type for data stored in that column. The key here is that the type is recommended, not required. Any column can still store any type of data, in theory. It is just that some columns, given the choice, will prefer to use one storage class over another. The preferred storage class for a column is called its “affinity”.

So under the “affinity” system, if in your CREATE TABLE statement you specify that a column stores INTEGER data, and you write an INSERT statement that stores a String instance in that column, the runtime allows it. (I initially wrote “it works just fine” but that may not be true — since your application may be assuming that values retrieved from that column are always integers.) When I first read about this behavior when we were reviewing the spec for the feature, I recognized that it was different than what I’d done before, but I figured it was okay — I’d just have to be extra careful when inserting values into the database, and enforce the data types myself by convention even if the runtime didn’t enforce them in practice.

However, the feedback we got from developers was that this doesn’t really match what they’re used to from typical web app database code (which likely uses databases such as Oracle, SQL Server, or MySQL). As a result, in the final release, the declared data types of database columns are more strictly enforced. If you declare a data type for a column, then attempt to store a value that isn’t an instance of that type, the database will try to convert the value to the appropriate type (for example, turning a number into a string, or parsing a string to see if its text is actually a number). If the value can be converted, then the converted value is stored; otherwise, the runtime throws an error. (For more details, see the column affinity description in the documentation.)

Personally I’m pretty happy with this solution. It’s still a bit more flexible than the databases I mentioned before — usually they won’t even try to convert a value, and will just choke if the data type doesn’t match. But I think that the way it works in AIR 1.0 is consistent philosophically (and actually) with the way data types work in ActionScript 3.0 where values can be strongly typed or weakly typed at compile time, but either way at runtime the type must match.

So, what do you do if you were one of the people with more SQLite experience than other db experience, of who otherwise preferred the old behavior? Well, there is still a workaround. If you don’t declare any data type for your columns, you can store data of any type without causing errors. This isn’t the same as the previous behavior, but based on some anecdotal observations I’d guess that developers who intentionally mix data types in columns are less likely to declare a column data type, in any case.

Also, as a side note, I decided to keep the term “column affinity” in the documentation even though the behavior changed. I did this for a couple of reasons: 1) Developers who’d been reading the docs were probably familiar with the term now, and 2) the data types still aren’t strictly enforced, in the sense that the runtime attempts to convert values before storing them (just as a default SQLite implementation does). For example, just about anything can be stored in a TEXT column without an error occurring. So in that sense, the data type specified in a CREATE TABLE statement is still somewhat of an “affinity” rather than a traditional strictly enforced data type.

What does “finished” really mean?

Not too many years ago, my definition of a “release version” of software was different than it is now. I knew that any software, no matter how much it is tested, is bound to have some bugs in it — it’s just not possible to ship software of any notable size without making a mistake somewhere. However, I had enough faith in big software companies that I assumed that when a company declares a product to be a “release” or “shipping” version, that it at least doesn’t have any bugs that they know of.

I’m not sure when I realized that this view is far from reality. I suppose it was probably with the first private beta I was involved with, though maybe it was before that.

In any case, I hope I’m not shocking anyone’s sensibilities when I point out the reality, that even though Flex 3 and AIR 1.0 have shipped, they do have bugs — and Adobe even knows it! The recent openness of Flex, in particular the introduction of the public Flex bugbase, makes this reality much more transparent. A quick search on the Flex SDK project, looking only at bugs (as opposed to feature requests), shows 309 “open”, “in progress”, “community”, or “new” issues. And that’s not even taking into account “deferred” bugs, such as SDK-14339 “WindowedApplication doesn’t update/show menu when it changes during runtime”.

While Adobe AIR doesn’t have a public bugbase, that doesn’t mean it’s any more free of bugs. Try calling the NativeMenu.display() method on a PowerPC Mac running OS X 10.4 and you’ll see what I mean (hint: the menu appears at the mouse cursor rather than at the specified coordinates).

So what does “release quality” software really mean? Well, it means that it doesn’t have any bugs that are “showstopper” issues, or that are “really bad.” Yes, I’m intentionally using non-specific terms here. The reality of life is that if Adobe (or any software company) waited to release software until all known bugs are fixed, the software would never get released. So instead, they use a process that’s sort of like this (I’m generalizing and also stating this based on my own observations, not on any review of actual process or guidelines within Adobe):

1. The decision makers figure out a date by which the software should be done. (I’m not talking about at the beginning of a product cycle — I’m starting somewhere in the middle.)
2. Throughout the process, bugs are reported. Any time a bug is reported, it is investigated and a decision is made as to whether resources can/should be allocated to fixing it. The criteria for this decision are generally based on how severe the bug is (whether it crashes the software/computer, causes data loss, is a usability issue, etc); how hard it is to fix; how much time it will take to fix; how likely it is that someone will run into the bug; whether or not there’s a workaround; etc.
3. As the product moves closer to the release date, the threshold for whether a bug will be fixed goes up — the closer the software is to the release date, the more severe and less difficult to fix a bug must be in order for it to get fixed.

This can be frustrating for people who file bugs, like me. Often, due to workload and general stability issues, it’s not practical for me to start writing the documentation for a feature until it’s fairly stable and close to finished. But that means that when I do find bugs, there’s a good chance it’s too late in the process for the bug to get fixed in time for the product release.

Ah, tradeoffs.

Go right to the source

Now that Flex 3 has shipped, the Flex 3 source code is available in the Flex Subversion (SVN) repository. I’ve actually been accessing it there for a while — internally we made the switch from Perforce to Subversion around the first of the year. I was pretty worried at the time, because I had never used SVN before. The majority of the Flex 3 work was already done at that point — they were just in final bug fixing mode. We still had about a week before our content had to be locked down, so I was working furiously to try and finish up some work I was doing on the Flex AIR components. I wasn’t too excited about the prospect of switching source control systems in the middle of that crunch. Fortunately, SVN turned out to be pretty straightforward. (In case you’re wondering, I use TortoiseSVN). It’s actually been good for me to learn SVN at work — it made it easier for me to move some of my code projects over to Google Code (a few that are already there, and a few more that I’ve started but not posted on my projects page yet). So overall I give SVN thumbs up, and I’m happy that the Flex source code is available that way.

If you’ve been following my posts on AIR and the SQL database functionality, you may have noticed a trend: every time there’s a new beta, I tend to go silent for a few weeks beforehand as I try to get things finished up with the documentation. Well, here we went again — another period of silence, another AIR beta.

The marketing team kept things pretty low-key with announcing this new beta, especially compared to previous rounds. I’m not sure of all the reasons for that, but there are a few that are important and helpful for you to know if you’re developing AIR applications:

• AIR is now API-frozen — as of this beta, there shouldn’t be any changes to the AIR apis. In fact, the goal was to have as few API changes as possible between AIR beta 2 and AIR beta 3, as things get closer to being locked down. Naturally, if we find a big security issue that requires us to change an API, we’re going to consider it — but aside from that, things are now the way they will be for AIR 1.0 (phew — it’s been tiring for me to update apps every beta, and I’m sure it has been for you, too).
• Along with the new AIR beta, Adobe also released a beta of a new product code-named “BlazeDS”. This very cool offering is a free, open-source, slimmed down LiveCycle Data Services — basically it includes the RPC Components (“Flash Remoting”) functionality as well as the Messaging functionality. In addition, we’re releasing an official specification for the AMF format. While the format was (for the most part) reverse-engineered long ago, I think it’s great to have something official for all the other open-source offerings like AMFPHP, Fluorine, etc. to work from.
• Along with beta 3, Adobe created the “Adobe AIR Marketplace” where developers can post apps for people to download and try out — basically an extension of the
• Flex 3 beta 3 is officially the last Flex 3 beta before Flex 3/AIR 1.0 (second paragraph, also in the FAQ PDF). ‘nuff said =)

Of course, following the trend of my going silent before each beta, you can expect that to be magnified as we continue leading up to AIR 1.0. There have been a few things each beta that I wanted to do but had to put off until later — but of course, this time there isn’t any “until later” — so it’s now or never!

Talking specifically about the local SQL database functionality, there were only a few changes this beta, but they’re pretty significant and maybe even a bit sneaky so you’ll want to pay attention to them:

• Specifying synchronous and asynchronous execution: Synchronous database execution was added to SQLConnection in beta 2. At that point, to specify that a SQLConnection’s operations were synchronous rather than asynchronous, you had to specify a true parameter in the SQLConnection() constructor. Now, however, the SQLConnection() constructor doesn’t accept any parameters. Instead, you specify the execution mode when you open the connection to the main database. To specify that you want to use synchronous execution, you call the SQLConnection.open() method; to specify async execution, you call the new SQLConnection.openAsync() method.

  The most important thing to note surrounding this change is this: if you’re migrating an app from beta 2 to beta 3, you may be changing the behavior of your app without even realizing it! If you want a connection to be synchronous, you’ll know you have to change things because the code won’t compile (SQLConnection() no longer accepts a parameter). However, if you want you connection to be asynchronous, then if you don’t change anything the code will still work but it will actually use synchronous rather than asynchronous execution. If you have a long-running query and it’s freezing the UI now, that’s probably the reason — the exact code you used previously to specify asynchronous execution (no SQLConnection() parameter, and open() to connect the db) now is the way to specify synchronous execution. If your code doesn’t cause any errors, you might not even notice immediately because the SQLConnection and SQLStatement events are still triggered even in synchronous execution — so your “success” event listeners will still get called (but error listeners won’t — the operations will throw exceptions instead).

• There were a couple of changes to the SQLError class and related classes: The SQLError.code property was removed (because it already inherited errorID from Error) and the details property was added, providing a more detailed error message in certain cases. Along with this, the SQLErrorCode class was removed entirely (tragically — I spent a fair amount of time hammering out those error descriptions with Jason, the engineer for the feature).

I think that’s it, but please let me know if I’ve forgotten another change!

In the mean time, In addition to the SQL database stuff I’ve been doing more with another part of AIR that I’ve previously been working on as I’ve had time — the AIR-related Flex components. This release includes a new one, the FlexNativeMenu component, which is pretty slick. Watch for more on this in the (hopefully near) future!

Here are the direct links:

• Grant Straker on Moving ZoomFlex from a homegrown framework to Cairngorm
• Ali Mills and Luke Bayes on Flex application frameworks (A great overview of the strengths and weaknesses of various frameworks like Cairngorm etc., from two really smart developers.)

Enjoy!

(via email from SilvaFUG)

If you’re interested in a summary of the talks, I’m afraid I didn’t do that. (But I highly recommend viewing the presentations:

• Grant Strake on moving ZoomFlex from a homegrown framework to Cairngorm
• Ali Mills and Luke Bayes comparing various Flex application frameworks

What I’ve written here is primarily just thoughts that I wanted to save for myself; things that maybe I don’t think about as often as I should, or things I want to remember about the audience of Flex and other Adobe developer products. Because I’m interested in the developer community, much of the focus is on points about the developer community that I sometimes need to remind myself of.

Grant Straker

The first speaker was Grant Straker, talking about his company’s choice to use a homegrown framework, and eventual decision to migrate it to Cairngorm instead. His company (Straker Interactive) has a RAD product (“ZoomFlex,” I believe it’s called) that bundles ColdFusion and Flex to create apps quickly — you use wizards to define data structures, and the product generates database structure, backend ColdFusion, and front-end Flex code for apps using that data. (The idea is that developers then take those Flex files and customize the front-end forms, style the app, etc.)

Here are some interesting thoughts/points I picked up:

• Originally they chose not to use Cairngorm for the underlying framework for their generated code. The reason: while there are some developers who build big, fancy, complex enterprise apps, there’s also a group of developers who “just want to know what they need to know to get their job done” — which often means build basic CRUD apps as quickly and easily as possible (e.g. web-enabling existing databases, spreadsheets, etc.). This latter group was/is more in their target audience.
• Code can be written in different ways — they try to generate code so that it’s clear and obvious what it does, and so that it can be easily extended by developers of varying levels of experience (key: don’t assume a high level of experience).
• In retrospect, he wishes they had just stuck with Cairngorm in the beginning. Now, 1.5 years later, there’s a large community, examples, documentation, etc. making it easier for a less-experienced developer to learn enough Cairngorm that they can understand it and use it.
• I was really amazed by how much code they are able to generate for developers. I’ve read some things about code generation tools, but I’ve never tried them out (due to the organizations I’ve worked for, and perhaps due to my personality as a developer who likes to have “control” of the code). However, I’ve definitely seen the down side of that, which is that I end up writing a lot of redundant or very similar code (especially for data access and manipulation). The “alternative” approach certainly has some attractions…
• Part of what they include is a library of pre-built UI components. The process of migrating these components to Cairngorm has been challenging at times. One of the principles of many frameworks including Cairngorm is that the user interface code is separate from the “model” (the underlying data). However, some components by nature lend themselves to having knowledge of their underlying data (e.g. their video player component) so figuring out how to structure those components is complicated.

Luke Bayes and Ali Mills - Evaluating application frameworks for Flex

Luke and Ali came into this presentation with no background in any of the major frameworks (other than the Flex framework). This is good because they didn’t have any biases, but it means they may have some non-best-practices too.

This was a great talk, but there was a lot of info in a short time so again, I’m not going to bother trying to write detailed notes. I highly recommend watching the recording.

However, once again in this presentation (in particular in the discussion afterwards) some of the same ideas came up. Luke in particular expressed a reluctance to have a prescriptive framework, because he doesn’t want to be “told how to code.” That opinion resonated with most of the audience there — but at the same time, everyone also acknowledged that the audience at a user’s group presentation isn’t really an accurate representation of the broad Flex developer community (especially the even broader community of developers who are considering Flex or who will be Flex developers in the future). If the Flex community is going to continue to grow, and be more accessible to new developers, it would be very helpful to have some prescriptive application frameworks that give people a predefined, standard architecture within which they can build their app (in the same way that Flex’s components provide user interface elements and layout elements that give developers a big head-start in building an app, compared to straight ActionScript or Flash).

What is the “next frontier” of Flex developers? Is it the “VB developer”1 (the “behind-the-firewall” corporate developer). If so, then to support that group of developers we’re going to need prescriptive frameworks that are easy to get into (“accessible” in Luke and Ali’s terms), that do as much work for you as they can, but that still don’t get in the way as an app grows in complexity.

At the same time, more advanced Flex developers may not want such a framework, and they certainly aren’t going to want to have to carry along the “baggage” (meaning both prescriptive architecture imposed on them, and literal baggage in download size) that would come along with such a framework if they’re not using it.

Personally, I think that’s an extremely important point for both Adobe and third-party framework developers to keep in mind going into the future.

“VB Developer” is my name for a developer who works in a medium-large corporation or organization, perhaps coding apps for a group within that organization, who doesn’t really want to learn everything there is to know about Flex (or their language of choice), or become a “guru,” but rather just wants to build their app and make it work nicely, but do so as quickly and painlessly as possible. Yes, the name “VB developer” is rather dated, since at this stage in history most such developers are doing web-based apps, probably using ASP.NET or J2EE in a large, standardized org or perhaps PHP or Ruby in a smaller or more independent group.

Keith Peters wrote a similar post on the same topic, which I also recommend.

(via Jesse Warden)

The part that caught my eye the most was that the wrapper class doesn’t dispatch any events to notify the view when the operations have completed. How, I asked myself, does it notify the view when the updated data loads? After a few seconds I realized the answer — it’s the magic of Flex data binding. The DataAccess class exposes the SELECT results as a property (dbResult) that’s a Flex ArrayCollection, and it’s marked [Bindable]. A Flex control can bind to that property as a data provider, and whenever the DataAccess instance reloads its data and updates the ArrayCollection. Then the Flex framework takes over, and the view gets updated automatically. Pretty slick; and it definitely saves a lot of event-handling code. So I guess seeing this in action gave me further appreciation for the power of data binding.

It has a couple of minor issues that I’ve noted in the comments on that page (but mostly they should be fairly easy to fix, if Brandon or someone else decides to do so).

(via: Greg Hamer)

Even though the unit tests I wrote for the ActionScript 2.0 version of the library used ASUnit, this time around I decided to go with the “home team” (i.e. developed by Adobe employees) solution and try out FlexUnit. Fortunately, at least for the tests I had already written, the two systems are pretty similar, so I only had a few tweaks to make to migrate them. (Too bad there wasn’t any way for me to unit-test my unit tests, to make sure they worked the same across frameworks.)

Anyway, along the way I found a couple of resources that were very helpful in getting started, especially since the FlexUnit documentation is rather sketchy (only limited API reference docs available). These were the articles that helped the most:

• Darron Schall: How to use FlexUnit with Flex Builder 2 (A great “getting started” article. This article was actually written while Flex Builder was still in public alpha, so it’s not perfectly accurate when describing Flex Builder’s dialog boxes — but it’s close enough that it was easy to figure out.)
• Daniel Rinehart: Asynchronous Testing with FlexUnit (Naturally, it doesn’t take long with ActionScript 3.0 before you want to test something involving events…so you need to do some asynchronous tests. The docs are no help here, and the included examples are really convoluted. I don’t know how Daniel figured it out, but I found his article very helpful for getting going with asynchronous tests.)