Latest News
Why Plurker Won't Be Developed Using Adobe AIR
12 months ago - Comments (View)1. Native Code
We’re writing a revolutionary desktop client for Plurk. We need the native capabilities of WPF and .NET. Here’s just a few of the things that we want to do that would be annoyingly difficult in AIR or impossible:
When a user closes the client, we want it to drop into the system tray.Without any window being active, we want to show customizable pop-up notifications that can appear on any corner of any single, dual, or even triple monitor setup.- We want REALLY sexy animations and effects that utilize DX10 and the GPU when possible.
- Yeah, AIR can do cool animations, but it can’t do ‘em using accelerated graphics like WPF can. Accelerated Graphics are a GoodThing in our opinion.
- Adobe AIR doesn’t have Multithreading (OUCH!)
- This means that newer processors can’t be utilized to their full capabilities. Multi-core processors will run Plurker beautifully using WPF. Not only that, with the way Keith is writing his API and GUI code, WPF will perform much more smoothly using native threads. This is an entire topic unto itself for why we’re going with WPF.
2. WPF’s ability to truly split UI design and back end programming
WPF has the insanely awesome ability to allow us to split the development and UI design processes. What this means is that Keith can throw some buttons and user controls together and throw them in a window, and start writing code right away.
When Jacob is completely finished with the Interface Design and UI, Ken can implement that interface using Expression Blend or whatever he feels comfortable implementing with. As long as he keeps the buttons and interface elements named the same as Keith is expecting, the two processes can be completely separated.
In other words, while Keith is hammering out the core features for Plurker, Jacob is creating the UI, and Ken is implementing it as soon as he gets each piece of the UI and making it work with the current version of the application.
In even simpler terms, we get shit done faster this way.
3. Keith has written the API in .NET
A small but important piece of information. One of the main reasons we’ve written Plurker thus far in WPF and .NET is because the API he’s created was written in it. The API is extremely robust thus far, and includes various options for us to talk to Plurk. We can do it Synchronously or Asynchronously, which is an absolute must if we want the Interface to be responsive and snappy.
Keith has implemented a means to quickly and easily implement changes that Plurk implements in their AJAX requests. For example, it took Keith a little under an hour to have the ‘mute’ feature code complete and completely tested. At the moment, we haven’t seen any unofficial APIs released that have these sorts of capabilities.
4. Most of our users will use Windows
The main argument for AIR is its support in Windows, OS X, and Linux.
Though all three of us are OS X lovers, and Keith is even an avid Linux fan, the numbers are pretty clear. Of our approximately 142 visitors on our first day of having this blog live, we saw over 100 users using Windows.
All of that being said, we will be releasing a Mac client in the future. And we’ll be doing that client with native Cocoa code as well, for all the reasons we listed above.
Hope this helped clear up any questions. Feel free to friend or add any of us on Plurk or just say Hi!
—The Plurker Team
Jacob Morse | Ken Hanson | Keith Hanson
