Skip to content

fix(ios): added timeout implementation for both getCurrentPosition and watchPosition#55

Merged
OS-ruimoreiramendes merged 29 commits intonextfrom
fix/RMET-4360/timeout-logic
Nov 4, 2025
Merged

fix(ios): added timeout implementation for both getCurrentPosition and watchPosition#55
OS-ruimoreiramendes merged 29 commits intonextfrom
fix/RMET-4360/timeout-logic

Conversation

@OS-ruimoreiramendes
Copy link
Copy Markdown
Contributor

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

  • Fix (non-breaking change which fixes an issue)
  • Feature (non-breaking change which adds functionality)
  • Refactor (cosmetic changes)
  • Breaking change (change that would cause existing functionality to not work as expected)

Platforms affected

  • Android
  • iOS
  • JavaScript

Tests

Test wit Location Sample in ODC

Screenshots (if appropriate)

Checklist

  • Pull request title follows the format RNMT-XXXX <title>
  • Code follows code style of this project
  • CHANGELOG.md file is correctly updated
  • Changes require an update to the documentation
    • Documentation has been updated accordingly

@OS-ruimoreiramendes OS-ruimoreiramendes self-assigned this Oct 29, 2025
@OS-ruimoreiramendes OS-ruimoreiramendes requested a review from a team October 29, 2025 12:57
@OS-pedrogustavobilro
Copy link
Copy Markdown
Contributor

@OS-ruimoreiramendes per what we talked earlier this should only go with Capacitor 8, in which case we should point this PR to next instead of main

@OS-ruimoreiramendes OS-ruimoreiramendes changed the base branch from main to next October 29, 2025 16:30
@OS-ruimoreiramendes
Copy link
Copy Markdown
Contributor Author

OS-ruimoreiramendes commented Oct 29, 2025

@OS-ruimoreiramendes per what we talked earlier this should only go with Capacitor 8, in which case we should point this PR to next instead of main

@OS-pedrogustavobilro Already changed the base branch to next and fix the conflicts

Comment thread CHANGELOG.md Outdated
Comment thread packages/capacitor-plugin/ios/Sources/GeolocationPlugin/GeolocationPlugin.swift Outdated
Comment thread packages/capacitor-plugin/ios/Sources/GeolocationPlugin/GeolocationPlugin.swift Outdated
Copy link
Copy Markdown
Contributor

@OS-pedrogustavobilro OS-pedrogustavobilro Oct 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks

Comment thread packages/capacitor-plugin/Package.swift
@OS-ruimoreiramendes OS-ruimoreiramendes changed the title feat(ios): added timeout implementation for both getCurrentPosition and watchPosition fix(ios): added timeout implementation for both getCurrentPosition and watchPosition Oct 30, 2025
Copy link
Copy Markdown
Contributor

@OS-pedrogustavobilro OS-pedrogustavobilro Oct 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When testing I'm observing this behavior in the example app in this repo:

  1. I receive a timeout in watchPosition (right now by setting a timeout of 1ms)
  2. 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.
  3. 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?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, let me take look.
I'll try to replicate it and see if the issue is related to the watch callbacks.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

@OS-ruimoreiramendes OS-ruimoreiramendes Oct 31, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@OS-pedrogustavobilro OS-pedrogustavobilro requested a review from a team October 31, 2025 17:53
@OS-ruimoreiramendes OS-ruimoreiramendes requested review from a team and removed request for a team November 4, 2025 15:20
@OS-ruimoreiramendes OS-ruimoreiramendes merged commit 4c22ac3 into next Nov 4, 2025
7 of 8 checks passed
capacitor-bot pushed a commit that referenced this pull request Nov 4, 2025
# [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))
@OS-ruimoreiramendes OS-ruimoreiramendes deleted the fix/RMET-4360/timeout-logic branch November 4, 2025 15:53
OS-pedrogustavobilro added a commit that referenced this pull request Nov 19, 2025
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.
capacitor-bot pushed a commit that referenced this pull request Dec 8, 2025
# [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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants