Note that these are basic demos so if you know pretty much anything about animation in ActionScript, these may not teach you anything.

All these scripts do pretty much the same thing. They draw a square on the stage. When you click on it, it moves horizontally from x=100 to x=400. Each of these is a class that you can run as the main class of an AS3 application.

1. The wrong way

The wrong way, of course, is to use a for loop:

package
{
    import flash.events.Event;
    import flash.events.MouseEvent;
    import flash.display.Sprite;
    public class BasicAnimation extends Sprite
    {
        // ------- Constructor -------

        public function BasicAnimation()
        {
            _createChildren();
        }

        // ------- Child display objects -------

        private var _rect:Sprite;

        // ------- Private constants -------

        private const START:int = 100;
        private const END:int = 400;

        // ------- Private methods -------

        private function _createChildren():void
        {
            _rect = new Sprite();
            _rect.graphics.beginFill(0xff0000, 1);
            _rect.graphics.drawRect(0, 0, 100, 100);
            _rect.graphics.endFill();
            _rect.x = START;
            addChild(_rect);
            _rect.addEventListener(MouseEvent.CLICK, _rect_click);
        }

        // ------- Event handling -------

        private function _rect_click(event:MouseEvent):void
        {
            // wrong way:
            _rect.x = START;
            while (_rect.x < END)
            {
                _rect.x++;
            }
        }
    }
}

The right way (most basic)

Of course, this one runs very slow since it’s moving at a rate of 1 pixel per frame.

package
{
    import flash.events.Event;
    import flash.events.MouseEvent;
    import flash.display.Sprite;
    public class BasicAnimation extends Sprite
    {
        // ------- Constructor -------

        public function BasicAnimation()
        {
            _createChildren();
        }

        // ------- Child display objects -------

        private var _rect:Sprite;

        // ------- Private constants -------

        private const START:int = 100;
        private const END:int = 400;

        // ------- Private methods -------

        private function _createChildren():void
        {
            _rect = new Sprite();
            _rect.graphics.beginFill(0xff0000, 1);
            _rect.graphics.drawRect(0, 0, 100, 100);
            _rect.graphics.endFill();
            _rect.x = START;
            addChild(_rect);
            _rect.addEventListener(MouseEvent.CLICK, _rect_click);
        }

        // ------- Event handling -------

        private function _rect_click(event:MouseEvent):void
        {
            // right way (very basic):
            addEventListener(Event.ENTER_FRAME, _enterFrameBasic);
        }

        private function _enterFrameBasic(event:Event):void
        {
            if (_rect.x < END)
            {
                _rect.x++;
            }
            else
            {
                removeEventListener(Event.ENTER_FRAME, _enterFrameBasic);
            }
        }
    }
}

Adding velocity as a variable

The solution to the slowness is to add a velocity variable. The value (in units of pixels per frame) will determine how quickly the animation moves. Basically you just try different values until you’re happy with something. Like the previous example, this is a purely linear animation — the velocity stays constant.

package
{
    import flash.events.Event;
    import flash.events.MouseEvent;
    import flash.display.Sprite;
    public class BasicAnimation extends Sprite
    {
        // ------- Constructor -------

        public function BasicAnimation()
        {
            _createChildren();
        }

        // ------- Child display objects -------

        private var _rect:Sprite;

        // ------- Private constants -------

        private const START:int = 100;
        private const END:int = 400;

        // ------- Private methods -------

        private function _createChildren():void
        {
            _rect = new Sprite();
            _rect.graphics.beginFill(0xff0000, 1);
            _rect.graphics.drawRect(0, 0, 100, 100);
            _rect.graphics.endFill();
            _rect.x = START;
            addChild(_rect);
            _rect.addEventListener(MouseEvent.CLICK, _rect_click);
        }

        // ------- Event handling -------

        private function _rect_click(event:MouseEvent):void
        {
            // right way (very basic):
            addEventListener(Event.ENTER_FRAME, _enterFrameBasic);
        }

        private function _enterFrameBasic(event:Event):void
        {
            if (_rect.x < END)
            {
                var velocity:int = 5;
                _rect.x += velocity;
            }
            else
            {
                removeEventListener(Event.ENTER_FRAME, _enterFrameBasic);
            }
        }
    }
}

Adding acceleration

Once you’ve separated out velocity, it becomes easy to make the animation non-linear by adding an acceleration value that causes the velocity to change over time. We’re just stepping back one level of complexity — the acceleration is now linear instead of the velocity.

