Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of purplecabbage@gmail.com
 designates 209.85.212.177 as permitted sender)
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>
From: Jesse MacFadyen <purplecabbage@gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: 
 <CAOBL_k7uS+i5zLDZT+YmcgG21Jzxg2SuXOJD5_zG6cn5p=zcaA@mail.gmail.com>
Date: Thu, 26 Jul 2012 22:51:46 -0700
Message-ID: <1144280150015843892@unknownmsgid>
Subject: Re: [Android] loadUrl,
 input methods and making the web a thread-safe place
To: "callback-dev@incubator.apache.org" <callback-dev@incubator.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

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
>>>