Thoughts about accessing Current Position

There are certain common uses of continuous sampling of the exact location of a phone that are/could be baked into Glide’s underlying functionality with the assurance that these values cannot be stored.
Use cases include:

  • the (currently implemented in the Data Editor) Distance to Location action: Return the distance from where the phone is currently located to a specific location.

  • Show the phone’s current position on a map – a feature request that has been made, but not implemented today. I am hopeful that this will appear before long.

Note: you can get several useful location capabilities today by going to another app on the phone that will provide this functionality showing position as well as driving/walking/cycling directions. On an iPhone when you tap on a map component (not the map of multiple items), the Apple Maps app (known to exist on all iPhones) will be fired up giving you these capabilities.

BUT, from a User Experience (UX), this is an interruption to the use of the Glide app. It would be better if the map component implemented these two capabilities directly. I assume on an Android phone the standard app GoogleMaps (similarly known to exist on all Android phones) is fired up when you tap on a map component.

We need to catalog these approaches to support the most common use cases for the current position while still limiting the ability to track a user. That, after all, is what it means to build applications without having to write programs – a worthy goal.

Although I understand the reason for restricting the permission to look at your location to one sample, I think this reduces the power of location-awareness because in some sense, tracking the position of a person is an important and useful capability. For example, on a walking tour (my current interest) it is nice to be able to see if you are walking in the right direction. This does not work if the user has to give permission every time the current location is sampled. Clearly, the functionality of tracking (with the standard blue dot) the location of the phone could be done inside map component without the ability to get ahold of the value of the location BUT, there are other potential uses of the current location that are not covered by tracking current location with a blue dot.
I wonder if the standard way I have seen used of asking permission at the start of an app (or perhaps every period of time) would be a reasonable compromise. Those users who do not want to be tracked at all would be able to deny permission once at the start of the app (or every period of time) in which case functionality that needs multiple updates of location could be disabled. This would be better than asking permission every time the current position is requested.

The app I am currently working on would be a lot more powerful if it was able to continuously update the user’s position over a period of time. Even if it was every 5 minutes, that would be great.

My client and I would like to know if this is anywhere in the product pipeline?

I was trying a hacky HTML solution, but it appears scripts are stripped out from the code on render.

Here is my Feature Request.

Is it possible, probably yes, but I think Glide purposely doesn’t want to put people in a position where they could potentially be unwillingly tracked. So my guess is not anytime soon.

I’m sure people have legitimate reasons for this feature, but if it would be that easy to add location tracking, then there could potentially be millions of us building free or cheap apps to track a user’s locations without proper notification. I think it starts getting into a very gray area regarding privacy and security. You may get permission via a simple switch to request location once, but then that bit is set in the browser and an app can request location for any other reason without prior notification to the user. I think it would be used maliciously more often than not.

3 Likes

Jeff, I understand your points about potential abuse by developers. I guess the solution until something better comes along is to only permit a single sampling of location initiated by intentional user interactions. So, for example, automatic updating of a screen that shows nearby locations of interest is out. I assume prohibiting continuous sampling is enforced by requiring the user to click on the image button on a map – as well as never returning the current location to the app.

Well, if you want to show nearby attractions with a constantly updating list, that’s easy to do with a Distance column that can measure the distance from a user’s current location to a point of interest. Then simply set a filter to only show POI’s within a certain distance. There are no restrictions on that because distance is calculated only on the user’s device and doesn’t share that location back to the server.

The same can be said for the image button on the map. It’s only determining a user’s location only on their device and doesn’t share anything with the sheet or table back at the server.

The only way to get a user’s location back to the sheet on the server is to use the location component, which explicitly asks the user for permission to share their current location back to the database, and thus to be shared with other users if the developer sets it up that way.

2 Likes