package
{
    import flash.events.Event;
    import flash.events.MouseEvent;
    import flash.display.Sprite;
    public class BasicAnimation extends Sprite
    {
        // ------- Constructor -------

        public function BasicAnimation()
        {
            _createChildren();
        }

        // ------- Child display objects -------

        private var _rect:Sprite;

        // ------- Private constants -------

        private const START:int = 100;
        private const END:int = 400;

        // ------- Private methods -------

        private function _createChildren():void
        {
            _rect = new Sprite();
            _rect.graphics.beginFill(0xff0000, 1);
            _rect.graphics.drawRect(0, 0, 100, 100);
            _rect.graphics.endFill();
            _rect.x = START;
            addChild(_rect);
            _rect.addEventListener(MouseEvent.CLICK, _rect_click);
        }

        // ------- Event handling -------

        private function _rect_click(event:MouseEvent):void
        {
            // right way (very basic):
            addEventListener(Event.ENTER_FRAME, _enterFrameBasic);
        }

        private var _velocity:int = 0;

        private function _enterFrameBasic(event:Event):void
        {
            if (_rect.x < END)
            {
                var accel:int = 3;
                _velocity += accel;
                _rect.x += _velocity;
            }
            else
            {
                removeEventListener(Event.ENTER_FRAME, _enterFrameBasic);
            }
        }
    }
}

Interpolating values over time

This next example doesn’t build on the previous ones but instead takes a completely separate approach to creating animation. This animation is time-driven rather than frame-driven. Instead of adding a particular number of pixels to the x value each frame, it calculates how much time has elapsed since the start and what the x value should be at that moment in time, then sets the x property to that value. A consequence of this approach is that regardless of the frame rate of the SWF, the animation will always last the same amount of time.

package
{
    import flash.utils.getTimer;
    import flash.events.Event;
    import flash.events.MouseEvent;
    import flash.display.Sprite;
    public class AnimationIntermediate extends Sprite
    {
        // ------- Constructor -------

        public function AnimationIntermediate()
        {
            _createChildren();
        }

        // ------- Child display objects -------

        private var _rect:Sprite;

        // ------- Private constants -------

        private const START:int = 100;
        private const END:int = 400;
        private const TOTAL_TIME:int = 5000;

        // ------- Private methods -------

        private function _createChildren():void
        {
            _rect = new Sprite();
            _rect.graphics.beginFill(0xff0000, 1);
            _rect.graphics.drawRect(0, 0, 100, 100);
            _rect.graphics.endFill();
            _rect.x = START;
            addChild(_rect);
            _rect.addEventListener(MouseEvent.CLICK, _rect_click);
        }

        // ------- Event handling -------

        private var _startTime:int = 0;

        private function _rect_click(event:MouseEvent):void
        {
            // right way (intermediate):
            _startTime = getTimer();
            addEventListener(Event.ENTER_FRAME, _enterFrameIntermediate);
        }

        private function _enterFrameIntermediate(event:Event):void
        {
            var elapsedTime:int = getTimer() - _startTime;
            var fractionComplete:Number = elapsedTime / TOTAL_TIME;

            if (fractionComplete < 1)
            {
                var totalDistance:int = END - START;
                var offset:int = Math.round(fractionComplete * totalDistance);
                _rect.x = START + offset;
            }
            else
            {
                _rect.x = END;
                removeEventListener(Event.ENTER_FRAME, _enterFrameIntermediate);
            }
        }
    }
}

The main point of this example is to demonstrate the idea that you can plug in an algorithm that calculates position given time, and by varying the algorithm you can vary the animation. This is a direct lead-in to the idea of using tweening functions to vary an animation, as demonstrated in the next example.

Using an animation library

This example shows the use of a third-party animation library (in this case Grant Skinner’s GTween library). The commented-out lines demonstrate how a library makes it easy to synchronize animation and vary the animation. Note that this is only meant as a very basic demonstration of the concept of using a library for animation — GTween and the many other animation libraries that are out there all provide many additional features.

