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 Fri, 10 Aug 2012 02:29:46 GMT
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 <bowserj@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 <agrieve@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
> > <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