A couple of weeks ago Adobe published the first beta of their new technology codenamed Apollo.
First of all it is important to understand that while Apollo is a new technology for Adobe which is currently in its first Alpha, the toolset which you are actually using to develop solutions has been in the market for quite a few years – and has been widely adopted by developers across the globe.
Most of the technologies involved into the Apollo solution stack originate from Adobe’s acquisition of Macromedia, the software company responsible for the universal Flash browser plugin and the de-facto standard for professional web design, Dreamweaver.
Predominantly Apollo applications will very likely be built using Adobe Flex Builder 2.0 (and the upcomming 3.0 release) – which is an Eclipse based IDE used to write ActionScript 3 code and design the user interface. The latter task is either accomplished by using Flex Builder’s visual designer or by coding MXML, Adobe’s declarative XML dialect. The designer effectively generates MXML. (This can also be used to dynamically generate user interfaces at runtime.)
The primary rendering engine in Apollo is Flash player Version 9. It’s the exact same engine which is uniquely ubiquitous in its distribution (700 million installed PCs, 150 million installed mobile devices).
With Apollo Adobe reaches out for true cross-platform desktop applications. The Flash player has successfully evolved from an animation tool for web designers (we all know the “Skip Intro” links) to an ubiquitous cross-browser platform for rich internet applications (RIAs) and forms and important part of Apollo.
Apollo primarily is Adobe’s “wrapper” – although it is more than just that – around these technologies. It kind of replaces browser specific hosts (Internet Explorer’s ActiveX, etc.) and adds desktop level features like file system access, copy & paste, clipboard access and drag & drop interactivity with other applications.
On top of that it provides platform specific installation and maintenance means. E.g. on a Windows PC it takes care for Start Menu entries, uninstall listings, etc. The Apollo runtime also allows developers to integrate means of remotely updating Apollo based applications and handles occasionally connected situations (offline ability).
My company has been working with Flex since Version 1.0 and hired a couple of Flex experts some time ago. In an attempt to evaluate the maturity of the technology, we initiated a port of one key product to Flex which would make the rich feature set of the application available in a browser.
Based on Flex 2.0 and Flex Builder we were able to port the entire enterprise solution in less than three weeks – port meaning a full port, not just prototyping.
The toughest – if one can say so – part of it was porting the communication protocol. In the .NET version we were relying on a synchronous IP socket based communication with our middleware. As the current runtime (Flash Player) is single threaded, it only offers asynchronous raw sockets. So we had to implement a standard Command Queue / Response Queue pattern. This along with porting the protocol parser was the tricky part. On the other hand it proved that ActionScript 3, the programming language of Flash – is (even with “Script” in its name) not just a simple language for graphical designers.
In fact it has evolved a lot, is object oriented and comes with a pretty rich class library.
Designing the user interface of the Flex based version was a walk in the park. This obviously is driven by the roots of the Flash player in animation and graphics. The Flash version was significantly surpassing the experience the WinForms (.NET) one delivered. Flash (and Apollo, too) make it easy to design custom chrome applications, with the ability to break the boundaries of a traditional window and Flex comes with the built-in ability to skin an entire application by means of style sheets (CSS) and extensions of style sheets.
Graphically rich chart based presentation is still extremely difficult to be done for thin-client distribution as it either involves server side pre-rendered images (huge load on data network), a proprietary browser plug-in or Java applets (which have their own problem area when it comes to distributing the right version of the JVM / plug-in to desktops).
Flex includes Flex Charting Components which is a beautiful way of leveraging client side rendering with server side data generation. We used Flex Charting Components and are since then using these in numerous of our products.
Adobe’s Flex currently is without competition in terms of the ubiquity of the runtime (Flash Player), true cross-platform support and the Eclipse based development environment to build applications. Apollo is the next logical step in Adobe’s strategy.
The single most important critical success factor – and the one reason why I would not yet unboundedly jump on the Apollo train, will be the support of the development community.
While the Macromedia Community was strong, Adobe has primarily been recognized for PDF and graphical design solutions.
They might not yet be recognized by developers as a serious software vendor in the enterprise application development space. This does not necessarily indicate that they are not there, but moreover their marketing has not caught up, yet.
Adobe offers a full blown Eclipse based IDE for Flex/Apollo which should make every Java developer happy. ActionScript 3 is a fully object oriented language with a great class library. However, most enterprise developers coming from a .NET / Java background tend to resist a language with “Script” in its name.
They seem to link it to JavaScript or a language for web designers as opposed to a real powerful programming environment for rich user interfaces – which it definitely is.
Once we launched the Flex initiative within our company we had severe difficulties getting our engineers to buy into it. The .NET team was used to use Visual Studio and for them moving to Eclipse was a horror scenario. Once they created their first Flex applications they started to really like it.
The reason is simple: It is so easy to create visually appealing user interfaces with Flex (the Flash part in it) that even your prototypes no longer look like early alphas. The other reason is that Flex Builder 2 is a very productive environment for building these apps. It makes great use of the capabilities built into Eclipse. Another reason is that Flex applications can easily be distributed through the web (= into the browser). So they could just upload files to a web server and demo to a larger audience.
Our Java team did not like the idea to go for Flex, either. Their primary reason – as they were already used to work with Eclipse – was, that they did not consider ActionScript being a serious language. Well, after a short period of prototyping they found out it’s been just a matter of having prejudices and “fear of the unknown”.
ActionScript for sure is not a language you would want to build middleware or heavy data processing engines with. On the presentation layer side it offers all you need (including various means to communicate) based on a pretty fast virtual machine.
The recently renamed Adobe LiveCycle Data Services – which are currently available in Beta 2.5 – are a solid communication stack hosted as J2EE applications which add a variety of sophisticated data and messaging related capabilities to the solution stack. These include replication and synchronisation mechanisms for occasionally connected applications. With LiveCycle Data Services Apollo applications can download a subset of the data they require to operate, allow users to make changes while they are disconnected and automatically distribute these changes back to the database on next connect. (This capability has contributed big time to the success of IBM’s Lotus Domino in the 1990s.)
In a nutshell: The window of opportunity for Apollo as a solid, true cross-operating-system runtime technology seems huge. It’ll depend on you and me and everyone to jump on the train, download alphas, betas and trials and help Adobe getting the development backing they deserve.