I am going to assume then that will be merged in and we'll be making the necessary native tweaks across the platforms we want to support.
ANDROID peeps: should we axe native geo code, or should we keep it around and thus update the implementation to follow this new approach? On 3/27/12 3:33 PM, "Shazron" <[email protected]> wrote: >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...geotest >>>>s >>
