You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Becky Gibson <gi...@gmail.com> on 2012/03/30 21:45:27 UTC
Unified JS Compass Issues
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?
Re: Unified JS Compass Issues
Posted by Becky Gibson <gi...@gmail.com>.
OK, I will use a timeout for iOS in 1.6 since that requires no modification
to other platforms. I worked that into the fix for CB-361[1].
[1] https://issues.apache.org/jira/browse/CB-361
On Tue, Apr 3, 2012 at 2:20 PM, Filip Maj <fi...@adobe.com> wrote:
> 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
> onŠ
>
> 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" <gi...@gmail.com> 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 <fi...@adobe.com> 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
> >>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" <gi...@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
> >> ><gi...@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?
> >> >>
> >> >>
> >> >>
> >>
> >>
>
>
Re: Unified JS Compass Issues
Posted by Filip Maj <fi...@adobe.com>.
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
onŠ
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" <gi...@gmail.com> 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 <fi...@adobe.com> 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
>>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" <gi...@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
>> ><gi...@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?
>> >>
>> >>
>> >>
>>
>>
Re: Unified JS Compass Issues
Posted by Becky Gibson <gi...@gmail.com>.
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 <fi...@adobe.com> 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 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" <gi...@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
> ><gi...@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?
> >>
> >>
> >>
>
>
Re: Unified JS Compass Issues
Posted by Filip Maj <fi...@adobe.com>.
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" <gi...@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
><gi...@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?
>>
>>
>>
Re: Unified JS Compass Issues
Posted by Becky Gibson <gi...@gmail.com>.
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 <gi...@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?
>
>
>