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?
