incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <>
Subject Re: Geolocation: Adhering to W3C Specification
Date Mon, 26 Mar 2012 23:12:17 GMT
I believe the WebKit implementation on Android doesn't provide the extra
information that the native implementation provides (such as altitude,
bearing, speed etc...). I might be wrong though.
Good catch on the timeout/frequency param! I guess we should decide what is
a "significant change in position". It is sort of difficult because it
depends on the accuracy required by apps.

On Mon, Mar 26, 2012 at 4:00 PM, Filip Maj <> wrote:

> Hey all,
> The past week or so I've been working on revamping the geolocation tests
> according to what is laid out by the W3C API [1]. Been tracking progress
> and whatnot in a JIRA issue [2].
> Good news: I've got the tests implemented plus cordova-js passing said
> tests (compare view to see diff available @ [3]).
> Bad news: we've been doing it wrong in our native implementations for…
> well, ever, it seems.
> Moving forward would like to hear suggestions from everyone.
> Breaking down what we didn't do in the past that the spec mandates:
>  *   Properly implementing a timeout. It is one of the available options
> that you can pass into getCurrentPosition / watchPosition. However, we've
> been using it to date as essentially a "frequency" parameter for
> watchPosition, I.e. "give me position updates every <options.timeout>
> milliseconds". This is wrong. According to the spec, the timeout option
> defines how long after invoking a watch/getCurrent the error callback
> should wait before it fires with a TIMEOUT PositionError object.
>  *   There is no control over how often watchPosition should fire success
> callbacks. Instead, the spec says: "In step 5.2.2 of the watch process, the
> successCallback is only invoked when a new position is obtained and this
> position differs signifficantly from the previously reported position. The
> definition of what consitutes a significant difference is left to the
> implementation."
>  *   I've also added tests + control of comparing the "maximumAge"
> parameter on the JS side, and keeping a reference to the last successful
> position retrieved from the native framework and comparing its timestamp
> together with maximumAge. This should implement proper caching of
> positioning on the WebView side and hopefully save some native round trips.
> All of this means the the API on the native side for geolocation will
> change (sorry iOS!). Basically we have three actions that the Geolocation
> plugin should listen for:
>  *   getLocation, which takes as parameters enableHighAccuracy (boolean)
> and maximumAge (int as milliseconds).
>  *   addWatch, parameter: only the usual callbackID required.
>  *   clearWatch, parameter: only the usual callbackID required.
> getLocation should require very little changing (other than not needing
> the timeout parameter anymore, since that is handled on the JS side in my
> patch).
> addWatch should keep a list of callback Ids, and, as soon as we have one
> watch started, the native framework should start watching the position for
> a "significant position difference". Once that happens, it should fire the
> success callback(s) for all stored watch callback Ids. If there is an issue
> retrieving position, it should fire the error callback(s) for all stored
> watch callback Ids.
> I commented out a bunch of iOS-specific code that already did a "distance
> filter" type of approach to position acquisition, but was only available if
> you provided undocumented parameters in the options object. Not sure about
> how feasible a distance filter is in Android, or Windows Phone, or our
> other supported platforms.
> One final point of discussion worth bringing up about this issue.
> BlackBerry and Android use the default implementation of geolocation
> abilities in their respective WEbViews. Because of this I would mandate
> removal of any Geolocation java code from the Android + BlackBerry
> implementations. Saves some bytes. Originally we had the Android plugin
> classes in there for support for devices before 2.0. Since we are only
> supporting 2.0 and above, this is no longer needed. Are there any issues
> with this?
> Appreciate you guys looking this over.
> Cheers,
> Fil
> [1]
> [2]
> [3]

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