Donna, Thanks for your efforts to explain the design and update the design doc!
It LGTM. Thanks, -ningxin > -----Original Message----- > From: Wu, Donna > Sent: Tuesday, May 12, 2015 3:00 PM > To: Hu, Ningxin; [email protected] > Subject: RE: [Crosswalk-dev] Intent to Implement: JS stub auto generation > for Java extension > > Hi, Ningxin: > I updated the doc according to your comments. Please help to review. > Thanks very much! > --Donna > > -----Original Message----- > From: Hu, Ningxin > Sent: Friday, May 8, 2015 5:21 PM > To: Wu, Donna; Hu, Ningxin; [email protected] > Subject: RE: [Crosswalk-dev] Intent to Implement: JS stub auto generation > for Java extension > > 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
