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]
<mailto:[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:
varnative_ =newxwalk.utils.NativeManager(extension);
varargs = {
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]
<mailto:[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
--
Samsung_Logo_for_Mail_Signature
Rafal Galka
Web Platform
Samsung R&D Institute Poland
Samsung Electronics
[email protected] <mailto:[email protected]>
_______________________________________________
Crosswalk-dev mailing list
[email protected]
<mailto:[email protected]>
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
_______________________________________________
Crosswalk-dev mailing list
[email protected]
<mailto:[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
