A co-worker and friend of mine, Francis Cheng, recently started a new blog that I wanted to share:

http://blogs.adobe.com/fcheng/

Francis is a former engineer on the Flash Authoring team (and before that, a lawyer). He’s been in his current position on the ActionScript documentation team for several years. He’s also one of Adobe’s representatives on the ECMAScript language committee, so he’s got a better idea than anyone else I know of the internals and future of the core ActionScript language.

So far his posts have been really great if, like me, you’re interested in knowing more about the less-used features of ActionScript and also getting an early look at new features that will probably be in future versions of ActionScript.

If you’re like me and you’ve been heads-down in work or just getting through the pre/post-Christmas season, you may have missed the article ”Creating more secure SWF web applications” by Peleus Uhley, that was posted on the Adobe Developer Center on Dec. 20.

In spite of the bad timing, it’s a nice, thorough article that gives a good view of things that we can do to make our apps more secure, in addition to security updates that Adobe continues to make to Flash Player.

(via email from Jeff Swartz)

Note: Sorry for the delay on this article. I composed this article a couple of weeks ago, and then I got busy with work and holidays and I forgot and didn’t publish it until now =(

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!

Several months ago I was asked to re-purpose two of my previous articles from this site for publication on the Adobe Developer Center (now renamed as the “Adobe Developer Connection”). The first one was published in September 2007, and the second was just published yesterday. So in a way this is sort of a revisiting of previous topics, but if you missed them before here they are in their new-and-improved form (or if you’re just really curious about me, you can see what I look like in my author photo on the articles =):

• Deep-linking to frames in Flash websites (Sept. 10, 2007) - for this article I took just one of the techniques I described in the original article and added more background information and better explanations. (I’m sometimes amazed by how much detail I leave out when I’m writing posts on this site!)
• Detecting when data is edited in the DataGrid component (Nov. 12, 2007) - this article was revised much less from the original than the other one. Basically I took the text and found places where I thought it needed more/better/clearer explanation, and added a sentence or revised the text. I definitely think the new version is better, but there isn’t any new information to be had if you read the original.

Last week I posted some of my thoughts on the future of Flex application frameworks, which were my take-aways from the October Silicon valley Flex user’s group (a.k.a. “SilvaFUG”) users group meeting. In that post I strongly recommended watching the recordings of the presentations. The recordings are available now, so once again I highly recommend watching them (now that you actually can watch them =)

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)

Note: On Nov. 1, 2007 I made a small change to the title of this article. The original title was “Flash Player Astro’s personality conflict…” (substituting “identity crisis” in the current title with “personality conflict”). However, I realized that “personality conflict” wasn’t the most accurate term for what I was trying to communicate, and “identity crisis” seemed like a better fit.

If you attended the North America MAX 2007 conference or tried to keep up with the news that was pouring out, you probably know that in the day 1 keynote address Emmy Huang and Justin Everett-Church demoed three new features of “Astro” (the “next version” of Flash Player):

• An improved text engine, allowing new capabilities like bi-directional text, re-flowing column text fields, and more.
• The ability to create custom graphic filters, rather than being limited to the built-in set in ActionScript.
• “Postcards in space” 3D transformations that can be applied to display objects to position/rotate them in 3D space.

I think there’s something funny about these three features and the way they’ve chosen to implement them. I didn’t really notice it when I first watched the demo video (no, I wasn’t at MAX), but later it jumped out at me as I was reading some of the responses to the demo in the PaperVision 3D email list, and even more so as I listened to the video interview that Lee Brimelow did with Justin Everett-Church later during MAX, in which Justin clarifies and expands on the three Flash Player features that were described. If you don’t want to jump away to watch the video (although it’s really good for understanding the new features) here’s a transcript of the most important statements Justin makes relating to my idea:

(:29) Justin: “[Astro’s ‘3D effects’ and PaperVision 3D] are kind of fairly different from each other…3D effects is kind of ‘3D for the rest of us’. If you wanted to try and use the 3D effects to do more complicated things there may be some APIs that might help you but you know PaperVision’s an excellent solution, you’re just not going to replace one with the other, they’re going after different objectives.”

(2:40) Lee: “There was a lot [of buzz] around filters and the ability to create your own filters, and we heard ‘Hydra’ mentioned. So what exactly is it? Is it a new programming language?” Justin: “So Hydra is a new language, it’s a pixel shader language. The Hydra language itself is very consistent with other pixel shader languages…the port between [Hydra and other pixel shader languages] is really easy.”

