React-native-geolocation-service: Geolocation fetch is taking too long

[omer-to]

Hello,

Thanks for the library. I am using the package as follows and the geolocation of the device takes almost half a minute to be fetched. Is this the normal behavior and is there anything I can do?

  Geolocation.getCurrentPosition(
            (position) => {
                const latitude = position.coords.latitude
                const longitude = position.coords.longitude
                store.dispatch(setUserCoordinates(latitude, longitude))
            },
            (error) => {
                return;
            },
            { enableHighAccuracy: true, maximumAge: 10000, 0 }
        )

[sataporn8063]

I have the same problem,

[gregoryfm]

Same here, any news?

[Agontuk]

You can use watchPosition/clearWatch method to retrieve location once, it should take less time. getCurrentPosition tries to obtain location as accurate as possible, hence the delay.

[gregoryfm]

Hi @Agontuk thanks for your work.

In my case, I need the most accurate location possible.
On android I get the result quickly, but on ios it takes 10s, sometimes more, to get the position.

I tested the geolocation package and the opposite happens. On ios I get the result instantly but on android, it takes longer...

PS: I upgraded to the latest version 5.1.1 and it still taking too long.

Thanks

[thanhluantl2304]

Any update on this?

[NoahFace]

The cause of this issue is the following in RNFusedLocation.swift:

let locManager = CLLocationManager()
locManager.delegate = self
locManager.desiredAccuracy = getAccuracy(options)
locManager.distanceFilter = distanceFilter
locManager.startUpdatingLocation() //<<<<<<<<<<<<< requestLocation()

If you change requestLocation() to startUpdatingLocation(), IOS location services will start returning location values immediately rather than after 10 seconds. It might be necessary to also call manager.stopUpdatingLocation() at the end of the cleanup code, but I think setting the delegate to nil (which already happens) will do this automatically.

@Agontuk, any chance you could publish a new patch with this change in it?
It is a fairly serious problem which makes the package almost useless on iOS currently.

[NoahFace]

Following on from the above, I think it is good practice to put in the call to stopUpdatingLocation() in both of the cleanup sections as follows. I'm not certain setting the delegate to nil will be sufficient, and if its not it will risk battery drain.

// Cleanup
timeoutTimer?.invalidate()
successCallback = nil
errorCallback = nil
manager.stopUpdatingLocation()
manager.delegate = nil

[tomoima525]

Hi @NoahFace
I changed the code locally with the fix you suggested but seems it did not work on my side(on iOS 14.1 simulator/actual device). Do you set { enableHighAccuracy: true } in your option? Would you be able to share the implementation on the JS side?

[NoahFace]

The local fixes I suggested definitely fixed the 10 second issue for me on IOS, and I have not found any side effects.
Make sure the module is being rebuilt - perhaps insert some logging.
My settings are as follows:

    Geolocation.getCurrentPosition(
          (position) => {
            ....
            }
          },
          (error) => {
           ......
          },
          {enableHighAccuracy: true, timeout: 12000, maximumAge: 30000, showLocationDialog: true}
        );

HTH.

[Agontuk]

The cause of this issue is the following in RNFusedLocation.swift:

let locManager = CLLocationManager()
locManager.delegate = self
locManager.desiredAccuracy = getAccuracy(options)
locManager.distanceFilter = distanceFilter
locManager.startUpdatingLocation() //<<<<<<<<<<<<< requestLocation()

If you change requestLocation() to startUpdatingLocation(), IOS location services will start returning location values immediately rather than after 10 seconds. It might be necessary to also call manager.stopUpdatingLocation() at the end of the cleanup code, but I think setting the delegate to nil (which already happens) will do this automatically.

@Agontuk, any chance you could publish a new patch with this change in it?
It is a fairly serious problem which makes the package almost useless on iOS currently.

You can just use watchPosition/clearWatch to get a one time location which uses startUpdatingLocation and stoptUpdatingLocation internally.

