Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of purplecabbage@gmail.com
 designates 74.125.82.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAOBL_k4gu939MmXijTeyB5vg2prmUM2v_kyjFh_Zj7SzwKr6Cw@mail.gmail.com>
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>
	<1144280150015843892@unknownmsgid>
	<CAOBL_k4rHKPrEE8tMz_7M58=mU_pO526P8+vk4D0ikV7QCOD2A@mail.gmail.com>
	<CAM1AYQCHSjVf5wQ7hSnir_LwmJSry2u4yNJhFGEEsONHtTzxCg@mail.gmail.com>
	<CABiQX1VJKkvGrxU3S5ybLsmfN7TudFQjYK+dbrHXu8riZgQvKQ@mail.gmail.com>
	<CAOBL_k4gu939MmXijTeyB5vg2prmUM2v_kyjFh_Zj7SzwKr6Cw@mail.gmail.com>
Date: Thu, 9 Aug 2012 15:03:06 -0700
Message-ID: 
 <CAKP6k2tmdif5WZF6LUsrgjO1prhN4gxbC7YXgoyys2oFJ9=Fmg@mail.gmail.com>
Subject: Re: [Android] loadUrl,
 input methods and making the web a thread-safe place
From: Jesse <purplecabbage@gmail.com>
To: callback-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=f46d044401d064e19104c6dc642a

--f46d044401d064e19104c6dc642a
Content-Type: text/plain; charset=ISO-8859-1

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

--f46d044401d064e19104c6dc642a--