Apollo ... the end of Zinc-type Apps?
Anyone who has programmed in Flash for longer than a couple of months soon realized that they would love to add functionality and power to their Flash applications. Flash is meant for the web, yet its ease of use and huge outreach to users makes a very appealing case for using Flash for more than your standard web applications. Programmers that have married themselves to Actionscript seek to utilize Flash's power on desktop applications or on other devices and for a wide variety of purposes. People have constantly asked me "Can Flash do _____ ?" The answer, as many of us have found, is often times "No." Or at least, not by itself. Hence the emergence of third-party applications, such as Zinc, that give Flash developers the power that software programmers have always had. Having access to the Windows/Mac API essentially turns a Flash programmer into a software developer.Of course, Adobe won't sit idly by and watch as third-party applications fill a growing target audience's need. The solution seems to be the buzzword of the year in the Flash developing community: "Apollo." According to Adobe,
"Apollo is the code name for a cross-operating system runtime being created by Adobe that will allow developers to leverage existing web technologies, such as Flash, Flex, HTML, JavaScript, Ajax, and PDF to easily create and deploy desktop applications. In this session, Mike Chambers will give an overview of Apollo, discuss how it aims to make RIA development and deployment better, and show how to get started developing for it.
(Understanding Apollo—Adobe)
So the question in my mind is, will Apollo fill the void? With using useful yet often buggy and unreliable Zinc-type applications, I've too many times run into walls with features that either aren't what I'd like them to be, or are at best in the beta stage.
It's obvious that the makers of programs like Zinc recognize the power of Apollo, and have reacted to protect their profits and customer allegiance. Soon after Apollo became an office buzzword early this summer, Multidmedia launched a designer/developer competition to encourage users to incorporate Flash/Flex projects into a widget-type application that runs on a user's desktop.
Although Zinc seems to be threatened, I still wonder about Apollo's capabilities. Are we going to have to continue relying on third-party applications or dead Director programs to access things such as multimedia devices, media players, or form-based applications?
Although I hope that Apollo is everything that it's hyped up to be, I am wary of trusting that Adobe will fulfill all my developer needs with this application. Clearly, however, Adobe is in the best position of anyone to capitalize on developer's needs. Especially if the Apollo runtime were automatically pushed with versions of the Flash Player, the capabilities of a large market penetration with the this product seems very appealing.
Apollo is definitely on its way, but developers will wait to see if it truly will be the solution that everyone says it is. If you're like me, you want to know more. A good start would be to register for next week's online event at Adobe, Understanding Apollo.

