LOCATION_ONE_SHOT always QUALITY_LAST_KNOWN?

Yes, I thought so.

However, this means I have to do the workaround only for the va-hr.... for a while (hope so)...

The workaround is not that difficult. Instead of using LOCATION_ONE_SHOT, you use LOCATION_CONTINUOUS and check the quality to determine if you want to disable GPS data again. I _think_ that this code should work to do that. It displays a progress bar while acquiring position data. You could easily pull the progress bar out if you didn't want it.

class AcquireGPSDelegate extends Ui.BehaviorDelegate
{
hidden var _M_callback;
hidden var _M_maxage;
hidden var _M_quality;

function initialize(callback, maxage, minquality) {
BehaviorDelegate.initialize();
_M_callback = callback;
_M_maxage = -maxage; // we want this to be negative
_M_quality = minquality;

Position.enableLocationEvents(Position.LOCATION_CONTINUOUS, self.method(:onPosition));
}

function onBack() {
Position.enableLocationEvents(Position.LOCATION_DISABLE, null);
}

function onPosition(info) {
if (info.accuracy == Position.QUALITY_LAST_KNOWN) {

// this is a subtraction (we are adding a negative duration)
var oldestAllowed = Time.now().add(new Time.Duration(_M_maxage));

// the position sample is older than we will allow
if (oldestAllowed.greaterThan(info.when)) {
return;
}
}
else if (info.accuracy < _M_quality) {
// poor signal, just ignore
return;
}

// we got good position data, stop receiving position updates
Position.enableLocationEvents(Position.LOCATION_DISABLE, null);

// notify the caller of the position
_M_callback.invoke(info);
}
}

// somewhere in your code...

var view = new Ui.ProgressBar("Acquiring GPS...", null);
var delegate = new AcquireGPSDelegate(self.method(:onPosition), 60 /* seconds */, Position.QUALITY_GOOD);
Ui.pushView(view, delegate, Ui.SLIDE_UP);


I only have one widget in the store that uses ONE_SHOT, and then, other than the first time it's used, only when the user requests a new location based on GPS (they can also use "settings" to set a station name, which could be more common).

Anyway, the last couple days been debating what to do... With just the va-hr impacted, I could wait for a fix and suggest the "settings" option for va-hr users, do a special for the va-hr in the app with the work-around, or just use the work-around for all devices (easier to code and remove later).

I went with the "work-around for all" approach (later, it will be commenting out 2-3 lines of code and un-commenting 1 to remove).

(the work around is starting with CONTINUOUS and then DISABLE when I get a location with an accuracy of poor or better)

I've tested it on various devices, and the only difference I see (and not a biggie), is that on a 230 I somethime get a "toast" when GPS is first locked. I'm going to stick with the "work-around for all" for now...

@TRAVIS.VITEK: My code looks similar, but without the "info.when" part. Thanks for that, I will give it a try.

@jim_m_58: I draw the screen dynamic depending on data I got from a json, so I need to know on which device I am. Therefore it's not that much effort for me to check if va-hr or other watch. But I understand your point.

Phil - "when" really only comes into play when the accuracy is "last known", as with the other values, it's always "now". With "last known", looking at "when" could be used to see if it's only a minute old, or an hour and you could decide if you want to use it or not as Travis does in his code. With the work-around and CONTINUOUS I did, I just ignore the "last known" (which I may never see) and wait for "poor" or better, so no check of "when" needed.

I did try my test app on a va, and while it did generally fire up GPS for each one_shot, if I ran the app twice - right after each other - I did see a "last known" status at times on the second run, but it had to be within a minute or so. I think this is Ok, as how much does your location change in a minute? But something to consider if you support both the va and va-hr, so maybe check "when" on devices where you still use a one_shot?

With "last known", looking at "when" could be used to see if it's only a minute old, or an hour and you could decide if you want to use it or not as Travis does in his code.

Sorry, if I wasn't clear enough.

At the moment, I'm using "CONTINUOUS" in my code and keep searching until the GPS is "USEABLE".
But when I got a "LAST_KNOWN", I let the user decide via "hold" on the screen to use it or to wait for better GPS.

pro: if the user doesn't move for hours, he can still use it's last known position - even indoor
con: maybe the usability / user has to know it's last position



I'm not happy at all with this solution.


But with the "when" - as you say - I can check if it's not older then 5 minutes, just use it and go ahead.
Otherwise the user has to wait....

One thing to remember with widgets on wearables (they are different on things like an Edge or Oregon - there they run "forever" - like a device app), is the "widget revert time". IIRC it's about a minute on the va-hr and forerunners, 45 secs on the va (if the widget has comm permissions, and only 10-15 if not). So giving the option to just wait might result in the widget timing out and going back to the watchface, depending on how long it takes to get GPS. (this can be extended if the user interacts with the screen, as the timeout resets).

In the case of my widget, I save the station/location from the last GPS data (and allow the user to edit it with settings), but also allow the user to request a new location by way of a button press in the widget (and if GPS is OK, the new station/location becomes the saved one). This is probably why I hadn't seen the "last known" issue sooner, as most of the times, the saved location is fine and GPS isn't needed.

Just something to consider - I don't know what your widget is for, but maybe you could default to the saved location, request and display the data for it, and if the user knows location has changed, allow the user to request a new location (which resets the timeout because it's a user interaction), and data for that location at that point? (if the data indicates the location, it would let the user also know the location needs to be updated) It would allow the widget to display data faster if the saved location is often OK, and only take the extra time for GPS if requested. (GPS can take longer than a makeWebRequest() )

If your widget is often used in the same location, skip the whole GPS part, and then it doesn't matter if you're in a place where it's hard to get GPS (inside a building, etc).

gambaramyrtle

I did some testing on the weekend with GPS quality "POOR". It was pretty fast and accurate enough.

I gather public transport information around the users position with a radius of max. 500m (due to json limits on hot spots).
Therefore, in most cases a new GPS signal is necessary.

Maybe I let the users decide via settings -> "always new GPS" or "button press GPS" -> depending on their preferences.

Thank you for the hint.