Ok, so this post is a long time coming. I have been wanting to talk about Apollo for a while and finally am taking the time to do so properly. The big word on the RIA scene (especially in Adobe-Land) for a while has been Apollo. Since last year when some of the early samples hit the conferences there has been a lot of buzz, marketing, and excitement about what Apollo will mean for the future of RIA development and possibilities. Now even though a lot of the early show and tells was borderline smoke and mirrors the concept and the hope is what really excited me.
Lets start with some back story. I personally and those I work with such as the very talented John Crosby have been doing what i would call more serious desktop Flash based development for the better part of 3 years. I have been doing desktop fixed media, and kiosk development longer than I have been doing Flash – yet was ultimatley consumed by the power and awe that is the Flash Player hehe. After much research and playing around when it came to the more recent years and Flash based desktop application development we favored MDM Zinc out of the myriad of competitors for various reasons such as API, performance, and extensibility.
Now what is Apollo, and what does it really offer? Well from my perspective Apollo is primarily a desktop runtime engine based on Flex 2, AS3, and the Flash 9 Player, with some spiffy new features. The ultimate feature and goal of Apollo is the ability to distribute your Apollo applications to any machine and the runtime will automatically generate and install a desktop projector-esque version with enhanced OS based integration such as window skinning and VERY VERY limited OS level controls. Current plans for launch support would cover Windows/Mac OSX/Linux based platforms for runtime support. Now one of the often most misunderstood purposes of Apollo I have seen is it is not meant to provide the ability to develop desktop applications using the wonderful Adobe Flash Player based technologies. Its main goal to be able run their standard web based counterparts on the desktop without the browser. Or in some ways it almost seems like the goal is to keep it mostly the same – add a couple new features (we will get to those in a bit) but just take the whole browser scenario out of the damn picture.
What is gained? Well much better branding and integration control with full OS level window skinning, for one point since it is not reliant on the browser. A very nice, but very limited, local data storage mechanism to handle such things as sometimes-connected-devices and persistent local data sessions – plus enhanced code framework controls to assist with such operations.
Bottom line – break the boundary between the browser and the desktop.
Lofty goal, but has many benefits. Interesting how the industry has come full circle – First the goal was to enable desktop like experiences on the web and now its taking web experiences to the desktop. So whats the biggest challenge in my opinion? Well the first and foremost is ubiquity and acceptance. What is the single reason why Flash is even a viable option for desktop experiences? Why is it even still around? Simple – the whole fricken world has it!!! The Apollo runtime will require a new install – not just an upgrade. And we are talking an OS level not just a browser level install. So that means corporations and enterprise level organizations will likely have it restricted right out of the box. Bog organizations that have thousands and thousands of employees and the security restrictions they enforce are really important and will come up again later when we discuss some of the limitations of an Apollo desktop application. The point is with the release of Apollo Engine it will be starting at pretty much ground zero – no ubiquity. No one can install an AIR file without it. Ohh dear god what will Adobe do!?!? Ohh wait….they are sneaky, smart little buggers aren’t they? If everyone already has Flash, maybe they can get people to install Apollo right through the Flash Player? Hmmm….. I seem to remember all sorts of special new upgrade capabilities of the Flash Player through the last few releases. Hehe the point is, this isn’t a new idea for Adobe (formerly Macromedia), this is something that has been planned for some time. Now I still think this is going to be an interesting hurdle for some time. One thing that the information from Adobe has seemed fairly vague on thus far is the distribution options for an Apollo application.
Lets discuss what Apollo creates and delivers, as per how it relates to runtime requirements and such. At the moment if you were to create a standard Apollo application and want to share it with a million of your best buddies you would end up with a .AIR file. What the heck is an AIR file you ask? Well its really just a .ZIP with a different extension similar to a .SWC file if you are familiar with those. When the Apollo runtime is installed it registers the AIR file extension to open with the runtime, which then on the fly generates the local system executable shell based on a configuration file and compiled SWF’s and assets within the AIR. So as long as you have the Apollo runtime an AIR file is your friend otherwise it’s as useless as a monitor with no computer or power. Now from Adobe there have only been vague answers to the ability to deliver runtime with application, or standalone application without runtime. You can manually deliver your compiled application without runtime, but it could be a mess. There needs to be multiple options to 1, help deliver the runtime to those who don’t have it WITHOUT multiple installs, and also to deliver the application OS target specific obviously without the runtime. Once the whole world has it yes, the preferred approach would be to deliver an AIR file for many many reasons, but until the ubiquity truly hits a high level I don’t see that as an option, yet the beautiful thing is the runtime generated executable is completely self contained and can run without any other OS level dependencies (not positive but pretty sure).
So some of the main benefits in my opinion the Apollo framework adds to the already reasonably impressive Flex 2/AS3 framework are as follows:
- System Windowing API: very cool but in current Alpha release far from complete or truly usable in my opinion and standardized workflows. The ease of use and theoretical future support could make this a really nice feature if it wraps up.
- Persistent Data Capabilities: One of the biggest steps in the right direction is the File Write and Read support. The ability to generate images from bitmap data, save xml, and my personal favorite save AMF data to local files opens up some great options. The ability to connect to a local DB like sqlLite is not supported and I am pretty disappointed. Since there is also no support for implementing DLL’s or other forms of system executions this is something in general that has a big issue for me, when I look at the future and capabilities. I believe there are also some cool controls as I mentioned to help manage sometimes-connected states though I personally have not looked into them very much yet.
- HTTPControl Sprite: This is one of the most exciting pieces in many ways in my opinion. The HTTPControl enables you to integrate instances of a the same browser engine that is used in saffari for your Apollo apps. You can do anything to them you would normally be able to do to a sprite including animate, distort, and all the whle still maintain generally full interactive control with the page contents. There is an excellent bridge of communication between the contents of the HTTPControl and the Apollo application. Cross scripting and even the ability to easily modify the html content loaded in from any source on the fly before its rendered through the player is supported and very impressive. MANY cool opportunities and capabilities here. Unfortunately at the early state of the current public alpha many features are still missing or in-progressm and I can only hope that they are all appropriately covered. Html content Flash support and appropriate system cursor display is an immediate must or the feature will be near useless as far as I am concerned. The performance is pretty close to good but not the same as a browser. Check out a cool sample here – as always Ely is the man!
I was fortunate to have a chance to speak with the developer of this functionality at Apollo Camp a few weeks back and gained some excellent knowledge on the under workings and limitations. One of the most important items that I feel I should share is knowing that the Flash Player itself is acting as the renderer. WHat this means for instance is if there is animated content for instance in the HTML content the Flash player has to try and render all of the content into a bitmap data fast enough. Early indications provided by the Adobe engineer indicated that likely only 15fps would ever look smooth, and I wonder if even that may be a stretch. What this means? Be careful what pages you try and render, because performance can likely be a factor. Another note – one of the features Adobe was plugging at Apollo Camp is the ability to make a HTML only application. Meaning you create your spiffy powerful html site (AJAX whatever), then deliver the whole experience through an Apollo application. Just note that it is very similiar if not exact to delivering it through the HTTPControl component via Flex or AS3. It still runs through the Flash Player renderer and applies the same limitations and performance concerns.
So some cool stuff for sure. Also a side note is some nice versioning installation controls as part of the runtime. However there are some major concerns I have with what is not planned on being directly capable via Apollo:
- File Open/Execute Capabilities: The more you want to do with a desktop application, especially without the full system level control of languages like C++ and Java, the more important it becomes that you can extend the prepackaged functionality by communication with other applications. Or as simple as being able to execute a newly generated ICS (Calendar File) file written by your application for instance. Now most likely the reason that such functionality is not supported is security. This can go back to that comment I made earlier regarding large enterprise level corporations, and their acceptance for both wanting to create such applications, and more so their willingness to install a new runtime enterprise wide due to security risks. Soon as open/execute/delete are capable surely malicious developers will take advantage of this and create some nasty applications or other such trojan delivery mechanisms – great power comes with great responsibility. truth is in my opinion without this functionality, the boundaries for innovation while maintaining support without heavy dependencies on additional middle-ware like a very cool but cumbersome process started by EffectiveUI using a Java Socket connection paired with your Apollo application – major downside is now your application requires both Apollo and Java runtime 
- System Level Extensibility Capabilities: One of the greatest features of other wrapper frameworks like MDM Zinc is their ability to enable system level extensibility. An example of this is Zinc’s ability to directly consume win32 DLL’s from your application – fricken awesome! Or AppleScript and such on a Mac. Now the main reply to this I have heard from Adobe is one of their main goal is complete cross OS support. They do not want to add any feature that does not work in ALL supported systems. Though this is admirable, I still see some major issues with this. I would prefer to have a way to externally communicate that was standardized via a cross capable API, though end results would differ on system. Honestly even if there was a different API for each system this is important enough and used by generally only very advanced applications that I believe it would be not only totally acceptable, but damn near necessary.
SUMMARY
Apollo has a lot to offer and can really open up some interesting doors – though I wouldn’t agree with the idea of it being the Desktop 2.0 catalyst. The concept I am most interested is cross browser-desktop linked applications. For instance when you go to www.FooVar.com my customized content/widget displays my special info, and as I interact with either my desktop widget or the browser I get cross communication, updating one and other- ooooh sexiness all around. At the moment I am worried about how far applications will be able to be taken on the desktop with the current limitations, and I think there is more hype than sustenance at the moment due to runtime ubiquity requirements, though I am interested to see what is in the works to solve this as release comes around. As far as past Adobe Alpha’s theres been more talk, and less walk than what seems to follow their history. Lots of features are mentioned, but not seen, which makes me excited and worried. This should get hopefully cleared up when beta time hits. I really hope it doesn’t fizzle to anymore than widget development because I see such potential, but right now its a waiting game to see what makes the cutting room floor, and how Adobe will get the world to get on the rocket bandwagon. Worse case Zinc still has support for Flash 9 content, and unfortunately we are already leaning a couple mini-apps back in that direction – but high hopes for Apollo breaking the atmosphere are still there! Let me know what you all think.
FYI – The name Apollo is a pre-release name only. The final name of the product has not been released.
And as always – only in my humble opinion hehe.
__________________________________________________
