Thanks Fil - I'm all for fixing geolocation in iOS. There's several jira issues for it, and I've been attempting to fix it as best I can, but users are still reporting problems with it since it doesn't match the native implementation of UIWebView.
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