The reason I'm using requestLocation is because it tries to provide an accurate location by using gps, whereas startUpdatingLocation will give you the last known location (that's why it's faster).

So I'm still not sure if I should change this behavior.

[NoahFace]

You may well be correct. However, the practical issue is that the way the code is written currently, it nearly always takes 10 seconds to get a position read on iOS (in my experience), which is impractical for many applications.
A lot of people have tried to switch to this package because the alternative was slow on Android.
This package currently has the opposite issue in that it's too slow on iOS to be useable.
I don't think its practical to suggest to people they should use watchPosition/clearWatch to get a one time read when that's exactly what getCurrentPosition is supposed to do, and those using the package should not need to have an understanding of how the package works internally (nor do we want them coding in different ways on Android vs. iOS).

I have three ideas:

A. Maybe the getCurrentPosition code should:
- Use the current logic if enableHighAccuracy = true.
- Use the logic I have suggested if enableHighAccuracy = false.

B. Another alternative approach might be to call startUpdatingLocation but not accept the first reading that comes back.
Rather, take the last reading that you have in say 2 or 3 seconds (or make this time configurable).

C. There is already a maximumAge option. So, you could call startUpdatingLocation() but honour the maximumAge setting to avoid returning stale locations (rather than relying on a maximum wait time as in B).

If it really does typically take 10 secs to get an accurate enough GPS read on iOS, then only A is going to cut it.

[tomoima525]

The local fixes I suggested definitely fixed the 10 second issue for me on IOS, and I have not found any side effects.
Make sure the module is being rebuilt - perhaps insert some logging.
My settings are as follows:

    Geolocation.getCurrentPosition(
          (position) => {
            ....
            }
          },
          (error) => {
           ......
          },
          {enableHighAccuracy: true, timeout: 12000, maximumAge: 30000, showLocationDialog: true}
        );

HTH.

@NoahFace Just wanted to let you know your suggestion fixed the issue. (Turned out the code was not updated properly on my end)

[manjinderr]

I am using this library from last 2 years. It is great. Thanks.

This library was working well up to version 4.0.2. getCurrentPosition returns location within 1 second.

I updated it to V5.1.1 on noticing below issue on IOS 14.2 and 14.3:
https://github.com/Agontuk/react-native-geolocation-service/issues/230

Now, the latest version 5.1.1 returns location after 10 seconds.

Here are more details:
1) Library version 5.1.1
2) enableHighAccuracy: true
3) Platform : IOS
4) Method: getCurrentPosition

This long delay is noticed on V5.0.0+.

Do you know what is changed from V4.0.2 to 5.0.0 that introduced this issue.

Are you going to fix getCurrentPosition for long delay issue.

This is breaking IOS app and is a blocker.

[stazrad]

@NoahFace I think you have some good ideas on this...following

[manjinderr]

As the issue above was critical to our IOS app, I used the original geolocation community plugin.
https://github.com/react-native-geolocation/react-native-geolocation
This solved the problem for now.
Our Android app is using Agontuk and IOS is using Community plugin.

[stazrad]

@manjinderr just did the exact same thing- now I'm using a combination of both libs...this one to ask for the initial location permission & the other to .getCurrentPosition 🤦‍♂️

[Agontuk]

Master branch is now updated with the fix, please try & see if it works for you. I'll release a new version soon.

I wanted to see if there's any other solution, but seems like it'll be good enough for now.

[KingAmo]

Master branch is now updated with the fix, please try & see if it works for you. I'll release a new version soon.

I wanted to see if there's any other solution, but seems like it'll be good enough for now.

i have tested the master branch and it works for me, when will you start a new release? I can't wait for it.

[thanhluantl2304]

when will this fix be released? I'm still waiting for it!

[FadiAboMsalam]

@Agontuk WHEN this will be released ?

[Agontuk]

v5.2.0 has been published.