Oppositely, it makes debugging easier. It can assure you that native code would be called once the API is called in JavaScript.
-----Original Message----- From: Crosswalk-dev [mailto:[email protected]] On Behalf Of Wu, Donna Sent: Wednesday, May 06, 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 _______________________________________________ Crosswalk-dev mailing list [email protected] https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
