Topic: Articles to remember

Simplified Chaos has an insightful article about deciding when to use AIR and when to stick to browser-based Flash/Flex. His recommendation is to use the browser by default, and only move to AIR if you really need that desktop functionality. His reasoning, which I can agree with, is that people are much less likely to try out a desktop app that they have to install (and probably uninstall later) than to just look at something in a browser. I definitely agree — I hadn’t really realized it until reading this, but I’ve noticed that when I hear about a new AIR app then I always hope the web site has some screenshots or videos of the app in action, so that I don’t have to install it to try it out.

Keith Peters wrote a similar post on the same topic, which I also recommend.

(via Jesse Warden)

Justin (“AlternateIdea”) has a nice, fairly technical write up of dealing with asynchronous operations when you’re using the AIR SQL database with JavaScript.

I admit, my JavaScript is much rustier than my ActionScript/Flex, so I’m glad to see these sorts of things — it helps me to see what patterns and approaches work for the larger-than-you-might-imagine JavaScript AIR developer audience.

Update: added links, so that you can actually find the article (Doh!)

Dan Thomas (“Danny-T”) has written up a nice concise intro to database concepts, geared toward working with databases in AIR (more…)

If you’re looking to simplify the local database access part of your AIR app, this might be the ticket. Brandon Ellis has written a no-frills wrapper class for AIR local database operations. The biggest benefit it provides is that if you add, delete, or update data in a table, it automatically updates whatever component is displaying the data from the related SELECT statement.

The part that caught my eye the most was that the wrapper class doesn’t dispatch any events to notify the view when the operations have completed. How, I asked myself, does it notify the view when the updated data loads? After a few seconds I realized the answer — it’s the magic of Flex data binding. The DataAccess class exposes the SELECT results as a property (dbResult) that’s a Flex ArrayCollection, and it’s marked [Bindable]. A Flex control can bind to that property as a data provider, and whenever the DataAccess instance reloads its data and updates the ArrayCollection. Then the Flex framework takes over, and the view gets updated automatically. Pretty slick; and it definitely saves a lot of event-handling code. So I guess seeing this in action gave me further appreciation for the power of data binding.

It has a couple of minor issues that I’ve noted in the comments on that page (but mostly they should be fairly easy to fix, if Brandon or someone else decides to do so).

(via: Greg Hamer)

The arguments are being made, and not just by the stereotypical open source advocates: some big-name industry analysts are suggesting that Flash Player should go open source, and that it won’t have the negative impacts that I and many others worry about:

• Anne Zelenka: “Why Open is Good and How Open Could Be Good for Flash” (and it’s predecessor, linked to from that article).
• Ted Leung: “Adobe wants to be the Microsoft of the Web” (and its followup article, linked at the bottom)
• Ryan Stewart: “How Adobe can overcome the issues around open sourcing the Flash Player” (he previously stated that Adobe shouldn’t open source Flash Player, so this is an interesting article with some new ideas I hadn’t seen before.)

I’ve been finishing up migrating my XML-RPC client library to ActionScript 3.0. First task, according to my own recommendation: write more unit tests.

Even though the unit tests I wrote for the ActionScript 2.0 version of the library used ASUnit, this time around I decided to go with the “home team” (i.e. developed by Adobe employees) solution and try out FlexUnit. Fortunately, at least for the tests I had already written, the two systems are pretty similar, so I only had a few tweaks to make to migrate them. (Too bad there wasn’t any way for me to unit-test my unit tests, to make sure they worked the same across frameworks.)

Anyway, along the way I found a couple of resources that were very helpful in getting started, especially since the FlexUnit documentation is rather sketchy (only limited API reference docs available). These were the articles that helped the most:

• Darron Schall: How to use FlexUnit with Flex Builder 2 (A great “getting started” article. This article was actually written while Flex Builder was still in public alpha, so it’s not perfectly accurate when describing Flex Builder’s dialog boxes — but it’s close enough that it was easy to figure out.)
• Daniel Rinehart: Asynchronous Testing with FlexUnit (Naturally, it doesn’t take long with ActionScript 3.0 before you want to test something involving events…so you need to do some asynchronous tests. The docs are no help here, and the included examples are really convoluted. I don’t know how Daniel figured it out, but I found his article very helpful for getting going with asynchronous tests.)

Some of the most useful links I’ve found on the recent project Tamarin announcement (Adobe’s contribution of code for AVM2—the ActionScript processing virtual machine portion of Flash Player—to the Mozilla Foundation).

• Tamarin project page
• Mozilla foundation press release
• Nice executive summary and analysis by Frank Hecker, executive director of the Mozilla Foundation
• Benchmark comparisons of Tamarin versus JavaScript performance

If you’ve only heard vague things about this deal and want a good summary, I’d read the article by Frank Hecker linked to above.

Most of the obvious and publicly discussed benefits are benefits for the Mozilla Foundation, Firefox, and developers using Mozilla technologies. Personally (as someone involved in ActionScript development) I think this is a really exciting announcement. Over the next day or two I hope to post my thoughts about what this means for the Flash Platform, and why I think it’s a good thing for Adobe (and, via trickle-down effect, for Adobe’s customers). But I’m on dad duty tonight, so that’ll have to wait a bit =).

If you’re interested in building large-scale Flex apps and not sure where to start, Brian Riggs has a nice article on Architecting a Flex App, where he gives a good overview and introduction to structuring an application using the Model-View-Controller pattern, as implemented in the Cairngorm framework.

Brian is one of two (at least so far, maybe there are more) authors writing on the Adobe Kiwi Project blog. The Kiwi Project (as stated in the tagline of the site) is a project which is working on creating “Read/Write Web Components for Flex.” I’m not sure of the details of what that means, but parts of it can be seen in the open-source NoteTag note-taking application which Brian uses as his example in this and other articles, and which is available on the Adobe Labs site.

Darrick Brown, who also writes on the site, has put up a couple of nice articles on ActionScript 3 from a C/C++ perspective. I don’t know either of those languages, although I work a lot in C# so I understood all his examples just fine. In any case he’s got what I think are some nice examples and thoughts for someone coming from any modern language.

Darron Schall put together a quick intro to using FlexUnit in FlexBuilder 2, in case anyone else is looking for such a thing.