Printable View
I am near the finish-line on my first AS3 (and OOP) project.
I have never user Flex before, or Apollo. I've just installed both.
Is there any better resource for starting off with Flex?
Is there any easy way to port an application from plain AS3 classes to Apollo (p.s. the application I'm building has it's own custom windows engine, so it would either be put within a single Apollo themeless window or would have to cut out my engine and merge the application in the Apollo environment).
Ideas?
Other than as an interesting project, I don't understand why the choice of Apollo at this time (as opposed to a stable commercial wrapper)? Not only is it in alpha...it's not expected to be a viable, stable solution until roughly end of '07 beginning of '08.
Have you created (and more importantly installed) any Apollo apps? Right now a ton of features are not implemented yet and a lot of what is already expected will become final is always subject to change (normal for any software in development).
If not...this is the install screen for an alpha creation:
http://www.flex-fanatic.com/index2.php?cid=3&did=195
Now while I may be willing to overlook that as a developer I surely would be concerned as an uninformed end user. We don't expect the next build of Apollo for a few months (and I have no clue if that screen will be different or not until final...who knows). If your creation is a collection of AS3 classes I would think compiling to SWF (maybe this is where Flex would be useful) and wrapping with a commercial wrapper for the desktop this year (Zinc, SWF Studio, SWFKit Pro, etc) would make more sense seeing as you would have a more robust command set (not to mention full Vista compatability).
Again..if all of this is simply to become familiar with Apollo and Flex or simply because cost effectiveness is a prevailing factor in your project (Apollo is free...commercial wrappers are not)...disregard what I've said. The Adobe Labs website has tons of info (and examples) on integrating AS3 with both and just about every known Flex blogger carries snippets and examples of usage with Apollo :)
Thanks for the reply.
Basically there is no commercial purpose in porting a web app to Apollo right at the moment. What I want to do is check the level of cross-development integration between plain flash and Flex/Apollo. (I have been developing LAMP applications for a while now, a few of which with Flash GUI, and I am used to hand-making EVERYTHING from scratch).
The idea of having to adapt to a framework drives me nuts (and I already have to cope with budget-thinking on the server-side), so I would prefer the third party tools, but on the other side, I have tried the MultiDMedia products a while back, and it was a very unsatisfactory experience.
Mainly due to lack of performance and stability in the Flash-to-container communication (a bit like AS-to-JS... you know, loops with sequences of calls, etc..).
There is definetly a third hand on this: I am at the end of my web development career, as I want to soon start a new one as product designer (as I studied for), so I don't want to invest too much time learning new skills that (though interesting) won't give me any stars.
Yo
The MultiDmedia products have improved and it much more stable than it used to be. It no longer uses ugly callbacks.
Seeing as you are a LAMPer, I can see your interest in Apollo (since it plans to target that OS whereas it's not as prevalent with other wrappers or secondary to OSX or WINOS if it is supported). The rub there is the alpha release of Apollo doesn't yet have the Linux support tapped in yet...although I do suspect that will not be the case with the next build (key word...suspect) :)
Basically Apollo would mean raising the perceived quality of the product of the firm.
It wouldn't look like a dynamic website anymore. It would be an app you install. A real app. With the original Adobe brand behind it.
Nobody from outside the industry would know Zinc for example!
You show the client it's Adobe platform, they will stay quiet!
Basically it will mean you can push the bill farther up, sensitively (I suppose).
This will make the *real* programmers (read Informatics Engineers) quite angry (as they are already undercharged).
It's a difficult world..