breautek commented on issue #287: URL: https://github.com/apache/cordova-plugin-geolocation/issues/287#issuecomment-2575813018
> When app is deployed to iOS Simulator and physical iPhone the watchPosition() fires a 4 times (every time) and then on the 4th call I get a timeout which is triggers my onError callback. iOS does something unique in that when you first start up the location manager, it will immediately send in "GPS updates", in whatever state it's in. These are usually garbage and/or out-dated location events but Apple favours sending them out for responsiveness vs accuracy. Android doesn't behave this way and will wait for a GPS event that is somewhat acceptable in accuracy. > After 1 timeout, watchPosition() stops and does not resume. This is probably due to the fact that Apple wants iOS developers to stop the location manager on errors, though if it's stopping the watch on timeout, then that might be wrong on Cordova's part. > Is there a way to slow down the watchPosition to only "check" once per 10 seconds...I don't need extreme "watching" in my app but I do need to try and update the users coordinates at certain intervals. Before I get into this, important to note that Cordova doesn't have an Android implementation. You're using the native browser geolocation implementation on Android. The android side of this plugin only handles permissions. Android & iOS has different "energy-saving" mantras. How Android filters geolocation updates is not really known, as it's a browser implementation detail. iOS does use distance filter checks. On both platforms, Healthy GPS connections will report a GPS update approximately every second. On iOS, GPS updates are filtered by a distance filter. These are hard-coded based on the high accuracy boolean. If I recall correctly, it's 5m for high accuracy, and 3km for coarse accuracy. GPS updates doesn't get broadcasted to app code immediately, but whenever the native GPS update is provided it is recorded and broadcasted to the webview (but not app code). On the plugin's JS side, there is an interval that ticks every second that provides the last known GPS update. I believe it will use the timestamp and maximum age to determine whether if app-code callback should be invoked or not. It will also trigger timeouts if it hasn't received a GPS update from native within the requested timeout time. So depending on the configuration, you could see several "GPS updates" that are actually the same GPS point, if GPS updates from native are slow. I'm kinda going off memory, I didn't review the code before I wrote this so I might have some minor details wrong... > Last, how intensive is enableHighAccuracy on the device as well as what are others experiences when not using it - the disabledHIghAccuraccy coordinates versus the enableHighAccurracy coordinates? Is there really a significant difference? High accuracy allows "fine" location, which is necessary if you want to know the street the user is on. Just because you have `enableHighAccurracy` enabled, doesn't mean the user will actually grant you high accuracy permission. The user can opt to only grant coarse (low accuracy) permission. If the boolean is off, then the option for the user to grant high accuracy location will not be shown and the user can only grant coarse accuracy (or obviously reject giving permission). If app code enables high accuracy, and the user grants high accuracy, it is still possible that the device will only operate with coarse accuracy, depending on device location settings (for example, if using GPS hardware is turned off). The exact accuracy Coarse option provides is implementation dependent but usually it uses more energy efficient means of determining the location, e.g. avoids using GPS hardware. Accuracy is usually guaranteed to be within 3km but is often (in my experience) much tighter radius. Even if the given point is accurate to a 3km radius, this is acceptable if you're trying to determine the user's country for example. If you don't need high accuracy, then allowing only coarse accuracy should see energy usage improvements. The interval used on the JS side might be a bit wasteful, but most of the energy consumption will be from the GPS hardware which the settings will configure the native stuff to be more energy efficient. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
