SWX twitter badge

I created the Twitter badge you see on the header of my blog yesterday using SWX. I'm using it to improve the next release of SWX which I hope to have out this weekend at some point.

My main focus in building this was to see what would break when using real world data and to see how easily you can build error checking and recovery into your SWX applications.

The Twitter badge is optimized so that it only ever gets the latest public update from my friends using the friends_timeline. The first call isn't as optimized as it could be because the Twitter API doesn't currently give you a way to request just the latest update (you have to get 20; there is an enhancement request pending for a count argument that would solve this problem). My service method in PHP throws away the unnecessary 19 and only returns the latest one though so at least that bit is optimized. This is initial call also appears to be plagued by the caching that Twitter has recently implemented so it will not always return the latest update.

After the initial call, I use the since argument to get only the latest update. When using since, the caching does not appear to be active and thus you actually get the latest (public) update. If there is no update, the resulting data transfer is only about 184 bytes. With an update, the data transfer appears to be in the region of 570-670 bytes. (And these should shrink further once I implement compressed SWF files in SWX.)

The badge tries to handle errors as gracefully as possible and recover from them whenever it can. A call to the SWX gateway times out in 12 seconds (I am polling every 15 seconds) and the next call is delayed by 15 seconds. The user is alerted but the experience is not interrupted. The badge continues to work. The same goes for twitter timeouts.

The badge itself weighs in at 36kb, 22kb of which is taken up by the embedded fonts that I'm using. The ActionScript in it is roughly 9kb in size. The remainder is taken up by miscellaneous assets.

I will release an article and the source for the example shortly -- most likely after the next release of SWX.

Using SWX on this has been a very positive experience. Since the data exchange itself was so easy to implement, I found I could spend my time on actually building the badge instead of getting caught up with the plumbing.

Of course, this is a very simple Flash widget but I am taking baby steps here so that I cover all the bases and potential issues do not fall through the cracks.

My to-do list for the next release looks like this:

I will also be changing the version numbering system with the next release, which will be 0.1.9 (Major.Minor.Revision) instead of 0.1i.

Very closely thereafter, I am planning on adding allowDomain support to SWX SWF files and implementing SWF compression (this is one optimization that I can add now without obscuring the intent of the codebase, so why not -- but do not expect any other optimizations any time soon.)

I've also finalized the licensing for SWX -- you can read a plain English overview of the SWX license on swxformat.org. (As always, if you have any suggestions on this front, do let me know.)

I can't wait to get the next build out so you guys can start working with existing service classes and build mashups, etc. I am going to release my Twitter service class along with the next release so you can start building Twitter mashups right away.

Comments