I have been working with the new SQL API for Adobe AIR which is available as of Flex 3 beta.

The new SQL capabilities provide numerous possibilities when developing online / offline desktop applications in Adobe AIR which require data to be persisted locally when not connected.

The SQLConnection and SQLStatement classes provide everything you need for working with a SQLite database. The SQLEvent and SQLResult classes provide an API into asynchronous statement executions from which query result and faults can be handled.

After initially working with the new classes I began to recognize the need for some interfaces which could assist in managing query results. With that being said I have created some straight forward interfaces which you can utilize to handle SQLConnection and SQLStatement results in order to handle SQLResults and SQLEvents uniformly.

The ISQLConnectionResponder interface defines a contract for classes that must provide an API which handles SQLEvent objects dispatched via a SQLConnection instance. The ISQLStatementResponder defines the contract for classes which must handle successfull SQLEvents dispatched via a SQLStatement instance. These interfaces are targeted at wrapper APIs for the SQLConnection and SQLStatement classes, therefore as a best practice they should be implemented in a has-a relationship design.

I am also in the process of developing an AIR specific ServiceLocator which integrates into the Adobe Cairngorm framework which will allow AIR application to utilizing the SQLite API to be built with Adobe Cairngorm. This will provide a temporary solution while we await a Cairngorm update which addresses this. As always I will publish the AIRServiceLocator as open source once completed.

One of the most powerful and convenient features of Flex is data binding. Data binding is the process of tying the data in one object (the source) to another object (the destination). Data binding can be used at compile time via the [Bindable] meta data tag and at runtime via the mx.bindings.utils API.

The mx.bindings.utils API provides a mechanism for dynamically applying data binding to an object. However, it does not provide a means for managing a specific data binding chain as a single unit.

The DynamicBindingChain API provides developers with a basic, yet robust API which allows multiple objects in a data binding chain to be managed. It provides a wrapper interface into the mx.bindings.utils API allowing objects to be added to a data binding chain, removed from the chain, validated against the property criteria in the chain as well as other methods for working with a managed data binding chain.

I have provided an example demonstrating some of the features available in the DynamicBindingChain API. In the example,  four TextArea objects text properties are dynamically bound and unbound to a TextInput objects text value.

Click here to view an example of the DynamicBindingChain. You can also view the source as well as the accompanying ASDoc.

A very important, yet somewhat overlooked area of design is documentation. For every public API published the quality of the code and it’s resulting usage is dramatically affected by the accompanying documentation.

In ActionScript 3.0 the ASDoc tool is invaluable. Not only is it fully supported, it is the standard for all ActionScript and mxml code documentation. Unfortunately, it is somewhat tedious to manually compile the documentation from the command line for each API you develop. To help assist developers in generating ASDocs from their code I have created a very simple ANT task which can easily be integrated within a Flex project to automate ASDoc generation.

The ASDocAntTask can be utilized from within Eclipse just as one would typically use a standard build file. Simply create an Eclipse project from the extracted file and specify the location of the source code you would like to compile documentation for as well as the directory where the generated ASDocs are to reside.

The ASDocAntTask project is comprised of the following files: asdoc.xml and asdoc.properties. Developers can specify project specific settings in asdoc.properties and run the default main target from asdoc.xml to both create the output directory, generate documentation from the source code as well as create a log file for the generated ASDocs.

The asdoc.properties file contains the following properties:

• asdoc.exe (location of asdoc.exe)
• src (location of source code)
• main.title (Documentation title)
• window.title (HTML window title)
• output.dir (Documentation output location)

The asdoc.xml contains file contains the following targets:

• clean (creates the output directory)
• create-docs (generates the ASDocs)
• log (creates the log.txt file)

These tasks can easily be modified to match your specific environment. They are very easy to use so if you do not regularly document your work then hopefully this will help get you in the habit.

You can download the ASDocAntTask eclipse project here