incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: [Android] loadUrl, input methods and making the web a thread-safe place
Date Thu, 09 Aug 2012 22:03:06 GMT
I published an app over the weekend for Android, and in the process I ran
an experiment. I am planning on branching to demo this, but don't have time
right now, so I thought I would explain it.

I created a WebView, gave it an external interface via
 addJavascriptInterface

In JS, I simply had an interval firing continuously to pass any commands to
native, and the native side returned any pending results.

There was no interference with the keyboard and the html text field
maintained focus through hundreds of calls.

This method is absolutely simple, and can be used to move data in both
directions, with the 1 caveat that JS must pull the data from native,
because Java pushing to JS causes the issues we encountered previously.

When I have time I will distribute a branch to demo ...

Thoughts on this approach?


On Thu, Aug 9, 2012 at 2: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
> >> >>>>>
> >>
>



-- 
@purplecabbage
risingj.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message