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.

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.

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.

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.

Many developers were frustrated–and many web developers had our curiosities pleasantly piqued–when Apple initially announced that “software” would be available for the iPhone in the form of Ajax web applications. Naturally, many of the disappointed folks were irritated because the web platform is something that they’re entirely unfamiliar with, probably having backgrounds in Objective C or something similar; probably a minority were disappointed because their target application legitimately could not be powered by HTML and Ajax.

That said, it is indeed a very thought-provoking concept: Using web technology as your application environment. As most web developers will attest to, there honestly isn’t that much that a typical application does that cannot be accomplished with web technology. With the advent of Ajax frameworks, applications built with web technology can have very similar responsiveness and dynamics of a “classic” application. Especially when you remove the burden of cross-browser compatibility, in the iPhone’s case.

But with the iPhone/iPod Touch scenario, it is irritating that the application has to reside in Safari and has to be loaded off the web. It almost feels as if Apple was trying to push something that wasn’t…quite…ready. Something like AIR!

AIR accomplishes everything that Apple was suggesting for the iPhone environment, but for the desktop. Use web technology, but write a “compiled”, stand-alone application that really doesn’t even have to use the web. Use HTML. Use Ajax. Use Flex and Flash. Have a nice encapsulated application on your desktop. Especially when you throw the Flash technology into the platform, it is now a very capable environment for a large variety of applications, without being constrained to the browser. Wouldn’t it be great if that same cross-platform environment, AIR, worked on the iPhone as well?

Oops, Flash technology isn’t currently supported by the iPhone. That is actually another source of contention. And the AIR environment does lose some of its punch without Flash and Flex, even though its HTML/Ajax implementation can do a very decent job with most typical applications.

Steve Jobs has made it clear that he likes the idea of web technology powering iPhone apps. Now, consider some of the facts. Apple announces the iPhone SDK will be released in February, and then fails to deliver. Meanwhile, Flash still isn’t found on the iPhone, and Adobe “invents the wheel” by getting web technology to drive native apps through its work with AIR. Is there a common theme with these events? Perhaps something like: Are Apple and Adobe working together to get the much-needed Flash technology onto the iPhone and, subsequently, releasing an SDK that uses AIR technology, with hooks into the iPhone system just like AIR currently has hooks into the Linux, Windows, and Mac OS X desktop operating systems?

It wouldn’t be the first time Apple has had to wait for its partners, or take the heat for them. For instance, Apple has clearly been taking a lot of heat for many factors of the iPhone that are clearly not in Apple’s interest, but in AT&T’s.

And this scenario would fit the circumstances around Adobe’s development of AIR. Adobe has been working on AIR since well before the iPhone was released, but AIR wasn’t officially released until February 25, 2008. Even if Apple and Adobe were working closely together, there just hasn’t been enough time for AIR to get released and hooks to be developed to provide iPhone-specific functionality in AIR. Adobe has understandably concerned itself with its own business first. With that done, attention can turn to Apple to support them in concluding their own business.

Of course, this prediction is a reflection of my own desires as much as it fits the circumstances. As a developer that uses Adobe technology including Flex and AIR, and an Apple enthusiast for more than 20 years, I would love to see things happen this way. Undoubtedly we will have a clearer idea of Apple’s iPhone development roadmap after this Thursday.

As if the thought of an “iPhone AIR” isn’t confusing enough.

I’d say its most clunky aspect is data entry, but otherwise it’s very decent.

Spaz gets more time in the Twitter limelight, and Ed talked up the benefits of AIR. Good job, Ed! I haven’t had a chance to read the whole interview yet, but look forward to reading it soon.

Use ColdFusion apps directly, use ColdFusion as the data provider, or use ColdFusion as the data provider and as a UI provider.

To use a CF web app directly, just wrap it in a frameset. This is so kludgy, I can hardly stand it. But it will work to put your web app in a desktop app at some basic level. I suppose it could be handy since it hides the URL, it can make a more kiosk-ish look. Could also be useful if part of your app is a normal app, but part of it should mimic the web app exactly and you don’t want to rewrite anything.

Better to use CF as a data provider.  ColdFusion is best at connecting with other systems, connecting to remote DBs, etc. Then communicate with web services, XML, flash remoting, JSON.  There is nothing new here, at this point, you just build typical connectivity that AJAX or Flash would use.

Flash remoting would probably be the best when using Flex. Provides a handy proxy-like access to your CFC.  Web services can also be done very easily with Flex.

Now, how about HTML/JavaScript (AJAX) in AIR? CFAjaxProxy, XMLHttpRequest, or plain HTTP (CF returns the data in XML, JSON, or text).

