Thanks, Donna. I believe this feature will make Java Extension developer's life easier.
I added some comments and questions into the design document. Please take a look. Thanks! -ningxin > -----Original Message----- > From: Wu, Donna > Sent: Wednesday, May 6, 2015 5:37 PM > To: Hu, Ningxin; [email protected] > Subject: RE: [Crosswalk-dev] Intent to Implement: JS stub auto generation > for Java extension > > Hi, Ningxin: > Thanks for your questions. I considered them and discussed with team > members and it help me to make it more clear of this feature. I added some > materials on the design > doc( https://docs.google.com/a/intel.com/document/d/1lQZR- > MNCgM_9VYxmM46a3zPQoUeVXtQMVqKn2aCUwws/edit?usp=sharing ). > > And try to answer your questions here: > * What's the benefit of code generation at runtime? > - I think the main benefit is to simplify the extension developer, and maybe > can cut crosswalk size a little bit. > > * Where to find the design JS-Native messaging protocol? > - I try to write some info on this is the doc, and copy them here: > * Java to JavaScript > * expose object/function/constructor to JavaScript, these > object/function/consturctor can has its own methods/properties > * invoke JavaScript callbacks, including fulfilling JavaScript Promise > * JavaScript to Java > * invoke exposed native methods > * access exposed native properties > * create new instance on exposed constructors > Extension developer don't need to know message format, they even don't > there is a message. Just invoke provided interfaces to interact between Java > and JavaScript. > > Would it make debugging the JS code more difficult? > Yes, it may make difficult to debug the JS code. I considered that we may > expose interface to extension developer when the js-stub is generated, for > debug or add customized JavaScript code, such as: > XWalkExtensionClient.didGeneratedJsStub(String jsStub) > > * A function binding as example. > //Echo.java > public class Echo extends XWalkExtensionClient { > @JsAPI > public String prefix = "From Java: "; > > > public Echo(String extensionName, XWalkExtensionContentClient context) > { > super(extensionName, context); > } > @JsAPI > public String echo(String msg) { > return prefix + msg; > } > } > // set extension namspce as "xwalk.Echo" in manifest.json > > > //app.js - use the extension in App > xwalk.Echo.echo("Welcome to Crosswalk!") > // return "From Java: Welcome to Crosswalk!" > > > xwalk.Echo.prefix = "My echo prefix"; > xwalk.Echo.echo("Hello World!"); > // return "My echo prefix: Hello World!" > > > Thanks! > --Donna > -----Original Message----- > From: Hu, Ningxin > Sent: Saturday, April 25, 2015 4:51 AM > To: Wu, Donna; [email protected] > Subject: RE: [Crosswalk-dev] Intent to Implement: JS stub auto generation > for Java extension > > Hi Donna, > > > > > Description: > > Currently, Crosswalk adopts a message passing > > <https://github.com/crosswalk-project/crosswalk-website/wiki/Message- > > passing-extensions> mechanism which is quite flexible. It provides > > passing-extensions> passage > > passing APIs without define any message format, the message format and > > meaning are depend on the developer. In this background, Crosswalk > > Android extension consists three parts: > > Java source code: Standard Android/Java classes, packaged into a jar file. > > JavaScript wrapper: A JavaScript file which exposes the Java code to > > an app running on Crosswalk. > > Configuration: A JSON file to wire up the JavaScript wrapper with > > the Java classes. > > > > Developers need to provide these parts above for an extension. But, > > during the build-in extensions developing process, we found that many > > duplicated work needed to implement most common interactions > between > > JavaScript wrappers and the native code(Java on Android), such as > > method calling, property accessing, new instance creating from a > > constructor. So, in the later design of Crosswalk-iOS, object-oriented > > extension APIs > > <https://github.com/crosswalk-project/crosswalk-ios/wiki/Extensions> > > were introduced, the JavaScript wrapper can be auto generated by > > wrapping the common interacting process between JavaScript wrapper and > > the native client. > > Now, we want to evolve this new easier mechanism in Crosswalk Android > > extensions. > > It would always be good to optimize the developer experience on Crosswalk. > Binding code auto generation sounds right to me. Thanks for sending this > intent. > > > > > Affected component: > > Crosswalk Android extension, document > > > > Related feature: > > JIRA feature: https://crosswalk-project.org/jira/browse/XWALK-3969 > > <https://crosswalk-project.org/jira/browse/XWALK-3969> > > > > Target release: > > Crosswalk-15 > > > > Implementation details: > > 1. change least at current interfaces in the code, Add generation > > logic on XWalkExtensionClient.getJsApi at Java level JS stub is > > generated during Java extensions' registration process. > > What's the benefit of code generation at runtime? > > > 2. only Java extension will benefit on this feature 3. Will use Java > > annotation to expose native objects to JS 4. special JS helper will be > > injected to some namespace in each JS context to wrapper the message > > poster 5. limited message format between JS and native > > It sounds like you are going to define the JS-Native messaging protocol. > Where to find the design? > > > 6. developer cannot modify generated JS stub > > Would it make debugging the JS code more difficult? > > Can you elaborate more about your design? Say, use a function binding as > example. > > Thanks, > -ningxin > > > 7. coexists with current mechanism, it means JS stub generation > > feature is not forcible but a choice, and there is no need to change > > existing extensions. > > > > Regards! > > Donna Wu > > _______________________________________________ Crosswalk-dev mailing list [email protected] https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
