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 Unified JS Compass Issues
Date Fri, 30 Mar 2012 19:45:27 GMT
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