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 23:55:26 GMT
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" <shazron@gmail.com> 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 <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...geotest
>>>>s
>>


Mime
View raw message