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 <[email protected]> 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] 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 >
