[
https://issues.apache.org/jira/browse/CB-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13457361#comment-13457361
]
Sean Nikolai Fridman commented on CB-1462:
------------------------------------------
Alrighty, but that doesn't affect the issue I experienced with the native
Android code.
Android still won't know whether it can disable location update listeners on
clearWatch because it will still have a callback id in its callback list.
Eventually the callback will be called, and yeah, with this fix the success
callback JS side won't be run, but GPS/NetworkLocation will still be running
since it wasn't stopped on clearWatch.
I guess native could always check to shut off GPS on the win/fail callbacks?
Would be curious to know how other native implementations do it. I still
wonder: can native really handle the situation properly without knowing the
callback is associated with a watch operation?
> False logic for native watchPosition/clearWatch
> -----------------------------------------------
>
> Key: CB-1462
> URL: https://issues.apache.org/jira/browse/CB-1462
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android, CordovaJS
> Affects Versions: 2.0.0
> Reporter: Sean Nikolai Fridman
> Assignee: Filip Maj
> Labels: clearwatch, geolocation, watchposition
> Fix For: 2.2.0
>
>
> *Note:* This is a bug in Android's native geolocation implementation. I can't
> speak to what happens on other platforms. However, I get the feeling that the
> bug is symptomatic of the JS implementation so it might very well exist on
> more platforms.
> *Description:* When watchPosition is called, it first calls
> getCurrentLocation (resulting in a native call to getLocation), then makes a
> native call to addWatch. In Android, addWatch callback ids and getLocation
> callback ids are stored in separate data structures. The bug I'm seeing is,
> when I call clearWatch before the watch operation's implicit
> getCurrentLocation callback is invoked, the watch operation is
> removed/stopped in native, but the corresponding getCurrentLocation operation
> is not. This is not compliant with the W3C spec, which states that that no
> further callbacks for the watch operation should be invoked. Worse, this
> causes a bug on Android where GPS is never shut off! clearWatch stops the
> location listener *iff* {{callbacks.size + watches.size == 0}}, and so if the
> callback hadn't been invoked yet...
> _(Actually, skimming back through the code, I'm not seeing anywhere where the
> location listener is stopped after a getCurrentPosition. Which may be another
> issue... not sure.)_
> *And the potential issue in Javascript is this:* if native has no knowledge
> of which getCurrentLocation callbacks are part of a watch operation and which
> are just normal independent ones, how can it possibly remove the callback id
> for the implicit getCurrentLocation operation on clearWatch? And how can it
> possibly know if it can really stop listening for location updates?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
