Alex, When I said Windows I meant Windows 7. I use it for rapid prototyping. Imagine having an audio DSP core written in C++, I can call C apis from the AIR windows native extensions that I wrapped with C, then I can call those same C apis in Android using Java JNI.
So I use Windows for rapid prototyping and testing of the Android mobile app that using the audio DSP core. My question since I am ignorant and really trying to find a real excuse to put some time into FlexJS, do you think it's possible somehow to do the same thing I am doing with testing the AIR app with say FlexJS(SWF) UI calling that surface API for the audio, then have the same API using Cordova for Android, plugging into it's Android plugin system, which the calls the native layer. This is what I am trying to figure out. If I could get this to work, then I would have a complete use case where I can use FlexJS to create the UI that is eventually translated to HTML/CSS for the Android cordova side. If this doesn't make sense, let me know. Mike On Wed, May 13, 2015 at 9:04 AM, Alex Harui <aha...@adobe.com> wrote: > > > On 5/13/15, 3:21 AM, "Michael Schmalle" <teotigraphix...@gmail.com> wrote: > > >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? > > Pretty much, just like AIR is a FP view with hooks down into native. > > Both claim you can call OS APIs and Windows DLLs. Here is a link to > Cordova’s info: > http://cordova.apache.org/docs/en/edge/guide_platforms_win8_plugin.md.html > http://cordova.apache.org/docs/en/3.3.0/guide_platforms_android_plugin.md.h > tml > > Now, I’ve never dealt with AIR Native Extensions directly myself, but IMO, > the challenge is: for some ANE, can you call same the native code from a > Cordova Plugin with the “same" API surface for both the ANE and Cordova > PlugIn, just as we create the same API surfaces for some other FlexJS > components by writing an AS version and a JS version. > > > > >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? > > First, I think a Falcon-based tool to cull the ASDoc annotations into a > data file still needs finishing. > I think the current MXMLC-based tool generates XML files that are XSLT’d > into HTML. I’m not convinced that the current HTML format is going to be > sufficient for FlexJS because the current format only knows about public > vs protected APIs. > > In FlexJS there are some components and APIs that you are unlikely to ever > use in building an application. The SingleLineBorderBead draws a > single-line border, but is composited into Container. If you are building > a new low-level component, you may need to know about > SingleLineBorderBead, but most folks are going to use Container. So my > temptation is to further annotate SingleLineBorderBead with a @advanced or > @lowlevel API so it can be filtered out by the doc viewer. > > Then, some other beads like the PromptTextBead have a public API for the > prompt text you’d put in your TextInput, but must also have a public API > like the strand setter so it can be used as a plug-in/bead on any > component. IMO, no need for most folks to view these low-level public > APIs either. > > In the current Flex SDK, APIs like these tend to be protected because we > use inheritance from base classes, but that isn’t the case in a > composition pattern. Other APIs might get excluded from the doc, but I > don’t think we should be hiding APIs either. Remember all the complaints > about private APIs in the current SDK? > > So, I’m thinking that XSLT is too hard for most folks to learn in order to > modify our doc viewer and an AIR app that serves as the doc viewer is > easier for most folks to work with and also serves as a nice example app. > I think it might also change the XML format output from the tool that > scans the source. > > Anyway, hope that’s more clear, those are my current thoughts. > > Thanks, > -Alex > > > > > > > > >>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 > >
