Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of agrieve@google.com designates
 209.85.214.175 as permitted sender)
MIME-Version: 1.0
Sender: agrieve@google.com
In-Reply-To: 
 <CAOBL_k5O_LAdRt7=nehGAq2CngK3PQLUdWttbhpMQEqFVGnj0g@mail.gmail.com>
References: 
 <CAOBL_k4JBvmqqK3D7fdALCBkjbfmoi4k++jT__wS3A0+pEBcSQ@mail.gmail.com>
 <CAM1AYQC=EG=z+sO4ni3ATpHkBJdHjV09yYipqm7LL4j-0QN46g@mail.gmail.com>
 <CAOBL_k7uS+i5zLDZT+YmcgG21Jzxg2SuXOJD5_zG6cn5p=zcaA@mail.gmail.com>
 <1144280150015843892@unknownmsgid>
 <CAOBL_k4rHKPrEE8tMz_7M58=mU_pO526P8+vk4D0ikV7QCOD2A@mail.gmail.com>
 <CAM1AYQCHSjVf5wQ7hSnir_LwmJSry2u4yNJhFGEEsONHtTzxCg@mail.gmail.com>
 <CABiQX1VJKkvGrxU3S5ybLsmfN7TudFQjYK+dbrHXu8riZgQvKQ@mail.gmail.com>
 <CAOBL_k4gu939MmXijTeyB5vg2prmUM2v_kyjFh_Zj7SzwKr6Cw@mail.gmail.com>
 <CAKP6k2tmdif5WZF6LUsrgjO1prhN4gxbC7YXgoyys2oFJ9=Fmg@mail.gmail.com>
 <CABiQX1U0vcjEjnqN6sb1TtM=CRrJSMfN9E06qHesYTgczRzV2A@mail.gmail.com>
 <04a201cd7706$49c0e5a0$dd42b0e0$@com>
 <CAOBL_k5O_LAdRt7=nehGAq2CngK3PQLUdWttbhpMQEqFVGnj0g@mail.gmail.com>
From: Andrew Grieve <agrieve@chromium.org>
Date: Fri, 10 Aug 2012 13:39:20 -0400
Message-ID: 
 <CABiQX1UJLt7j4gDBXfrpFDJQQCXO0jJqup+VBryKgAKh0-zA_Q@mail.gmail.com>
Subject: Re: [Android] loadUrl,
 input methods and making the web a thread-safe place
To: callback-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=f46d04447ea91eccf004c6ecd4b0

--f46d04447ea91eccf004c6ecd4b0
Content-Type: text/plain; charset=ISO-8859-1

Calling the private sendMessages() to eval JS doesn't have the same with
dismissing the keyboard, although it's quite possible that it will have
other bugs. If nothing else, I think it would be neat to add it as
togglable options so devs can try it out and see if it causes any bugs.
Another risk is that the added WEBKIT_DRAW that seems to be required will
make it slower than other options.

Instead of online/offline events, we could turn polling on when a textbox
is focused and turn it off when it blurs. This might increase typing lag
though... I'm also not how straight-forward it is to detect if the keyboard
is active due to ContentEditable.

Joe, I'm sure you looked at this when it came up with the 2.3 emulator, but
is there a way to detect that you're in the emulator?


On Fri, Aug 10, 2012 at 12:59 PM, Joe Bowser <bowserj@gmail.com> wrote:

> 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
> <jbondc@gdesolutions.com> 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:
> >
> https://github.com/android/platform_frameworks_base/blob/master/core/java/an
> > droid/webkit/WebViewCore.java#L1673
> >
> https://github.com/android/platform_external_webkit/blob/master/Source/WebKi
> > t/android/jni/WebCoreFrameBridge.cpp#L1489
> >
> > Yet google 'hides' this API? Anyone know why?
> >
> >
>

--f46d04447ea91eccf004c6ecd4b0--