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