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
api based on a timer. In order to implement the more iOS specific version
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.
implementation is hidden in the existing watchFilter api. However, it does
have the implication that iOS will now have a device specific
are comfortable with that?
On Mon, Mar 19, 2012 at 2:10 PM, Patrick Mueller <pmue...@gmail.com> wrote:
Ah, I see what you're talking about now Becky.
On Mon, Mar 19, 2012 at 13:39, Jesse MacFadyen <purp...@gmail.com
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