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 22:33:21 GMT
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 <fil@adobe.com> 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" <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