Adobe today announced beta versions of its Flex 3 SDK, released under the Mozilla Public License, the Eclipse-based FlexBuilder 3 IDE, the desktop Adobe Integrated Runtime, or AIR—previously known as Apollo—and a new version of Flash Player 9 designed to take advantage of multicore CPUs.

In this interview with Artima, Adobe senior product specialist Kevin Hoyt talks about the new features in these developer releases:

Frank Sommers: Let's start with the new Flash Player beta. Why provide multicore CPU support in Flash Player?

Kevin Hoyt: Until this release, Flash Player 9 hasn't taken advantage of multicore CPUs. This version does. That gives the Player a much better ability to have full-screen video, and a much faster rendering of vector graphics on a multi-core system. If you think of a Flex UI, it is rendered through the vector rendering engine in Flash Player, and so there is also the potential that this upgrade makes some Flex applications perform faster. This will be a Player 9 release, but we haven't announced a version number for it yet.

Frank Sommers: Can you tell us about new features in the Flex 3 beta?

Kevin Hoyt: With this beta release we now officially jumped into the Mozilla Public License for the Flex SDK, something we announced earlier this year we would do. We also opened up the bug database for Flex: everybody can see what bugs are there.

The new features in Flex 3 all target the currently available release version of Flash Player 9, so all of these features can be used right away. For Flex core, there are some nice new components, including the advanced data grid. That data grid now includes hierarchical display, and highly customizable item renderers and headers. Some people call this a treegrid because it combines the tree and table components, and allows you to build hierarchical displays for data drill-down.

Coming from an AIR background, there is a lot more AIR integration, including the ability to create AIR projects in FlexBuilder 3 beta, AIR project publishing, and some new controls that are centered around working with the APIs available in AIR. For example, there are new Flex components around the filesystem APIs.

Frank Sommers: Why "AIR" for the name of the desktop runtime, and what new features does the beta contain?

Kevin Hoyt: Apollo was the previous name, and now we call it the Adobe Integrated Runtime, or AIR. When we released the alpha version of Apollo, a lot of people focused on its off-line capabilities. The early parts of the API were somewhat rudimentary there, such as the file I/O, and to be able to install and run an AIR application on the desktop.

But there is a much bigger story for Apollo, or AIR, than just off-line applications: That is to take Web-application skill sets—be that HTML, or Flash, or Flex—and build desktop applications using those skills.

When I say desktop applications, I mean far more than just offline applications. Some of the things that you'll see in the AIR beta are features that'll express what we mean by desktop applications, including things like full clipboard support, native drag and drop both into the application and out of the application, and enhanced native windowing support. Then there is new native menu support, so if you're on the Mac and you use these new classes, the menu will show up on the top [of the screen], and on Windows it will show up on the top of your application. Those are some of the features that make the runtime a desktop environment versus just an offline environment.

We also improved on some things that were there in the alpha. One of those is the file API, and we also polished the network detection capability. We also put in the latest version of WebKit, improving the HTML rendering. We also tied things much better into the application workflow when you deploy HTML applications with AIR.

I should mention that DreamWeaver CS3 released a set of extensions last night that allows you to also build AIR applications within the DreamWeaver environment. There is also an open-source IDE, Aptana, also built on Eclipse. Aptana has a very powerful JavaScript debugger and code intelligence algorithm for JavaScript, and they also released a set of extensions for the Aptana environment. If you are using the latest and greatest JavaScript toolkit, for example, you can now create with those Aptana extensions AIR projects. The Aptana extensions provide things like code intelligence for the AIR APIs, and the ability to package and publish an AIR application.

A significant new feature in the beta is SQLite integration. That means local database access for AIR applications, which has been the most-requested feature out of the alpha. The SQLight engine is very rich as far as desktop applications go—it supports BLOBs that can be two gigabytes in size, for instance. We've done a lot of internal performance testing, and have been very pleased with the volume SQLite can handle.

SQLite integration has been on the drawing board for a while, and we tried to keep it under lock and key until the release of this beta. But, as it were, Google contacted us, and told us about their Google Gears project that also uses SQLite for local data storage. So we are going to work with Google, Mozilla, Opera, and a few others, and make sure the APIs are all aligned and in sync: If you're using any of the SQLite functionality, whether through Google Gears or through some other means, those APIs will match what you will have available in AIR.

We are at an early stage of doing that and, at this point, there are some differences. For example, Google Gears is aimed at a purely synchronous operation: you have to complete a transaction before you can do anything else. In the AIR version of SQLite, the integration focuses on both synchronous and asynchronous access: You can do things in the database, and get events when you commit.

With AIR and our LifeCycle suite, we also provide integration between the offline and online modes. The LifeCycle data services include a lot of data management and transaction features specifically around data synchronization. Having a SQLite database in the client in the AIR environment means that if you use that against the LifeCycle APIs available in Flex, you have seamless authoring for both offline and the Web, and have full synchronization capabilities as well.