CFAjaxProxy. Makes a CFC available inside AIR app. Creates a JS proxy for a CF component. So on the CF side, you use cfajaxproxy, point it to a CFC, and instantiate the CFC in JS. Now, some initialization code is required. It is generated by the cfajaxproxy tag. So just copy the literal HTML/JavaScript generated by cfajaxproxy, and drop that into your HTML for AIR (just change the URL to the CFC to be the absolute URL; cfajaxproxy will write it as a relative URL).

It wouldn’t hurt to just write some basic AJAX code on the web, using cfajaxproxy, and then copy that to your AIR HTML.

Now what about taking your apps offline? Well, you’ll need to identify what is going to work offline, and store offline data (either to the filesystem or to a local database). Decide how the app will go offline: Modal (distinct offline/online mode, user driven, easiest to implement), or modeless (seamless offline/online mode, most of data is stored locally, better user experience but more work for the developer). Then, synchronization strategy: Manual sync, background client-driven sync, or server-driven sync.

Synchronization and online/offline management can be improved. They will describe more at the sneak peak session. Code samples will be at his website, http://coldfused.blogspot.com.

AIR allows web technology to be deployed directly to the desktop.  Flex, flash, PDF, HTML, JavaScript, CSS, Ajax.  Always starts with a root document (HTML or SWF). HTML may contain PDF or SWF. Both have renderer, VM, and DOM.  Code between the VMs can interoperate.  All can be display in native OS chrome. And you can persist data locally (hence this preso!).

Storage models: Local shared objects, encrypted local store, file system, embedded SQL database.

Local shared objects. There are in package flash.net.*.  Used to serialize memory resident data structures. Runs in synchronous mode. This is a monolithic storage model. So it is fine for writing huge amounts of data, but when going to retrieve a single entry out of thousands, can take a proportionately long time.

Encrypted local store. In package flash.filesystem.*. Used to store sensitive data. Runs in synchronous mode also. All data is serialized using ByteArray. So it’s like blob storage with keys. A ByteArray is like an in-memory stream of information. So you take an array, put it in a ByteArray, then add the ByteArray to the encrypted local store. This encrypted local store is just this space that is available to you based on the application and user.  And it is faster at accessing the record you want. But the point isn’t that it’s faster at accessing records; the point is that it is doing security to make sure no one can read it without authorization.

File system. In package flash.filesystem.*. Provides random access to file system data. Can be asynchronous or synchronous. Two main components: File and FileStream. File represents a path to a particular file or directory. Completely OS-independent. FileStream does the actual work. Handles binary, object, text data.

Path handling: nativePath(), canonicalize(), resolvePath().

Cataloging: userDirectory(), desktopDirectory(), documentsDirectory(), applicationResourceDirectory(), applicationStorageDirectory(). File info (size, createDate, etc). copyTo(), moveTo(), etc. upload(), download(), send(), etc.  browse(), browseForDirectory(), etc.

FileStream implements the IDataInput/IDataOutput APIs. Can put binary data in — readBytes(), writeBytes(), readInt(), writeInt(), readDouble, writeDouble, etc.  Can do AMF3/AMF0 object serialization — readObject(), writeObject().

Embedded SQL Database.  Self-contained factor is nice. You have no external dependencies; it will work the same on any OS. Each database is stored completely within a single file. Zero setup. No configuration or administration required. It just starts working.  No server process required, no need for an administrator to create the database and user accounts. Handles transactions! Has a large capacity: Theoretical limit of over 2TB.

Package is in flash.data.*. Can be asynchronous and synchronous.  Uses SQLConnection and SQLStatement.

SQLConnection. Establishes connection state, configuration, transactions, schema access. In async mode, also creates its own background thread. So you can create five SQLConnections to run five database operations simultaneously.

SQLStatement. Does CRUD operations. Does parameters, paging, and custom result row data types.

The database functionality is VERY fast. Can work with thousands–millions–of records in less than 1 second. Data reads are even faster.

SQLConnection: open(), attach(). The attach() will allow you to run queries on tables across multiple databases. Comes in handy during certain circumstances. Handled not too unlike SQL Server, when you are referencing an external database in your SQL statements.

SQLStatement.getResult() — Returns a SQLResult object.

SQLResult: data() returns an array of objects that contain each row of the result. complete() indicates if you pulled the whole result set. lastInsertRowID() is self-explanatory. rowsAffected() is also self-explanatory.

