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 <[email protected]>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? > > >
