incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon MacDonald <simon.macdon...@gmail.com>
Subject Re: [Android] loadUrl, input methods and making the web a thread-safe place
Date Tue, 07 Aug 2012 14:09:31 GMT
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 <bowserj@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
> <purplecabbage@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 <bowserj@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
>>> <simon.macdonald@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 <bowserj@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
>>>>>

Mime
View raw message