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
