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

[OS-ruimoreiramendes]

Description

This PR adds a new IONGeolocationLib library (version 2.0.0) that includes logic to handle timeouts for both getCurrentPosition and watchPosition.

Context

• https://outsystemsrd.atlassian.net/browse/RMET-4360

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-pedrogustavobilro]

@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 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

[OS-pedrogustavobilro]

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.

[OS-ruimoreiramendes]

Thanks

[OS-pedrogustavobilro]

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?

[OS-ruimoreiramendes]

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

[OS-pedrogustavobilro]

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.

[OS-ruimoreiramendes]

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.

[OS-pedrogustavobilro]

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.

[OS-pedrogustavobilro]

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