by chrisdouglass » 12 Feb 2007, 21:55
Hey guys,
Alex I agree that installing something for a web application is a pain but Macromedia saw/sees around 95% penetration of their player b/c most people go ahead and install the Flash runtime. As Bruce mentions, it's painless b/c it's mostly unintrusive and requires no user feedback and no personal data/input, etc.
Also, for me as a desktop application developer I'm already building an installer for my application to install it and its components. And, by executing a simple and free license agreement with Adobe you can distribute the latest Flash player runtime installer within your application's install. Thus, at the end of my install I kick off the Flash install.
And in this sense, the desktop app scenario, this distribution overhead is essentially "pain neutral" for an end user since they've already went through the pain of downloading and executing my app's installation. Kicking off the Flash installer is basically a non-issue.
Now, if you're delivering a web-only application you're in the same boat as everybody that deploys Flash content on their website: redirect the user to the Adobe "Get Flash Player" page if the user doesn't have Flash. And for 95% of the world, they've been OK with that pain and installed Flash.
So, I expect whatever the runtime for Apollo to be that similar numbers will install it and enjoy the next rev of Flash. And for us desktop developers, again executing the Flash Apollo runtime during our install will be a non-issue.
Maybe the most important piece of Bruce's post was that Adobe will be on the same release schedule or very close with all of the important platforms: Win, Mac, Linux. So, to me that's great since one of the reasons I've looked into cross-platform toolkits for the GUI is b/c I wanted to make sure guys on Linux could still use my app. But, the Flash runtime lagged behind in the past for Linux and I didn't like that.
Hopefully, Adobe will deliver.
They have EVERY motivation to deliver though and for the most part, via Flex,they're already there. So, Apollo will be pretty revolutionary in many ways but a LOT of it is already shippping. It's the rich desktop/system/file/low-level OS capabilities that will appeal to desktop developers. I mean, they won't cover every API of every OS and in some way I'm sure you'll still be sandboxed but at least they're trying to help get us down to a lower-level than just running in the browser.
BUT, what I do see coming after Apollo is out there is a way for serious applications to handle cross-platform system servies like threading, IPC, highly performant code, integration with legacy APIs, etc and that's where POCO comes into the picture. For me at least. I'm not a Linux guy, I'm not a Mac guy. I'm a Win32 C++ guy that has invested a LOT of time in reasearching cross-platform enabling my application on the system and the GUI levels.
So, I think some slick integration with Apollo would make POCO very very appealing to a lot guys doing non-trivial applications. On that note, Flash currently allows external application integration via a COM event interface e.g. ExternalInterface, FlashCall, fscommand, etc. How Apollo allows you to integrate with external applications will be of HUGE importance to me.
If they don't make it at least as functional as the current Flash mechanism, then I'm screwed and will have to use some other toolset for my GUI (probably wxWindows). But, the problem that does exist right now is there is no ExternalInterface capability on Mac or Linux. So, I'm not sure how to talk to external apps on those platforms except for maybe a socket server in my app that my local Flash app connects to.
At any rate, in terms of a great design environment for making a NICE UI and having it work on win/mac/linux, the Flash/Flex solution doesn't seem to have much of an equal. They just need to give us more runtime integration with system-level (C++,etc) applications on the desktop, maybe Apollo will do that. They're thinking of the web designers, web coders mainly but perhaps they will cover the desktop developers of the world too. I hope so.
But, I've put a lot of time recently into WPF too and since it can run on the mac via WPF/e I may actually give it a fair shake. It doesn't solve my Linux problem but Mono goes a long way to giving me a bridge one day. But, Mono may solve my need to resort to another language to do system level coding. But, that's down the road too. Their coverage of the .Net library isn't complete and if you use 3rd party .Net toolkits then some of them won't port even if you have source (some use direct API calls even on Windows b/c even .Net doesn't have full API coverage on its native platform yet).
So, for now, in the next 24 months or so I see a strong possibility of Apollo/Flash/Poco being a unique, powerful and most likely unmatched toolset combination in terms of power and platform support. It may become the best solution to many ISVs main problem: how to get my app running on the most platforms with the best ROI for my development effort without comprimising performance or usability and most importantly code-reuse(quality).
Besides, they let device builders use the Flash SDK to build embedded ports of the Flash runtime: cell phones, etc. So, I see a potentially really nice way to cover just about every frequency in the cross-platform spectrum: desktop OS - web - hand held/PDA/Smartphones - cell phones- etc using Apollo/Flash and POCO.
:) After looking and looking and reading a LOT, I don't see a better option. Of course, one of the interesting aspects of the Adobe acquistion of Flash/MM, is that whatever rich desktkop/web/embedded application development solution they deliver will eventually integrate nicely within the design workflow all designers already use: Illustrator, Photoshop, Fireworks, etc... That will have value too.
MS is just starting that process with the Expression tools. They're not that great yet.
BTW, in case anyone wants a possible bridge from Flash/Apollo into .Net/WPF and then onto BSD/Linux/Mac via Mono, there's a really nice SWF 2 XAML converter out there. It works great!!
http://www.mikeswanson.com/SWF2XAML/
