This is for implementing the JS Shim... you write a function and inside it you call a native method. Promises works well for async functions and especially for implementing methods who themselves return promises (like many contemporary web apis)
Kenneth On Wed, May 13, 2015 at 3:52 PM Huo, Halton <[email protected]> wrote: > I’m kind of confused, it think whether to use Promise or callback is > really depend on the IDL definition. What my knowledge told me is to use > Promise as much as possible, but consider the historic reason, the callback > should be supported as well. > > Actually, what we were trying to do is adding support of IDL, XWALK-1946 > <https://crosswalk-project.org/jira/browse/XWALK-1946> is for Android, > but idea should be same as C++ extension. Donna is enhancing Android > extension by the idea of XWALK-3969 > <https://crosswalk-project.org/jira/browse/XWALK-3969> , IDL support will > base on that. > > > > Anyway, this is definitely nice to have enhancement for C++ extension. > > > > Thanks, > > Halton. > > *From:* Crosswalk-dev [mailto: > [email protected]] *On Behalf Of *Kenneth > Rohde Christiansen > *Sent:* Wednesday, May 13, 2015 7:53 PM > *To:* Rafal Galka; Crosswalk Dev List > *Subject:* Re: [Crosswalk-dev] Intent to implement: [TEC] Unified JS <-> > Native communication > > > > Promises are natively supported in V8, so it should not be any problem. > And they use microtasks so they should be fast. > > I think it would be fine to expend xwalk_extension_module > > > > Kenneth > > > > On Wed, May 13, 2015 at 12:59 PM Rafal Galka <[email protected]> wrote: > > Yeah, promises are catchy nowadays :) > But it's not native approach for current JavaScript (ES5) and it will be > another abstraction layer which introduces an overhead. > Promises are very good for big applications, where code > readability/maintainability is crucial. In our device APIs case, extension > JS code is simple data exchange layer and should be as fast as possible. > So I'm not convinced to introduce promises here. > > NativeController sounds better. > > I'm not sure we should extend "extension" interface. It's fully native > (V8) implementation which doesn't hold any state. NativeController need to > hold some additional data to operate. > If it's not a problem we can consider how to provide additional JS API > code to xwalk/extensions/renderer/xwalk_extension_module.cc > > > > > On 13.05.2015 11:45, Kenneth Rohde Christiansen wrote: > > Ah looks like a nice idea. > > I think you should make call() return a promise instead for handling the > result. It is a common new practise and it allows chaining > > > > I don't like the name Manager because Manager says almost nothing :-) it > is in line with Controller. Would it be possible to just add this > convenience to the extension object itself instead? > > > > On Wed, May 13, 2015 at 11:31 AM Rafal Galka <[email protected]> wrote: > > Hello, > > Few more words about NativeManager: > > Currently each module uses JavaScript " extension" interface directly, to > communicate with native code. > It's very simple interface which requires wrapper implementation to match > data between extension.postMessage() and extension.setMessageListener(). > NativeManager will provide common dispatching mechanism to simplify and > unify communication. > > Example of async call via NativeManager: > > *var *native_ = *new *xwalk.utils.NativeManager(extension); > > > > *var *args = { > > foo: 'bar' > > }; > > native_.call('some_native_command', args, *function*(result) { > > // handle async result from native > > }); > > From internal point of view NativeManager will automatically generate > callbackId, pass it to native and invoke proper callback on native response > (PostMessage()). > > NativeManager will provide also methods for sync calls and platform change > listeners. > > Best regards, > Rafal Galka > > > > On 13.05.2015 10:40, Kenneth Rohde Christiansen wrote: > > Could you give a bit more information. The auto JSON/string conversion > seems fine, but I don't understand the idea of NativeManager > > Kenneth > > > > On Tue, May 12, 2015 at 12:06 PM Rafal Galka <[email protected]> wrote: > > *Description:* > Each Tizen extension implements message/error handling between JS/C++ in > different ways. > It leads to inconsistency and code redundancy both in native code and JS. > Goal of this change is to provide set of tools/helpers to unify plugin > implementations. > > > *Affected component: *Tizen Extensions Crosswalk > > > *Related feature: *JIRA: > https://crosswalk-project.org/jira/browse/XWALK-4204 > > > * Target release: *N/A > > * Implementation details:* > - [C++] Unified message/result handlers with automatic string <-> JSON > conversion and error handling > - [JS] xwalk.utils.NativeManager component for sending messages and > receive sync/async replies > - Changes should be backward compatible > - One of the modules will be refactored in order to present improved > module structure > > -- > > [image: Samsung_Logo_for_Mail_Signature] > > Rafal Galka > Web Platform > Samsung R&D Institute Poland > Samsung Electronics > [email protected] > > _______________________________________________ > 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 > > > > _______________________________________________ > 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
