incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <>
Subject Re: [Android] loadUrl, input methods and making the web a thread-safe place
Date Fri, 10 Aug 2012 16:59:25 GMT
If you use WebView.loadUrl("javascript://foo()"), loadUrl strips the
javascript:// and runs stringByEvaluatingJavaScriptFromString.  I
believe the reason that Google hides and obfuscates this is because it
can do some weird things with the UI that is rendered on top of it.
(i.e. Text/Password Boxes, Check Boxes, Select Buttons, etc).

I personally like the online and offline event overloading, as long as
we can keep real online and offline events working properly.  We did
have polling as a backup in the past with the jsPrompt overloaded.
While addJavascriptInterface is cleaner, I can see more backlash from
our community for breaking the emulator.  That should be taken in
consideration, although this only breaks the Google 2.3 emulator, and
I don't think it affects Motorola or Sony emulators, which devs should
be downloading anyway (unless they have an unlimited budget).

On Fri, Aug 10, 2012 at 7:41 AM, Jonathan Bond-Caron
<> wrote:
> On Thu Aug 9 11:07 PM, Andrew Grieve wrote:
>> Going Native->JS
>> 1) Poll using 1) from above. (async)
>> 2) Poll using 2) from above. (async)
>> 3) Use loadUrl (breaks keyboard) (async)
>> 4) Trigger an online/offline event and have JS pull in value using a
>> sync
>> JS->Native option (async)
>> 5) Use a local server and hanging gets (async & complicated)
>> Notes:
>> -We currently use a combination of #1 and #5
>> -#3 is faster and simpler but breaks keyboard focus
> Out of curiosity, has anyone asked google why this is such a PITA?
> iOS has: UIWebView.stringByEvaluatingJavaScriptFromString
> The native java code binding to webkit already exists:
> droid/webkit/
> t/android/jni/WebCoreFrameBridge.cpp#L1489
> Yet google 'hides' this API? Anyone know why?

View raw message