Apple should be following W3C, although I don't know if they fixed this bug yet, it's still unresolved for me in Radar: http://openradar.appspot.com/radar?id=1160403 but based on what my test on 5.1, they've fixed it.
Sure ping me on email/jabber let's set up a time. On Tue, Mar 27, 2012 at 3:07 PM, Filip Maj <[email protected]> wrote: > Assuming that the native WebView implementations across whatever platforms > adhere to the W3C Geo spec, then these native changes would line up our > implementation with what users are expecting in their browser. > > I can help with tweaking the implementation on iOS, but would love if you > could once-over it, Shaz, and perhaps jump on a quick remote hack sesh > with me for 15-20 mins to make sure we are looking good. > > On 3/27/12 2:46 PM, "Shazron" <[email protected]> wrote: > >>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 >
