I think the benefits outweigh the negatives in this case. We would need to document this approach somewhere though.
On 3/19/12 12:09 PM, "Becky Gibson" <[email protected]> wrote: >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 >>
