Window API. Lightweight windows are nice because they won’t appear in the taskbar/dock.  Utility windows don’t even have title bars and are nice for toolbars or similar things. You can have transparent windows so that the only content you’ll see is the Flex/HTML content you put in there.

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.

The following are notes from an Adobe MAX 2007 session.

Server monitoring can help you get rid of some of your bottlenecks. Can make a big difference. The general server monitoring can even be used in production,  but DO NOT use the memory monitoring on a production site. May bring it down, even on low load.

The Overview Screen will let you see slow active requests, charts of the number of requests, average response time, etc. What errors have been thrown lately? What alerts have been posted (will explain later)? Various other statistics like that.

The Statistics Screen will display a bunch of various useful bits of info.

Requests. Active CF threads, slowest threads, active sessions, cumulative server usage, highest hit counts, cache status, etc. By looking at this info, you can find long-running active requests that can actually wreak havoc on the whole server. You start chopping those down, and before you know it, your server will run like a race horse. There’s also a memory statistics section.

Memory. Shows general memory usage, requests by memory usage, threads by memory usage, queries by memory usage, sessions by memory usage, application scope mrmory usage. You may at times find large amounts of memory that aren’t even used effectively in your apps, thus can slightly tweak the way things are being done. Beware: Garbage Collection isn’t always the answer. Memory can be hidden in shared scopes or caches.

Database. Active queries, slowest queries, cached queries, etc. Most frequently run queries.

Errors. Requests with errors, requests that have timed out. Having a lot of errors used to cause stability issues; not as much now, although if your logs fill up the whole hard drive, ColdFusion will have a problem! Plus, if you’re having that many errors, won’t you want to know about it?

Alerts. Can set alerts for various circumstances you’ll want to be notified on. If the hung thread count reaches a certain maximum, or if a thread has run for x seconds, you can do certain actions (send email, dump snapshot, kill thread, reject any more requests) or you can supply a processing CFC that can then do anything you want.

The Snapshots Screen will give you all the details of the server at the moment the snapshot was taken. Will save all the detail into a text file. Can’t automate regular snapshots, although you probably could do it with the Admin API. Just set up a scheduled task that tells the Admin API to take a snapshot.

eBay has an AIR app for managing your eBay activity. Launched during MAX 2007, even though it has been around since last year’s MAX. They learned things from it.

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.

During CFUnited, it didn’t look like I was going to be able to make it to MAX, which was ironic, since it’s in Chicago this year and I live not too far from Chicago.

Well, things worked out and now I’ll be going to MAX. See you all there. I’ll be taking notes feverishly during the sessions.