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" 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
>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?
>>
>>
>>