Professional Cairngorm™

13.3. Impact on Cairngorm Usage

As mentioned in Chapter 12, the choice of using Adobe Air and placing the database on the local machine is not without its drawbacks. Specifically, since no HTTPServices are being called, the normal method of allowing the delegate responder to react to the HTTPServices call will not work.

For simplicity's sake we are using the SQL API in synchronous mode (otherwise you end up with a bunch of callback functions). Because we are using this mode, you will have to use try-catch blocks to catch any errors that occur during the SQL execution. In doing so, you can see that the responder functions are being directly called in the try-catch blocks for their respective situations (everything went okay versus something went wrong).

So while the ServiceLocator has been taken out of the mix and there are some differences in how delegates are being constructed to access the local database, you are still for the most part following the standard Cairngorm flow for accessing data.

On the positive side, there is an added benefit of using value objects with this system. You learned in Chapter 9 that it is conventional to have the properties on value objects match their representations on the server side or data store. This is so they can be used as data transfer objects.

As it turns out, one of the SQL classes has a feature that will make value objects a nice means of representing data in the application. Specifically, the SQLStatement has a property called itemClass. ...