(4:10) Justin: “So our new text layout engine is really a group of hooks in the Flash Player that are lower level than we’ve ever had before. On top of that we’re building a series of components so they will do things like multi-column flow, inline HTML, bidirectional text, ligatures, lots of complex [?] sorts of things. But those components are developed in ActionScript 3.0 and will be deployed as part of your application. The hooks that are there are going to be exposed to developers so if you want to build your own component, if what we do isn’t exactly suiting your needs then you’ll be able to build a first-class text control.”

Notice that, based on the way Justin describes it, the idea for the improved text engine is that the actual functionality provided by Flash Player/ActionScript is very low-level, and Adobe provides components that give the higher level functionality we expect from a standard text field object (as well as additional enhanced versions).

Think about that for a moment.

Imagine if the flash.text.TextField class, the display object that’s used any time text is displayed in an ActionScript app, were actually a component on top of some lower-level API – and non-Adobe developers could freely write their own version of the TextField class, using those same low-level APIs.

By the same token, imagine if the built-in filters (the flash.filters.* classes) were actually “components” or library classes written on top of some lower-level API. (In fact, I think that’s how lots of developers see them, especially since they all derive from the flash.filters.BitmapFilter base class – with the notable issue that developers can’t create their own BitmapFilter subclasses and use them in ActionScript.) So imagine if you were allowed to create your own BitmapFilter subclass, and Flash Player would use it along with any of the Adobe-provided filters.

Yes, obviously the low-level aspect of the filters involves writing them in Hydra, not in ActionScript, and I really don’t have any idea how that’s all going to get hooked together. Just bear with me – I’m trying to describe big concepts here, not small details =)

Can you see what I’m getting at? That’s exactly what’s happening with two of the three new Flash Player features that were presented at MAX – Adobe is providing a low-level API, much lower than what most developers are going to need to use, and then they’re also providing components or libraries that will be the standard tool that most people will actually use. I think that’s an interesting approach, and one that the advanced developer community is going to really latch on to even while it doesn’t cause any pain or extra work for the typical developer.

However, compare that to the 3D (or 2.5D, as it’s often called) functionality that was shown at MAX. As Justin says, it’s intentionally a high-level API – 3D “for the rest of us” – compared to projects like PaperVision 3D that are working to provide full-fledged 3D modeling, textures, virtual world capabilities, etc. The PaperVision community isn’t so thrilled about this. Naturally they don’t think the player needs a high-level 3D API – they see PaperVision as providing the high-level API, and they’d much rather see the player provide new low-level APIs and/or improved processing power that allows them to do more, better with their higher-level APIs. (I’m paraphrasing and probably mis-describing this to some extent, since by I am by no means a 3D expert or even intermediate-level developer.)

As another aside, it occurs to me that the idea that Flash Player APIs are “high level functionality provided by the Flash Player team written in ActionScript” isn’t actually new. It’s a well-known fact that a notable amount of the Flash Player functionality is actually written in ActionScript and not in C++ or C or assembler code. In those cases the only difference between the built-in functionality and an external ActionScript library that you or I write is that the ActionScript code comes pre-installed in Flash Player and doesn’t have to be part of a SWF file download. An interesting historical note related to this is the history of the XML class (the old-school one that lives on as flash.xml.XMLDocument). The XML class was introduced in Flash Player 5, and in that release it was written entirely in ActionScript and consequently suffered from some speed issues in how it parsed XML. The ActionScript developer community (Branden Hall, I believe) wrote an alternative implementation known as XMLNitro that was faster than the built-in one. Back then in ActionScript 1, it was fairly straightforward to “redefine” methods of the built-in classes so that the player used your own ActionScript code instead, so that’s what many people did to get faster XML parsing. Funny, isn’t it, that with the newer constructs added in ActionScript 2.0 and ActionScript 3.0, we’ve also lost some functionality – namely the ability to overwrite built-in functionality with our own code. That was definitely a low-level capability that was previously available in Flash Player.

