Hi Bubble developers,
I’m building an app similar to Uber using Bubble. After building the web app, I’ll deploy it natively using a wrapper. I need to implement live driver tracking after a trip is confirmed.
Is there an efficient way to achieve this natively after wrapping the app? I’d love any guidance, suggestions, or best practices for implementing this feature.
Thank you! 
Hey @Deva_b 
The best way I have seen this done was through an API where the vehicle already had a tracker added to it. That seemed like the most accurate and they don’t need to have their phone running in the background updating every few seconds. There might be some other ways to do this, I suggest looking into the wrapper you are using to see if they have that option available. I think BDK might have that option. OR you can even recommend Bubble add it into their Native App Builder that they are working on right now. I don’t think it is an option yet, but I know they were asking about what they should work on next. This seems like a good idea for them.
My thoughts…
I looked into something like this on Bubble and it just wasn’t practical for my needs.
If you only have a few users or drivers it may work for you.
From my testing for a simple app with 3000 users, it would cost so much in WUs that it wouldn’t be practical.
You can do ‘current geographic location’ and run a workflow every few seconds, but that takes up a lot of work units.
You can try a plugin (which I didn’t) but it would only be practical if it used client-side javascript.
You could try custom states…which I thought about, but that still wasn’t practical.
So, what I’m saying is it depends on how many customers etc., drivers, etc., you’re talking about.
Other backends will save you probably 15X over what you would spend on Bubble for an app like this.
Bubble is great for some apps, but for others probably not such a great idea.
Natively have this as an option for their wrapping service. Basically you trigger it from the frontend sending in an identifier (drivers UID for example) and then have a webhook setup to receive location data with the identifier (so then you would do a search for driver(UID = Request Datas ID)first item’s location = request data’s lat/long…etc).
When it is triggered you can set the intervals for how often the webhook gets pinged i.e every 30 seconds or 30 minutes. You can start/stop this as required so you could increase the ping rate when a job is active and decrease it when the driver is idle for example.
It works in the background insomuch as if the app is sitting in the background it will still receive data, but if the app is closed completely then it will stop receiving updates. This meaning that when the app is opened again you would need to retrigger capture of location data. There’s a few ways to approach doing that.
you could also “animate” the tracking to make it look like it is real time when it is not.
ie
driver accepts job
duration is determined from driver to pickup
duration is used to roughly place the driver on the map for the user
infrequently the app updates the actual realtime location and then recalculates the animation for the remaining distance
I’d also optimize the realtime checker based on the remaining distance.
ie if the car is 1 hr away you could check every 5 minutes
if the car is 15 minutes away then check every 1 minute
if the car is less than 15 minutes away then check every 30 seconds
this achieves several things and is likely how most rideshare/delivery services actually do the “tracking”
you can use google maps to get realtime duration for a more accurate progress
it’s a little slight of hand that very few users would notice but it would save you a ton of wu
