Topic: Articles to remember

If you’re like me and you’ve been heads-down in work or just getting through the pre/post-Christmas season, you may have missed the article “Creating more secure SWF web applications” by Peleus Uhley, that was posted on the Adobe Developer Center on Dec. 20.

In spite of the bad timing, it’s a nice, thorough article that gives a good view of things that we can do to make our apps more secure, in addition to security updates that Adobe continues to make to Flash Player.

(via email from Jeff Swartz)

Last week I posted some of my thoughts on the future of Flex application frameworks, which were my take-aways from the October Silicon valley Flex user’s group (a.k.a. “SilvaFUG”) users group meeting. In that post I strongly recommended watching the recordings of the presentations. The recordings are available now, so once again I highly recommend watching them (now that you actually can watch them =)

Here are the direct links:

• Grant Straker on Moving ZoomFlex from a homegrown framework to Cairngorm
• Ali Mills and Luke Bayes on Flex application frameworks (A great overview of the strengths and weaknesses of various frameworks like Cairngorm etc., from two really smart developers.)

Enjoy!

(via email from SilvaFUG)

If you’re trying to help other developers (or yourself) get a better understanding of what AIR is and isn’t, with nice information for decision-maker types (e.g. if you’re trying to explain AIR to your boss) look no further than the November 2007 issue of Dr. Dobb’s Journal. In that issue, Oliver Goldman, one of the senior engineers on the AIR team, has an article introducing/describing AIR. I think it does a great job covering the bases of what AIR is, how developers can use it, and how it can be integrated (and secured) in an enterprise setting. It’s got some depth — it’s too long for a 5 minute or less overview — although it’s not a tutorial nor is it technical in the sense of including code samples or anything like that (which surprised me since Oliver is an engineer — but, as I’ve learned, he’s also a great writer.)

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