I have a couple of presentations coming up soon, and I haven’t been getting word out as much as I probably should have.

• At the end of May I’ll be speaking at the Webmaniacs conference in Washington D.C. (May 19-23). I’m giving a two hour hands-on session titled “AIR: Windows, Menus, and the System Tray.” The session is being offered twice, on both Thursday the 22nd and Friday the 23rd. (And inexplicably, the Friday afternoon last-session-of-the-conference session is much more full than the Thursday one.)
• In two days, on Thursday April 17, I’ll be presenting a “beta” version of the same presentation for the Silicon Valley Flex Users’ Group meeting. That meeting is being held at the Adobe San Francisco office at 601 Townsend St., from 5:30 - 9:30 pm. (I’ll be presenting for the first half of the meeting, then Luke Bayes will be talking about his “Sprouts” tool set for the remainder of the meeting.)

As I always do, I’ll be releasing the slides and source code for these presentations once they’re done. However, since my SilvaFUG presentation is just a “beta” version of my Webmaniacs one, I won’t release that one until after Webmaniacs is done. (Since presumably the Webmaniacs version will be the better flushed out, more complete one =)

The first details of the overarching “themes” for Flex 4 (“Gumbo”) have been posted on the Flex open source wiki. Four themes are listed (“Design in Mind”, “Accelerated Development”, “Horizontal Platform Improvements”, and “Broadening Horizons”) although currently only ”Design in Mind” has any details.

And what nice details they are!

Here are a few highlights that stood out to me:

Flex applications however have gained a reputation for looking too similar to each other, as many developers choose to use the Flex default look and feel (known as Halo)…we have found that it remains too challenging to create a truly custom experience. It is therefore a priority for Gumbo to make easy customization of Flex application experiences the norm instead of the exception.

Major features…component and skinning architecture…make it easier to describe experience-oriented features such as states and transitions

Perhaps the most revealing part for existing Flex devs is the aptly named “Caveats and Reassurances” section:

Gumbo will remain compatible with Flex 3…Over multiple releases post-Gumbo we expect to deprecate the Halo model…Halo and new Gumbo components can co-exist…new MXML features may require some changes to your existing markup. However, you can make these decisions on a file-by-file basis

But my favorite line of all is in the “Related Work” section:

Provide a tool in which design-oriented users can easily customize the look of individual components or entire applications. Yes, this is Thermo. We’re not discussing it here.

Of course, this is all fairly in line with what’s been talked about previously, such as Thermo, MXML-G, Ely’s presentation about a new component structure with separation of model and view, etc. But it’s nice to see more information…and what’s not there but is hinted at is even more tantalizing.

I’ll definitely be watching that page for more information about “Design in Mind” and the other Flex 4 themes.

(via email from Matt Chotin – also see the announcement on the Flex team blog)

There’s been plenty of blog play about Google’s recently announced Apps Engine, which provides scalable server hosting for web apps.

I found a couple of posts that were very interesting from a different perspective than just the “hey free web hosting” angle, that I wanted to save/share:

• Alec Saunders discusses Google App Engine as an example of the competition between Microsoft and Google, and why Google “gets it” but Microsoft doesn’t.
• Jacob Brunson thinks this is an example of Google ”changing the world” – an innovative idea coming from inside Google rather than being bought by them.

And one more link that is a coding-focused one, but I wanted to save it anyway. =)

• Ronald Schouten has a great list of resources for learning Python and Django (Python being the language you must use with Google Apps Engine, and Django being one of the most popular Python frameworks for web apps).

Lots of big releases for Adobe AIR and Flash Player today. In no particular order:

• Security update for Flash Player (“9.4”) (also see the DevNet article)
• Security update for Adobe AIR (“1.0.1”)
• New public Flash Player bugbase (also see the DevNet article)
• Adobe Media Player 1.0 (with a lot more content now that it’s final – if you’ve tried it before but didn’t bother with it because of lack of content, it’s worth another look)

Note: I added AMP after this post was already published, since it wasn’t yet public at the time.

Peter Elst, an excellent Flex/Flash developer and speaker, just finished touring as part of the on AIR Europe tour. He’s posted his slides and sample applications from his presentation, ”Introduction to SQLite in Adobe AIR”. Looks like it was a great presentation, and even without hearing him he’s got some nice samples to dig through.

(via Twitter from Peter himself)

A couple of months ago at a SilvaFUG meeting I saw a demo of some graph visualization libraries – the kind of thing you use to create a graph showing nodes linked together according to various relationships.

The current “favorite” is the Flex Visual Graph Library (FVGL) Open Source Project.

