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 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
