incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: Geolocation: Adhering to W3C Specification
Date Tue, 27 Mar 2012 23:57:03 GMT
We should axe it/move it to its own plugins repo.  Someone may want it, but
I don't want to make promises for it.

On Tue, Mar 27, 2012 at 4:55 PM, Filip Maj <fil@adobe.com> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message