Topic Archive: Apollo

Apollo: How Alpha is Alpha?

Dietrich Kappe, Tuesday, May 29, 2007 @ 5:16 am

Jan Erik Paulsen has been writing some sample Apollo applications. In his view, Apollo isn't quite there yet:

The Apollo SDK also feels a bit lightweight for something coming out of
Adobe. Apollo/Flex is very powerful indeed, but the SDK does not
reflect this. Third party applications are currently in crash-o-rama
spectacular mode since about 60% of non-Adobe demo applications throw
exceptions. It is alpha after all.

Yes, it is alpha software, but 60%? I've seen about the same rate. That seem a bit high. Presumably these apps all ran on the developer's local machine. I know that is a bad way to test apps, but since they aren't a) complicated and b) running on a supposedly platform independent runtime, you would expect this rate to be a bit lower.

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

Adobe Apollo - First Impressions

Dietrich Kappe, Monday, March 26, 2007 @ 6:00 am

I just worked my way through the O'Reilly Apollo for Adobe Flex Developers Pocket Guide. This booklet is written by the Apollo development team and is essentially a "getting started" guide to the Alpha1 release. The booklet doesn't contain anything that you can't find in the online documentation available from Adobe (which may in fact be more up-to-date), though. In fact, they both contain the same oversite, i.e. they neglect to mention that you will need some sort of Flex SDK for the Apollo SDK to work. That may seem obvious, but is in fact a bit of a stumbling block for those of us expecting the Apollo SDK to be a complete solution. For those of you looking to experiment with the SDK, download the free Flex SDK and unzip it to the same dir where you plan to install the Apollo SDK.

What is Apollo?

It is important to step back for a second and point out what Apollo is not. Apollo is not a general desktop runtime meant to compete with lower-level application runtimes. This means that you probably wouldn't want to build Photoshop on top of Apollo. Apollo's primary use case is enabling Rich Internet and web applications to be deployed to the desktop. This is a very important but subtle distinction, as enabling RIAs on the desktop is the primary use case driving the Apollo 1.0 feature set.

[...]

Apollo solves most of the problems with deploying web applications via the browser. However, there are still advantages to deploying applications via the browser. The fact that there are so many web applications despite the disadvantages discussed earlier is a testament to the advantages of running within the browser. When those advantages outweigh the disadvantages, developers will still deploy their applications via the web browser.

But is it not necessarily an either/or question. Because Apollo applications are built using web technologies, the application that you deploy via the web browser can be quickly turned into an Apollo application. You can have a web-based version that provides the browser-based functionality, and then also have an Apollo-based version that takes advantage of running on the desktop. Both versions could leverage the same technologies, languages, and code base.

Apollo applications complement web applications. They do not replace them.

I have been and continue to be skeptical about the future of Apollo. The niche described above seems most compelling for the mobile space, support for which is not in Alpha 1. You think Apollo is going to take off? Then I have a Java WebStart app I'd like to sell you.

What else is in Alpha 1? Support for Flash (surprise), HTML and tight integration between the Flash/ActionScript and Javascript/DOM sides of the house, abstraction of OS services (File I/O, windows, etc.). What isn't in Alpha 1? No PDF support, nor the talked about security or offline parts of the platform. They need to introduce this kind of support quickly, otherwise nimble desktop RoR beasts likeSlingshot that promise to have "simple and transparent data synchronization" will eat their lunch.

As for developing applications in it, if you've developed Flex apps before, it should all seem very familiar, with the addition of some OS/Browser specific API's. Some other observations:

• Apollo uses WebKit as it's HTML engine, the same one that is used within the MacOS browser Safari.
• IDE development with Apollo only works with FlexBuilder 2.0.1 right now. If you want to use Eclipse and the free Flex SDK, you are out of luck for now and will be restricted to doing command-line development (or installing an evaluation copy of FlexBuilder).
• It is somewhat humorous that Apollo's built-in HTML engine doesn't deal with flash in a web page.
• As already mentioned, you will need the Flex SDK in some form to have the Apollo SDK work.
• I was't able to get the packaging command, adt, to work for me. It returns a "null" error.

Overall, the Alpha1 SDK has a complete component GUI, since it leverages Flex, and basic integration with the OS and HTML engine. We'll have to await a future release to see all of the things that will make developing robust RIA's on the desktop (offline + security) pleasant and easy.

 
  Technorati : ajax, apollo, flash, flex, ruby on rails, slingshot

• Digg
• Reddit
• del.icio.us

Comments (1)

agile ajax

Apollo - Adobe’s JVM

Dietrich Kappe, Thursday, August 3, 2006 @ 9:00 am

Apollo was announced by Adobe back in March of 2006. What is Apollo? From the Adobe Apollo official FAQ:

Apollo is the code name for a cross-operating system runtime being developed by Adobe that allows developers to leverage their existing web development skills (Flash, Flex, HTML, JavaScript, Ajax) to build and deploy Rich Internet Applications (RIAs) to the desktop.

[snip]

While a number of more traditional desktop applications can be built and targeted at the Apollo runtime, Apollo is targeted at making it easy to develop and deploy Rich Internet Applications to the desktop.

So, Flash without the browser? Actually, its a little more than that. It's supposed to have a full featured API that allows you to interact with the underlying OS (Windows XP and OS X at this point). It also appears that some fairly low level programming is possible:

Apollo 1.0 will not have built in support for communicating directly with databases. However, it will be possible to write Database drivers in ActionScript (leveraging binary or XML sockets), which would allow Apollo applications to communicate directly with a database (both local and remote).

It seems like this is the "browser without the browser" in a JVM like package that users install on their PC's and Mac's. Developers can distribute Apollo based apps much like Java applications are distributed today, depending on the presence of the previously installed runtime. The runtime is a natural continuation of the development of the flash platform, which started out in Flash 2 with simple commands and has evolved into a second generation byte code VM with JIT compilation. Apollo looks to extend that platform and allow a tighter integration between the HTML/Javascript part of the runtime and the technologies that keep the lights on at the Adobe headquarters in San Jose -- Flash and PDF. No more need for a Flex/Javascript bridge.

What's in the API? From a presentation by Adobe:

• Offline / Occasionally Connected
• Applications can run in background
• Network
• • HTTP
  • XML-RPC / SOAP / Rest based web services
  • Binary and XML sockets
• File I/O
• Local storage / Settings API
• Custom Chrome

Still a little nebulous, I know. I find the offline/occasionally connected support very intriguing, but right now its just a tease.

Apollo may well be successful where Flash has struggle to gain acceptance in the past. As Ajax drives acceptance of rich interaction web applications, it is helping Flash along. If Apollo is seen as a better or cleaner way of deploying Ajax applications, or even as just another viable target for existing Ajax frameworks, that should drive it's adoption. Still, Ajax prompts me to ask lots of stupid questions: how is this different from client-server; why not just use Java/Swing; why run desktop style apps in a browser; what's wrong with Flash?

There are a few open questions for Apollo. For example, ActionScript 3 eliminated eval(), i.e. you can no longer include dynamically generated ActionScript. Since some Ajax frameworks and techniques load Javascript at runtime (JSON, etc.), the lack of a ECMAScript eval() is going to be a problem. According to the above presentation, ActionScript and Javascript will coexist within the environment, so maybe there will be an eval() in the one but not the other.

Apollo is slated for prerelease in the second half of 2006 (any day now) so we'll have an answer to some of our questions soon.

Technorati : adobe, apollo, flash, runtime

• Digg
• Reddit
• del.icio.us

Comments (1)

agile ajax