GPS Quality required in Data Field

Activity.info.currentLocationAccuracy

Same values as in position.

Thanks Jim, that had completely passed me by in the documentation!

Something to note, is that in the sim, the quality is what you set it to in settings, and doesn't change based on the data being played back in a .fit.

What I do (really just for the sim) is check the lat/lon. If they are 180' or -180 (it might be 90 and -90 for lat), consider it bad data. (I have a .fit that I found this - GPS is bad for a short period of time - maybe a tunnel - but it takes a long time to get to the spot where this happens!). I do recall that when this does happen (again, just the sim), elapsedDistance gets messed up, as the bad reading is used...

Thanks Jim. I've used the GPS Quality on App Testing in the Sim before, and it works better as you can turn the quality right down and make sure the app responds correctly.

Ok, spotted a bit of a SDK shortfall here :p

I can easily work-around this by using the numerical values but...

The currentLocationAccuracy property on Activity.Info documentation says:
Returns:
(Number) — Position.QUALITY_XXX value


So the Activity.Info class cross references the Position Class.

Now, this assumes you have permission to the Position Class, which of course you don't on Data Fields. Therefore you can't check the currentLocationAccuracy property with the desired constants, as they are not accessible.

Cheers
Chris

Ok, spotted a bit of a SDK shortfall here :p

I can easily work-around this by using the numerical values but...

The currentLocationAccuracy property on Activity.Info documentation says:
Returns:
(Number) — Position.QUALITY_XXX value


So the Activity.Info class cross references the Position Class.

Now, this assumes you have permission to the Position Class, which of course you don't on Data Fields. Therefore you can't check the currentLocationAccuracy property with the desired constants, as they are not accessible.

Cheers
Chris

You can replicate it with something like this:

enum {
GPS_QUALITY_NOT_AVAILABLE,
GPS_QUALITY_LAST_KNOWN,
GPS_QUALITY_POOR,
GPS_QUALITY_USABLE,
GPS_QUALITY_GOOD
}


Thanks.

The reason for highlighting, is the best solution is one from GARMIN, as anything we do will never guarantee a match to the Position constants, and if they change.

For example if GARMIN adds a GPS_QUALITY_VERYPOOR before POOR it throws out a self implementation.

Now this may never happen, but the purpose of constants is to remove the need to worry about the underlying values, and if they change.