incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Geolocation: Adhering to W3C Specification
Date Tue, 27 Mar 2012 22:07:08 GMT
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" <shazron@gmail.com> 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 <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