Their Visual Graph explorer sample gives a nice overview of the functionality that’s available.

Anyway, I forgot to note this earlier, so I’m adding it now, though there’s a good chance this isn’t news to anyone who’s interested in this sort of thing.

(via email from Ted Patrick)

I’ve been wanting to have strongly typed arrays in ActionScript for a long time. I was pretty excited when I read that it’s part of the EcmaScript 4th edition specification (in the form of the Vector class), and much more excited when I heard that the Vector class is being included in Flash Player “Astro” (as announced at 360 Flex Atlanta by Matt Chotin).

Since the majority of the time when someone’s using an Array in ActionScript, they really want all the elements to be the same type anyway, this is a really great addition and I think it will be used heavily. The Vector class allows (requires) you to specify the type it will contain at compile time – both for variable declarations and when creating instances. In both cases the syntax you use is a “type parameter” suffix .<T>:

var names:Vector.<String> = new Vector.<String>();

The type parameter syntax is part of a separate EcmaScript 4th edition proposal. Sadly they couldn’t make the syntax identical to that for generics in C# (and I believe Java does it the same way), which is almost the same but without the initial . (period). (For an interesting read, take a look at the history of the various options the committee members considered for representing type parameters.)

Anyway, because you specify the type at compile time, the idea is that the compiler can do the type checking for you for adding and getting elements from a Vector instance. In addition, since using Array (and the runtime type checking and type casting that array access involves) has always been a bottleneck in ActionScript performance, I expect that performance improvements can be expected. (Okay, I’ve heard anecdotal reports around the office of much better performance for Vector than for Array.)

Francis Cheng (who’s on the EcmaScript committee) has a couple of nice articles about the Vector class and type parameters, so I won’t bother recreating everything he’s written. Definitely worth a read (like everything he writes).

As an (almost) final note, I should point out that I haven’t seen anything indicating that type parameters will be generally available in “Astro” – just Matt’s announcement about the Vector class specifically.

And finally, on a personal note, I’m excited because I get to do the documentation for the Vector class. It’s always fun getting to write about new features that are personally valuable. And this is one that I’ve definitely been interested in for a while!

I wanted to share a couple of links and some of my thoughts about Mozilla Prism (also here), which (from my understanding) is currently a way to take a browser page and isolate it so that it runs in its own window (and maybe its own process – not certain about that one) without the extra trappings of browser chrome. It’s been compared with Adobe AIR, and while there are similarities there are certainly differences too.

I missed the initial announcements and only became aware of Prism a couple of weeks ago when I happened on a discussion of Prism by Mike Chambers (complete with rather emotional comments on many sides). I can’t say I agree with everything Mike says there – it sounds like at the time he wrote it he didn’t have a complete understanding of what Prism was/is – although certainly some of the people who commented obviously didn’t have a great understanding of Adobe AIR. In any case, it’s an old (by Internet time) post, so I’m sure nobody in that conversation would want to be held to their stated opinion.

My opinion about Prism is more in line with something JD shared recently, specifically the quote below which I think clarifies the value proposition (and relative merits) of both AIR and Prism:

For me, the top difference between the Adobe Integrated Runtime and what I currently understand of Mozilla Prism is the balance between creator choice and user choice. AIR lets you create a predictable beyond-the-browser experience; Prism lets the developer indicate how they’d like the presentation to appear, but the enduser can still modify the markup, scripts and styles they choose to package up in Prism. Two different types of contract between creator and consumer.

Any existing webpage can be repackaged and modified in Prism; any web developer can create desktop-optimized experiences in AIR.

I think this is very relevant to one example that I’ve given to explain one of the benefits of AIR. There are now apps that people use in a browser (e.g. GMail), but they use them like a desktop application – opening them up and keeping them open all day. The user doesn’t want that browser window to navigate to a different page, and if some web site causes the browser to hang or crash, the user’s email app gets hung too. For an app like that, it makes sense for the developer to create a version in AIR that can be run as a separate application. However, there’s a big dependency from the user perspective – the app developer has to actually create the AIR app. (e.g. Google would have to make an AIR version of GMail). Once the developer decides to build an AIR app, there are other benefits and capabilities that become available – but the point is it’s still in the developer’s hands to actually build the app. The value I see for Prism is that with Prism the end user can choose to make that app a Prism app without the need for any action by the app developer. Of course, the app will still have dependencies on things like an Internet connection, and won’t have any more capabilities than any other browser-sandbox app. But it’s certainly no worse than what the user already has in the browser, with some nice conveniences added in.

