incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <>
Subject Re: Unified JS Compass Issues
Date Tue, 03 Apr 2012 18:20:36 GMT
Geo won't get in until post-1.6 (it's a bit late). What we have currently
"works" - just not up to W3C spec.

If the compass stuff is something we need to commit now to get it in for
1.6, Becky, I would just do whatever is easiest for you right now. In 1.7
we can comfortably refactor the sensor APIs to whatever pattern we decide

My preference is run with the pattern I used for the geo rewrite, which is:

1. Have a dictionary of watches, which maps timer ids -> callback ids.
2. Have an array of callback ids that store all callback ids received from
incoming getCurrent* calls.
3. Native interface implements a `size` method that returns the total
number of stored ids in the dictionary + array.
4. When a getCurrent or watch call comes in, store the callback id in the
right spot. If the sensor isn't started, start it.
5. When the framework lets you know of a sensor update, return the info to
all stored callback ids. Clear out getCurrent* callback ids. If `size` ==
0, call stop.

On 4/3/12 5:54 AM, "Becky Gibson" <> wrote:

>Since changing this affects both Android and iOS we need to make some
>decisions in order to get this changed and tested for 1.6. iOS has to make
>a change to compass in order to work properly in 1.6.  It would be nice if
>we could all agree on what change we want to make.
>Are you going to be checking in your geolocation changes soon?
>On Mon, Apr 2, 2012 at 7:02 PM, Filip Maj <> wrote:
>> 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
>> 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
>> for accel instead of offering a timeout function.
>> Whatever the final decision is, should definitely apply that same
>> 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
>> >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
>> >> 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
>> >>the
>> >> sensor when a watch ended.
>> >>
>> >> I was going to mimic the Android behavior of using a timeout to turn
>> >> the sensor.  However, the unified JS code changes that behavior as
>> >>  Previously the watchHeading code for Android called into a device
>> >> 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
>> >>    the sensor turn off/on if the watch frequency is > than the
>> >>    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
>> >>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
>> >>only
>> >>    watchHeadingFilter api rather than overloading getCurrentHeading.
>> >>
>> >> thoughts?
>> >>
>> >>
>> >>

View raw message