package
{
    import com.gskinner.motion.easing.Bounce;
    import com.gskinner.motion.easing.Sine;
    import com.gskinner.motion.GTween;
    import flash.events.MouseEvent;
    import flash.display.Sprite;
    public class AnimationTween extends Sprite
    {
        // ------- Constructor -------

        public function AnimationTween()
        {
            _createChildren();
        }

        // ------- Child display objects -------

        private var _rect:Sprite;

        // ------- Private constants -------

        private const START:int = 100;
        private const END:int = 400;
        private const TOTAL_TIME:int = 5;

        // ------- Private methods -------

        private function _createChildren():void
        {
            _rect = new Sprite();
            _rect.graphics.beginFill(0xff0000, 1);
            _rect.graphics.drawRect(0, 0, 100, 100);
            _rect.graphics.endFill();
            _rect.x = START;
            addChild(_rect);
            _rect.addEventListener(MouseEvent.CLICK, _rect_click);
        }

        // ------- Event handling -------

        private function _rect_click(event:MouseEvent):void
        {
            var tween:GTween = new GTween(_rect, TOTAL_TIME);
            tween.setValue("x", END);
//            tween.setValue("alpha", .5);
//            tween.ease = Sine.easeInOut;
//            tween.ease = Bounce.easeOut;
        }
    }
}

For lack of a better name, I call it my “AIR SQLite utility library”

The code currently contains one major piece of functionality (well, two different variations on one bit of functionality), which is a SQL “query runner” library. This is a wrapper for the AIR SQL classes that allows you to run a SQL statement by just passing a few bits of information:

• The text of the SQL statement itself
• An object containing properties with the values for any statement parameters in the SQL
• A Function to call when the operation completes
• A failure Function
• (optionally) a class to use as the data type for the data returned from a SELECT statement

The library does all the work of creating SQLStatement objects and caching prepared queries, as well as pooling SQLConnection instances so you can execute multiple statements simultaneously. It also has a variation that allows you to specify a “batch” of statements to execute, and they are executed in order in a transaction.

I’ve also got an additional utility to add to the library. It’s a “database copy” utility that allows you to create a “deep copy” of a database — all it’s tables, views, etc. — with or without data. The key reason why this is useful is that you can use it to create an encrypted database from an unencrypted database (and vice-versa). It’s written and tested, but I decided to modify the structure slightly before releasing it, so it’s not checked in yet.

I’ve put the details about how it works and why it’s designed that way in the project page. In case you’ve ever wondered how I design apps, I think the examples and this library give some insight into how I actually do my database-driven AIR app development. At least, how I structure the data-access part of my apps.

On (another) personal note, this project is also my first project that I’ve posted to my Github repository (as opposed to projects I’ve forked). It was actually posted-but-not-advertised on Google code for a month or so, but I decided to move to Github because the collaboration and checkin-without-network-connection features are so awesome.

• First thing first: if you haven’t seen the MythHackers video about Flash on the iPhone, you must go watch it. I laughed so hard my eyes were watering.
• Aditya Bansod’s ADC article “Developing for the Apple iPhone using Flash,” from the Product Manager who’s in charge of the Flash Platform development for iPhone effort. Includes some technicial details on how it actually works and how you build the apps.
• Adobe Labs: Apps for iPhone: Video demo and list of apps that are already in the app store today
• Adobe Labs developer FAQ: this has the most information about what this really means for developers
• Mike Chambers is, as always, a great resource for information on this topic. He has a nice summary blog post, plus I know he’s collecting questions to answer in his MAX session (on Wednesday, I believe).
• Arno Gourdol, engineering manager for Adobe AIR (and huge iPhone fan and former Apple employee) talks briefly about the underlying technology, with a focus on MAX sessions where you can learn more.
• Never one to hold back his enthusiasm, Ted Patrick has posted the source code for three different Flash Platform iPhone apps he wrote, that can be seen on the demo phones in the Adobe booth at MAX. (He says it’s four apps in the blog title, but he explains that two of them are the same app with and without hardware acceleration.)

That’s all for now. I’ll keep updating the list as I find more resources.

• 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.

But not any more. A few days ago I checked in a beta (barely tested) version of that adds support for Flash Player 10 (browser) projects. It’s not linked from the main google code project page yet, but you can get to it from the GZIP encoder project downloads page.

The download that adds Flash Player 10 support is “ascompress-.2.0.zip”. It now includes two SWC files:

• GZIPEncoder_AIR.swc is the full package, with all the same features as the previous release (.1.0.2).

• GZIPEncoder_Flash.swc is the Flash-Player-only version. It only compresses/uncompresses ByteArrays, and doesn’t have any support for files.

  Of course, since Flash Player 10 also adds local file opening/saving support that uses ByteArray data for the files, you could easily write your own code to prompt the user for a gzip file, or compress a file and prompt the user to save it. For an example of opening and saving files from Flash Player 10, see my quick start article: “”

