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