25 Nov, 2008

Limitations of Adobe AIR

Posted by Bhavin Turakhia | (29) Comments

Most people tend to compare AIR and WPF/.NET. The predominant assumption is that AIR is to WPF as Flex is to Silverlight. AIR is touted as a cross platform desktop application development environment. This assertion holds true for basic widget-type desktop applications with limited functionality. The model begins to fall apart when you begin moving out of basic widgety apps into the realm of true rich and complex desktop applications. Some of the most fundamental shortcomings that come to mind are -

• AIR does not support multi-threading
• AIR does not allow making native calls to the underlying operating system APIs
• AIR does not permit loading native libraries (eg DLLs / C libraries etc)
• Limited Database support (no drivers for diverse databases)
• Limited Networking support (Raw network socket manipulation not available)
• Installer cannot be extended to install ancillary executables or other processes
• Limited to no support for building services / daemons / protocol servers
• Relatively strict sandbox

This is a short list of hurdles that I have come across. There are certainly many more limitations over and above these. AIR is essentially more like an extension of a chromeless browser, meant for running a web application within a desktop environment. It cannot be compared to a powerful desktop programming language like .NET (with WPF). Infact even XUL has better support for writing rich Desktop applications than AIR.

On the flip side I hear many good things about AIR in terms of ease of development. AIR apps can be developed in significantly lower timeframes than in most other desktop development environments. AIR also enables sharing of codebase between a web app and a desktop app.

Hopefully Adobe will catch-up on the missing elements soon, so that AIR becomes a strong enough contender to the current limited number of existing desktop development environments.

26 May, 2008

AIR vs WPF: Show me the money!!

Posted by Bhavin Turakhia | (3) Comments

I was thinking about AIR vs WPF (or Flex vs Silverlight) from another perspective today. If I wear the Adobe hat and Microsoft hat, I have to ask where is the $$$ in all of this (for Adobe and Msft).

Well firstly, both Msft and Adobe are selling the IDEs (or as they call them XXX Development Studio). But seriously – selling IDEs cant be big business.

Another revenue stream could be licensing the runtime specification for others to build their own runtimes (JDK style). While I may be totally ignorant about this – I don’t think either Msft or Adobe is doing much of this as of today. Some of the specification seems open and free. There is potential to begin licensing the runtime specs for non-PC devices such as mobile phones and set top boxes etc. However, given the competition, runtimes will likely be free for all devices and vendors (in this case Adobe / Msft) will likely go out of their way to have device vendors bundle their respective runtimes.

One more revenue stream would be self-created applications. This is much like Microsoft’s strategy with MS Office which has always been their cash-cow due to the platform ubiquity of Windows. Adobe is building a slew of their own products around Flex and AIR, and an increased adoption of their platform can result in additional revenue from their own applications. Offcourse this is always a sensitive area, since by building these applications they compete with the very app developers they want to attract to the platform. However Adobe has an advantage over Msft in this area due to the platform neutrality of AIR/Flex. Any app built by them is more attractive to an enterprise which has a heterogenous Operating System environment within the enterprise.

This brings me to the last potential revenue stream – an indirect revenue stream through propagation of the platform. Something that Msft has been very good at in the past. They made their fortunes due to the plethora of applications built in VB / VC in the good old days. The more apps that got built the more copies of Windows (and as a result Office) were sold. Here Msft has a distinct advantage. Every WPF adopter creates an additional boost in sales of Windows licenses. Unless I am missing something Adobe has no such incentive.

This indirect revenue stream appears to be significantly larger in scope than selling the IDE or licensing revenues or currently even their respective home-grown apps. If that is the case, then Microsoft has significantly more to gain by becoming a RIA standard as oposed to Adobe. This would in turn mean that Microsoft can afford to invest significantly more resources and $$s in the development of RIA as opposed to Adobe. Greater investment *may* mean more features, greater adoption and eventually platform dominance.

The one way I see for Adobe to counter this is to open up the platform and have the IBMs, Google’s, Yahoo’s, Sun’s of the world involved in AIR/Flex direction and development. This strategy has been very successful with Java on the server side (though I am sure Sun would have liked to get a greater piece of the action than it has) and if AIR/Flex is to become a default option for desktops/RIA, partnership with the rest of the industry will create the momentum it needs.

12 May, 2008

Things I wish AIR and WPF had

Posted by Bhavin Turakhia | (8) Comments

This makes a great follow-up to my last post on the Paradox of Choice. Life would be simpler with a single platform . Before I start a flame war on that subject let me quickly turn your attention to the real topic of this post. I have been grappling with deciding between AIR and WPF for internal application development and in all honesty, I’d like to have them both. Here are my short list of gripes (or on a more positive note, my wishlist for AIR and WPF)

Missing in AIR

• Advanced socket manipulation functionality (ability to create UDP sockets, NIO etc)
• Talk to any RDBMS
• Multi-threading
• Decent server socket libraries for building server applications (yes I know AIR is a desktop client platform, but given the Web 2.0 world, the line between a client and a server is beginning to blur considerably)
• Accessing global keyboard shortcuts
• Accessing native libraries (the kind that I get with XPCOM on XUL)
• Ability to instantiate external applications
• Greater control on the installer and installation process

Missing in WPF

• Write once, run anywhere ie the ability to run on Mac/Linux (I have already confessed that this is a wish list)
• A full-fledged HTML rendering engine (as opposed to having to instantiate an IE control with limited flexibility)

Hopefully folks at Msft and Adobe are listening