[Android] Evaulate Javascript and Threading

[Joe Bowser <bo...@gmail.com>]

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>)

Re: [Android] Evaulate Javascript and Threading

[Ian Clelland <ic...@chromium.org>]

On Thu, Nov 21, 2013 at 2:16 PM, Joe Bowser <bo...@gmail.com> wrote:

> On Thu, Nov 21, 2013 at 11:08 AM, Ian Clelland <ic...@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.
>

Nice... I wish I could have made it out to that :|


>
> > 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.
>
>
I guess we're asking the same question, then :)

I haven't seen anything that suggests that it will enable anything new,
that we can't already do.

If it doesn't, then I don't see any point in writing a separate code path
just for 4.4+ devices; it will just be more code.

On the other hand, if it *does* allow exciting new things, (and I'm hoping
it does,) then we should check it out :)


> Also, I think we should make the chrome debugger a preference to be
> turned on and off, but that's another thread.
>

We should have that thread, too.

Ian


>
> >>
> >> 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>)
> >
> >
>

Re: [Android] Evaulate Javascript and Threading

[Joe Bowser <bo...@gmail.com>]

On Thu, Nov 21, 2013 at 11:08 AM, Ian Clelland <ic...@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>)
>
>

Re: [Android] Evaulate Javascript and Threading

[Ian Clelland <ic...@chromium.org>]

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.

Certainly better than setting the WebView's document.location in any case.

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? Besides
being miles better aesthetically, does it give us any performance / reduce
odd quirks / anything that would make it worth the extra code complexity?

Ian

On Thu, Nov 21, 2013 at 1:49 PM, Joe Bowser <bo...@gmail.com> wrote:

> 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>)
>