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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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 > >> > >
