incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Unified JS Compass Issues
Date Mon, 02 Apr 2012 23:02:48 GMT
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" <gibson.becky@gmail.com> 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
><gibson.becky@gmail.com>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?
>>
>>
>>


Mime
View raw message