incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: [Android] loadUrl, input methods and making the web a thread-safe place
Date Thu, 09 Aug 2012 21:47:28 GMT
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
View raw message