fix(ios): added timeout implementation for both getCurrentPosition and watchPosition#55
Conversation
|
@OS-ruimoreiramendes per what we talked earlier this should only go with Capacitor 8, in which case we should point this PR to |
@OS-pedrogustavobilro Already changed the base branch to next and fix the conflicts |
There was a problem hiding this comment.
Note: CI is failing on example app build for Android, but I think it could be due to the gradle version being updated on Capacitor Framework. Since this PR doesn't touch Android, I don't think we need to concern ourselves with it here. We'll probably be opening PRs soon to address that. Just wanted to let you know.
There was a problem hiding this comment.
When testing I'm observing this behavior in the example app in this repo:
- I receive a timeout in
watchPosition(right now by setting a timeout of 1ms) - I try a get current position with timeout of 1ms. I receive two timeout errors - I believe 1 for this request and one for watch.
- I increase the timeout and call get current position. I start receiving locations in the watch.
All this leads me to believe that perhaps there needs to be logic in place to remove the watch callbacks in case of timeout error? Or to generalize the question: Which GeolocationError's are recoverable for a watch and which are not? I think the code assumes right now that all are, and that's not necessarily the case?
There was a problem hiding this comment.
Hm, let me take look.
I'll try to replicate it and see if the issue is related to the watch callbacks.
There was a problem hiding this comment.
With your change now, I'm having this issue: I have a watch in progress, and I trigger a second one (or a get current position) that times out, it also stops receiving updates for the first one.
This and the previous issue are all tied to the fact that timeouts are not specific to one single watch or location request.
There was a problem hiding this comment.
I’ve have figured out the cause in onLocationPermissionGranted()
let shouldRequestCurrentPosition = callbackManager?.locationCallbacks.isEmpty == false
let shouldRequestLocationMonitoring = callbackManager?.watchCallbacks.isEmpty == false
When a watch is already active and a getCurrentPosition is triggered, both flags are true. The current position itself doesn’t time out because we return the last known location from the watch.
However, startMonitoringLocation is also called again due to shouldRequestLocationMonitoring being true, which starts a new timer.
This issue existed before the current changes, so it will not be addressed in this PR.
| :path: "../../../../node_modules/.pnpm/@capacitor+ios@8.0.0-alpha.3_@capacitor+core@8.0.0-alpha.3/node_modules/@capacitor/ios" | ||
| CapacitorGeolocation: | ||
| :path: "../../../capacitor-plugin" | ||
| :path: "../../../../node_modules/.pnpm/@capacitor+geolocation@file+packages+capacitor-plugin_@capacitor+core@8.0.0-alpha.3/node_modules/@capacitor/geolocation" |
There was a problem hiding this comment.
I think due to something in pnpm or npm lock files, the example app now instead of depending on the local version, seems to depend on the latest published alpha - This causes npx cap sync to not update the geolocation code Pod for the example app.
I "fixed" on my end it by removing all lock files and node-modules, and sticking to just plain npm install on both plugin and example app.
We should strive for consistency in our repos, use pnpm for all, or npm for all, or at least use one of them for the same repository, not both.
There was a problem hiding this comment.
This doesn't really need to be addressed in this PR, and only affects the example app, so I'll be approving the PR, no point in dilly-dallying any further xD
# [8.0.0-next.4](v8.0.0-next.3...v8.0.0-next.4) (2025-11-04) ### Bug Fixes * **ios:** added timeout implementation for both getCurrentPosition and watchPosition ([#55](#55)) ([4c22ac3](4c22ac3))
Because the native Android library now applies the `timeout` explicitly to `addWatch`, we should allow consumers of this plugin to configure interval's to be lower that timeout, while leaving default value of `timeout` for backwards compatibility with versio 7.1.x We document this as a breaking change, as it has the possibility of causing location timeouts where there previously were none. There was also an equivalent breaking change for iOS, in a previous PR. References: - https://outsystemsrd.atlassian.net/browse/RMET-4360 - https://outsystemsrd.atlassian.net/browse/RMET-4688 - #55 BREAKING CHANGE: The `timeout` property now gets applied to all requests on Android on iOS, as opposed to just web and `getCurrentPosition` on Android. This aligns with what is documented in the plugin. If you are experiencing timeouts when requesting location in your app, consider using a higher `timeout` value. For `watchPosition` on Android, you may use the `interval` parameter introduced in version 8.0.0.
# [8.0.0](v7.1.6...v8.0.0) (2025-12-08) ### Bug Fixes * **android:** use 'propName = value' assignment syntax in build.gradle files ([08f311a](08f311a)) * **ios:** added timeout implementation for both getCurrentPosition and watchPosition ([#55](#55)) ([4c22ac3](4c22ac3)) * peerDependency for pnpm compatibility ([a94839d](a94839d)) ### Features * **android:** Fallback option for no network or Play Services ([#53](#53)) ([09277b7](09277b7)) * **android:** New parameter `interval` in `watchPosition` ([#62](#62)) ([7fda0cf](7fda0cf)) * Capacitor 8 support ([6ead26a](6ead26a)) ### BREAKING CHANGES * **android:** The `timeout` property now gets applied to all requests on Android on iOS, as opposed to just web and `getCurrentPosition` on Android. This aligns with what is documented in the plugin. If you are experiencing timeouts when requesting location in your app, consider using a higher `timeout` value. For `watchPosition` on Android, you may use the `interval` parameter introduced in version 8.0.0. * Capacitor major version update requires major version update on the plugin.
Description
This PR adds a new IONGeolocationLib library (version 2.0.0) that includes logic to handle timeouts for both getCurrentPosition and watchPosition.
Context
Type of changes
Platforms affected
Tests
Test wit Location Sample in ODC
Screenshots (if appropriate)
Checklist
RNMT-XXXX <title>