Now that Adobe AIR 1.0 is in the wild, I wanted to post an update about changes that happened with the local SQL database functionality between beta 3 and the final release. Plus, I’ve had some general thoughts about the release of the software that I thought I’d share.

For some reason, the final time that I saved this post before publishing it, my changes didn’t get saved. So if you saw this soon after it was posted, and wondered why it didn’t really talk about SQL changes, and why it had some messed up headings…that’s why. Sadly I’m sure I can’t recreate the text as well as I wrote it the first time. But here’s my best effort…

First of all, allow me to clear something up. I am aware that Adobe AIR 1.0 shipped almost exactly a month ago, so this shouldn’t be news to anyone who’s actually interested in it. I intentionally held off on publishing my thoughts (and a description of changes since beta 3). As a rule, I never post anything in the week or so following a big product announcement – there are so many “me too” posts about the product, and so little actual different thoughts or original ideas, that I don’t want to clog up the aggregaters by adding to the hubbub (the “MXNA firehose” as I’ve heard JD describe it).

That’s not a complete excuse, of course. The truth is also that I’ve just gotten busy with a lot of post-launch cleanup activities, and of course moving ahead on future projects (Flash Player 10 and AIR 2.0), so I’ve neglected this post for longer than it deserved.

And now, lest I postpone it any longer, here are a few bits of news and opinion from my corner of the Flex/AIR world:

• Local SQL database changes
• What does “finished” really mean?
• Go right to the source

Local SQL database feature changes

Wait a minute – didn’t I say a couple of months ago that as of beta 3 AIR is API frozen? Indeed that was the intention, and with one small exception it’s true. And that was the first thing that came to my mind when I read the notification (shortly after beta 3 was locked down) that some changes to the SQL functionality had been checked in to source control. But I was correct before – the API hasn’t changed – just one particular behavior has.

The specific change is with how the runtime treats column data types in database tables. In betas 1-3, AIR was consistent with the “default” SQLite behavior:

the type of a value is associated with the value itself, not with the column or variable in which the value is stored…. All other SQL databases engines that we are aware of use the more restrictive system of static typing where the type is associated with the container, not the value.

In order to maximize compatibility between SQLite and other database engines, SQLite support [sic] the concept of “type affinity” on columns. The type affinity of a column is the recommended type for data stored in that column. The key here is that the type is recommended, not required. Any column can still store any type of data, in theory. It is just that some columns, given the choice, will prefer to use one storage class over another. The preferred storage class for a column is called its “affinity”.

So under the “affinity” system, if in your CREATE TABLE statement you specify that a column stores INTEGER data, and you write an INSERT statement that stores a String instance in that column, the runtime allows it. (I initially wrote “it works just fine” but that may not be true – since your application may be assuming that values retrieved from that column are always integers.) When I first read about this behavior when we were reviewing the spec for the feature, I recognized that it was different than what I’d done before, but I figured it was okay – I’d just have to be extra careful when inserting values into the database, and enforce the data types myself by convention even if the runtime didn’t enforce them in practice.

However, the feedback we got from developers was that this doesn’t really match what they’re used to from typical web app database code (which likely uses databases such as Oracle, SQL Server, or MySQL). As a result, in the final release, the declared data types of database columns are more strictly enforced. If you declare a data type for a column, then attempt to store a value that isn’t an instance of that type, the database will try to convert the value to the appropriate type (for example, turning a number into a string, or parsing a string to see if its text is actually a number). If the value can be converted, then the converted value is stored; otherwise, the runtime throws an error. (For more details, see the column affinity description in the documentation.)

Personally I’m pretty happy with this solution. It’s still a bit more flexible than the databases I mentioned before – usually they won’t even try to convert a value, and will just choke if the data type doesn’t match. But I think that the way it works in AIR 1.0 is consistent philosophically (and actually) with the way data types work in ActionScript 3.0 where values can be strongly typed or weakly typed at compile time, but either way at runtime the type must match.

So, what do you do if you were one of the people with more SQLite experience than other db experience, of who otherwise preferred the old behavior? Well, there is still a workaround. If you don’t declare any data type for your columns, you can store data of any type without causing errors. This isn’t the same as the previous behavior, but based on some anecdotal observations I’d guess that developers who intentionally mix data types in columns are less likely to declare a column data type, in any case.

Also, as a side note, I decided to keep the term “column affinity” in the documentation even though the behavior changed. I did this for a couple of reasons: 1) Developers who’d been reading the docs were probably familiar with the term now, and 2) the data types still aren’t strictly enforced, in the sense that the runtime attempts to convert values before storing them (just as a default SQLite implementation does). For example, just about anything can be stored in a TEXT column without an error occurring. So in that sense, the data type specified in a CREATE TABLE statement is still somewhat of an “affinity” rather than a traditional strictly enforced data type.

