incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Becky Gibson <gibson.be...@gmail.com>
Subject Re: Unified JS Compass Issues
Date Tue, 03 Apr 2012 12:54:52 GMT
Since changing this affects both Android and iOS we need to make some
decisions in order to get this changed and tested for 1.6. iOS has to make
a change to compass in order to work properly in 1.6.  It would be nice if
we could all agree on what change we want to make.

Are you going to be checking in your geolocation changes soon?

On Mon, Apr 2, 2012 at 7:02 PM, Filip Maj <fil@adobe.com> wrote:

> What about the approach of having private start/stop functions that the
> native code will trigger when:
>
> - call start a getCurrent or a watch call comes in and we have not started
> yet
> - call stop after a getCurrent call finishes or all watches are cleared
> and we are listening for compass changes
>
> This is what I did for the geo rewrite. I'm thinking we do the same thing
> for accel instead of offering a timeout function.
>
> Whatever the final decision is, should definitely apply that same pattern
> to all of our getCurrent* sensor APIs: compass, accel, geo.
>
> On 4/2/12 1:30 PM, "Becky Gibson" <gibson.becky@gmail.com> wrote:
>
> >OK, so I read the code wrong.  The default timeout is 30000 ms not 3000.
> >So, we can just go with option 1 below and turn off the sensor after 30
> >seconds of no activity.  Although, that might be a bit long.  Still
> >interested in others' opinions.
> >
> >-b
> >
> >On Fri, Mar 30, 2012 at 3:45 PM, Becky Gibson
> ><gibson.becky@gmail.com>wrote:
> >
> >> I was updating the iOS compass code to implement the iOS only
> >>  watchHeadingFilter functionality.  On the list we had discussed
> >>passing
> >>  the filter parameter to iOS in the current watchHeading api via the
> >> options object rather than making a new JS api.  I also needed to update
> >> iOS to the unified JS compass code. Previously iOS used a repeats
> >>parameter
> >> to indicate that a watch was occurring rather than a one time heading
> >> request.  And iOS relied on a device call to stopHeading() to turn off
> >>the
> >> sensor when a watch ended.
> >>
> >> I was going to mimic the Android behavior of using a timeout to turn off
> >> the sensor.  However, the unified JS code changes that behavior as well.
> >>  Previously the watchHeading code for Android called into a device api,
> >> setTimeout.  This set a timeout to be 10 seconds greater than the
> >>specified
> >> watch frequency.  If no getHeading requests were received within the
> >> timeout the sensor was turned off.   This call to setTimeout has been
> >> removed from the unified JS compass code.  The default timeout in the
> >> Android Java code is 3 seconds.   Thus, with unified JS if you set a
> >> frequency greater than 3 seconds, the sensor will keep getting turned
> >>off
> >> and on between heading requests.
> >>
> >> I see three options:
> >>
> >>    1. do nothing and set the default timeout to be much longer and let
> >>    the sensor turn off/on if the watch frequency is > than the default.
> >>    2. Add back the setTimeout call.
> >>    3. Add a stopHeading call to explicitly turn off the sensor.  This
> >>    would be called from stopWatch() and from the success callback of
> >>    getCurrentHeading.
> >>    4. Pass the options object with the frequency into the device side
> >>    getHeading api.   If the option object has a frequency and it is >
> >>0, we
> >>    can use this to set the timeout value greater than the frequency.
> >>     Currently the device side getHeading api does not expect any
> >>options.
> >>    However, in order to support the iOS watchHeadingFilter I need to
> >>pass the
> >>    filter value in and was planning to modify the getCurrentHeading JS
> >>api to
> >>    take an options parameter.  It's debatable how "clean" this option
> >>is.  It
> >>    might be better to have explicit apis like 2 or 3 and provide an iOS
> >>only
> >>    watchHeadingFilter api rather than overloading getCurrentHeading.
> >>
> >> thoughts?
> >>
> >>
> >>
>
>

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