On Thu, Nov 21, 2013 at 11:08 AM, Ian Clelland <iclell...@chromium.org> wrote:
> I've seen that show up in the API docs, and it looks like a much saner way
> to execute JS in the WebView -- almost akin to iOS's
> stringByEvaluatingJavascriptString, except that the result is *also*
> returned to the browser, and not into native code.
BTW: loadUrl("javascript://foo()") calls
stringByEvaluatingJavascriptString, and it's not thread-safe, which is
why it interferes with the UI thread and causes keyboards to disappear
and all that stuff. Apparently you can in theory take down a whole
device with it on iOS according to some couch guy I met at CascadiaJS
a week or so ago.
> The problem is obviously backwards-compatibility. If we can't use it on
> newer devices, then is there any point in having it in the code?
Yes! We can choose to use this the same way we choose other techniques
now. Just because we have to make it work with all the versions of
Cordova doesn't mean that we can't use the latest features. That's
why we have things like reflection. This is how we had things like
geolocation back when we supported Android 1.5 and 1.6.
> Besides
> being miles better aesthetically, does it give us any performance / reduce
> odd quirks / anything that would make it worth the extra code complexity?
>
That's the question that I'm asking.
Also, I think we should make the chrome debugger a preference to be
turned on and off, but that's another thread.
>>
>> So, this is 4.4 only, but should we start adding this to our bag of JS
>> tricks?
>>
>>
>> http://developer.android.com/reference/android/webkit/WebView.html#evaluateJavascript(java.lang.String,
>> android.webkit.ValueCallback<java.lang.String>)
>
>
