The first version of our contact management application introduced us to the database access API in AIR. However, the lack of “application partitioning” or “separation of concerns” in that first implementation represented a poor architecture with no potential for reusability.

In this second version, we use the Data Access Object pattern to improve the overall architecture of our application. A Data Access Object typically encapsulates the data access logic for one entity (in this case: Contact).

An interface (named IContactDAO) defines the “contract”:

package
{
	import flash.utils.ByteArray;
	import mx.collections.ArrayCollection;

	public interface IContactDAO
	{
		function findAll():ArrayCollection;

		function insert(contact:Object):void;

		function update(contact:Object):void;

		function updatePicture(contactId:int, jpeg:ByteArray):void;

		function deleteItem(contact:Object):void;
	}
}

The ContactDAO class implements that interface and provides one specific implementation of the contract (persisting data to the embedded SQLite database).

Benefits:

• The View doesn’t know anything about your data access logic: You can reuse the same view (ContactForm) with a different way to access your data. You would just create another class implementing IContactDAO and pass an instance of that class to ContactForm. Notice that the dao property of ContactForm is of the IContactDAO data type (the interface). This allows us to pass an instance of any class implementing the IContactDAO interface to ContactForm.
• The DAO doesn’t know anything about the view: You can reuse the same data access logic from within different views.

Install inSync Local DAO Edition:

Click here to download the source code. You can also right-click the app and select View Source to view the source code and download the application.

Limitation:

There is still a lot of SQL code to write. There are a few options to overcome that limitation:

• You could create a mini DAO framework where a base DAO class would take care of all the boilerplate code to set up and execute SQL statements. (See the BaseDAO class in Salesbuilder for an example).
• You could use an ORM framework where SQL statements are automatically generated.

In part 3, we’ll look at a version of inSync built with an annotation-based ORM framework.

Follow @ccoenraets

In my MAX session called “Liberate your Data with AIR”, I presented different approaches to access local data using the SQLite database access API in AIR.

The list of approaches included:

1. “SQL in View”
2. Data Access Object (DAO) pattern
3. Using an Object Relational Mapping (ORM) framework

I demonstrated a version of inSync (a simple contact management application) built with each of these approaches. I’m dedicating one blog post to each approach. This first post is focused on the “SQL in View” approach. To spice things up just a little bit, inSync also demosntrates how to take a picture of a contact using your webcam and store it in the SQLite database as a blob.

Install inSync Local SQL Edition:

NOTE: this application uses the same skin and overall context as a sample I posted previously to illustrate offline data synchronization using LCDS, but the implementation is entirely different: No LCDS here… just local data access.

Click here to download the source code. You can also right-click the app and select View Source to view the source code and download the application.

Using the “SQL in View” approach, you embed SQL statements as needed in View components. In this example the ContactForm component has create, update, and delete methods with the appropriate embedded SQL statements to insert, update, and delete a contact in the database. This approach works for quick prototyping, but is generally a bad practice. When you mix view logic and data access logic in the same component, neither the view logic, nor the data access logic is reusable: you can’t reuse the view with a different way to access your data, and you can’t reuse your data access logic with a different view.

I provide this approach here as a quick way to get acquainted with the database access API in AIR. For real life implementations, a more partitioned approach such as the DAO pattern or an ORM framework is of course highly recommended. Stay tuned for an example of approaches 2 and 3.

Follow @ccoenraets