incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: [Android] loadUrl, input methods and making the web a thread-safe place
Date Thu, 09 Aug 2012 21:15:24 GMT
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
<simon.macdonald@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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message