Snitter on AIR Beta 2
A week ago, Adobe released a new version of the AIR runtime. Shortly thereafter, I released a new version of Snitter, my Twitter client that I built on top of the runtime. Since then, I've been adding in a bunch of new features, bug fixes and tweaks.
Dan Rubin did the design on the new Snitter version and it's been very well received. That, along with themes, has proven to be very welcome additions. When you can't please everybody, create themes! (Truly, I've had people complain about the green and refuse to use the application because of it — to others who, despite the new features, have said that the green is still the best. Go figure.)
What's new in the runtime
Many of the complaints with the original release of Snitter were unfortunately limitations of the AIR platform. Input controls and scroll widgets were hideous, keyboard text selection was non-existant, among other deficiencies.
Beta 2 luckily fixed most of the major issues (with US keyboard layout being the remaining one on my list). The new version of Webkit also offered up the ability to make use of border radius which allowed for a very flexible UI.
New security sandbox
From a development perspective, there's also a new security sandbox which offers up limitations that can be difficult to work around at times. The application sandbox prevents you from using eval or new Function. With AIR's ability to access the file system, the ability to run arbitrary code from an external source does pose a risk.
To get around this, you place the functionality within a child sandbox via an
IFRAME. Within the child sandbox, you no longer have access to the AIR interface except through a
parentSanboxBridge object. Methods are added to this object from within the application sandbox and allows you to isolate functionality exposed to the child sandbox.
While there was an initial hassle to rearrange the application, it's been fairly easy to work with since. It does mean that design decisions should be settled on early on as to how code and UI should be split between the two sandboxes.
Difficulties in Development
One of the biggest headaches in development has been dealing with two moving targets: the AIR runtime and the Twitter site.
Having functionality shift within AIR did mean a rewrite of a chunk of functionality but the more troublesome has been the Twitter site. Between the site going down and shifts in the API, it's difficult to put together functionality for an app and be confident that it'll continue to work weeks out.
My personal words of wisdom: if offering an API, build it and then extend it. Changing it afterwards should not be an option. Likewise, error messaging should always be returned in the format specified. As it stands, when Twitter goes down or does an upgrade, the response back is HTML, not XML or JSON.
One thing I've definitely noticed is that when Twitter goes down, the application gets blamed. Some early converts jumped ship because of error alerts that occurred in other apps. In the end though, we all connect to the same service and all suffer the same consequences. The bigger lesson here is how one should handle an error. Sometimes, it's important to be in a person's face but sometimes, as it is in this case, not forcing a user to respond to an error message makes the application appear to work better.
One of the joys of releasing an application like this is building something that you know people are using every day and enjoy using. I've been using twittersearch to search for mentions of Snitter and respond to feedback both positive and negative. Many people will be vocal about what they like or don't like but never provide that feedback directly to the source (ie: me).
All-in-all, I'm really pleased with where Snitter is right now. I set out originally to build something that simply had the features that I wanted but has since turned into something that I want to be considered the best desktop Twitter client out there, OSX or Windows. Feature wise, I think I've done just that (with more features to come).