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

timeoutMilliseconds on IOS seems to depict how long the GPS will take to return #39

Closed
wickedw opened this issue Oct 24, 2016 · 3 comments

Comments

@wickedw
Copy link

wickedw commented Oct 24, 2016

Please fill out either the bug or feature request section and remove whatever section you are not using.

Possible Bug

Running the included SAMPLE app produces some strange behaviour with the timeoutMilliseconds parameter.

On IOS Device, if I set this to 10 seconds as per sample (no code changes) then the GPS will come back eventually BUT is really slow, it wont timeout but takes approx 10+ seconds (did not time it exactly).

If I set timeoutMilliseconds to 1000 ms, then the GPS comes back (seemingly correct) after 1 second.
If I set timeoutMilliseconds to 500 ms, then the GPS comes back (seemingly correct) after 0.5 seconds?

Yes, this does not make sense, I could be doing something wrong, but I am not modifying the sample in any other way, could the async task code IOS imp be getting confused on when it is supposed to return its result?

NOTE The IOS emulator comes back instantaneously no matter the setting.
Droid (used S3) seem to use the timeout as expected.

UPDATE: After looking at the plugin code, I noticed that the accuracy of 165 of the returned IOS GPS was > then 50 default, so when setting the desired Accuracy to 200 it comes back instant :) but I would like to know why it does return the same result on the timeout above.
I "think" I can see what could be happening in the code for this to happen, will dig further.

Version Number of Plugin: 3.0.4
Device Tested On: IOS 10

Steps to reproduce the Behavior

Run the sample with various GPS timeoutMilliseconds as above.

Thanks for your help

Best
Matt

@alanspires
Copy link

+1 this is the same behavior I have seen in my production apps on latest beta versions.

@wickedw
Copy link
Author

wickedw commented Oct 24, 2016

In GeolocationSingleUpdateDelegate,

This code will ignore the update location from IOS on the first call as its accuracy is too low (50 versus 165 in my case) -

if ((!this.includeHeading || this.haveHeading) && this.position.Accuracy <= this.desiredAccuracy)
{
            this.tcs.TrySetResult(new Position(this.position));
            StopListening();

}

and then this timer will fire again on the timeout, notice that haveLocation is now true and then will return the result regardless of previous accuracy check.

  Timer t = null;
            t = new Timer(s =>
            {
                if (this.haveLocation)
                    this.tcs.TrySetResult(new Position(this.position));
                else
                    this.tcs.TrySetCanceled();

                StopListening();
                t.Dispose();
            }, null, timeout, 0);

Just Brainstorming


Not sure what we actually want here?
We could just set the accuracy as wide as we can manage as a user, but worth discussing ...

We might be expecting from this call -

"Get us our CurrentPosition within the desired Accuracy within the time limit?"

and its performing -

"I will try once, get the first location returned, ignore it if its not accurate; and then wait for the rest of the time limit doing nothing before giving you my original answer".

You could move the haveLocation = true inside the accuracy check which would make it work more clinically in that it will say it did not get a GPS in the time limit and then return null, but maybe we need some nice way of saying, I would like accuracy of X but Y is really fine if we will have to wait all day? not sure at all but worth thinking about.

Great plugin as ever BTW, thank you, will widen my accuracy for now.

@alanspires
Copy link

alanspires commented Nov 9, 2016

I have my accuracy set to 1609 meters (1 mile) and this still occurs 75%+ of the time. So I don't believe accuracy is the issue.

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

2 participants