I am looking for a way for a transport company to track the location data of a vehicle permanently so that the time to the next customer can be calculated.
The user should be informed about this, that’s no question.
This doesn’t work with the location component because the switch always turns off.
Is there now a workaround for how this can work?
BTW: The radar integration doesn’t help me either, because here too “track once” is only triggered by an action.
I’m going to be honest here. I don’t think a web app is well suited for something like this. I say that because it requires an app to be open and active on the screen at all times. Turning the screen off or switching to a different app on your device is going to kill that connection, so drivers would not be able to use their device for anything else or be able to turn the screen off. Plus, for it to work with the native location component, it would require constant and rapid updates to the table, which I’d guess is not something glide would like.
I’ve dabbled a little bit with location in some personal apps. The location component is more suited for getting a location once or using it while actively interacting with the app. I don’t think it was ever intended for something like live user tracking although it can technically do that to some degree. In my experience it’s never been fully reliable for live tracking. In this app below, I store the location in a user specific column in an app I’m not signed into just to prevent unnecessary writes to the table. Fun to play with, but not something I’d use in a production environment.
Outside of Glide, I’ve built a simple HTML page that can continuously monitor my location and draw a track on the screen as I move. It’s not something I can embed in a Glide app because location info is not accessible within an iframe web embed for security reasons, and there is no way to directly integrate it with Glide tables unless you start using the Glide API which will chew through update real quick. However, as soon as I turn my screen off or navigation away from that page (which runs locally on my device), it’s no longer tracking.
I’ve also dabbled with websockets in a page that I have embedded into a Glide app. This is for a music app I made that lets me remote control it from another device. Websockets allow for a somewhat direct connection between devices or multiple devices and allow for rapid fire updates to be shared between device. Again, these pages need to be active on the screen to reliably maintain that connection, which can sometimes drop. Plus I need to be mindful of the number of data packets I’m sending since I’m limited with the service I use.
With all that said, based on my experience, it’s difficult to track live location and share it with others, especially with a web app. Possible…yes, but in a web based app, I don’t think you will ever have a reliable long term experience. I honestly think something like this is only going to work well with a native app that can better run in the background of the device and have access to GPS data and a server that can handle the rapid fire traffic.
You mention transport, so I don’t know if that means long haul over the road travel or something more like a local in-town delivery service. I think you might have better luck having check-ins where a driver presses a button or edits a row periodically as they do their deliveries. Amazon delivery for example only updates locations at each stop, so I never see real time location… just location of the last stop.
first of all, I would really like to thank you for this detailed explanation.
I really appreciate it!
Thanks for the input. I already had the idea of integrating it into the delivery process. I’ll have to think about it a bit more though.
The workflow is such that the supplier first goes to a pick-up address, loads something there and then goes to a delivery address. This means that a tour always has 2 destinations (pick-up location and destination).
I want the customer to be able to see ( as with Amazon ) where the driver is currently located so that he can estimate how long it will take him to arrive at his pick-up location.
It just has to be foolproof, you know! Some kind of complex check-in and check-out mechanism won’t work, i think. People forget that and then the system is useless.
I once read here that the topic of time-based actions is in the beta phase? When the feature comes, I could theoretically call up “Track once” every 15 minutes. Do you know more about that?
That’s understandable. Yeah, it’s a little more difficult to get updates if you only have a single origin and destination.
I’m not participating in the close beta, so I don’t know what it will all be capable of. I have doubts though that you would be able to do anything with a time based action. Time based actions run server side against the data sitting on the server, and the server is not going to have any awareness of a particular user’s device or it’s current location. I just can’t see how it would be possible. Location needs to be sent to the server from the device. The server can’t reach out and get it. Plus, you still have the fact that a user has to interact with the location component just to get it to update a location in the table.
I still feel that the most dependable option would require a native app that can run full time in the background of the device. Or at the very least, a third party app that has an accessible web based API that can be queried periodically by your app.
This is a very important point regarding the closed beta. An example of it is any thing related to datetime, say a “Now” value, might not be in your own timezone (unless you configure a flow to get it in your own time), but the server’s time. I learned this the hard way when I first tried it.
I imagine it to be something like this:
I use “radar” as an application in glide.
With radar you can, for example, fire “Track once” via an action.
The action is triggered by a button at the moment.
This means that every time the button is pressed, the user reveals his location.
Later, the same action is triggered by a certain time.
This means that the user no longer needs to press a button, the location is transmitted when this time is reached.
And of course - with now() I am in the user’s time zone. but in my case it will always be the same time zone.
Of course, it is possible that the “new” time trigger will be implemented completely differently.
But that’s how I would like it to be in any case;-)
Like I said, I think the time triggers will only run server side against data stored in the tables on the server. I don’t believe it will have any sort of connection to actions executed by buttons. I don’t think it will reach into an individual device and automatically click a button or run an action on the device. But I’m just speculating, so it remains to be seen once it’s released.
The whole purpose of these automated actions is to do things with the data without any need for a front end, such as an app.
If I understood the discussion correctly, geolocation in Glide is good for the following use case: “Click here to share you location. Thank you, we identified your current location and won’t be tracking your movements or location from here onwards.”
I find this pretty important and hadn’t realized that this is how geolocation in Glide or PWAs in general works.
Not sure about that “won’t be tracking” part, we discussed this before, it seems to track to some extent, but there’s no official docs about that and we don’t want our updates to be used for constant tracking either.