You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Joe Bowser <bo...@gmail.com> on 2012/07/27 00:44:35 UTC
[Android] loadUrl, input methods and making the web a thread-safe place
Hey
So, on ICS and greater, it turns out that the routing table is
fragile, so fragile in fact that you can't connect to localhost if you
don't have an internet connection of some sort. This is a problem for
us on Android because we need to connect to localhost to use the
bridge and communicate with the Callback Server so that we can get the
callbacks. In my opinion, this is the straw that broke the camel's
back, and this bug is far worse than the reason we moved to the
CallbackServer to begin with.
First, some history:
Back in OSCON 2010, we talked to Justin at Google about how they could
help PhoneGap, and he mentioned that we shouldn't be using loadUrl for
sending Javascript over because it is linked to the Handler and can
interrupt the UI thread. He suggested a callback server, which Bryce
implemented. The callback server and sending commands over the prompt
happened at roughly the same six months, when Gingerbread was being
rolled out.
Now, in 2012, we are starting to have issues with the Callback Server
approach, and we should examine why we did this in the first place.
The test case for it is simple:
1. Put an input field on the accelerometer page on Mobile-Spec
2. Turn on Accelerometer
3. Try to type something
What it will do is it will update the accelerometer values as you type
text. This is awesome, but I'm wondering if anyone is actually going
to use this use case, and if it's OK to break this functionality in
exchange for performance and stability. We currently have the ability
to use loadUrl("javascript:foo()") again by checking whether we have
focus on a text field, which we can use with HitTestResult, which
inspect's webkit's cursor. This would fix the bug that I call
"Airplane, Airplane Crash" where you can crash our bridge by switching
your phone in and out of airplane mode over and over again. I have a
test repository here, and it passes most of Mobile Spec. It would be
nice to be able to have this as a configurable option to start.
https://github.com/infil00p/callback-android/tree/testbridge
Any thoughts?
Joe
Re: [Android] loadUrl, input methods and making the web a thread-safe place
Posted by Joe Bowser <bo...@gmail.com>.
It's totally "Do as I say, not as I do". That being said, there is a
real problem when you start using loadUrl without checking where your
WebKit cursor is.
On Thu, Jul 26, 2012 at 4:06 PM, Anis KADRI <an...@gmail.com> wrote:
> Just one thought:
>
> If google thinks it's a bad idea to use loadUrl to execute javascript they
> should probably start by removing that exact thing from their docs [1].
>
> [1]
> http://developer.android.com/reference/android/webkit/WebView.html#addJavascriptInterface(java.lang.Object,
> java.lang.String)
>
> On Thu, Jul 26, 2012 at 3:44 PM, Joe Bowser <bo...@gmail.com> wrote:
>
>> Hey
>>
>> So, on ICS and greater, it turns out that the routing table is
>> fragile, so fragile in fact that you can't connect to localhost if you
>> don't have an internet connection of some sort. This is a problem for
>> us on Android because we need to connect to localhost to use the
>> bridge and communicate with the Callback Server so that we can get the
>> callbacks. In my opinion, this is the straw that broke the camel's
>> back, and this bug is far worse than the reason we moved to the
>> CallbackServer to begin with.
>>
>> First, some history:
>>
>> Back in OSCON 2010, we talked to Justin at Google about how they could
>> help PhoneGap, and he mentioned that we shouldn't be using loadUrl for
>> sending Javascript over because it is linked to the Handler and can
>> interrupt the UI thread. He suggested a callback server, which Bryce
>> implemented. The callback server and sending commands over the prompt
>> happened at roughly the same six months, when Gingerbread was being
>> rolled out.
>>
>> Now, in 2012, we are starting to have issues with the Callback Server
>> approach, and we should examine why we did this in the first place.
>> The test case for it is simple:
>>
>> 1. Put an input field on the accelerometer page on Mobile-Spec
>> 2. Turn on Accelerometer
>> 3. Try to type something
>>
>> What it will do is it will update the accelerometer values as you type
>> text. This is awesome, but I'm wondering if anyone is actually going
>> to use this use case, and if it's OK to break this functionality in
>> exchange for performance and stability. We currently have the ability
>> to use loadUrl("javascript:foo()") again by checking whether we have
>> focus on a text field, which we can use with HitTestResult, which
>> inspect's webkit's cursor. This would fix the bug that I call
>> "Airplane, Airplane Crash" where you can crash our bridge by switching
>> your phone in and out of airplane mode over and over again. I have a
>> test repository here, and it passes most of Mobile Spec. It would be
>> nice to be able to have this as a configurable option to start.
>>
>> https://github.com/infil00p/callback-android/tree/testbridge
>>
>> Any thoughts?
>>
>> Joe
>>
Re: [Android] loadUrl, input methods and making the web a thread-safe place
Posted by Anis KADRI <an...@gmail.com>.
Just one thought:
If google thinks it's a bad idea to use loadUrl to execute javascript they
should probably start by removing that exact thing from their docs [1].
[1]
http://developer.android.com/reference/android/webkit/WebView.html#addJavascriptInterface(java.lang.Object,
java.lang.String)
On Thu, Jul 26, 2012 at 3:44 PM, Joe Bowser <bo...@gmail.com> wrote:
> Hey
>
> So, on ICS and greater, it turns out that the routing table is
> fragile, so fragile in fact that you can't connect to localhost if you
> don't have an internet connection of some sort. This is a problem for
> us on Android because we need to connect to localhost to use the
> bridge and communicate with the Callback Server so that we can get the
> callbacks. In my opinion, this is the straw that broke the camel's
> back, and this bug is far worse than the reason we moved to the
> CallbackServer to begin with.
>
> First, some history:
>
> Back in OSCON 2010, we talked to Justin at Google about how they could
> help PhoneGap, and he mentioned that we shouldn't be using loadUrl for
> sending Javascript over because it is linked to the Handler and can
> interrupt the UI thread. He suggested a callback server, which Bryce
> implemented. The callback server and sending commands over the prompt
> happened at roughly the same six months, when Gingerbread was being
> rolled out.
>
> Now, in 2012, we are starting to have issues with the Callback Server
> approach, and we should examine why we did this in the first place.
> The test case for it is simple:
>
> 1. Put an input field on the accelerometer page on Mobile-Spec
> 2. Turn on Accelerometer
> 3. Try to type something
>
> What it will do is it will update the accelerometer values as you type
> text. This is awesome, but I'm wondering if anyone is actually going
> to use this use case, and if it's OK to break this functionality in
> exchange for performance and stability. We currently have the ability
> to use loadUrl("javascript:foo()") again by checking whether we have
> focus on a text field, which we can use with HitTestResult, which
> inspect's webkit's cursor. This would fix the bug that I call
> "Airplane, Airplane Crash" where you can crash our bridge by switching
> your phone in and out of airplane mode over and over again. I have a
> test repository here, and it passes most of Mobile Spec. It would be
> nice to be able to have this as a configurable option to start.
>
> https://github.com/infil00p/callback-android/tree/testbridge
>
> Any thoughts?
>
> Joe
>
Re: [Android] loadUrl, input methods and making the web a thread-safe place
Posted by Andrew Grieve <ag...@chromium.org>.
Idea for how to do this without messing up regular online/offline events:
1. Have JS addEventListenter() using the capture phase
2. Poll for messages in the handler.
3. If there is a message, stopPropagation on the event.
4. Reset the state of onLine (canceling propagation of this event as well)
On Thu, Aug 9, 2012 at 5:47 PM, Joe Bowser <bo...@gmail.com> wrote:
> Actually, that would work better than other bridges so far. How would
> this work with the supported online/offline event, and would this
> affect XHRs and other network behaviour that is happening on an
> interval?
>
>
> On Thu, Aug 9, 2012 at 2:15 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
> > How about this for a possible work-around:
> >
> > When the keyboard is up, use WebView.setNetworkAvailable() to trigger an
> > online/offline event in the JS, and then have the JS poll on
> online/offline
> > events.
> >
> > Demo of this working here:
> > https://github.com/agrieve/incubator-cordova-android/commits/testbridge
> >
> > Andrew
> >
> >
> > On Tue, Aug 7, 2012 at 10:09 AM, Simon MacDonald
> > <si...@gmail.com>wrote:
> >
> >> We need to do something as it would not be good if we missed an
> >> online/offline event while the user was typing in a text field.
> >>
> >> Simon Mac Donald
> >> http://hi.im/simonmacdonald
> >>
> >>
> >> On Wed, Aug 1, 2012 at 7:10 PM, Joe Bowser <bo...@gmail.com> wrote:
> >> > I like the latter. It really should be up to the developer of the
> >> > plugin whether they're discardable or not.
> >> >
> >> > So, would this make sense to be an option in 2.1?
> >> >
> >> > On Thu, Jul 26, 2012 at 10:51 PM, Jesse MacFadyen
> >> > <pu...@gmail.com> wrote:
> >> >> We could add a lifecycle event, just like pause/resume so each plugin
> >> >> could react accordingly.
> >> >> ie FileTransfer would discard progress events, but queue the complete
> >> event.
> >> >>
> >> >> As an alternative, plugin results could have a property which
> >> >> indicates if they are discardable.
> >> >>
> >> >> Cheers,
> >> >> Jesse
> >> >>
> >> >>
> >> >>
> >> >> On 2012-07-26, at 10:10 PM, Joe Bowser <bo...@gmail.com> wrote:
> >> >>
> >> >>> It depends. For accelerometer, it may not make sense since it would
> >> >>> just plow a series of events over and over again, and we only care
> >> >>> about the current acceleration, which would be fired on the
> interval.
> >> >>> Basically, we still have the same problem, except that we break the
> >> >>> native callout instead of the keyboard, which is the lesser of the
> two
> >> >>> evils. If someone wants both to work, we'll have to either do
> polling
> >> >>> or go back to the Callback Server.
> >> >>>
> >> >>> But yeah, it would be great if we can send something from Java back
> to
> >> >>> Javascript without it blocking.
> >> >>>
> >> >>> On Thu, Jul 26, 2012 at 7:56 PM, Simon MacDonald
> >> >>> <si...@gmail.com> wrote:
> >> >>>> Okay, I'm working off 4 hours of sleep so if what I say is not
> >> coherent
> >> >>>> bear with me. I looked over the code you posted up and it looks
> like
> >> if you
> >> >>>> are in a text field the request to loadUrl is lost. Does it make
> >> sense to
> >> >>>> queue up these requests and process them once the user is outside
> of
> >> the
> >> >>>> text field?
> >> >>>>
> >> >>>> Simon Mac Donald
> >> >>>> http://hi.im/simonmacdonald
> >> >>>>
> >> >>>>
> >> >>>> On Thu, Jul 26, 2012 at 6:44 PM, Joe Bowser <bo...@gmail.com>
> >> wrote:
> >> >>>>
> >> >>>>> Hey
> >> >>>>>
> >> >>>>> So, on ICS and greater, it turns out that the routing table is
> >> >>>>> fragile, so fragile in fact that you can't connect to localhost if
> >> you
> >> >>>>> don't have an internet connection of some sort. This is a problem
> >> for
> >> >>>>> us on Android because we need to connect to localhost to use the
> >> >>>>> bridge and communicate with the Callback Server so that we can get
> >> the
> >> >>>>> callbacks. In my opinion, this is the straw that broke the
> camel's
> >> >>>>> back, and this bug is far worse than the reason we moved to the
> >> >>>>> CallbackServer to begin with.
> >> >>>>>
> >> >>>>> First, some history:
> >> >>>>>
> >> >>>>> Back in OSCON 2010, we talked to Justin at Google about how they
> >> could
> >> >>>>> help PhoneGap, and he mentioned that we shouldn't be using loadUrl
> >> for
> >> >>>>> sending Javascript over because it is linked to the Handler and
> can
> >> >>>>> interrupt the UI thread. He suggested a callback server, which
> Bryce
> >> >>>>> implemented. The callback server and sending commands over the
> >> prompt
> >> >>>>> happened at roughly the same six months, when Gingerbread was
> being
> >> >>>>> rolled out.
> >> >>>>>
> >> >>>>> Now, in 2012, we are starting to have issues with the Callback
> Server
> >> >>>>> approach, and we should examine why we did this in the first
> place.
> >> >>>>> The test case for it is simple:
> >> >>>>>
> >> >>>>> 1. Put an input field on the accelerometer page on Mobile-Spec
> >> >>>>> 2. Turn on Accelerometer
> >> >>>>> 3. Try to type something
> >> >>>>>
> >> >>>>> What it will do is it will update the accelerometer values as you
> >> type
> >> >>>>> text. This is awesome, but I'm wondering if anyone is actually
> going
> >> >>>>> to use this use case, and if it's OK to break this functionality
> in
> >> >>>>> exchange for performance and stability. We currently have the
> >> ability
> >> >>>>> to use loadUrl("javascript:foo()") again by checking whether we
> have
> >> >>>>> focus on a text field, which we can use with HitTestResult, which
> >> >>>>> inspect's webkit's cursor. This would fix the bug that I call
> >> >>>>> "Airplane, Airplane Crash" where you can crash our bridge by
> >> switching
> >> >>>>> your phone in and out of airplane mode over and over again. I
> have a
> >> >>>>> test repository here, and it passes most of Mobile Spec. It
> would be
> >> >>>>> nice to be able to have this as a configurable option to start.
> >> >>>>>
> >> >>>>> https://github.com/infil00p/callback-android/tree/testbridge
> >> >>>>>
> >> >>>>> Any thoughts?
> >> >>>>>
> >> >>>>> Joe
> >> >>>>>
> >>
>
Re: [Android] loadUrl, input methods and making the web a thread-safe place
Posted by Andrew Grieve <ag...@chromium.org>.
I know that the team didn't want to provide s synchronous API for
stringByEvaluatingJavaScriptFromString because the performance would be
quite bad due to having to block on the WebCore thread. Why there is not
async API, such as exposing the one you point out, I don't know :(.
That said, we are able to use the API you pointed out via reflection, and
we should consider this as an option as well.
The follow code does seem to work on Android 2.2 and 4.1:
https://github.com/agrieve/incubator-cordova-android/commit/2400a63e8a64ab5e1d1de7bf30203eaed394781f
If we go this route, we can still fall back on another technique if a
future android version changes the private API it relies on.
On Fri, Aug 10, 2012 at 10: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_frameworks_base/blob/master/core/java/android/webkit/WebViewCore.java#L1673>
>
> https://github.com/android/platform_external_webkit/blob/master/Source/WebKi
> t/android/jni/WebCoreFrameBridge.cpp#L1489<https://github.com/android/platform_external_webkit/blob/master/Source/WebKit/android/jni/WebCoreFrameBridge.cpp#L1489>
>
> Yet google 'hides' this API? Anyone know why?
>
>
>
Re: [Android] loadUrl, input methods and making the web a thread-safe place
Posted by Andrew Grieve <ag...@chromium.org>.
I've been updating status on this bug:
https://issues.apache.org/jira/browse/CB-638
At least another week worth of work to do to make the options stable enough
to switch over to them.
On Mon, Aug 27, 2012 at 12:16 PM, Filip Maj <fi...@adobe.com> wrote:
> Did the options get implemented? Coming back to the code after a month it
> looks like you guys overhauled a lot of stuff :)
>
> On 8/13/12 6:22 PM, "Joe Bowser" <bo...@gmail.com> wrote:
>
> >On Fri, Aug 10, 2012 at 10:39 AM, Andrew Grieve <ag...@chromium.org>
> >wrote:
> >> 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?
> >>
> >
> >That's not as simple as it sounds, we have to check which emulator its
> >running. I'm sure the emulator has device information in it and we
> >can grab that using our existing device API. Of course, I didn't do
> >this because there may be that crappy knock-off phone out there that
> >also runs JSC as its Javascript Engine. We created the fix with the
> >assumption that there were these Chinese OEMs who may be creating
> >cheap, crappy phones which may be using JSC instead of V8 for their
> >Javascript Engines and that these OEMs would use Gingerbread.
> >
> >BTW: We haven't seen a real phone running 2.3 with JSC as its
> >Javascript Engine. It is plausible, but it would fail the Google
> >Tests.
> >
> >Joe
>
>
Re: [Android] loadUrl, input methods and making the web a
thread-safe place
Posted by Filip Maj <fi...@adobe.com>.
Did the options get implemented? Coming back to the code after a month it
looks like you guys overhauled a lot of stuff :)
On 8/13/12 6:22 PM, "Joe Bowser" <bo...@gmail.com> wrote:
>On Fri, Aug 10, 2012 at 10:39 AM, Andrew Grieve <ag...@chromium.org>
>wrote:
>> 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?
>>
>
>That's not as simple as it sounds, we have to check which emulator its
>running. I'm sure the emulator has device information in it and we
>can grab that using our existing device API. Of course, I didn't do
>this because there may be that crappy knock-off phone out there that
>also runs JSC as its Javascript Engine. We created the fix with the
>assumption that there were these Chinese OEMs who may be creating
>cheap, crappy phones which may be using JSC instead of V8 for their
>Javascript Engines and that these OEMs would use Gingerbread.
>
>BTW: We haven't seen a real phone running 2.3 with JSC as its
>Javascript Engine. It is plausible, but it would fail the Google
>Tests.
>
>Joe
Re: [Android] loadUrl, input methods and making the web a thread-safe place
Posted by Joe Bowser <bo...@gmail.com>.
On Fri, Aug 10, 2012 at 10:39 AM, Andrew Grieve <ag...@chromium.org> wrote:
> 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?
>
That's not as simple as it sounds, we have to check which emulator its
running. I'm sure the emulator has device information in it and we
can grab that using our existing device API. Of course, I didn't do
this because there may be that crappy knock-off phone out there that
also runs JSC as its Javascript Engine. We created the fix with the
assumption that there were these Chinese OEMs who may be creating
cheap, crappy phones which may be using JSC instead of V8 for their
Javascript Engines and that these OEMs would use Gingerbread.
BTW: We haven't seen a real phone running 2.3 with JSC as its
Javascript Engine. It is plausible, but it would fail the Google
Tests.
Joe
Re: [Android] loadUrl, input methods and making the web a thread-safe place
Posted by Andrew Grieve <ag...@chromium.org>.
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 <bo...@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
> <jb...@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?
> >
> >
>
Re: [Android] loadUrl, input methods and making the web a thread-safe place
Posted by Joe Bowser <bo...@gmail.com>.
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
<jb...@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?
>
>
RE: [Android] loadUrl, input methods and making the web a thread-safe place
Posted by Jonathan Bond-Caron <jb...@gdesolutions.com>.
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?
Re: [Android] loadUrl, input methods and making the web a thread-safe place
Posted by Andrew Grieve <ag...@chromium.org>.
Summary time!
Options for going JS->Native
1) Use prompt() (synchronous, can return values)
2) Use addJavascriptInterface() (synchronous, can return values)
3) URL interception (async)
Notes:
-We are currently using #1.
-According to trigger.io's
blog<http://trigger.io/cross-platform-application-development-blog/2012/02/24/why-trigger-io-doesnt-use-phonegap-5x-faster-native-bridge/>,
#2 is much faster but has issues on the 2.3 emulator.
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
Optimizations:
1) When doing any synchronous JS->Native calls, batch pending Native->JS
commands with the current command's return value.
2) Batch all pending messages together when sending/pulling them (local
server currently sends one at a time I think)
Andrew's hopes:
-JS->Native: Use #2, but leave the option to use #1. Use #2, except when on
the 2.3 emulator (not sure if this is detectable)
-Native->JS: Use #3+#4 so that we don't have a hard-to-get-right local
server and we don't need to do polling
-Implement all optimizations
-Implement optimization #1 on iOS as well (except the other way around) I
was planning on doing this after I close out CB-593.
-Have a benchmark that can compare different messaging techniques (I just
added one for iOS, should do same for Android)
Andrew
On Thu, Aug 9, 2012 at 6:03 PM, Jesse <pu...@gmail.com> wrote:
> I published an app over the weekend for Android, and in the process I ran
> an experiment. I am planning on branching to demo this, but don't have time
> right now, so I thought I would explain it.
>
> I created a WebView, gave it an external interface via
> addJavascriptInterface
>
> In JS, I simply had an interval firing continuously to pass any commands to
> native, and the native side returned any pending results.
>
> There was no interference with the keyboard and the html text field
> maintained focus through hundreds of calls.
>
> This method is absolutely simple, and can be used to move data in both
> directions, with the 1 caveat that JS must pull the data from native,
> because Java pushing to JS causes the issues we encountered previously.
>
> When I have time I will distribute a branch to demo ...
>
> Thoughts on this approach?
>
>
> On Thu, Aug 9, 2012 at 2:47 PM, Joe Bowser <bo...@gmail.com> wrote:
>
> > Actually, that would work better than other bridges so far. How would
> > this work with the supported online/offline event, and would this
> > affect XHRs and other network behaviour that is happening on an
> > interval?
> >
> >
> > On Thu, Aug 9, 2012 at 2:15 PM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> > > How about this for a possible work-around:
> > >
> > > When the keyboard is up, use WebView.setNetworkAvailable() to trigger
> an
> > > online/offline event in the JS, and then have the JS poll on
> > online/offline
> > > events.
> > >
> > > Demo of this working here:
> > >
> https://github.com/agrieve/incubator-cordova-android/commits/testbridge
> > >
> > > Andrew
> > >
> > >
> > > On Tue, Aug 7, 2012 at 10:09 AM, Simon MacDonald
> > > <si...@gmail.com>wrote:
> > >
> > >> We need to do something as it would not be good if we missed an
> > >> online/offline event while the user was typing in a text field.
> > >>
> > >> Simon Mac Donald
> > >> http://hi.im/simonmacdonald
> > >>
> > >>
> > >> On Wed, Aug 1, 2012 at 7:10 PM, Joe Bowser <bo...@gmail.com> wrote:
> > >> > I like the latter. It really should be up to the developer of the
> > >> > plugin whether they're discardable or not.
> > >> >
> > >> > So, would this make sense to be an option in 2.1?
> > >> >
> > >> > On Thu, Jul 26, 2012 at 10:51 PM, Jesse MacFadyen
> > >> > <pu...@gmail.com> wrote:
> > >> >> We could add a lifecycle event, just like pause/resume so each
> plugin
> > >> >> could react accordingly.
> > >> >> ie FileTransfer would discard progress events, but queue the
> complete
> > >> event.
> > >> >>
> > >> >> As an alternative, plugin results could have a property which
> > >> >> indicates if they are discardable.
> > >> >>
> > >> >> Cheers,
> > >> >> Jesse
> > >> >>
> > >> >>
> > >> >>
> > >> >> On 2012-07-26, at 10:10 PM, Joe Bowser <bo...@gmail.com> wrote:
> > >> >>
> > >> >>> It depends. For accelerometer, it may not make sense since it
> would
> > >> >>> just plow a series of events over and over again, and we only care
> > >> >>> about the current acceleration, which would be fired on the
> > interval.
> > >> >>> Basically, we still have the same problem, except that we break
> the
> > >> >>> native callout instead of the keyboard, which is the lesser of the
> > two
> > >> >>> evils. If someone wants both to work, we'll have to either do
> > polling
> > >> >>> or go back to the Callback Server.
> > >> >>>
> > >> >>> But yeah, it would be great if we can send something from Java
> back
> > to
> > >> >>> Javascript without it blocking.
> > >> >>>
> > >> >>> On Thu, Jul 26, 2012 at 7:56 PM, Simon MacDonald
> > >> >>> <si...@gmail.com> wrote:
> > >> >>>> Okay, I'm working off 4 hours of sleep so if what I say is not
> > >> coherent
> > >> >>>> bear with me. I looked over the code you posted up and it looks
> > like
> > >> if you
> > >> >>>> are in a text field the request to loadUrl is lost. Does it make
> > >> sense to
> > >> >>>> queue up these requests and process them once the user is outside
> > of
> > >> the
> > >> >>>> text field?
> > >> >>>>
> > >> >>>> Simon Mac Donald
> > >> >>>> http://hi.im/simonmacdonald
> > >> >>>>
> > >> >>>>
> > >> >>>> On Thu, Jul 26, 2012 at 6:44 PM, Joe Bowser <bo...@gmail.com>
> > >> wrote:
> > >> >>>>
> > >> >>>>> Hey
> > >> >>>>>
> > >> >>>>> So, on ICS and greater, it turns out that the routing table is
> > >> >>>>> fragile, so fragile in fact that you can't connect to localhost
> if
> > >> you
> > >> >>>>> don't have an internet connection of some sort. This is a
> problem
> > >> for
> > >> >>>>> us on Android because we need to connect to localhost to use the
> > >> >>>>> bridge and communicate with the Callback Server so that we can
> get
> > >> the
> > >> >>>>> callbacks. In my opinion, this is the straw that broke the
> > camel's
> > >> >>>>> back, and this bug is far worse than the reason we moved to the
> > >> >>>>> CallbackServer to begin with.
> > >> >>>>>
> > >> >>>>> First, some history:
> > >> >>>>>
> > >> >>>>> Back in OSCON 2010, we talked to Justin at Google about how they
> > >> could
> > >> >>>>> help PhoneGap, and he mentioned that we shouldn't be using
> loadUrl
> > >> for
> > >> >>>>> sending Javascript over because it is linked to the Handler and
> > can
> > >> >>>>> interrupt the UI thread. He suggested a callback server, which
> > Bryce
> > >> >>>>> implemented. The callback server and sending commands over the
> > >> prompt
> > >> >>>>> happened at roughly the same six months, when Gingerbread was
> > being
> > >> >>>>> rolled out.
> > >> >>>>>
> > >> >>>>> Now, in 2012, we are starting to have issues with the Callback
> > Server
> > >> >>>>> approach, and we should examine why we did this in the first
> > place.
> > >> >>>>> The test case for it is simple:
> > >> >>>>>
> > >> >>>>> 1. Put an input field on the accelerometer page on Mobile-Spec
> > >> >>>>> 2. Turn on Accelerometer
> > >> >>>>> 3. Try to type something
> > >> >>>>>
> > >> >>>>> What it will do is it will update the accelerometer values as
> you
> > >> type
> > >> >>>>> text. This is awesome, but I'm wondering if anyone is actually
> > going
> > >> >>>>> to use this use case, and if it's OK to break this functionality
> > in
> > >> >>>>> exchange for performance and stability. We currently have the
> > >> ability
> > >> >>>>> to use loadUrl("javascript:foo()") again by checking whether we
> > have
> > >> >>>>> focus on a text field, which we can use with HitTestResult,
> which
> > >> >>>>> inspect's webkit's cursor. This would fix the bug that I call
> > >> >>>>> "Airplane, Airplane Crash" where you can crash our bridge by
> > >> switching
> > >> >>>>> your phone in and out of airplane mode over and over again. I
> > have a
> > >> >>>>> test repository here, and it passes most of Mobile Spec. It
> > would be
> > >> >>>>> nice to be able to have this as a configurable option to start.
> > >> >>>>>
> > >> >>>>> https://github.com/infil00p/callback-android/tree/testbridge
> > >> >>>>>
> > >> >>>>> Any thoughts?
> > >> >>>>>
> > >> >>>>> Joe
> > >> >>>>>
> > >>
> >
>
>
>
> --
> @purplecabbage
> risingj.com
>
Re: [Android] loadUrl, input methods and making the web a thread-safe place
Posted by Jesse <pu...@gmail.com>.
I published an app over the weekend for Android, and in the process I ran
an experiment. I am planning on branching to demo this, but don't have time
right now, so I thought I would explain it.
I created a WebView, gave it an external interface via
addJavascriptInterface
In JS, I simply had an interval firing continuously to pass any commands to
native, and the native side returned any pending results.
There was no interference with the keyboard and the html text field
maintained focus through hundreds of calls.
This method is absolutely simple, and can be used to move data in both
directions, with the 1 caveat that JS must pull the data from native,
because Java pushing to JS causes the issues we encountered previously.
When I have time I will distribute a branch to demo ...
Thoughts on this approach?
On Thu, Aug 9, 2012 at 2:47 PM, Joe Bowser <bo...@gmail.com> wrote:
> Actually, that would work better than other bridges so far. How would
> this work with the supported online/offline event, and would this
> affect XHRs and other network behaviour that is happening on an
> interval?
>
>
> On Thu, Aug 9, 2012 at 2:15 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
> > How about this for a possible work-around:
> >
> > When the keyboard is up, use WebView.setNetworkAvailable() to trigger an
> > online/offline event in the JS, and then have the JS poll on
> online/offline
> > events.
> >
> > Demo of this working here:
> > https://github.com/agrieve/incubator-cordova-android/commits/testbridge
> >
> > Andrew
> >
> >
> > On Tue, Aug 7, 2012 at 10:09 AM, Simon MacDonald
> > <si...@gmail.com>wrote:
> >
> >> We need to do something as it would not be good if we missed an
> >> online/offline event while the user was typing in a text field.
> >>
> >> Simon Mac Donald
> >> http://hi.im/simonmacdonald
> >>
> >>
> >> On Wed, Aug 1, 2012 at 7:10 PM, Joe Bowser <bo...@gmail.com> wrote:
> >> > I like the latter. It really should be up to the developer of the
> >> > plugin whether they're discardable or not.
> >> >
> >> > So, would this make sense to be an option in 2.1?
> >> >
> >> > On Thu, Jul 26, 2012 at 10:51 PM, Jesse MacFadyen
> >> > <pu...@gmail.com> wrote:
> >> >> We could add a lifecycle event, just like pause/resume so each plugin
> >> >> could react accordingly.
> >> >> ie FileTransfer would discard progress events, but queue the complete
> >> event.
> >> >>
> >> >> As an alternative, plugin results could have a property which
> >> >> indicates if they are discardable.
> >> >>
> >> >> Cheers,
> >> >> Jesse
> >> >>
> >> >>
> >> >>
> >> >> On 2012-07-26, at 10:10 PM, Joe Bowser <bo...@gmail.com> wrote:
> >> >>
> >> >>> It depends. For accelerometer, it may not make sense since it would
> >> >>> just plow a series of events over and over again, and we only care
> >> >>> about the current acceleration, which would be fired on the
> interval.
> >> >>> Basically, we still have the same problem, except that we break the
> >> >>> native callout instead of the keyboard, which is the lesser of the
> two
> >> >>> evils. If someone wants both to work, we'll have to either do
> polling
> >> >>> or go back to the Callback Server.
> >> >>>
> >> >>> But yeah, it would be great if we can send something from Java back
> to
> >> >>> Javascript without it blocking.
> >> >>>
> >> >>> On Thu, Jul 26, 2012 at 7:56 PM, Simon MacDonald
> >> >>> <si...@gmail.com> wrote:
> >> >>>> Okay, I'm working off 4 hours of sleep so if what I say is not
> >> coherent
> >> >>>> bear with me. I looked over the code you posted up and it looks
> like
> >> if you
> >> >>>> are in a text field the request to loadUrl is lost. Does it make
> >> sense to
> >> >>>> queue up these requests and process them once the user is outside
> of
> >> the
> >> >>>> text field?
> >> >>>>
> >> >>>> Simon Mac Donald
> >> >>>> http://hi.im/simonmacdonald
> >> >>>>
> >> >>>>
> >> >>>> On Thu, Jul 26, 2012 at 6:44 PM, Joe Bowser <bo...@gmail.com>
> >> wrote:
> >> >>>>
> >> >>>>> Hey
> >> >>>>>
> >> >>>>> So, on ICS and greater, it turns out that the routing table is
> >> >>>>> fragile, so fragile in fact that you can't connect to localhost if
> >> you
> >> >>>>> don't have an internet connection of some sort. This is a problem
> >> for
> >> >>>>> us on Android because we need to connect to localhost to use the
> >> >>>>> bridge and communicate with the Callback Server so that we can get
> >> the
> >> >>>>> callbacks. In my opinion, this is the straw that broke the
> camel's
> >> >>>>> back, and this bug is far worse than the reason we moved to the
> >> >>>>> CallbackServer to begin with.
> >> >>>>>
> >> >>>>> First, some history:
> >> >>>>>
> >> >>>>> Back in OSCON 2010, we talked to Justin at Google about how they
> >> could
> >> >>>>> help PhoneGap, and he mentioned that we shouldn't be using loadUrl
> >> for
> >> >>>>> sending Javascript over because it is linked to the Handler and
> can
> >> >>>>> interrupt the UI thread. He suggested a callback server, which
> Bryce
> >> >>>>> implemented. The callback server and sending commands over the
> >> prompt
> >> >>>>> happened at roughly the same six months, when Gingerbread was
> being
> >> >>>>> rolled out.
> >> >>>>>
> >> >>>>> Now, in 2012, we are starting to have issues with the Callback
> Server
> >> >>>>> approach, and we should examine why we did this in the first
> place.
> >> >>>>> The test case for it is simple:
> >> >>>>>
> >> >>>>> 1. Put an input field on the accelerometer page on Mobile-Spec
> >> >>>>> 2. Turn on Accelerometer
> >> >>>>> 3. Try to type something
> >> >>>>>
> >> >>>>> What it will do is it will update the accelerometer values as you
> >> type
> >> >>>>> text. This is awesome, but I'm wondering if anyone is actually
> going
> >> >>>>> to use this use case, and if it's OK to break this functionality
> in
> >> >>>>> exchange for performance and stability. We currently have the
> >> ability
> >> >>>>> to use loadUrl("javascript:foo()") again by checking whether we
> have
> >> >>>>> focus on a text field, which we can use with HitTestResult, which
> >> >>>>> inspect's webkit's cursor. This would fix the bug that I call
> >> >>>>> "Airplane, Airplane Crash" where you can crash our bridge by
> >> switching
> >> >>>>> your phone in and out of airplane mode over and over again. I
> have a
> >> >>>>> test repository here, and it passes most of Mobile Spec. It
> would be
> >> >>>>> nice to be able to have this as a configurable option to start.
> >> >>>>>
> >> >>>>> https://github.com/infil00p/callback-android/tree/testbridge
> >> >>>>>
> >> >>>>> Any thoughts?
> >> >>>>>
> >> >>>>> Joe
> >> >>>>>
> >>
>
--
@purplecabbage
risingj.com
Re: [Android] loadUrl, input methods and making the web a thread-safe place
Posted by Joe Bowser <bo...@gmail.com>.
Actually, that would work better than other bridges so far. How would
this work with the supported online/offline event, and would this
affect XHRs and other network behaviour that is happening on an
interval?
On Thu, Aug 9, 2012 at 2:15 PM, Andrew Grieve <ag...@chromium.org> wrote:
> How about this for a possible work-around:
>
> When the keyboard is up, use WebView.setNetworkAvailable() to trigger an
> online/offline event in the JS, and then have the JS poll on online/offline
> events.
>
> Demo of this working here:
> https://github.com/agrieve/incubator-cordova-android/commits/testbridge
>
> Andrew
>
>
> On Tue, Aug 7, 2012 at 10:09 AM, Simon MacDonald
> <si...@gmail.com>wrote:
>
>> We need to do something as it would not be good if we missed an
>> online/offline event while the user was typing in a text field.
>>
>> Simon Mac Donald
>> http://hi.im/simonmacdonald
>>
>>
>> On Wed, Aug 1, 2012 at 7:10 PM, Joe Bowser <bo...@gmail.com> wrote:
>> > I like the latter. It really should be up to the developer of the
>> > plugin whether they're discardable or not.
>> >
>> > So, would this make sense to be an option in 2.1?
>> >
>> > On Thu, Jul 26, 2012 at 10:51 PM, Jesse MacFadyen
>> > <pu...@gmail.com> wrote:
>> >> We could add a lifecycle event, just like pause/resume so each plugin
>> >> could react accordingly.
>> >> ie FileTransfer would discard progress events, but queue the complete
>> event.
>> >>
>> >> As an alternative, plugin results could have a property which
>> >> indicates if they are discardable.
>> >>
>> >> Cheers,
>> >> Jesse
>> >>
>> >>
>> >>
>> >> On 2012-07-26, at 10:10 PM, Joe Bowser <bo...@gmail.com> wrote:
>> >>
>> >>> It depends. For accelerometer, it may not make sense since it would
>> >>> just plow a series of events over and over again, and we only care
>> >>> about the current acceleration, which would be fired on the interval.
>> >>> Basically, we still have the same problem, except that we break the
>> >>> native callout instead of the keyboard, which is the lesser of the two
>> >>> evils. If someone wants both to work, we'll have to either do polling
>> >>> or go back to the Callback Server.
>> >>>
>> >>> But yeah, it would be great if we can send something from Java back to
>> >>> Javascript without it blocking.
>> >>>
>> >>> On Thu, Jul 26, 2012 at 7:56 PM, Simon MacDonald
>> >>> <si...@gmail.com> wrote:
>> >>>> Okay, I'm working off 4 hours of sleep so if what I say is not
>> coherent
>> >>>> bear with me. I looked over the code you posted up and it looks like
>> if you
>> >>>> are in a text field the request to loadUrl is lost. Does it make
>> sense to
>> >>>> queue up these requests and process them once the user is outside of
>> the
>> >>>> text field?
>> >>>>
>> >>>> Simon Mac Donald
>> >>>> http://hi.im/simonmacdonald
>> >>>>
>> >>>>
>> >>>> On Thu, Jul 26, 2012 at 6:44 PM, Joe Bowser <bo...@gmail.com>
>> wrote:
>> >>>>
>> >>>>> Hey
>> >>>>>
>> >>>>> So, on ICS and greater, it turns out that the routing table is
>> >>>>> fragile, so fragile in fact that you can't connect to localhost if
>> you
>> >>>>> don't have an internet connection of some sort. This is a problem
>> for
>> >>>>> us on Android because we need to connect to localhost to use the
>> >>>>> bridge and communicate with the Callback Server so that we can get
>> the
>> >>>>> callbacks. In my opinion, this is the straw that broke the camel's
>> >>>>> back, and this bug is far worse than the reason we moved to the
>> >>>>> CallbackServer to begin with.
>> >>>>>
>> >>>>> First, some history:
>> >>>>>
>> >>>>> Back in OSCON 2010, we talked to Justin at Google about how they
>> could
>> >>>>> help PhoneGap, and he mentioned that we shouldn't be using loadUrl
>> for
>> >>>>> sending Javascript over because it is linked to the Handler and can
>> >>>>> interrupt the UI thread. He suggested a callback server, which Bryce
>> >>>>> implemented. The callback server and sending commands over the
>> prompt
>> >>>>> happened at roughly the same six months, when Gingerbread was being
>> >>>>> rolled out.
>> >>>>>
>> >>>>> Now, in 2012, we are starting to have issues with the Callback Server
>> >>>>> approach, and we should examine why we did this in the first place.
>> >>>>> The test case for it is simple:
>> >>>>>
>> >>>>> 1. Put an input field on the accelerometer page on Mobile-Spec
>> >>>>> 2. Turn on Accelerometer
>> >>>>> 3. Try to type something
>> >>>>>
>> >>>>> What it will do is it will update the accelerometer values as you
>> type
>> >>>>> text. This is awesome, but I'm wondering if anyone is actually going
>> >>>>> to use this use case, and if it's OK to break this functionality in
>> >>>>> exchange for performance and stability. We currently have the
>> ability
>> >>>>> to use loadUrl("javascript:foo()") again by checking whether we have
>> >>>>> focus on a text field, which we can use with HitTestResult, which
>> >>>>> inspect's webkit's cursor. This would fix the bug that I call
>> >>>>> "Airplane, Airplane Crash" where you can crash our bridge by
>> switching
>> >>>>> your phone in and out of airplane mode over and over again. I have a
>> >>>>> test repository here, and it passes most of Mobile Spec. It would be
>> >>>>> nice to be able to have this as a configurable option to start.
>> >>>>>
>> >>>>> https://github.com/infil00p/callback-android/tree/testbridge
>> >>>>>
>> >>>>> Any thoughts?
>> >>>>>
>> >>>>> Joe
>> >>>>>
>>
Re: [Android] loadUrl, input methods and making the web a thread-safe place
Posted by Andrew Grieve <ag...@chromium.org>.
How about this for a possible work-around:
When the keyboard is up, use WebView.setNetworkAvailable() to trigger an
online/offline event in the JS, and then have the JS poll on online/offline
events.
Demo of this working here:
https://github.com/agrieve/incubator-cordova-android/commits/testbridge
Andrew
On Tue, Aug 7, 2012 at 10:09 AM, Simon MacDonald
<si...@gmail.com>wrote:
> We need to do something as it would not be good if we missed an
> online/offline event while the user was typing in a text field.
>
> Simon Mac Donald
> http://hi.im/simonmacdonald
>
>
> On Wed, Aug 1, 2012 at 7:10 PM, Joe Bowser <bo...@gmail.com> wrote:
> > I like the latter. It really should be up to the developer of the
> > plugin whether they're discardable or not.
> >
> > So, would this make sense to be an option in 2.1?
> >
> > On Thu, Jul 26, 2012 at 10:51 PM, Jesse MacFadyen
> > <pu...@gmail.com> wrote:
> >> We could add a lifecycle event, just like pause/resume so each plugin
> >> could react accordingly.
> >> ie FileTransfer would discard progress events, but queue the complete
> event.
> >>
> >> As an alternative, plugin results could have a property which
> >> indicates if they are discardable.
> >>
> >> Cheers,
> >> Jesse
> >>
> >>
> >>
> >> On 2012-07-26, at 10:10 PM, Joe Bowser <bo...@gmail.com> wrote:
> >>
> >>> It depends. For accelerometer, it may not make sense since it would
> >>> just plow a series of events over and over again, and we only care
> >>> about the current acceleration, which would be fired on the interval.
> >>> Basically, we still have the same problem, except that we break the
> >>> native callout instead of the keyboard, which is the lesser of the two
> >>> evils. If someone wants both to work, we'll have to either do polling
> >>> or go back to the Callback Server.
> >>>
> >>> But yeah, it would be great if we can send something from Java back to
> >>> Javascript without it blocking.
> >>>
> >>> On Thu, Jul 26, 2012 at 7:56 PM, Simon MacDonald
> >>> <si...@gmail.com> wrote:
> >>>> Okay, I'm working off 4 hours of sleep so if what I say is not
> coherent
> >>>> bear with me. I looked over the code you posted up and it looks like
> if you
> >>>> are in a text field the request to loadUrl is lost. Does it make
> sense to
> >>>> queue up these requests and process them once the user is outside of
> the
> >>>> text field?
> >>>>
> >>>> Simon Mac Donald
> >>>> http://hi.im/simonmacdonald
> >>>>
> >>>>
> >>>> On Thu, Jul 26, 2012 at 6:44 PM, Joe Bowser <bo...@gmail.com>
> wrote:
> >>>>
> >>>>> Hey
> >>>>>
> >>>>> So, on ICS and greater, it turns out that the routing table is
> >>>>> fragile, so fragile in fact that you can't connect to localhost if
> you
> >>>>> don't have an internet connection of some sort. This is a problem
> for
> >>>>> us on Android because we need to connect to localhost to use the
> >>>>> bridge and communicate with the Callback Server so that we can get
> the
> >>>>> callbacks. In my opinion, this is the straw that broke the camel's
> >>>>> back, and this bug is far worse than the reason we moved to the
> >>>>> CallbackServer to begin with.
> >>>>>
> >>>>> First, some history:
> >>>>>
> >>>>> Back in OSCON 2010, we talked to Justin at Google about how they
> could
> >>>>> help PhoneGap, and he mentioned that we shouldn't be using loadUrl
> for
> >>>>> sending Javascript over because it is linked to the Handler and can
> >>>>> interrupt the UI thread. He suggested a callback server, which Bryce
> >>>>> implemented. The callback server and sending commands over the
> prompt
> >>>>> happened at roughly the same six months, when Gingerbread was being
> >>>>> rolled out.
> >>>>>
> >>>>> Now, in 2012, we are starting to have issues with the Callback Server
> >>>>> approach, and we should examine why we did this in the first place.
> >>>>> The test case for it is simple:
> >>>>>
> >>>>> 1. Put an input field on the accelerometer page on Mobile-Spec
> >>>>> 2. Turn on Accelerometer
> >>>>> 3. Try to type something
> >>>>>
> >>>>> What it will do is it will update the accelerometer values as you
> type
> >>>>> text. This is awesome, but I'm wondering if anyone is actually going
> >>>>> to use this use case, and if it's OK to break this functionality in
> >>>>> exchange for performance and stability. We currently have the
> ability
> >>>>> to use loadUrl("javascript:foo()") again by checking whether we have
> >>>>> focus on a text field, which we can use with HitTestResult, which
> >>>>> inspect's webkit's cursor. This would fix the bug that I call
> >>>>> "Airplane, Airplane Crash" where you can crash our bridge by
> switching
> >>>>> your phone in and out of airplane mode over and over again. I have a
> >>>>> test repository here, and it passes most of Mobile Spec. It would be
> >>>>> nice to be able to have this as a configurable option to start.
> >>>>>
> >>>>> https://github.com/infil00p/callback-android/tree/testbridge
> >>>>>
> >>>>> Any thoughts?
> >>>>>
> >>>>> Joe
> >>>>>
>
Re: [Android] loadUrl, input methods and making the web a thread-safe place
Posted by Simon MacDonald <si...@gmail.com>.
We need to do something as it would not be good if we missed an
online/offline event while the user was typing in a text field.
Simon Mac Donald
http://hi.im/simonmacdonald
On Wed, Aug 1, 2012 at 7:10 PM, Joe Bowser <bo...@gmail.com> wrote:
> I like the latter. It really should be up to the developer of the
> plugin whether they're discardable or not.
>
> So, would this make sense to be an option in 2.1?
>
> On Thu, Jul 26, 2012 at 10:51 PM, Jesse MacFadyen
> <pu...@gmail.com> wrote:
>> We could add a lifecycle event, just like pause/resume so each plugin
>> could react accordingly.
>> ie FileTransfer would discard progress events, but queue the complete event.
>>
>> As an alternative, plugin results could have a property which
>> indicates if they are discardable.
>>
>> Cheers,
>> Jesse
>>
>>
>>
>> On 2012-07-26, at 10:10 PM, Joe Bowser <bo...@gmail.com> wrote:
>>
>>> It depends. For accelerometer, it may not make sense since it would
>>> just plow a series of events over and over again, and we only care
>>> about the current acceleration, which would be fired on the interval.
>>> Basically, we still have the same problem, except that we break the
>>> native callout instead of the keyboard, which is the lesser of the two
>>> evils. If someone wants both to work, we'll have to either do polling
>>> or go back to the Callback Server.
>>>
>>> But yeah, it would be great if we can send something from Java back to
>>> Javascript without it blocking.
>>>
>>> On Thu, Jul 26, 2012 at 7:56 PM, Simon MacDonald
>>> <si...@gmail.com> wrote:
>>>> Okay, I'm working off 4 hours of sleep so if what I say is not coherent
>>>> bear with me. I looked over the code you posted up and it looks like if you
>>>> are in a text field the request to loadUrl is lost. Does it make sense to
>>>> queue up these requests and process them once the user is outside of the
>>>> text field?
>>>>
>>>> Simon Mac Donald
>>>> http://hi.im/simonmacdonald
>>>>
>>>>
>>>> On Thu, Jul 26, 2012 at 6:44 PM, Joe Bowser <bo...@gmail.com> wrote:
>>>>
>>>>> Hey
>>>>>
>>>>> So, on ICS and greater, it turns out that the routing table is
>>>>> fragile, so fragile in fact that you can't connect to localhost if you
>>>>> don't have an internet connection of some sort. This is a problem for
>>>>> us on Android because we need to connect to localhost to use the
>>>>> bridge and communicate with the Callback Server so that we can get the
>>>>> callbacks. In my opinion, this is the straw that broke the camel's
>>>>> back, and this bug is far worse than the reason we moved to the
>>>>> CallbackServer to begin with.
>>>>>
>>>>> First, some history:
>>>>>
>>>>> Back in OSCON 2010, we talked to Justin at Google about how they could
>>>>> help PhoneGap, and he mentioned that we shouldn't be using loadUrl for
>>>>> sending Javascript over because it is linked to the Handler and can
>>>>> interrupt the UI thread. He suggested a callback server, which Bryce
>>>>> implemented. The callback server and sending commands over the prompt
>>>>> happened at roughly the same six months, when Gingerbread was being
>>>>> rolled out.
>>>>>
>>>>> Now, in 2012, we are starting to have issues with the Callback Server
>>>>> approach, and we should examine why we did this in the first place.
>>>>> The test case for it is simple:
>>>>>
>>>>> 1. Put an input field on the accelerometer page on Mobile-Spec
>>>>> 2. Turn on Accelerometer
>>>>> 3. Try to type something
>>>>>
>>>>> What it will do is it will update the accelerometer values as you type
>>>>> text. This is awesome, but I'm wondering if anyone is actually going
>>>>> to use this use case, and if it's OK to break this functionality in
>>>>> exchange for performance and stability. We currently have the ability
>>>>> to use loadUrl("javascript:foo()") again by checking whether we have
>>>>> focus on a text field, which we can use with HitTestResult, which
>>>>> inspect's webkit's cursor. This would fix the bug that I call
>>>>> "Airplane, Airplane Crash" where you can crash our bridge by switching
>>>>> your phone in and out of airplane mode over and over again. I have a
>>>>> test repository here, and it passes most of Mobile Spec. It would be
>>>>> nice to be able to have this as a configurable option to start.
>>>>>
>>>>> https://github.com/infil00p/callback-android/tree/testbridge
>>>>>
>>>>> Any thoughts?
>>>>>
>>>>> Joe
>>>>>
Re: [Android] loadUrl, input methods and making the web a thread-safe place
Posted by Joe Bowser <bo...@gmail.com>.
I like the latter. It really should be up to the developer of the
plugin whether they're discardable or not.
So, would this make sense to be an option in 2.1?
On Thu, Jul 26, 2012 at 10:51 PM, Jesse MacFadyen
<pu...@gmail.com> wrote:
> We could add a lifecycle event, just like pause/resume so each plugin
> could react accordingly.
> ie FileTransfer would discard progress events, but queue the complete event.
>
> As an alternative, plugin results could have a property which
> indicates if they are discardable.
>
> Cheers,
> Jesse
>
>
>
> On 2012-07-26, at 10:10 PM, Joe Bowser <bo...@gmail.com> wrote:
>
>> It depends. For accelerometer, it may not make sense since it would
>> just plow a series of events over and over again, and we only care
>> about the current acceleration, which would be fired on the interval.
>> Basically, we still have the same problem, except that we break the
>> native callout instead of the keyboard, which is the lesser of the two
>> evils. If someone wants both to work, we'll have to either do polling
>> or go back to the Callback Server.
>>
>> But yeah, it would be great if we can send something from Java back to
>> Javascript without it blocking.
>>
>> On Thu, Jul 26, 2012 at 7:56 PM, Simon MacDonald
>> <si...@gmail.com> wrote:
>>> Okay, I'm working off 4 hours of sleep so if what I say is not coherent
>>> bear with me. I looked over the code you posted up and it looks like if you
>>> are in a text field the request to loadUrl is lost. Does it make sense to
>>> queue up these requests and process them once the user is outside of the
>>> text field?
>>>
>>> Simon Mac Donald
>>> http://hi.im/simonmacdonald
>>>
>>>
>>> On Thu, Jul 26, 2012 at 6:44 PM, Joe Bowser <bo...@gmail.com> wrote:
>>>
>>>> Hey
>>>>
>>>> So, on ICS and greater, it turns out that the routing table is
>>>> fragile, so fragile in fact that you can't connect to localhost if you
>>>> don't have an internet connection of some sort. This is a problem for
>>>> us on Android because we need to connect to localhost to use the
>>>> bridge and communicate with the Callback Server so that we can get the
>>>> callbacks. In my opinion, this is the straw that broke the camel's
>>>> back, and this bug is far worse than the reason we moved to the
>>>> CallbackServer to begin with.
>>>>
>>>> First, some history:
>>>>
>>>> Back in OSCON 2010, we talked to Justin at Google about how they could
>>>> help PhoneGap, and he mentioned that we shouldn't be using loadUrl for
>>>> sending Javascript over because it is linked to the Handler and can
>>>> interrupt the UI thread. He suggested a callback server, which Bryce
>>>> implemented. The callback server and sending commands over the prompt
>>>> happened at roughly the same six months, when Gingerbread was being
>>>> rolled out.
>>>>
>>>> Now, in 2012, we are starting to have issues with the Callback Server
>>>> approach, and we should examine why we did this in the first place.
>>>> The test case for it is simple:
>>>>
>>>> 1. Put an input field on the accelerometer page on Mobile-Spec
>>>> 2. Turn on Accelerometer
>>>> 3. Try to type something
>>>>
>>>> What it will do is it will update the accelerometer values as you type
>>>> text. This is awesome, but I'm wondering if anyone is actually going
>>>> to use this use case, and if it's OK to break this functionality in
>>>> exchange for performance and stability. We currently have the ability
>>>> to use loadUrl("javascript:foo()") again by checking whether we have
>>>> focus on a text field, which we can use with HitTestResult, which
>>>> inspect's webkit's cursor. This would fix the bug that I call
>>>> "Airplane, Airplane Crash" where you can crash our bridge by switching
>>>> your phone in and out of airplane mode over and over again. I have a
>>>> test repository here, and it passes most of Mobile Spec. It would be
>>>> nice to be able to have this as a configurable option to start.
>>>>
>>>> https://github.com/infil00p/callback-android/tree/testbridge
>>>>
>>>> Any thoughts?
>>>>
>>>> Joe
>>>>
Re: [Android] loadUrl, input methods and making the web a thread-safe place
Posted by Jesse MacFadyen <pu...@gmail.com>.
We could add a lifecycle event, just like pause/resume so each plugin
could react accordingly.
ie FileTransfer would discard progress events, but queue the complete event.
As an alternative, plugin results could have a property which
indicates if they are discardable.
Cheers,
Jesse
On 2012-07-26, at 10:10 PM, Joe Bowser <bo...@gmail.com> wrote:
> It depends. For accelerometer, it may not make sense since it would
> just plow a series of events over and over again, and we only care
> about the current acceleration, which would be fired on the interval.
> Basically, we still have the same problem, except that we break the
> native callout instead of the keyboard, which is the lesser of the two
> evils. If someone wants both to work, we'll have to either do polling
> or go back to the Callback Server.
>
> But yeah, it would be great if we can send something from Java back to
> Javascript without it blocking.
>
> On Thu, Jul 26, 2012 at 7:56 PM, Simon MacDonald
> <si...@gmail.com> wrote:
>> Okay, I'm working off 4 hours of sleep so if what I say is not coherent
>> bear with me. I looked over the code you posted up and it looks like if you
>> are in a text field the request to loadUrl is lost. Does it make sense to
>> queue up these requests and process them once the user is outside of the
>> text field?
>>
>> Simon Mac Donald
>> http://hi.im/simonmacdonald
>>
>>
>> On Thu, Jul 26, 2012 at 6:44 PM, Joe Bowser <bo...@gmail.com> wrote:
>>
>>> Hey
>>>
>>> So, on ICS and greater, it turns out that the routing table is
>>> fragile, so fragile in fact that you can't connect to localhost if you
>>> don't have an internet connection of some sort. This is a problem for
>>> us on Android because we need to connect to localhost to use the
>>> bridge and communicate with the Callback Server so that we can get the
>>> callbacks. In my opinion, this is the straw that broke the camel's
>>> back, and this bug is far worse than the reason we moved to the
>>> CallbackServer to begin with.
>>>
>>> First, some history:
>>>
>>> Back in OSCON 2010, we talked to Justin at Google about how they could
>>> help PhoneGap, and he mentioned that we shouldn't be using loadUrl for
>>> sending Javascript over because it is linked to the Handler and can
>>> interrupt the UI thread. He suggested a callback server, which Bryce
>>> implemented. The callback server and sending commands over the prompt
>>> happened at roughly the same six months, when Gingerbread was being
>>> rolled out.
>>>
>>> Now, in 2012, we are starting to have issues with the Callback Server
>>> approach, and we should examine why we did this in the first place.
>>> The test case for it is simple:
>>>
>>> 1. Put an input field on the accelerometer page on Mobile-Spec
>>> 2. Turn on Accelerometer
>>> 3. Try to type something
>>>
>>> What it will do is it will update the accelerometer values as you type
>>> text. This is awesome, but I'm wondering if anyone is actually going
>>> to use this use case, and if it's OK to break this functionality in
>>> exchange for performance and stability. We currently have the ability
>>> to use loadUrl("javascript:foo()") again by checking whether we have
>>> focus on a text field, which we can use with HitTestResult, which
>>> inspect's webkit's cursor. This would fix the bug that I call
>>> "Airplane, Airplane Crash" where you can crash our bridge by switching
>>> your phone in and out of airplane mode over and over again. I have a
>>> test repository here, and it passes most of Mobile Spec. It would be
>>> nice to be able to have this as a configurable option to start.
>>>
>>> https://github.com/infil00p/callback-android/tree/testbridge
>>>
>>> Any thoughts?
>>>
>>> Joe
>>>
Re: [Android] loadUrl, input methods and making the web a thread-safe place
Posted by Joe Bowser <bo...@gmail.com>.
It depends. For accelerometer, it may not make sense since it would
just plow a series of events over and over again, and we only care
about the current acceleration, which would be fired on the interval.
Basically, we still have the same problem, except that we break the
native callout instead of the keyboard, which is the lesser of the two
evils. If someone wants both to work, we'll have to either do polling
or go back to the Callback Server.
But yeah, it would be great if we can send something from Java back to
Javascript without it blocking.
On Thu, Jul 26, 2012 at 7:56 PM, Simon MacDonald
<si...@gmail.com> wrote:
> Okay, I'm working off 4 hours of sleep so if what I say is not coherent
> bear with me. I looked over the code you posted up and it looks like if you
> are in a text field the request to loadUrl is lost. Does it make sense to
> queue up these requests and process them once the user is outside of the
> text field?
>
> Simon Mac Donald
> http://hi.im/simonmacdonald
>
>
> On Thu, Jul 26, 2012 at 6:44 PM, Joe Bowser <bo...@gmail.com> wrote:
>
>> Hey
>>
>> So, on ICS and greater, it turns out that the routing table is
>> fragile, so fragile in fact that you can't connect to localhost if you
>> don't have an internet connection of some sort. This is a problem for
>> us on Android because we need to connect to localhost to use the
>> bridge and communicate with the Callback Server so that we can get the
>> callbacks. In my opinion, this is the straw that broke the camel's
>> back, and this bug is far worse than the reason we moved to the
>> CallbackServer to begin with.
>>
>> First, some history:
>>
>> Back in OSCON 2010, we talked to Justin at Google about how they could
>> help PhoneGap, and he mentioned that we shouldn't be using loadUrl for
>> sending Javascript over because it is linked to the Handler and can
>> interrupt the UI thread. He suggested a callback server, which Bryce
>> implemented. The callback server and sending commands over the prompt
>> happened at roughly the same six months, when Gingerbread was being
>> rolled out.
>>
>> Now, in 2012, we are starting to have issues with the Callback Server
>> approach, and we should examine why we did this in the first place.
>> The test case for it is simple:
>>
>> 1. Put an input field on the accelerometer page on Mobile-Spec
>> 2. Turn on Accelerometer
>> 3. Try to type something
>>
>> What it will do is it will update the accelerometer values as you type
>> text. This is awesome, but I'm wondering if anyone is actually going
>> to use this use case, and if it's OK to break this functionality in
>> exchange for performance and stability. We currently have the ability
>> to use loadUrl("javascript:foo()") again by checking whether we have
>> focus on a text field, which we can use with HitTestResult, which
>> inspect's webkit's cursor. This would fix the bug that I call
>> "Airplane, Airplane Crash" where you can crash our bridge by switching
>> your phone in and out of airplane mode over and over again. I have a
>> test repository here, and it passes most of Mobile Spec. It would be
>> nice to be able to have this as a configurable option to start.
>>
>> https://github.com/infil00p/callback-android/tree/testbridge
>>
>> Any thoughts?
>>
>> Joe
>>
Re: [Android] loadUrl, input methods and making the web a thread-safe place
Posted by Simon MacDonald <si...@gmail.com>.
Okay, I'm working off 4 hours of sleep so if what I say is not coherent
bear with me. I looked over the code you posted up and it looks like if you
are in a text field the request to loadUrl is lost. Does it make sense to
queue up these requests and process them once the user is outside of the
text field?
Simon Mac Donald
http://hi.im/simonmacdonald
On Thu, Jul 26, 2012 at 6:44 PM, Joe Bowser <bo...@gmail.com> wrote:
> Hey
>
> So, on ICS and greater, it turns out that the routing table is
> fragile, so fragile in fact that you can't connect to localhost if you
> don't have an internet connection of some sort. This is a problem for
> us on Android because we need to connect to localhost to use the
> bridge and communicate with the Callback Server so that we can get the
> callbacks. In my opinion, this is the straw that broke the camel's
> back, and this bug is far worse than the reason we moved to the
> CallbackServer to begin with.
>
> First, some history:
>
> Back in OSCON 2010, we talked to Justin at Google about how they could
> help PhoneGap, and he mentioned that we shouldn't be using loadUrl for
> sending Javascript over because it is linked to the Handler and can
> interrupt the UI thread. He suggested a callback server, which Bryce
> implemented. The callback server and sending commands over the prompt
> happened at roughly the same six months, when Gingerbread was being
> rolled out.
>
> Now, in 2012, we are starting to have issues with the Callback Server
> approach, and we should examine why we did this in the first place.
> The test case for it is simple:
>
> 1. Put an input field on the accelerometer page on Mobile-Spec
> 2. Turn on Accelerometer
> 3. Try to type something
>
> What it will do is it will update the accelerometer values as you type
> text. This is awesome, but I'm wondering if anyone is actually going
> to use this use case, and if it's OK to break this functionality in
> exchange for performance and stability. We currently have the ability
> to use loadUrl("javascript:foo()") again by checking whether we have
> focus on a text field, which we can use with HitTestResult, which
> inspect's webkit's cursor. This would fix the bug that I call
> "Airplane, Airplane Crash" where you can crash our bridge by switching
> your phone in and out of airplane mode over and over again. I have a
> test repository here, and it passes most of Mobile Spec. It would be
> nice to be able to have this as a configurable option to start.
>
> https://github.com/infil00p/callback-android/tree/testbridge
>
> Any thoughts?
>
> Joe
>