What does “finished” really mean?

Not too many years ago, my definition of a “release version” of software was different than it is now. I knew that any software, no matter how much it is tested, is bound to have some bugs in it – it’s just not possible to ship software of any notable size without making a mistake somewhere. However, I had enough faith in big software companies that I assumed that when a company declares a product to be a “release” or “shipping” version, that it at least doesn’t have any bugs that they know of.

I’m not sure when I realized that this view is far from reality. I suppose it was probably with the first private beta I was involved with, though maybe it was before that.

In any case, I hope I’m not shocking anyone’s sensibilities when I point out the reality, that even though Flex 3 and AIR 1.0 have shipped, they do have bugs – and Adobe even knows it! The recent openness of Flex, in particular the introduction of the public Flex bugbase, makes this reality much more transparent. A quick search on the Flex SDK project, looking only at bugs (as opposed to feature requests), shows 309 “open”, “in progress”, “community”, or “new” issues. And that’s not even taking into account “deferred” bugs, such as SDK-14339 “WindowedApplication doesn’t update/show menu when it changes during runtime”.

While Adobe AIR doesn’t have a public bugbase, that doesn’t mean it’s any more free of bugs. Try calling the NativeMenu.display() method on a PowerPC Mac running OS X 10.4 and you’ll see what I mean (hint: the menu appears at the mouse cursor rather than at the specified coordinates).

So what does “release quality” software really mean? Well, it means that it doesn’t have any bugs that are “showstopper” issues, or that are “really bad.” Yes, I’m intentionally using non-specific terms here. The reality of life is that if Adobe (or any software company) waited to release software until all known bugs are fixed, the software would never get released. So instead, they use a process that’s sort of like this (I’m generalizing and also stating this based on my own observations, not on any review of actual process or guidelines within Adobe):

1. The decision makers figure out a date by which the software should be done. (I’m not talking about at the beginning of a product cycle – I’m starting somewhere in the middle.)
2. Throughout the process, bugs are reported. Any time a bug is reported, it is investigated and a decision is made as to whether resources can/should be allocated to fixing it. The criteria for this decision are generally based on how severe the bug is (whether it crashes the software/computer, causes data loss, is a usability issue, etc); how hard it is to fix; how much time it will take to fix; how likely it is that someone will run into the bug; whether or not there’s a workaround; etc.
3. As the product moves closer to the release date, the threshold for whether a bug will be fixed goes up – the closer the software is to the release date, the more severe and less difficult to fix a bug must be in order for it to get fixed.

This can be frustrating for people who file bugs, like me. Often, due to workload and general stability issues, it’s not practical for me to start writing the documentation for a feature until it’s fairly stable and close to finished. But that means that when I do find bugs, there’s a good chance it’s too late in the process for the bug to get fixed in time for the product release.

Ah, tradeoffs.

Go right to the source

Now that Flex 3 has shipped, the Flex 3 source code is available in the Flex Subversion (SVN) repository. I’ve actually been accessing it there for a while – internally we made the switch from Perforce to Subversion around the first of the year. I was pretty worried at the time, because I had never used SVN before. The majority of the Flex 3 work was already done at that point – they were just in final bug fixing mode. We still had about a week before our content had to be locked down, so I was working furiously to try and finish up some work I was doing on the Flex AIR components. I wasn’t too excited about the prospect of switching source control systems in the middle of that crunch. Fortunately, SVN turned out to be pretty straightforward. (In case you’re wondering, I use TortoiseSVN). It’s actually been good for me to learn SVN at work – it made it easier for me to move some of my code projects over to Google Code (a few that are already there, and a few more that I’ve started but not posted on my projects page yet). So overall I give SVN thumbs up, and I’m happy that the Flex source code is available that way.

Since I’ve been working on Adobe AIR, I naturally have lots of thoughts about what it is and isn’t, and how it compares to some of the many similar and related technologies that have been announced and released over the past year or so.

Today I read an article by Tim Negris that I think does a great job of clearly articulating how AIR fits into the ecosystem, in particular what types of applications AIR is suited for. It also includes some insightful analysis of how the competitive landscape is shaping up, and how the release of AIR might be related to some of the negative and/or confusing messages about Adobe that have come out recently.

Anyway, if you’ve been wondering about AIR and some of its competing/related platforms, I highly recommend this article:

Why Adobe AIR Is Not Google Gears, Prism, JavaFX or Silverlight