incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Becky Gibson <>
Subject Re: Unified JS Compass Issues
Date Mon, 02 Apr 2012 20:30:59 GMT
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.


On Fri, Mar 30, 2012 at 3:45 PM, Becky Gibson <>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?

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