incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Geolocation: Adhering to W3C Specification
Date Mon, 26 Mar 2012 23:00:31 GMT
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] http://dev.w3.org/geo/api/spec-source.html#api_description
[2] https://issues.apache.org/jira/browse/CB-359
[3] https://github.com/filmaj/incubator-cordova-js/compare/master...geotests

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