[ConnectIQ Feature Request] Fallback to mobile device for location

Former Member over 9 years ago

There's a lot of apps that use location information to provide data, apps like weather or tidal info etc.

Users want these apps to work when they're indoors or otherwise in locations that make a GPS lock difficult. Mobile operating systems have gotten pretty good at providing location information without GPS locks, because of cell phone towers, wifi harvesting and various other voodoo.

It seems that it would be pretty easy to add location lookups to the Garmin Connect application that runs on phones and have devices like the Fenix fallback to that when trying to find location if GPS quality is poor.

Interested to know what you guys think, it would certainly make the apps I'm working on at the moment work a little better.

Cheers
-Rob

jim_m_58 over 9 years ago

There's a lot of apps that use location information to provide data, apps like weather or tidal info etc.

Users want these apps to work when they're indoors or otherwise in locations that make a GPS lock difficult. Mobile operating systems have gotten pretty good at providing location information without GPS locks, because of cell phone towers, wifi harvesting and various other voodoo.

It seems that it would be pretty easy to add location lookups to the Garmin Connect application that runs on phones and have devices like the Fenix fallback to that when trying to find location if GPS quality is poor.

Interested to know what you guys think, it would certainly make the apps I'm working on at the moment work a little better.

Cheers
-Rob

What I do for my weather stuff is save the last good location in the object store, and use it, if available, but give the user a method to update that location by doing a ONE_SHOT GPS lookup. Therefore, I don't need a good GPS whenever I run my stuff.

Trying to get a location from your phone would mean that you would need to have your phone with you, and you still might not get a good GPS.

Former Member over 9 years ago

What I do for my weather stuff is save the last good location in the object store, and use it, if available, but give the user a method to update that location by doing a ONE_SHOT GPS lookup. Therefore, I don't need a good GPS whenever I run my stuff.

Trying to get a location from your phone would mean that you would need to have your phone with you, and you still might not get a good GPS.

I think it's good app design to cache things like location but caches only last so long. While it's true that a mobile phone location might not be perfect it's probably going to be a lot better than a ONE_SHOT simply failing because the user is indoors.

I'm not suggesting a mobile be the primary location source but I think it would greatly enhance the user experience if my watch was capable of doing semi-reasonable fixes in more conditions than it can currently.

jim_m_58 over 9 years ago

I think it's good app design to cache things like location but caches only last so long. While it's true that a mobile phone location might not be perfect it's probably going to be a lot better than a ONE_SHOT simply failing because the user is indoors.

I'm not suggesting a mobile be the primary location source but I think it would greatly enhance the user experience if my watch was capable of doing semi-reasonable fixes in more conditions than it can currently.

Storing the last good location in the Object Store isn't a cache that expires. Once you store it, it's there as long as you want it.

On the watch itself, when requesting GPS, you may get a status of "last known position", and that is a cache that seems to stick around for an hour or two after the last time you used GPS and got good data. I save the location myself and don't use that cache.

Think of using the OS as you're last known "state", and not as a cache that expires. With my weather stuff, that "state" is the last location I got the weather for (usually my house), but by hitting something like menu, I can update that "state" to my current location.

julienvm over 9 years ago

One problem with cached location is that information will be wrong if user changed position. In this case, I think it's critical for the user to know which location is being used.

I therefore propose (in widget "Location Check - BETA") caching of both the location and the address (here city & country name), so that user knows what location is being used, and can decide whether or not to get a GPS update.

Otherwise it's always possible to get a location through internet via an API that locates the IP address of the phone. (something like http://mylocation.org/) But of course, you may get the phone operator's location instead of your own. Haven't tested that.

Former Member over 9 years ago

By "expires" I meant that it may become invalid over time, if the user changes locations between uses, which isn't hard to imagine.

JulienVM - you don't need to call out to a third party service, most phone SDK's expose a getlocation function. Literally all that's required is a small change to the Garmin Connect service (that manages things like makeJsonRequest) so that you can make a location request direct to the phone.

jim_m_58 over 9 years ago

By "expires" I meant that it may become invalid over time, if the user changes locations between uses, which isn't hard to imagine.

And that's why based on an action by the user, it will fire up GPS with a one shot to update the location and get the data for the new location. For things like a widget, using the last saved location will speed up the widget, as it can often skip the whole GPS part. And there could also be times the user wants data for a specific location, and not their current one (such as the weather at home, or maybe tide data for a specific location).

Former Member over 9 years ago

You can make every app developer try and compensate for those times when GPS fixes are hard or you can make it so your smart watch can take advantage of the data that's already on the phone it's paired with.

It's great that you've written an app that doesn't need this. I have too, though I'd prefer to have not had to, seriously, this seems like a no-brainer to me. The functionality is right there on the phone SDK, all that's required is a tiny change to the Garmin connect background process to do the passthrough and some decisions as to wether this should be rolled into ONE_SHOT or add a ONE_SHOT_FALLBACK_TO_PHONE or similar...

Nikeow over 9 years ago

I agree with this. There should always be a backup plan.
Just like A-GPS on the iPhone. Lock is instant.

jim_m_58 over 9 years ago

It just seems to me, that if a watch with GPS can't get a GPS fix and an app needs it, you can just show a message like "Step outside to get GPS" if there isn't a fix after x seconds, vs adding logic to get a "guess" from a phone.

The standard apps on the watches seem to handle a lack of GPS ok...

Former Member over 9 years ago

First off, that "guess" is at least as accurate as the watch if the many pages of feedback on the Garmin forums and Facebook are to believed.

Second, on what planet is it a good user experience to ask the user to change location in order for their app to work - especially when there's a decent source of location information freely available?