[Thali-talk] Confusing over the Cordova variable

Yaron Goland yarong at microsoft.com
Thu Jun 25 01:27:41 EDT 2015


Taking a look at story_0_sree I don't see you using PouchDB at all in the webview. Which from what I remember of the architecture of the postcard app makes sense. So you must be getting this error when you use PouchDB inside of jxcore.
Which means that PouchDB's utils.isCordova function is incorrectly detecting you as running inside of the Cordova Webview. Which would explain why fireWindowEvent isn't working.
Now the isCordova function is defined here<https://github.com/pouchdb/pouchdb/blob/3a8e0541af8a22cffd71fe9cda9800d3f1b583e4/lib/utils.js#L106> and we can see that all it does is see if there is a global variable with the name 'cordova'. And if there is then it assumes that you are in a Cordova webview.
I suppose one could quibble but in searching through the Internet most folks seem to use some variant of checking for the cordova variable.
Which means that we need JXCore to NOT use the cordova variable name at all, ever. Because when they do use it they will confuse libraries like PouchDB that will think they are running in a Cordova WebView.
               Thanks,
                              Yaron


From: Sreejumon Purayil
Sent: Wednesday, June 24, 2015 9:55 PM
To: Yaron Goland; thali-talk at thaliproject.org
Subject: RE: Confusing over the Cordova variable

Thanks Yaron for the details.  Any thoughts on this issue? https://github.com/jxcore/jxcore-cordova/issues/41

From: Yaron Goland
Sent: Wednesday, June 24, 2015 5:42 PM
To: Sreejumon Purayil; thali-talk at thaliproject.org<mailto:thali-talk at thaliproject.org>
Subject: Confusing over the Cordova variable

Note: This is to the public alias

Sreejumon asked me a question I thought was worth explaining to the general gathered. The question was - what is this about a Cordova variable in JXCore?

To understand what's going on you have to understand the way JXCore and Cordova work together. This is the architecture:


Cordova Webview <----->Cordova Bridge <----->Cordova Native Plugin
                                                             <-- -->JXCore Plugin for Cordova<-- -->JXCore<-- -->JXCore Native Plugin

So JXCore wrote an API that you can call in the webview. It looks like jxcore('myFunction').call(some, args, callback);
Inside of JXCore you then write something like cordova('myFunction').registerAsync(function (some, args, callback) {});
So the idea is that when the code in the webview calls jxcore('myFunction').call(some, args, callback) this will cause some, args and the callback to be marshalled and sent over (as a string) the Cordova Bridge to the JXCore Plugin for Cordova who will then manifest it inside of JXCore where it will call the function that was registered with cordova('myFunction').registerAsync.
Now this is all pretty straight forward and makes sense, at least to me.
What happens next is what we were talking about.
Because let's say that what you want to do is make a call between JXCore and a JXCore Native Plugin? In that case the way you do it is that in JXCore you call cordova('myNativeFunction').callNative(more, args, callback);
What happens next really depends on what language the native plugin is written in but, for example, with Java on Android there is a file called JXcoreExtension.java and inside of it you will see calls like:
jxcore.RegisterMethod("myNativeFunction", new JXcoreCallback() {
   @Override
   Public void Receiver(ArrayList<Object> params, String callbackId) {
      ...
  }
});
So this is all well and good but it does cause a problem.
Why is callNative on the cordova object?
Look up... see callNative? See how it's defined on the cordova object?
Why?!?!?!
The answer is.... Because. In truth callNative has nothing to do with Cordova. Nada. Zip. Nichevo. Rien.
And this confused folks because it makes it look like you have to use cordova in order to make calls between JXCore and a JXCore native plugin. But of course, that is not true.
So at some point JXCore is going to fix this and move callNative to a different object so everyone isn't so confused.
            Thanks,
                        Yaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist10.pair.net/pipermail/thali-talk/attachments/20150625/f56237df/attachment.html>


More information about the Thali-talk mailing list