These notes are taken at Adobe MAX 2009.

You can use HTTPService, WebService, RemoteObject components in Flex to pull data in different ways. Now what about ColdFusion 9?

ColdFusion’s Flash Remoting has been improved. So Flash applications that have ColdFusion 9 as a backend will interact much faster, and it can handle circular references.

There is now direct data translation between ActionScript and CF types, instead of previously having an intermediate Java layer that handled this. This involves changes in services-config.xml, but no code changes are required in your apps. Support for the old style remoting is still present for backward compatibility.

So how much faster is it? Drastically faster. Easily x9 faster, and that increases as the number of transactions occurs, according to the whitepaper Adobe has released about it.

BlazeDS. ColdFusion 9 is now integrated with BlazeDS as the default installation.

Configuration File. Services-Config.xml is now split into 4 files. There are a handful of ColdFusion-specific properties under the channel definition now. An “enable-small-messages” property is there and should be set to “false”. This is important for the new Flash Remoting in CF9, because BlazeDS’s default is “true”.

There is an AMFChannel component in Flex for the new Flash Remoting (Note: You can alternatively tell the AMFChannel component to have enableSmallMessages=”false”). Finally, the endpoint class is changed for the new CF9 one.

Offline AIR apps with ColdFusion 9

Now the fun stuff. ColdFusion 9 has an ORM for AIR! Build offline AIR apps without the SQL mess and conflict handling. There is a CF-AIR persistent framework for SQLite on the client side. CF keeps track of all updates to local database and synchronizes with the server, including conflict resolution.

By having ORM on the client- and server-side, these two are integrated through the CF-AIR persistent framework.

In the application code for the demo, there were customer.cfc and address.cfc persistent objects. Then a sync CFC is used for providing the fetch and sync functions for communication with the AIR client.

Step #1: Create the persistent CFCs.

Step #2: Create the sync CFC. He called it custmgr.cfc. The CFC has implements=”ISyncManager” as an attribute. Then you have fetch() and sync() methods that handle the transactions. Here you can provide your logic for handling certain scenarios, such as conflicts.

Step #3: On client side, create equivalent AS classes that map to the CFC via the [RemoteClass(alias="")] metadata tag.

Step #4: Use the CF-built AIR libraries provided to fetch data from server, with the SyncManager component. It’s very simple, practically just point it to the sync CFC and do a fetch() method. To work with the database, you then openSession() and can create new AS objects and call save() on the session to insert/update/etc. Finally, using commit() will commit the results and invoke the sync() process.

On the client side, it can receive conflict notification and receive both versions of the data so that you can decide what to do with the conflict.

It is very exciting to have some help implementing synchronization without having to purchase LCDS. Using the CF9/AIR integration libraries will be very nice.

These are notes taken at MAX 2009. This is obviously subject to change before AIR 2 is launched.

Multi-touch gestures. This is especially useful for Flash’s new ability to compile down to iPhone, but it will even work on tablets or laptops that support multi-touch, such as the track pad on MacBooks.

Opening Files. There is now a File.openWithDefaultApplication() method which does just what it says. So you can open data document of any type in its native app from your AIR app, i.e. open a Word document in Word from your AIR app. Executables are blacklisted, such as *.exe, *.bat, or other executables.

File “downloaded”. You can use myFile.downloaded=true to set the bit on a file that will notify the user with a message like, “This file has been downloaded from the Internet. Are you sure you want to open it?” the first time it opens.

Volume Detection. Listen for mounting and unmounting of volumes. Query system for volume info. So this gives you the ability to work with external volumes including optical media or attached cameras.

Native processes. You can start native processes outside of AIR, or even reference it and launch it. This includes passing in arguments and utilizing stdin, stdout, stderr! Now, you can’t use this ability from an app that has been installed straight from an AIR file. You have to have the app in a native installer. This way, someone on a Mac won’t try to run an app that wants to run a Windows executable, or something similar. In the demo, the Mac screenshot process was invoked, and in another demo, Spotlight functionality was invoked and its output was incorporated into the app!

File promises. Ability to tell the OS about files you don’t have yet. Gives you the ability to drag and drop files in cases when they are on the network or Internet.

