incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Becky Gibson <>
Subject Re: Plan for device specific APIs?
Date Mon, 19 Mar 2012 19:09:18 GMT
Not to belabor the point but I want to make sure we all understand the

The whole idea behind changing the iOS implementation is to make it more
efficient and NOT use a timer to request the heading.  However, the
watchHeading Javascript is written to repeatedly call the device getHeading
api based on a timer.   In order to implement the more iOS specific version
with a filter option I will need iOS specific JavaScript code.   This code
would use the standard timer implementation if no filter parameter if
provided but would call out to the iOS watchHeadingFilter device
implementation if one is provided.

Thus, there are no additional JavaScript apis for iOS, the optional
implementation is hidden in the existing watchFilter api.  However, it does
have the implication that iOS will now have a device specific
implementation of the JavaScript watchHeading definition.  I assume folks
are comfortable with that?


On Mon, Mar 19, 2012 at 2:10 PM, Patrick Mueller <> wrote:

> Ah, I see what you're talking about now Becky.
> On Mon, Mar 19, 2012 at 13:39, Jesse MacFadyen <
> >wrote:
> > I think the 2 iOS calls for compass can coexist peacefully if it is
> > refactored to use the filter value as an option in the original call
> > to watchHeading. Other platforms could ignore this option, or even
> > implement it and this could be considered a quirk.  Exposing another
> > method on compass, (and presumably possibly geolocation, and
> > accelerometer) for this makes no sense to me.
> >
> +1 on enabling additional functionality via 'options' passed to an API
> +1 on not adding additional methods to enable additional functionality in
> an API
> --
> Patrick Mueller

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message