Interestingly, even in modern (i.e. post Adobe-Macromedia merger) history this idea of “low level APIs with higher-level components on top for normal use” isn’t completely new in “Astro”. One obvious precedent is the Flex framework; however, the example I’m thinking of is part of the Flash authoring tool. Historically Flash authoring was released simultaneously with new versions of Flash Player, and consequently there were always new authoring tool features that corresponded to new player features (obvious example: the filters and blend modes that were added in Flash 8 to Flash authoring as visual tools and to Flash Player as ActionScript APIs). Interestingly, however, in Flash CS3 there were some authoring tool features that were added that didn’t have a corresponding player API. Specifically I’m referring to the “copy motion as ActionScript” feature that allows you to select a tween sequence on the timeline and copy it “as ActionScript” – the animation becomes ActionScript code that you can paste somewhere and use to re-create the animation programmatically. What I think is notable about that authoring tool functionality is that the pasted code doesn’t work as-is via a player API – rather, it requires some external ActionScript libraries that were included with Flash CS3 (the fl.motion. and fl.transitions. packages). So the functionality underlying that feature of Flash CS3, one of the headline features of the product (created by none other than Robert Penner), was completely independent of the core Flash Player APIs and was instead provided by an external library.

Think about it this way: the Flash authoring tool team wanted to include functionality that wasn’t provided in core Flash Player ActionScript. It was specifically a “high level” type of functionality – simple scripted animation. Other people have written their own APIs to do the same thing, using the ActionScript “low level” APIs (display object properties, enterFrame events, etc.) and the Flash authoring “high level” approach does the same thing – it provides a library of code to simplify a certain task, so that users can easily create the effects they want, within the limitations of the high level library. I see this as another existing example of this idea of core ActionScript providing low-level functionality, with third parties and also Adobe providing high-level functionality in the form of ActionScript libraries that build on top of that low-level functionality.

Now, going into the future, there is a new Flash Player feature that allows the player to cache certain Adobe-approved code libraries, so the user downloads them once and then they’ve got them for every future site they visit that uses the same library. We’ve heard that the Flex framework is going to be the first such “cacheable” library. However, if this feature had existed earlier it could obviously have been used for the ActionScript classes that are used to support the Flash CS3 simplified animation (“copy motion”) functionality. For that matter, the Flash CS3 UI components could be given the same treatment and be available as a cacheable library, although that might be less necessary by virtue of their “intentionally lightweight” design.

While I really can’t say for sure, it seems like it’s not a stretch that the new text components would be distributed this way, especially since, as Justin points out, “those components are developed in ActionScript 3.0 and will be deployed as part of your application.”

I think that, going into the future, this is a potential direction I can see Flash Player and ActionScript moving in:

• Flash Player/core ActionScript provides low-level APIs
• Adobe provides components or libraries written in ActionScript that provide high-level-enough (“medium-level”?) functionality such that most common use cases and functionality are provided for. Probably these components/libraries are external, player-cacheable code libraries rather than part of Flash Player itself.
• Third-party developers can likewise create their own components and libraries that either build on the Adobe-provided components/libraries or provide alternate implementations.

Of course, the obvious exception to this way of working is the new 3D effects, which are very high level and are essentially the end user functionality, rather than providing low-level building blocks on which Adobe and/or third party developers can build more robust libraries.

What do you think of this future? Does it sound good, or scary? I’d love to hear your thoughts on this one…

Disclaimer: While I am an Adobe employee, I actually had very little knowledge of these “Astro” features until watching the MAX keynote presentation. I had heard general descriptions of some of them, but certainly nothing like the level of detail that was given by Emmy and Justin in the keynote and follow-up interview. Likewise, since then I haven’t gotten any additional “insider” information about these or other future Flash Player features. Obviously some of what I say in this post is speculation about the future, and I readily admit that it is indeed speculation and nothing more – I don’t have insider knowledge on this, and I might be completely wrong about all of it. =)

This post started out as my notes from the Oct. 11, 2007 SilvaFUG user’s group meeting, which included two talks on Flex application frameworks, but by the end I realized it was more of a restatement of (filtered through my opinion) some of the important forward-looking ideas that came out of the audience discussions and the presentations at that meeting. So I think it rambles more than I would normally like, but I was trying to capture my “raw thoughts” while the meeting was progressing.

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.