As I implied when I described this as “beta (barely tested)” I haven’t done a lot of testing of this code yet. I don’t actually anticipate that there will be issues — really all I did was refactor the code into two classes instead of one — but that doesn’t mean there won’t be any issues, of course. =) If you’re interested, and especially if you’re one of the people who’s asked for this support, I would love it if you try it out and let me know how it works for you. If you’re willing to test it out, I’ll be happy to quickly make any fixes necessary.

On a personal note, the screenshot that Lee posted for the Vector class documentation was written by me. So that was fun to see =)

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)

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)

Since the majority of the time when someone’s using an Array in ActionScript, they really want all the elements to be the same type anyway, this is a really great addition and I think it will be used heavily. The Vector class allows (requires) you to specify the type it will contain at compile time — both for variable declarations and when creating instances. In both cases the syntax you use is a “type parameter” suffix .<T>:

var names:Vector.<String> = new Vector.<String>();

The type parameter syntax is part of a separate EcmaScript 4th edition proposal. Sadly they couldn’t make the syntax identical to that for generics in C# (and I believe Java does it the same way), which is almost the same but without the initial . (period). (For an interesting read, take a look at the history of the various options the committee members considered for representing type parameters.)

Anyway, because you specify the type at compile time, the idea is that the compiler can do the type checking for you for adding and getting elements from a Vector instance. In addition, since using Array (and the runtime type checking and type casting that array access involves) has always been a bottleneck in ActionScript performance, I expect that performance improvements can be expected. (Okay, I’ve heard anecdotal reports around the office of much better performance for Vector than for Array.)

Francis Cheng (who’s on the EcmaScript committee) has a couple of nice articles about the Vector class and type parameters, so I won’t bother recreating everything he’s written. Definitely worth a read (like everything he writes).

As an (almost) final note, I should point out that I haven’t seen anything indicating that type parameters will be generally available in “Astro” — just Matt’s announcement about the Vector class specifically.

And finally, on a personal note, I’m excited because I get to do the documentation for the Vector class. It’s always fun getting to write about new features that are personally valuable. And this is one that I’ve definitely been interested in for a while!

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.

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)

• 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.

• 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.)

Now, if you or someone you know is a Flash designer with almost-none-to-basic ActionScript experience, and you want to learn ActionScript from the established master, you can do it for free. Adobe is sponsoring a free, one-day ActionScript training course given by Colin Moock that’s traveling around the U.S. (and eventually the world) starting in October 2007.

They’re calling it “Colin Moock’s ActionScript 3.0: From the Ground Up Tour.” And you shouldn’t feel intimidated if you are just getting started with ActionScript — the site explicitly says it’s not for advanced developers, so if you’re just getting going (i.e. you’ve done some frame scripts but not anything with classes) you should be in your element.

Currently it looks like there are stops scheduled in San Francisco, Los Angeles, and New York City. Even if you don’t live in one of those areas, think of it this way — for only the price of travel you’re getting an awesome training experience.

(via Stefan Gruenwedel)

Okay, that sounds really boring. But I don’t mean it to. I’m actually incredibly excited by this, because it makes it a lot easier for people like me, with web app experience but not desktop app experience, to create data-driven apps and store persistent data using techniques that I’m familiar with.

And, on a personal note, it means that I finally get to talk about what I’ve been working on for the last couple of months. If you actually follow my web site, you’ve probably picked up on the fact that I was heavily involved in the ActionScript-related documentation for the Flash CS3 release. Well, naturally, now that Flash CS3 is out the door, I’ve been moved onto another project — onto Apollo/AIR, specifically.

More specifically, since I’ve been programming SQL databases for many years, as part of my web app development work, I got pegged (well, I actually volunteered) to do the documentation and samples for the local SQL databases feature.

When I first read the spec for the feature, I was completely floored. I was expecting some minimal support for a few things, but what we’ve got is much more than I could come up with use cases for. Want a good idea of the breadth of the functionality that’s available? Spend some time reading “SQL support in local databases” (it’s an appendix of the AIR language reference). Views? Indexes? Triggers? They’re in there.

In case you don’t have a free few hours, I’ll just point out my favorite parts of the feature. These will probably be most meaningful if you’ve already faced the joy and pain of working with web-database apps, especially with an OOP language:

