> If the extension would be registered to the native extension service > automatically, when is the right time point to do that? It is required that > the extension must be registered into XWalk ONLY when there is a valid web > content, in another word, the XWalkExtensionAndroid won't be plugged into > xwalk successfully before a XWalkView is created. > So my question here is, as a public API, how to provide a much decent way to > enforce the pre-condition of extension registration? E.g. provide > XWalkView.registerExtension as Shiliu said.
[halton] Here "register" means register extension to XWalkExtensionServer. Short answer for your questions is the XWalkExtensionInstance won't be created if there is no render. Let me explain how extension works in C++ side, that would help you understand. There are two classes standing for an extension, XWalkExtension and XWalkExtensionInstance. l XWalkExtension: represent the name, jsapi string, entry point l XWalkExtensionInstance: method of PostMessage, PostSyncMessage, where the really logic to filed in. XWalkExtensionServer will host list of XWalkExtension and initiated during browser process startup. These extensions will only send the XWalkExtension information(name, jsstring, etc) to render when a render starts. And XWalkExtensionInstance will be created on demand. Does it help you? > In addition, since the XWalkView already exposes addJavaScriptInterface and > evaluateJavaScript for Java<->JavaScript interoperability, as we know, > PhoneGap plugin is based on these 2 APIs, why do we introduce a new extension > system? Woo, this is a big question, it might not be right time to challenge this requirement now since this mechanism exists since M3. I'll try to answer it with several bullets: l Crosswalk extensions support different platform and language. Offer Java extension on Android will give developer unified interface as much as possible. l evaluateJavaScript is available since API level 19(Android 4.4), without it there is one-way interoperation, which means only JS -> Java is supported. Since Crosswalk target level 14(4.0+), this should be a problem. Thanks, Halton. From: Min, Hongbo Sent: Friday, July 11, 2014 10:09 AM To: Wang, Shiliu; Huo, Halton Cc: crosswalk-dev@lists.crosswalk-project.org Subject: RE: [Crosswalk-dev] Intent to Implement - Pluggable extensions for embedding API Hi, Halton If the extension would be registered to the native extension service automatically, when is the right time point to do that? It is required that the extension must be registered into XWalk ONLY when there is a valid web content, in another word, the XWalkExtensionAndroid won't be plugged into xwalk successfully before a XWalkView is created. So my question here is, as a public API, how to provide a much decent way to enforce the pre-condition of extension registration? E.g. provide XWalkView.registerExtension as Shiliu said. In addition, since the XWalkView already exposes addJavaScriptInterface and evaluateJavaScript for Java<->JavaScript interoperability, as we know, PhoneGap plugin is based on these 2 APIs, why do we introduce a new extension system? Thanks...Hongbo From: Crosswalk-dev [mailto:crosswalk-dev-boun...@lists.crosswalk-project.org] On Behalf Of Wang, Shiliu Sent: Thursday, July 10, 2014 4:53 PM To: Huo, Halton; crosswalk-dev@lists.crosswalk-project.org<mailto:crosswalk-dev@lists.crosswalk-project.org> Subject: Re: [Crosswalk-dev] Intent to Implement - Pluggable extensions for embedding API Thanks for the explanation. LGTM. Thanks, Shiliu. From: Huo, Halton Sent: Wednesday, July 9, 2014 4:27 PM To: Wang, Shiliu; crosswalk-dev@lists.crosswalk-project.org<mailto:crosswalk-dev@lists.crosswalk-project.org> Subject: RE: [Crosswalk-dev] Intent to Implement - Pluggable extensions for embedding API No, if an extension is created like new EchoExtension, the extension will be registered to the native(C++) extension service automatically, this is already done in XWalkExtensionAndroid and JNI code as well. Thanks, Halton. From: Wang, Shiliu Sent: Wednesday, July 09, 2014 3:37 PM To: Huo, Halton; crosswalk-dev@lists.crosswalk-project.org<mailto:crosswalk-dev@lists.crosswalk-project.org> Subject: RE: [Crosswalk-dev] Intent to Implement - Pluggable extensions for embedding API Is there any API to register Extension? Thanks, Shiliu. From: Crosswalk-dev [mailto:crosswalk-dev-boun...@lists.crosswalk-project.org] On Behalf Of Huo, Halton Sent: Wednesday, July 9, 2014 9:21 AM To: crosswalk-dev@lists.crosswalk-project.org<mailto:crosswalk-dev@lists.crosswalk-project.org> Subject: [Crosswalk-dev] Intent to Implement - Pluggable extensions for embedding API Description: This feature is Android only. So far, pluggable android extension[1] is supported for runtime mode(shared or embedded). After embedding API[2] supporting is added in, there is clear need to add this support pluggable extension support for embedding API as well. Affected component: XWalk embedding API XWalk embedding API document and test case Related feature: https://crosswalk-project.org/jira/browse/XWALK-1052 Target release: Crosswalk8 Implementation details: Android extension is rely on org.xwalk.core.internal.extensions.XWalkExtensionAndroid to bridge all Java instances via C++ extension instances to JS side and vice versa. XWalkExtension will be exposed in Embedding API public XWalkExtensionAndroid(String name, String jsApi) public XWalkExtensionAndroid(String name, String jsApi, String[] entryPoints) protected void destroyExtension() public void postMessage(int instanceID, String message) public void broadcastMessage(String message) public abstract void onMessage(int instanceID, String message) public abstract String onSyncMessage(int instanceID, String message) Internally, it will call org.xwalk.core.internal.extensions.XWalkExtensionAndroid. Difference with runtime extensions: * The life cycle related APIs(onPause, onResume, etc) are not provided. This is mainly because the responsibility of life cycle handling for embedding API and runtime are different For embedding API. Embedder(embedding API) own the extension instance reference and decide what to do, while runtime layer. While for runtime, extension reference is handled inside runtime, which means hidden for runtime user, so we need offer the life cycle APIs. * There will be no helper like make_apk.py for embedding API, embeedder is responsible to add extension jar to workspace. The document for that. * Despite the life cycle API, the extension code for embedding and runtime should very similar but not compatible because the based interface are different. If extension developer want to support both embedding API and runtime layer, we might offer a tooling or HOWTO. References: [1] https://crosswalk-project.org/#documentation/android_extensions [2] https://crosswalk-project.org/#documentation/embedding_crosswalk Thanks, Halton.
_______________________________________________ Crosswalk-dev mailing list Crosswalk-dev@lists.crosswalk-project.org https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
