incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: Geolocation: Adhering to W3C Specification
Date Tue, 27 Mar 2012 21:46:59 GMT
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 <fil@adobe.com> 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

Mime
View raw message