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 Wed, 01 Aug 2012 23:10:47 GMT
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
<> 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 <> 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
>> <> 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
>>> On Thu, Jul 26, 2012 at 6:44 PM, Joe Bowser <> 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.
>>>> Any thoughts?
>>>> Joe

View raw message