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 03:07:06 GMT
Summary time!

Options for going JS->Native
1) Use prompt()  (synchronous, can return values)
2) Use addJavascriptInterface()  (synchronous, can return values)
3) URL interception (async)

Notes:
-We are currently using #1.
-According to trigger.io's
blog<http://trigger.io/cross-platform-application-development-blog/2012/02/24/why-trigger-io-doesnt-use-phonegap-5x-faster-native-bridge/>,
#2 is much faster but has issues on the 2.3 emulator.


Going Native->JS
1) Poll using 1) from above. (async)
2) Poll using 2) from above. (async)
3) Use loadUrl (breaks keyboard) (async)
4) Trigger an online/offline event and have JS pull in value using a sync
JS->Native option (async)
5) Use a local server and hanging gets (async & complicated)

Notes:
-We currently use a combination of #1 and #5
-#3 is faster and simpler but breaks keyboard focus

Optimizations:
1) When doing any synchronous JS->Native calls, batch pending Native->JS
commands with the current command's return value.
2) Batch all pending messages together when sending/pulling them (local
server currently sends one at a time I think)

Andrew's hopes:
-JS->Native: Use #2, but leave the option to use #1. Use #2, except when on
the 2.3 emulator (not sure if this is detectable)
-Native->JS: Use #3+#4 so that we don't have a hard-to-get-right local
server and we don't need to do polling
-Implement all optimizations
-Implement optimization #1 on iOS as well (except the other way around) I
was planning on doing this after I close out CB-593.
-Have a benchmark that can compare different messaging techniques (I just
added one for iOS, should do same for Android)

Andrew


On Thu, Aug 9, 2012 at 6:03 PM, Jesse <purplecabbage@gmail.com> wrote:

> 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