incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Becky Gibson <gibson.be...@gmail.com>
Subject Re: Unified JS Compass Issues
Date Tue, 03 Apr 2012 19:22:42 GMT
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 <fil@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" <gibson.becky@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 <fil@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" <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message