Several weeks ago I became hooked on Twitter and the ability to keep up with what my friends are doing. Since then I spent some time building an Apollo application that integrated with the Twitter services. Shortly after that Adobe announced AIR and I scrapped what I was working on and started over. My goal was to not only build something that worked with Twitter but to use some key development aspects of Flex 3 and AIR. Along the way I hoped to learn more about Flex development.
Today I'm making the application (twitterAIR) available for the general public to try in the hopes of getting comments and suggestions. I'd like for twitterAIR to become an application people enjoy using on a daily basis but in order for that to happen I need to know what works well, what doesn't, and what features folks would like to see.
So, if you use Twitter and you'd like to try twitterAIR on Mac or Windows you can download it via the Downloads pod to the right or using this link:
If you're interested you can also read about some of the features of Flex/AIR development I used to put the application together. Just click the "more" link below.
Integration with twitter.com
All of the integration with twitter was done with custom HTTP calls and XML processing. Twitter provides an AS3 API but it could use significant improvement as it's lacking in several key areas. I only use the API for specifying the event handler event types.
Complete custom skinning and chrome
The design was created in Photoshop (png's) and pieced into Flex as a completely custom "look and feel." This includes the background image, all buttons, chrome, logos, scrollbars, and fonts (excluding the text input font). Also, there's no native windowing elements in the app; all windowing mechanisms were written in AS3. The scrollbars were created in PhotoShop and displayed via CSS.
In order to provide as clean a UI as possible 3 typefaces are embedded into the application and used in every area text shows (excluding the text input font).
Date localization and manipulation
In order to display the "4 minutes ago" or "8 hours ago" text for each tweet some cool date manipulation was written. This involved doing some minor conversions between UTC time and the client's localized time and determining there difference in milliseconds. Then, configuring the text that says how old each tweet is when compared to the client machine.
The settings window and error windows were created as view (the V in MVC) components. All communication between these view components and the main application occur via the Flash event model. The settings view component functions as an ItemRender to a List component.
The Twitter servers do a good job of caching data to the client. For an application like Twitter, this can prove frustrating when you're trying to keep up with what your friends are doing on Twitter. To combat this, I've employed some anti-caching mechanisms to ensure each HTTP call to Twitter returns the most up-to-date tweets possible.
Custom Form Validation
In order to validate the form controls in the settings window, I wrote a custom validation package/class that extends the Validator class and is fed by a defined Model (vanilla XML with data binding). It's a decent example of validating an entire Flex form with a custom validator and having results dispatched back to the settings window via events. The tooltips that display when there are form errors are skinned in CSS.
File-system API integration
All information gathered in the settings window is stored on the client machine. The username and password fields are encrypted to provide a small level of security. You don't want anyone to obtain your Twitter username/password do you?
The update minutes and seconds are configured into the proper milliseconds value which is used as the source for a Timer instance. When the timer runs it executes ActionScript that facilitates communication with Twitter. This can be retrieving the public tweets or friends tweets. The timer is started and reset based on different user activity in the app.
Auto-update can be configured from 59 seconds to 1 hour to never. Of course, the user can always force an update by pressing Refresh. I envisioned someone wanting to refresh on a manual basis so this is accomplished by setting the update frequency to 0 minutes, 0 seconds, and then using the Refresh button. Keep in mind that at the time this documentation was written Twitter was allowing a maximum of 70 HTTP pings per hour per client. The auto-update settings are restricted to keep this from happening, but the refresh button is not, so be careful or you might not receive any tweets for awhile.
Internet connectivity monitoring
Admittedly, the application does not utilize the connectivity monitoring provided by AIR. However, network monitoring is accomplished and error messages will display if you disconnect from the Internet.
6 related blog entries
- twitterAIR 1.1.3 for AIR Beta 2 (October 1, 2007)
- twitterAIR 1.1.2 Released (July 29, 2007)
- twitterAIR 1.1.0 Released (July 16, 2007)
- twitterAIR on AIRapps.net (July 10, 2007)
- twitterAIR Screen Shots (July 4, 2007)
- Why Deploy With AIR Versus the Browser? (July 2, 2007)