Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not returning location when location method is "Device only" #14

Open
hortemo opened this issue Dec 17, 2017 · 11 comments
Open

Not returning location when location method is "Device only" #14

hortemo opened this issue Dec 17, 2017 · 11 comments

Comments

@hortemo
Copy link

hortemo commented Dec 17, 2017

Hi! I am not able to get a location when using:

  • getFusedLocation(true)
  • FusedLocation.Constants.BALANCED
  • ACCESS_FINE_LOCATION
  • Location method "Device only"

This is on a real device for which i.e. Google Maps works fine. It works fine for other location methods (High Accuracy and Battery Saving).

Is this your experience as well, or is it most likely something on my part?

@MustansirZia
Copy link
Owner

MustansirZia commented Dec 18, 2017

Hi!
Does it go inside the catch statement or the promise just never resolves?

@MustansirZia
Copy link
Owner

Also, what do you mean by Location method "Device only"?

@lone-cloud
Copy link

Well Android has 3 Location modes that you can set: High accuracy, Battery saving and device only. He must be referring to the later.

@hortemo
Copy link
Author

hortemo commented Dec 19, 2017

Yes, I am talking about the location mode in Android settings. I get no error, it just never returns any location data.

@MustansirZia
Copy link
Owner

Hi @hortemo! A more likely cause for this problem is that since you're using Device only and forcing a new location update your device is not able to get a location as your device maybe somewhere indoors or has a poor internet connection. You've optimally set the mode to BALANCED but externally forced your device to get a new location from your GPS only. I think I should probably implement a timeout feature just so these cases are taken care of.

@Neha1490
Copy link

Neha1490 commented Jan 15, 2018

@MustansirZia - Hi, I am also facing the same issue.
I have tried to change Location Priority as HIGH_ACCURACY but still getting the same issue.

In some of the devices its getting lastLocation as null and getting request.getPriority() = 100 but is is not able to get location again and it is not going in catch block also.

@sraka1
Copy link

sraka1 commented Feb 18, 2018

@MustansirZia the problem seems to be that if the device setting is set to "Device Only" (GPS only), trying to get the location with "balanced" accuracy never works (irregardless of GPS signal strength). This can be replicated easily in the simulator. A timeout is a good idea. Reading this setting and acting accordingly would be even better.

EDIT: According to https://stackoverflow.com/questions/35830987/fused-location-provider-is-there-a-way-to-check-if-a-location-update-failed, it would be good to replace the LocationListener here with a LocationCallback, which has a onLocationAvailability method which is always executed and provides a status regarding the availability of the location (meanwhile the onLocationChanged method of the LocationListener has no guarantees on being executed).

@MustansirZia
Copy link
Owner

MustansirZia commented Feb 19, 2018

@sraka1 You're probably right, it's about time we make use of a more appropriate callback. LocationCallback does seem a better way to go than the original LocationListener . This requires attention.
I still, however, want to know why the "balanced" accuracy fails with "Device Only", that also requires some attention. Whenever I get time I'm going to look at this and hopefully come up with an update.

@MustansirZia
Copy link
Owner

MustansirZia commented Feb 28, 2018

Package updated to 0.2.1 8f64dbb which makes use of LocationCallback instead of LocationListener. This would guarantee that the promise would get rejected if no suitable location could be returned (Fresh or old). As @sraka1 had pointed out earlier, LocationListener had no way of knowing that the request had failed inside it so a LocationCallback was a good way to go.
This should also eliminate the need for a timeout.

@ingvardm
Copy link

ingvardm commented Mar 6, 2018

actually just saw this bug. If no one else is working on it, ill try to find some time in the next few days and look at it.

@MustansirZia
Copy link
Owner

It didn't go inside catch statement? Which version of the library are you using?

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

No branches or pull requests

6 participants