• SQLStatement.itemClass: This was my immediate favorite. You specify a class, and SELECT statement result rows are automatically converted into instances of that class (saving lots of boilerplate code to loop through results and turn rows into instances of some other class). If I could have done this in ASP.NET, I’d probably have saved about 25% of the total code I wrote.
• SQLStatement.prepare() and SQLStatement.parameters: Now that I’ve spent some time building apps and working with the code, I’ve gotten a lot of respect for this method. Basically, this is the way to create the equivalent of pre-compiled stored procedures for your AIR app.
• SQLResult.lastInsertRowID: I had to lobby long and hard for this one, which, since I’m a remote employee, meant lots of email exchanges. Finally I managed to clearly articulate my reason, and sure enough, persistence paid off. If you’ve created a database app, chances are you’ve run into the case where you INSERT a row, and you need to get back the auto-generated primary key so that you can insert a related row. The wrong way to do it is SELECT MAX(id_column) FROM table. The right way, in AIR, is to use lastInsertRowID.

I’m excited that I can talk about this now. I’ve got some samples, practices, and information that I’m looking forward to sharing. I’ll start with an answer to a question that I’ve seen asked around (well, mostly I’ve just seen misinformation, not people asking whether it’s right) about the relationship between the AIR local SQL database API and the Google Gears SQL database API:

• Does Apollo “include” part of Google Gears? - No. There is no shared code between AIR and Google Gears (with the possible exception noted in the next answer).
• What do AIR and Google Gears have in common, then? - Both AIR and Google Gears let you create applications that access databases located on a users local machine. Both AIR and Google Gears chose to use SQLite, a free, public domain embedded SQL database engine, to provide that functionality. So whatever code AIR uses that hasn’t been modified from SQLite, is the same as the code that Google Gears uses that hasn’t been modified in its implementation of SQLite.
• What’s this about AIR including the same database API as Google Gears? - To be honest, although I’ve been involved in the AIR database API for a while, the first I heard of Google Gears’ database API was when the public announcements were made. Thinking back, I see now that discussions were going on for a while, and I even unknowingly provided some support to the management team and others who were involved in that discussion. Right now, although the underlying database engines are based on the same engine, since SQLite is written in C, any implementation that doesn’t use C/C++ needs to write its own API. The two implementations (Adobe’s and Google’s) weren’t developed together, and at this point (from what I’ve seen) the two APIs are pretty different. Case in point: synchronous versus asynchronous database operations. In Google Gears, data access operations are synchronous — calls to the database are blocking, meaning the runtime freezes at the line of code that called the database until the result is returned. In AIR, on the other hand, all data operations are asynchronous — you call SQLStatement.execute() to run a query, and when the result comes back an event listener function is called (at which point the result data can be accessed). That alone means a big difference in how you write code to work with the two systems.
• So wait a minute, what about the whole “Adobe and Google are working together on the database API” thing? - Adobe and Google are having “discussions,” and (from what I’ve heard) the plan is to hopefully make the APIs the same or similar enough that a developer who writes data access code for Google Gears will have an easy time writing data access code for AIR (and vice versa). In addition, since the SQL part of both runtimes really is dependent on SQLite much more than the particular runtime implementation, and SQL code probably is interchangeable between the two runtimes, assuming the same database schema etc.

So from me, and the other engineers and stakeholders inside Adobe, please try out the local SQL database functionality of Apollo, and please let us know what we can do to make it better. In particular, let me know what is missing or what you’d like to see in terms of documentation and samples — but don’t limit yourself to that. Please share your comments/suggestions!

On a more personal note…

I’m really excited about this. I really just can’t say in words how excited I am. When I decided to accept an offer to work full-time for Adobe, one of the first “regrets” that crossed my mind was when I considered that it was highly likely that I wouldn’t be doing any more database programming (since my work involves dealing with ActionScript, and up to now there hasn’t really been any direct database access from ActionScript). So I was excited to say the least when I heard about this feature and it was decided that I’d get to work on it.

Suffice it to say, this has been a pretty busy time. This feature was actually slated to appear in a later release, but at the near-last minute the decision was made to get it done in time for the public beta. That meant a lot of writing and application-building in a hurry! Then two weeks and a private beta release later, a group of people including me, engineers and QEs, and other interested folks, went through a few rounds of discussions on what was missing and what we could do to make the API better. The result, which of course still isn’t finished, is what you can download today.

And, although she isn’t a developer and doesn’t use Apollo/AIR at all, it’s an understatement to say that my wife is glad to see this beta out the door, if only because it means I don’t have to work evenings any more (it’s been a very busy month+ =).