Ticket Created
over 3 years ago

WERETECH-10061

Wrong Activity.getActivityInfo().currentLocation on fenix 6 pro

I seems that Activity.getActivityInfo().currentLocation returns a position object with lat/lon coordinates of 0 (zero), instead of returning null.

In watch faces, Activity.getActivityInfo().currentLocation is used to get current or recent GPS position retrieved by GPS fix from last activity.

When GPS fix expired after some time, Activity.getActivityInfo().currentLocation should return null.

But on my fenix 6 pro it seems to return a position object with lat/lon coordinates of 0.

Code used in watch face:

var location;
var locationArray;

location = Activity.getActivityInfo().currentLocation;
if (location != null) {
   locationArray = location.toDegrees();
}
-
On my fenix 6 pro location var is not null and locationArray is [0.000000, 0.000000]
On my forerunner 645 location var is null, which is correct.
Simulator is also correct with fenix 6 (pro).
  • Never ending bugs observation #384848 from user #374: the watch is not ashamed to return even Position.QUALITY_POOR accuracy when the location is unknown together with position [0,0] while the user is really not on the equator. 

    So all developers must test all erroneous values mentioned below regardless of any accuracy value. 

    PS: I'm slowly starting to think on starting a Kickstarter project to fund Garmin a QA and at least one senior developer who understand what quality of code and automated testing means. Anybody with me?:)

  • Yep. I wanted to point out the bugs that others might expect.

    To summarize known bugs: unknown position might be represented as any of: null, [0,0], [180,180] and who knows what else, so testing the range as you suggest might be a good idea. According to the report above, it can happen even with QUALITY_LAST_KNOWN. 

    It would be also great, if Garmin developers could fix it and document how the accuracy is set when the Toybox.Position is set from the phone rather than activity (if it really works like that as it seems). 

    End of report:) 

  • Notice the ">=" for Position.QUALITY_POOR.  It's not a ">".

    what you're seeming is simple to handle.  If you get a location with an accuracy less than that, or with a glaring issue (lat>90) don't use it, but have your last good location saved in Application.Storage.

    If you get something good, save it to Application.Storage.

    Then for sunrise/set, use what's in application storage.

    I do this all the time for things like sunrise/set and weather data.

  • It could work when you want to know what is the current accuracy, but not if you need the nearest position approximation available. (e. g. for sunrise/sunset position or weather forecast). 

    In your proposal the watch wouldn't get the position: 
    a) when it was acquired recently, but not updated ever since
    b) when the guy moved back from an activity that was 100 kms away back to home and his position was updated by a phone location, not a GPS activity again. 

    According to my observation it seems that the Toybox.Position.Info.position returns a position even in these situation, although with [0,0] and [180,180] bugs. 

    Testing for Position.QUALITY_POOR would mean user won't get a sunrise/sunset position and weather forecast even when an approximate position is available. 

  • This is why accuracy/quality is available.

    A simple test if the location is really available, like

    if(info.accuracy>=Position.QUALITY_POOR) {

    The meanings are documented here: developer.garmin.com/.../Position.html