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
