Not to belabor the point but I want to make sure we all understand the details.
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? -becky On Mon, Mar 19, 2012 at 2:10 PM, Patrick Mueller <[email protected]> wrote: > Ah, I see what you're talking about now Becky. > > On Mon, Mar 19, 2012 at 13:39, Jesse MacFadyen <[email protected] > >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 > http://muellerware.org >