Listening on a socket. Ability for inter-application communication. Better protocol support (such as FTP). Networking utilities. You just use ServerSocket.bind() and ServerSocket.listen() methods in conjunction with an event listener to act on activity. Demonstrated it with an HTTP proxy app called HTTPeek (on Google Code). Very fast. Handles the socket connection well.

Advanced Networking. Get network information. Support for IPv6. UDP support. A DNS resolver. More coming.

Audio Encoding. Surprisingly, this wasn’t supported before. Now you can encode data directly from the microphone.

Global Error Handling. You can now catch all uncaught errors and error events in your app. This is useful because on a client that does not have the debugger version of Flash, the app will just stop working. With this global error handling feature, you can log the errors to a file or over the network, or do other things.

Accessibility. Functionality from Flash Player 10 will now be supported in AIR. It has 28 accessible Flex components, supporting MSAA (Microsoft Active Accessibility) in JAWS or Microsoft Narrator, for example.

JavaScript Profiling. Can access profiling information via Aptana.

Optimization. Lower memory consumption, lower CPU utilization especially when the app is idle.

Misc. Improved printing. SQLite supports nested transactions. Exit even on shutdown (can now see when the event is not cancelable). Various WebKit enhancements.

Flex 3 will work for AIR 2, but Flex 4 with Flash Builder 4 will be a cleaner, more set up approach for developing AIR 2. You’ll have to overlay AIR 2 SDK on your Flex Builder 3 installation if you want to develop for AIR 2 in Flex 3.

Tom Yager, writer of the Ahead of the Curve column in InfoWorld, wrote up a nice article about AIR entitled AIR gets rich apps right. Touting Adobe’s credentials through their past record, he indicated that Adobe is a great candidate for accomplishing what AIR is intended to do: Get that web technology to the desktop environment untethered from the web browser.

I’ve always loved Tom Yager and find his columns very interesting (although the Intel/AMD discussions lose my interest). It’s great to see him praising AIR.

The following are my notes during the Adobe AIR Local Data Storage Options webinar that was presented during Adobe Developer Week. It was presented by Greg Hamer and the slides and demo code are already online.

Before getting started, note how Microsoft and Adobe are taking two different approaches: Microsoft is trying to bring the .Net desktop development community to the web. Adobe is conversely trying to bring web developers to the desktop! (Kevin Lynch)

There are four main options for AIR local storage: Local Shared Objects, File System, Encrypted Local Store, and the embedded SQLite database. Shared Objects are available in the Flash Player as well; all of these options are obviously available in AIR. Note that the data size limitation for Shared Objects does not exist in the AIR runtime!

Performance considerations. Shared Objects read and write very quickly. File system access and encrypted local stores are typically be slow in writing. Embedded SQLite databases are typically the best combination of speed and random access of items. Greg highlighted the AIR_LocalStorage_Demo app created by Jason Williams that demonstrates the speeds of the four storage methods.

Local Shared Objects. You can serialize memory resident data structures. Great! However, it runs in synchronous mode.

Encrypted Local Store. Used to store sensitive data. The price is the slow write speeds.  Also runs in synchronous mode. All data is serialized using ByteArray.

File System. Obviously important for management of documents. Can run in sync and async mode. The File and FileStream objects work together to point to a file and read/write data. The File object helps remove you from the pain of dealing with Mac vs. Windows environments with properties like File.userDirectory, File.documents.Directory, File.desktopDirectory, etc. It also has methods for opening Open and Save dialog boxes native to the environment as well as copying/moving/deletion methods.

Embedded SQLite Database.  Nice thing about them is that they are self-contained in a single file and require no external software installation to begin using them (support is built into the AIR runtime). Even supports transactions. And the database supports large amounts of data: SQLite has a theoretical limit of over 2TB. Supports ANSI-SQL 92.

However, it’s not a full-blown enterprise database server, obviously. So you lose things like stored procedures, enforcing data type constraints, foreign key constraints, and primary keys must be integers. It also isn’t a multiuser environment.

Session evaluation. I am unhappy to say that I was disappointed with the session. It was high-level, the coverage of code samples (when they weren’t passed over completely) consisted of merely reading the code back to us. I recommend viewing the recording if you have zero knowledge of data storage in Flex and AIR, as it would serve as a decent first-baby-step introduction for you.