Skip to main content

Device location (Lesson 4.10)

Time to get our user’s location data! This device resource can unlock a whole host of interesting functionality for your app.

Sofia Maconi avatar
Written by Sofia Maconi
Updated over 2 weeks ago

Transcript

So, what we're going to do in this video is we're going to add the logic that is going to request from our users that they share with us their location, so that we can use that location data as this geographic address data type that we just learned about.

We can use this geographic address to create a better user experience for them — to display a location for their diary entry on screen, to be able to pin that location onto a map.

So, to start with, I'm just going to change the structure of this group address. It's not going to be the last time that we make changes here to this group, but I want to set it up in a slightly different way here so we can best understand how we get the user's device’s location.

So, I'm going to remove the input actually from here. And then we've still got this text value — that's okay, I'm just going to clear that out.

And then, one of the things that I'm going to add is a button. And this button, I'm going to actually set this to be a less prominent design. This button is going to be what the user clicks to get their current location.

Okay, and I'm going to use here an icon called “navigation arrow.” Let's change the placement of this icon to be on the left, and just add a little bit of gap spacing while we're here as well.

So, what I want to happen is: when the user clicks this button, we're going to get their location and we're going to store it inside of this group address.

I'm going to set up this group address to be prepared to hold a geographic address-type thing — so we are shaping this container, if you will, to be able to hold a geographic address-shaped piece of information.

And then, the text element that we had earlier, I'm just going to pull through the parent group’s geographic address. That's all I'm going to do here.

And so, we can be really clear about what's going on, let's just add a canvas placeholder as well, and change the styling ever so slightly so it's kind of obvious what's going on.

So, if we now add some geographic address into this group address, it should be displayed through this text element.

One of the ways that we can do this is using a data source called current geographic position. Now, this is going to take the current geographic position of the user's device.

The only issue is that, as I've opened this up here on my phone, I'm not seeing any value appear in my text element. So this text element here should be showing the parent group’s geographic address, but I'm not seeing anything.

The reason is that we don't yet have permission to access the device’s location. So we have to request that specifically using a workflow.

So, I'm going to add a workflow to this button. We'll go under Native mobile, and then we've got a couple of options here related to the user's location. I'm going to choose this one here: Request location permissions.

What this will do is show a modal — basically just a popup — asking the user to provide access to their device’s location. You’ve probably seen this screen before on other apps. The user can choose whether they want to allow access to their location just this one time or any time while using the app.

So if I tick here “Allow once,” then now you can see that the device’s address is appearing here. That’s because after requesting the permissions with this action, and the user providing those permissions, we’ve effectively unlocked access to the location of the user’s device.

Now, there’s another way that we can do this as well that I’m going to show you, just in case that’s better for your use case.

If we don’t set the data source here using current geographic position — so if I go and clear this out — and what I do instead is use this Get current location action, what this action does is it provides, as an output to subsequent actions, the device’s current location.

So, what I could do is take that location and display it inside of some container that's configured to hold an address — for example, this group address that we’ve set up, right? This guy here that’s configured to hold a geographic address.

What I can do is push or populate this group with the result of the previous step.

Now, to get the permission request modal to appear again when this button is clicked — that’s this modal here — if you previously selected “Allow once,” then just quit the Bubble Go app and open it up again, and that should reset the permissions.

If you hit “Allow while using the app,” you’ll need to go into your device’s settings and update the permissions that you’re providing to the Bubble Go app.

I’m going to hit here “Allow once” again so we can test this out. Then you can see that the address is being populated again — of course, this time we just did it in a slightly different way.

Now, just like when we’re requesting camera permissions, we can update the text that appears here. In fact, we’re going to be required to do this in order to get accepted into the app stores.

We actually do this under the Settings tab, and then under Languages, you have these things called Application texts.

If we keep scrolling down, you’ll find a whole bunch related to mobile and the different texts that are going to appear when we request access to different device resources.

In the context of requesting access to these resources, these texts — these instructions providing context to the user — we call these purpose strings.

For a lot of these, we’re not going to be able to see the updated purpose string that we might add until we have begun to deploy our application. In other words, we’re not going to be able to see them while we’re testing in Bubble Go.

So, we’re going to revisit this — adding all of our purpose strings — later on in the course. For now, just note that we are going to come back to update these.

Now, the last thing that we should do here is make sure that we’re saving the address that we’re storing inside of this group address.

Let’s go into our save workflow. What we were currently feeding into this location field was that location input that we deleted.

So instead, we’re going to set this to our group address, which of course is holding on to a geographic address.

Let’s test if this is working now. I’ll add an image and some other test data here, add my location, and hit Create.

You can see that this data, including the location, has been added into the database.

Now, in our case, it does actually work better that we set up here the data source for this address to pull the current geographic position.

And then, this button — what this will do is not get the current location and display data, but, as before, simply request the location permissions from the user, which will then, of course, allow this data source to correctly pull the geographic position of the user’s device.

What I could also do here to give a little bit more insight about what’s going on is say Given location permissions.

And what we have access to here is a data source which is Has granted location permissions.

So, whenever this is “Yes,” we should see this data source being retrieved correctly.

We can test that because our text element is just pulling through the geographic address.

So, we should see two things if this is working:

Not only should we see the address of the device, but we should also see — I’ll get rid of this canvas placeholder because that’s a little confusing — we should also see either a “Yes” or “No” value, but in our case a “Yes” value if the user’s given the correct permissions.

So, on my iPhone, I’ve closed Bubble Go and reopened it here, and you can see that the location permissions are set to “No.”

If I tap on Get location permissions and then “Allow once,” then you can see two things:

You see that not only is the location permissions value here set to “Yes,” but also we’re getting the user’s address coming through as well.

And if I reload Bubble Go here and then open up the diary entry form again, you see that these values are the same.

Now, if I actually close Bubble Go, as I’ve just done here, and reopen it, you see these location permissions are reset back to “No.”

If I try to get the current location though, and I say “Allow while using the app” — this is on iPhone, and there’ll be an equivalent setting on Android — then, of course, the address will come through correctly here.

But also, if I close my application and open it again, those location permissions will be preserved. So the user will actually have to go into their device settings in order to retract those location permissions.

Now, the other thing we might want to do is hide this button Get current location after the user’s already given us their address.

We could do that simply by saying: yeah, by default this button is not going to be visible.

But, of course, look — if they haven’t given us their location permissions, so if this data source here is equal to “No,” well in that case, we want the button to be visible.

Then that button will be hidden.

We don’t need to worry too much about this because we’re going to evolve this feature so that users can actually search for a location, not just tag their current device’s location.

But nonetheless, this does show you how you can use this data source in practice.

Perfect. So now that users can tag their diary entries with their current location, let's learn how we can display these locations out on a map.

Did this answer your question?