If you’re trying to help other developers (or yourself) get a better understanding of what AIR is and isn’t, with nice information for decision-maker types (e.g. if you’re trying to explain AIR to your boss) look no further than the November 2007 issue of Dr. Dobb’s Journal. In that issue, Oliver Goldman, one of the senior engineers on the AIR team, has an article introducing/describing AIR. I think it does a great job covering the bases of what AIR is, how developers can use it, and how it can be integrated (and secured) in an enterprise setting. It’s got some depth – it’s too long for a 5 minute or less overview – although it’s not a tutorial nor is it technical in the sense of including code samples or anything like that (which surprised me since Oliver is an engineer – but, as I’ve learned, he’s also a great writer.)

Now that the roar of MAX is over, and since AIR public beta 2 is now available on Adobe Labs, I thought I’d highlight what’s new in beta 2 specifically around the embedded SQL database in AIR:

• Synchronous database operations
• Schema API (database instrospection)
• Additional data types
• Other new documentation
• Bug fixes

Synchronous database operations

From the various public and internal feedback forums I’ve seen (discussion lists, mailing lists, etc.) this is definitely the most-requested feature from beta 1 (at least related to the embedded database). It’s in there now – when you instantiate a SQLConnection object, just add true as a constructor argument and all the operations (including SQL statements) that are executed through that SQLConnection will run synchronously.

The good news is it’s really very similar to the way things worked in beta 1, so if you’ve already been doing things asynchronously you won’t have to do much to get going with synchronous db operations. Note that a lot of people have referred to this as a “synchronous API” but in fact there isn’t a separate synchronous API – it’s the same API, with the exception of the single SQLConnection() argument.

To learn more, here’s the place where you should probably start: Developing AIR Applications > Working with files and data > Working with local SQL databases > Using synchronous and asynchronous database operations (Flex | HTML/JavaScript | Flash)

Schema API (database instrospection)

One limitation that developers pointed out in beta 1 was that there wasn’t any built-in way to get information about the structure of a database, tables, etc. In beta 2, there’s a new set of classes that can be used to get at that information. There isn’t any information in the developers guide about this yet, but in this case you can figure it out by looking in the API reference. The best place to start is probably with the SQLConnection.loadSchema() method (Flex | HTML/JavaScript | Flash).

There are also several new classes that are used for the various types of schema information you can get:

• SQLTableSchema (Flex | HTML/JavaScript | Flash)
• SQLViewSchema (Flex | HTML/JavaScript | Flash)
• SQLIndexSchema (Flex | HTML/JavaScript | Flash)
• SQLTriggerSchema (Flex | HTML/JavaScript | Flash)
• SQLColumnSchema (Flex | HTML/JavaScript | Flash)

Additional data types

Several ActionScript/JavaScript data types can now be used as column data types in the CREATE TABLE statements. When you specify one of these data types for your column, you can pass an instance of that type into an SQL statement (using a parameter) and it will property store and retrieve the data as the ActionScript/JavaScript data type. The new supported data types are:

• Boolean
• Date
• XML

More information about these data types can be found in the developers guide section “Working with database data types” (Flex | HTML/JavaScript | Flash) and in the language reference appendix “SQL support in local databases” (specifically the ”data type support” section). (Note that the link goes to the Flex language reference. I couldn’t find that appendix in the Flash or HTML/JS versions, although the content is identical for all of them since it’s really just talking about SQL.)

Other new documentation

Although I did take several weeks between beta 1 and beta 2 to move from Indiana to the San Francisco bay area, I did get some additional documentation written. If I remember right, these are the sections that are new for beta 2 (other than the ones I’ve already mentioned above):

• Using parameters in statements (Flex | HTML/JavaScript | Flash)
• Strategies for working with SQL databases (Flex | HTML/JavaScript | Flash) - new sections on improving performance and best practices
• … and more! (improvements and corrections in various other sections)

Bug fixes

Need I say more? =)

(In seriousness, lots of bugs were fixed, so if there’s an issue you were running into, try it out in beta 2 and let us know if it’s still not working.)

Simplified Chaos has an insightful article about deciding when to use AIR and when to stick to browser-based Flash/Flex. His recommendation is to use the browser by default, and only move to AIR if you really need that desktop functionality. His reasoning, which I can agree with, is that people are much less likely to try out a desktop app that they have to install (and probably uninstall later) than to just look at something in a browser. I definitely agree – I hadn’t really realized it until reading this, but I’ve noticed that when I hear about a new AIR app then I always hope the web site has some screenshots or videos of the app in action, so that I don’t have to install it to try it out.

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

(via Jesse Warden)