Well I have absolutely NO experience with Cordova, I think years ago I set it up once but that is the extent of my dealings. From what I gather it's an HTML view with hooks down to native correct?
> mobile/desktop plugin workflow for FlexJS Can you elaborate on this? I don't understand what context a plugin is. ASDoc So when you say another form of asdoc tool, what do you actually mean? I am confused about the AIR application, what would it's purpose be? Can you point to specific instances of differences you refer to when talking about app verses component dev APIs? Just understand I am getting back into this and really haven't even got FlexJS to compile yet. I haven't had the ability to muck around the as/js code yet either. I have watched some stuff from Om about the strands and beads(read the scant docs), I get the whole composition thing but don't get what you are saying about an asdoc AIR and it's difference from a command lin tool. Mike >It would have been icing on the cake if I wasn't using native extensions >for dll on Windows and Java on Android for these apps, then I could really >test FlexJS. That is also why one thing I might work on is a Web Audio >extensions lib with FlexJS, that is my dream. Besides working on the compiler, I would love it if you created some sort of mobile/desktop plugin workflow for FlexJS. Just like FlexJS currently generates a SWF for testing and potential deployment then cross-compiles to HTML/JS/CSS, mobile applications for FlexJS should be able to use AIR to run the SWF for testing and cross-compile and generate apps via the Cordova/PhoneGap process. We have already proven that the Cordova process works for FlexJS for mobile apps that don’t have native extensions. There is a cordova-build.xml file in the flex-asjs root that will crank the FalconJX output into a Cordova app. I’ve used it on DataBindingTest, I think Peter has also used it on GoogleMaps. FWIW, another thing I’ve been thinking about is a different sort of ASDoc tool. Now that the classes in FlexJS are made up of small composited pieces, the public API seems like it needs sub-division: public APIs that application developers are likely to use, and public APIs that the developers of the small pieces are likely to use. In my mind it would be an AIR app and we’d add more asdoc annotations to APIs to help differentiate them, but I could be totally wrong about that. Food for thought, -Alex