Note! Putting data on disk via the database can be slow sometimes. Recognize that it is a 6-step process: (1) Acquire shared lock on the database. (2) Acquire a RESERVED lock on the database. (3) In-memory rollback journal is updated. (4) Contents of rollback journal are physically written to disk. (5) Acquire an EXCLUSIVE lock to the database. (6) Write all modifications for the DB to the disk.

At this rate, you’re probably only going to get 5-6 database transactions per second.  Maybe as many as 20 on a high-end box. So the key is to put MANY database operations all in a single transaction.

Transactions. SQLConnection manages the transaction. Use SQLConnection.begin() to start the transaction. Then, commit() and rollback() work as expected.

Storage classes. There are numbers (int/real), text, and blobs.

Affinity. Declaring a data type on a column determines the column’s affinity. You’re saying, “I want this field to be stored like this.” However, if you send a string to a field that should be a number, it won’t throw an error, it will just put it in there as a string.  Supports ActionScript affinities of boolean, date, int. Next beta should support XML, XMLList, Object, etc.  But currently, you can put arrays or objects in with blob, which will then treat it like a ByteArray.

Introspection. Access to the table/view, column, index, and trigger information, including the SQL used to create the entity. But you can do selective loading, i.e. I want to see the tables in this database. Just use SQLConnection.loadSchema(). Will return a SQLSchemaResult that has tables, views, triggers, and indexes. These are all arrays of objects with the associated values.

Transparent windows require that you build your own functionality for window handling: Closing, minimizing, moving, resizing, etc. Now, when you use custom chrome, you can use Scale-9 in Flash/Flex to make it really easy to handle how resizing of the graphic works. You can do this with the <mx:canvas> tags in Flex.

HTML Control. WebKit is entirely integrated into the Flash Rendering Pipeline. Using the bridge, you can use functionality in either JavaScript or ActionScript and use it in the other environment: AS called within JavaScript; JavaScript called within AS.

File I/O. Full read/write access within the access provided the user running the OS. Have asynchronous and synchronous versions of the API. So quick and small file access can be done in a synchronous manner quickly, and longer access can be done asynchronously to maintain a quality user experience. Use standard native file dialogs: Save, select, select multiple, directory.

File I/O can save not just text/binary stuff, but you can read/write serialized AS objects. So, you can create an AS object with the info you need, then very rapidly write it out and have it very easy to read back in as that object.  Just use the writeObject() method of the filestream! Similarly, just use loadObject() when reading.  To make this work, you will need to add a tad of metadata to the object to make it work. Another caveat, the data will not be human-readable. But if human-readability is not important, this is much more rapid for writing a lot of data than it would be to save in some text or XML format and needing methods to write out and read back in the data.

Another solution could be to write this kind of data to the database via the database API. But sometimes that may be overkill, plus this can write files anywhere.

Database. A fully-embedded SQLite database engine. You’re accessing a local database. This is not for accessing remote databases. To do that, you’ll want a webservice that provides access to that database.  This database support is great for providing online/offline support. You can sync the information locally and then just utilize the local version.

One note: Every database function will be a separate transaction. If you have hundreds/thousands of database functions to perform, wrap them into one transaction so that the filesystem can do the file transaction more efficiently. In his sample, writing 1,000 database records took 2.3 seconds with no transactions; it took 0.1 second with transactions.

When handling database connectivity, you will: (a) Point to the database file. (b) If it doesn’t exist, do the code to create the database. (c) Do your database statements.

First, recognize that desktop apps have much more power than a web app. Why doesn’t everyone do them then? Desktop apps are a lot more expensive to build! Web apps have been getting more expensive as standards of quality rise, but they’re still cheaper than full-fledged desktop apps.

eBay built a fully-functioning prototype in just 3 months. Here are some lessons learned.

1. Start with a good foundation. They started the AIR app because they had already been building web services and API for eBay. So all they really had to do is build a UI. All the web service hype from 2002 was indeed hype, but now, five years later, the concept is finally coming together in a very key and important way. These web services are a great way to connect desktop apps to the web. Store your business logic in the web services that the desktop apps can access.

2. Design takes a long time. Of the first 3 months, six weeks were spent on design alone. Why? (a) AIR offers a lot of freedom. If it was more restrictive, it would have been more straightforward. (b) They were pioneering things. There is not a prescribed manner to address a lot of the questions that come up. (c) Expectations have been raised for user experience.

3. Betas are really useful. I mean real betas, not marketing betas. They have thousands of users in the beta program and they get tons of feedback.

4. The most important AIR feature is… Freedom from constraints of the browser. No frustrating back button. No location bar.

