Topic: Elsewhere on the web

Lee Brimelow has just pointed out that the Flash Player 10 documentation is available for download on Adobe Labs. I’m excited that this is public, so I can start talking about it more — I’ve been working on the documentation for several months now =)

On a personal note, the screenshot that Lee posted for the Vector class documentation was written by me. So that was fun to see =)

Back in November 2005 (yes, 2.5 years ago!) I wrote an article about how data types and type checking work in ActionScript. ActionScript is different than many languages, in that the ActionScript compiler can be used for compile-time type checking (or not), and at runtime it is a strongly typed language, but it also has features of dynamically typed languages. This allows for some flexibility but also means that you have to be careful about testing your code (because the compiler won’t always catch everything).

My conclusion (not original by any means) was that unit testing is an important tool for ActionScript developers. I’ve tried a couple of ActionScript unit testing frameworks (ASUnit and FlexUnit). And finally getting to the point of this post, I was interested to learn today that the crew at Digital Primates is releasing an open source unit testing framework for Flex, known as “dpunit”.

(via Jesse Warden via Twitter)

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 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.

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