I wrote about an Active Record implementation for the Adobe Integrated Runtime using it's SQLite database functionality. I put up all the code on Google Code under the name AIR Active Record. Please check it out, let me know of bugs or features, or better yet, submit fixes and add-ons. If you're interested in being an active developer on it let me know.

Update:

To use the ActiveRecord (sorry for the lack of documentation), you need to extend it with a class for each table you'll use. For example, if I wanted an employee table I would create an Employee class like this:

In the metadata, the name is the property name which will be auto-generated and auto-populated (when you access it) for the relation. The className is the full class path (e.g. com.foo.Bar). multiple is a flag that specifies whether it's a one-to-many relationship. You can have many-to-many relationships as well.

If you aren't creating the database yourself there is a handy-dandy feature which will do it for you off of code introspection. Many-to-many is not supported for creation this way unless you have a class for that join table and run it on that.

This will create the table if it doesn't exist, but it is also useful for updating the table if you've added new properties to the class. (right now it doesn't delete columns if you remove properties)

Then, you use it. You'll need to look at the code comments, or maybe generate the AS3 docs off of it to see all you can do, but this is some of what you can do (let's say you have an Employee class and a Task class):

Pretty cool stuff. Maybe someone should document it! :D Anyone interested in figuring out and documenting super-cool code, please apply!

I wrote a project timer awhile ago. After I had done that (in Flash 8) I needed a task list that could be split up by client and project, so I combined the old time and a new task list into what I called creatively the Project Tracker. I've been using it since Apollo preview release. I just added a new feature for myself that rounds the times to the nearest half-hour or hour if desired (since that's how my company bills clients), and I thought that I'd share it. It allows you to keep track of time spent on tasks, project, and clients as well as let's you check off any of them when complete. You can also store notes about each of them.

It doesn't use any AIR specific features, just SharedObject, but I sure like to have it as a desktop application rather than in the browser. I always close browser versions on accident.

This application is provided as-is with no documentation, support, or guarantee of anything. Hope you find it useful. You can view Project Tracker in your web browser before you download it.

Update: Republished for the AIR 1.0 release and updated badge install.
Update 2: Found and fixed the problem reported in comments. Using a relative path in the badge installer for AIR apps results in some of the errors reported.

I'm working on a library to give rich text or WYSIWYG functionality to an AIR HTMLLoader. It's coming along nicely thus far. I have all the keyboard shortcuts happening and the HTML is being replaced by the appropriate stuff (e.g. bold fixes webkit's <span class="Apple-blah blah" style="font-weight: bold"> to just <b>). I've got undo/redo in place even with typing and deleting etc.

So I was thinking, it would be cool to write a DocBook editor in AIR. It might be the first DocBook authoring tool that looked nice. :) DocBook is an XML format for books or documentation. I won't go into why it's so great, but you can check it out yourself.

NativeMenus for AIR have been somewhat of a pain since each item in a menu can take 3-4 lines of code or more to write once you add the listener, the key shortcuts, etc. Then when you've got 20 items or so you have an unreadable unmanageable mess to deal with. Very unFlexy. So I set about making it work in MXML with the advantages of readability, conciseness, and don't forget bindability. This makes it a much cleaner solution than a component which creates a commonly used menu or using XML data providers to define the menus.

First I created a Menu class which extends NativeMenu. Because of the way MXML works we will need to set our menu's items in one go rather than using the addItem and addItemAt methods. So I created an items setter to complement the items getter which is part of NativeMenu.

I want all of the MXML tags under my <Menu> tag to be the MenuItems, so in order to tell the compiler where those go I also added a metadata tag at the top of my class.

Now moving on to the items themselves I created a MenuItem class. I wanted some more magic here since this is where all the hassle goes. First thing I wanted to do was to make a simple way to define the key shortcut. In code you have to add a keyEquivalent letter and a keyEquivalentModifiers entry for each modifier key. Way too complex for MXML. So I created a getter/setter called shortcut that parsed a string and added the pieces for you. Now I could have shortcuts that looked like "Ctrl+P" and "Cmd+Shift+F" in the MXML. Very readable. Much better. (I also set Cmd to Ctrl when on Windows since Mac Cmd shortcuts are usually the same as Windows Ctrl.)

Next I tackled submenus. I created a getter/setter called items (same as the menu now) which let you specify your submenu's items directly underneath the parent item. I figured it's not a common use-case to add listeners on the submenu itself. I also added the metadata to make MXML items inside of a MenuItem map to the "items" property.

Now our items can have their subitems directly under them in the MXML.

Finally I looked at adding support for the mnemonicIndex property to get set. For those of you who don't know what this is, it tells AIR which letter in the menu to underline and allow a key-stroke to select it (I believe it is a Windows feature, but may be supported on Mac as well....somehow). Very important for accessibility. So I figured I'll just have an underscore denote which letter should be, such as "_File" would say that "F" is the mnemonic letter.

Nicely done. We now have our label set and our mnemonic letter specified with just the label property, and this lends itself to setting the mnemonic letter separately for other languages as it is part of the label text.

I quickly added a MenuSeparator which just extended NativeMenuItem and set the isSeparator value in the constructor to true. This was for readability in the MXML.

The last thing I wanted to do is to add support for menu differences between Ma, Windows and Linux. This was a last minute idea because menus can look differently, behave differently, or have different shortcuts between the two systems. So I added a property to MenuItem called "os" which should be a string of "mac", "win", "lin" or a combination of them such as "win/lin". Then I added to the Menu items setter code that would skip over adding items which were set for an OS that was not the current one. This allows two items with the same name to be specified but with different shortcuts, or two submenus that are different on different OSes.

Now I could define menus in MXML like this:

The final result was:

Enjoy!

I've been working with AIR quite a bit since my side project is in AIR. I thought it would be pretty cool to create an active record implementation in AIR since I've got one on the server side.

I have to use synchronous database connections for it so that everytime I access an object's related properties I don't have to use a callback, though it could be refactored to do that. Not my idea of fun though, and after an excellent presentation by Jason Williams, "Working with Persistent Data in AIR," where he showed how fast it was to retrieve data from an AIR database I figured it would be just fine.

Currently I don't have metadata allowing you to define how every property maps to a field in the database, nor do I have many "special case" hooks for this and that. I figured that any AIR app you write will be using a fresh database and not a legacy system. How many desktop apps using a SQLite database will you be updating with AIR and using the same database file? Maybe I'm wrong, but I don't think so.

I also added a piece that you can run which will create and update database tables based off the ActiveRecord object's properties. So you have a nice update mechanism for the database when you update your app using the updater api.

I'll be open-sourcing the code when I have time (isn't that always the case), but you can get the code now, test it out, and let me know what enhancements you'd like to see. Sorry, no documentation currently. If I like the ideas or they're requested enough I'll be sure to add them in. :)

Oh, and when you unzip it you'll see "flight" is the package Tyler (my twin) and I are using for our projects. It started when he and Rob Taylor started a component set in AS2 under the name but AS3 and Flex 2 came out and they never finished. Maybe an AS3 set will happen someday.

Update: AIR Active Record is open sourced.