5. Users don’t care about software platforms. A good platform, like AIR, just gets out of the way. Installation, auto software update, startup,  etc. Beta users haven’t complained about these kinds of things–the kinds of things that typically hinder Java apps or some other platforms.

Window API

Multi-window support. Transparent windows. Z-Ordering. All of the various aspects of OS windows can be applied to your AIR windows. When you use transparent windows with no chrome, the arrow will click through the transparent part of images as well. Nice.

File I/O

Reading and writing of files. No problem. Can launch native file dialogs. Can handle selection, selecting multiples, directories, etc. Async and sync versions of the APIs.  Would use async API if you’re doing very heavy processing.

Database Support

SQLite embedded database. Zero setup, uses a single file. Not for accessing remote databases. This is for using a completely local database. Easily storing data in a database format, but in a local manner.  He didn’t show any examples of this.

Drag and Drop / Clipboard

System level drag and drop support is there! AIR app to AIR app, or AIR app to OS app and back again. Or to the desktop. Can use it for handling URLs, files, text, or even AS objects.  When marking something as draggable, you can assign one or many “transfer formats”. So when you drag an item to another app, if it doesn’t accept one data type, perhaps it will recognize another data type. For instance, if you have an image and a text transfer format, the receiving app may not like the image format, but it recognizes the text format, so it proceeds without a problem.

Service Monitoring

Handles the online/offline support. Will monitor the network interface for changes. Will detect not just network connectivity, but you can test access to a particular service. Do I have access to http://my.address.com/myservice?

Conclusion

These APIs work in JavaScript too because of the bridge, but it all works very well in Flex.  Daniel Dura was the presenter, and hit site at http://www.danieldura.com has a lot of AIR information.

Enabling more powerful RIAs: Need good runtime performance. This was improved with AS3. Need good development model. Flash is scary for developers. So Flex enables developers to write Flash apps in code. Bridged gap between Flash and developers. Finally, need a desktop runtime. This is where AIR comes in. Web is great, but sometimes you need that desktop connectivity.

AIR tries to be “webby”. So, it’s cross-platform, has an easy install experience. Basically a web-enabled desktop experience. And can use Flash, but can also use your standard HTML/JavaScript skills. And can even combine Flash and JavaScript together with a bridge. So do JavaScript when you want, because it’s more comfortable, but then tap into some Flash functionality when it is needed because you can’t do it from JavaScript. Even supplies a local database functionality: SQLite. So that mentality in web development, which means an expectation to have database connectivity, can continue in the desktop app.

Timeframe. Flex 3 Beta and CF 8 Beta have already come and gone, so has AIR Beta 1. At MAX, we’ll see AIR Beta 2, and of course we already have CF 8 proper. AIR 1.0 is scheduled for sometime in the beginning of 2008, as is Flex Builder 3.

Deployment. Typical web apps just get put on the webserver and you send the URL. An AIR file is just a zip-based package similar to Java, so you could send the AIR file, but that would require that the user has the AIR runtime installed. As a solution, there is an “Express” installation that is web-based (not hard to do). You send them a link to your app, and it will install the app but also check that the user has the runtime. This addresses the issue of deploying to users who do not currently have AIR on their PC.

Once installed, the AIR app is no different than any other app on the platform it was installed in. In OS X, it appears as a Universal app; in Windows, it is a normal executable. It appears in the Start Menu or Applications folder. If it crashes, it dies on its own, it doesn’t bring down all AIR apps. And so on.

Remember http://www.adobe.com/go/air. That address will always point to all things AIR.

Add’l Notes. The FileTypes node in your application.xml file will let you specify your own filetypes that will be registered with the filesystem! So if your app generates a particular file, you can have your files be double-clickable and open in your AIR app. The AIR runtime is not just a webpage on the desktop. It really is an integrated desktop experience.

JavaScript Development. Developing AIR in HTML/JavaScript is very easy, even though you can’t do it with a built-in functionality that Flex Builder has, as long as you use the SDK stuff Adobe provides. The JavaScript bridge makes it pretty easy to access the Flash-specific functionality. The key in development is just using the ADL and ADT command-line tools that are provided for free. Point ADL to your application.xml file, and it compiles it and runs it on the spot. No problem! We wrote an HTML/JavaScript app that takes some user input and writes it to a file on the desktop in only 6 vital JavaScript lines of code.

Aptana. They recommended Aptana as a great IDE for doing HTML/JavaScript development for AIR, since it has some AIR-specific support. Good to know! I love Aptana already, so that is convenient!

This concluded the initial walkthroughs of developing AIR in Flex and JavaScript. This is exactly what I was looking for to understand the basics of AIR development, which took some of the “scary” mystery out of it.