19 Comments:
One distinctive difference between Zinc and Apollo is Apollo has Flash, HTML and PDF under one hood. The WebKit HTML engine will be used in Apollo and it will render the output into a Flash object. Which means you will be able to manipulate it just like any other Flash object. For example applying Flash 8 filters and skew the HTML page. This is much more than just a simple desktop app, its a whole new bread of skewing the line between Flash, HTML and PDF.
If adobe opens up Apollo to dlls, .NET assemblies and more access to the actual OS then it will compete with Zinc. Right now it doesn't look like that's where its headed, however it would be great to have such a company as large as Adobe making this possible so we can actually do lowerlevel OS operations. When you say cross platform though - you instantly open up a can of worms. So they should just branch off and let developers do their own platform specific actions if they want, but keep the major functionality cross platform.
renaun--
Thanks for the comment. But is that all Apollo will allow us to do? Skew the line between Flash, HTML, and PDF? Are we going to be able to access Windows/Mac API's? How about read/write files? Detect resolutions/display configurations? Use media players? Those are some of my big questions. I love that we're skewing the line with web technologies, but I guess I expect more with a "desktop" application.
I think there are significant needs for both approaches. OS-level executable code offers security permissions beyond what we can achieve in a sandbox'd application browser.
I don't have full info on eventual 1.0 features myself yet... no word on Xtra-like extension mechanisms or degree of system access. The goal is more on making it convenient and safe to achieve OS-neutral persistence, rather than just to duplicate EXEs.
From what I see of Adobe, the goal is to grow the ecology rather than own all elements of the ecology -- the free Flex SDK was a signal indicator of this approach. Complementary solutions indicate health.
It will take awhile before we're all agreed on the relative benefits of OS-native and Apollo-style work... this sound right to you too...?
jd/adobe
That's an interesting thought. I guess we'll see how Apollo changes the culture of decent internet applications vs. desktop Flash hacks. I, for one, hope that we can use Apollo for much more than HTML, PDF, and leveraging other web technologies.
It will be able to read and write files, but in its own sandbox. None of us know how much they will open up in terms of OS level stuff until they release it.
I see things in Apollo, that Zinc, can't do as more appealing then making Apollo another Desktop application platform. Apollo is more, just the fact that you can drag a flex app item over a google map and have it refresh the google map html page shows the power. It is about leveraging Flash,HTML and PDF not about making the same old desktop applications.
John, well put "grow the ecology rather than own all elements of the ecology". Its not about building desktop apps but empowering people to create new kinds of applications. That doesn't mean there will not be a purpose for OS level type apps.
Disregarding Apollo's cool fusion of Flash/HTML/PDF for the moment....
There are really two classes of "desktop" applications that we should discuss. There are developers trying to build both classes of applications who want to use Flash and Flex.
System-specific desktop apps require lots of low-level features, many of which are impossible to abstract across OSes. System databases, registry access, custom driver access, etc. These apps also tend to want to re-use native code DLLs.
Cross-OS desktop applications cannot have access to all of those low-level features without undermining their own cross-OS-ness. The benefit they get is a "run anywhere" guarantee, just like web pages.
Apollo is clearly focused on cross-OS applications. Support for custom DLLs (like Zinc provides) would undermine the guarantee that Apollo wants to make.
Over time, the functionality supported by Apollo will grow. But for the class of applications that requires low-level, system-specific programming access and can sacrifice the guarantee of simple cross-OS support, Zinc and its peers will still be valuable.
Ethan Malasky
I guess apollo will either be aimed at one of two groups - the widget developers looking for something more advanced, or desktop application programmers looking for a more flexible approach to certain scenarios.
I'm thinking it'll most like be the first group - at least with the first version, however looking at teh way Adobe is trying to get Flash taken as a serious application platform they might surprise us all with something truly awesome.
I don't however think they will specicifically allowing the use of windows type dll files - simply because apollo is meant to be a cross-platform runtime thing. However, when Flash introduced ExternalInterface communication with practically anything became possible if you knew what you were doing.
This could be awesome, it could take on wpf and win (cross-platform at least), or it could end up feeling like a bodged together collection of technologies with numerous quirks and annoyances.
Either way it is a step forward and will be interesting to watch.
Great comments everyone. I see the merit in Adobe's cross-platform approach, but I also wish they would add in Xtra-type functionality so those of us who want to take Apollo farther could. Either way, I think Apollo is a step in an exciting direction.
Good comments all around. Just one comment to clarify something.
With Apollo, we are aiming to create a cross platform runtime for deploying Rich Internet Applications (RIA). We are not (for 1.0) aiming to create a general application runtime.
i.e. don't expect to see photoshop in Apollo 1.0.
Hope that helps clarify our intent for 1.0.
mike chambers
mesh@adobe.com
Regarding the comments about access to media players, I seriously doubt Adobe is gonna let you embed WMP or QT objects inside an Apollo app. That is what Flash video is for! :) Personally, I can't wait to get my hands on the beta.
gosh!--
Point well taken, but have you ever tried to run Flash video in a fullscreen application with other things going on? Not so great unless your machine is a supercomputer. Yes, Flash and Flash video are meant for the web, I understand that. But I want to use Flash for more!
(i.e. ... Kiosks?)
[snip]
Regarding the comments about access to media players, I seriously doubt Adobe is gonna let you embed WMP or QT objects inside an Apollo app. That is what Flash video is for! :) Personally, I can't wait to get my hands on the beta.
[/snip]
I just watched a video from MAX 2006, where I can see great HTML support. There is no reason you can not create a hybrid application to host media which Flash Player can't handle?
I am sure we would see kind of patterns once Apollo is out and people start building applications.
-abdul
Anyone seen this?
http://www.multidmedia.com/blog/2006/07/waiting-for-apollo-zinc-flex-today.html
I like the idea of Apollo but I can't help feel this is just "Central" redux. In fact, Adobe should take a closer look at working with the likes of MDM & Zinc. (Wasn't it just 10 years ago that Macromedia purchased a product called FutureSplash?) :-)
anonymous--
Zinc is great for a lot of things. I use it in a lot of the applications I develop. But to be honest, when you look at some of the methods built into Zinc and really get testing it, it's a little bit of a buggy program. I've tested Zinc in the last couple of months pretty extensively, and have found some fundamental problems with the application. The company is responsive and have said that they are working on the problems, but I worry a lot about basing applications on a platform that is somewhat unreliable.
My understanding is that Apollo will not target CD based applications so either way there will be a marginal market for third party wrappers I assume. I'm not a huge fan of Zinc myself and while they have the Flashiest website of the wrappers apps their app is no comparison to one like SWF Studio (which was the only one to recieve an actual license from Macromedia to embed the player). The command set is far better with everything from encryption (448 blowfish) to their proprietary Scratch feature (dynamic data storage right inside the EXE which can be maniuplated at runtime after compile time...also encrypted (448) on the fly as well) and right now most of us who use it are awaiting a Flash9 embedded player. Once that arrives to test Flex content with I'm going to have to see the benefits of Apollo over it myself. I like the idea of Adobe keeping all it's eggs in their basket but boxing out CD's is not a smart move if that is the game IMO.
zinc sucks, plain and simple.
i find it's a poor product, and the fact they say they've integrated AS3/Flex when all it is is a flash.utils.Proxy into their current framework is lazy.
Apollo will never be the Zinc's of the world, and is not meant to be - Adobe is just trying to push the boundaries of the flash platform, as well as a web browser, which is great.
If you want a cross-platform framework for lower level ops, there is one: Java.
I think many of us want Flash to be this all encompassing software utility that can do anything and everything, but that's not likely to happen.
As far as projector software goes, SWF Studio is good, but for christ's sake their development cycles as years long. (I think it's now been a years since they said they were working on an AS3 API)
I think we've definitely established here that Apollo will not be the end-all to third party wrappers and apps.
Believe me, I've used Zinc enough to know that while it may not be the best application, but it does allow you to develop for platforms that would be otherwise impossible. I've been developing for interactive kiosks lately, and I can't find another tool that works as well as Zinc for what we do.
So although the program is lacking, there is simply not a better solution as of yet.
I think the reasons any of us would need a wrapper would vary from person to person as well as how it relates to why we code in the first place. I do know whatever I do decide is desktop worthy as it relates to me, being able to handle dynamic data (what I do) without need of a server side locally is just a benefit I can't live without. It's also a big plus to be able to re-use web based routines of mine with minor alterations for desktop use, especially seeing as I can read/write files without need of a server and also rely on sql database structures I have in place by altering them as needed, simply dumping the structure and embedding them in say SQLLite with a wrapper.
A good example of re-useable code to me is the Style Explorer Flex application from Adobe Consulting. Great little tool. Problem is it's web based which doesn't make sense and simply creates the CSS to copy/paste. Flex on rails then advances that little number and now it allows for download of the CSS. Cool and all but still trapped in a web based enviro and still tied to a server side (in their case ruby). Peter will also update his to download but still it's web based. Now I take the app and write routines to write the CSS locally and wrap it in a wrapper. I can pack it on any media and take it wherever I go...no server side needed nor connection at all. I simply write the CSS to disk. Makes sense because I don't necessarily need a connection to use Flex Builder and I certainly shouldn't need a connection to make Flex specific CSS. That's is a perfect re-useable code scenario that can be applied to many a routine we all have lying around or as part of our overall bodies of work. An online cart system can become a desktop based product catalog with minor alterations while still supporting the checkout process with any available connection and without even needing an external browser since most of the wrappers will embed one.The list of possibilities is endless for porting our code with little added work to ourselves and still reaping the benefits of a server side like ability to read/write/store. If Apollo will let me do things like that with my dynamic Flex code, I'm hooked. If not, I don't see me getting away from supporting a wrapper anytime soon.
Post a Comment
Links to this post:
Create a Link
<< Home