Check distance to a beacon

[udameli]

I guess this is more of an enhancement request. It'd be great if there was a way to check the distance to a beacon with a particular tag. From my understanding, the only way to learn how far a user is from a beacon is to set up a proximity zone and listen to an enter/exit event which isn't the most convenient way to see how far a user is from a beacon at any given moment. Would you consider adding a method that would do just that? :)

[heypiotr]

This is actually a bigger on-going debate we're having within the Proximity SDK team. Our problem with an API for distance is, the distance estimations based on BLE signal strength are inherently finicky due to the nature of the 2.4 GHz radio waves. We want to avoid the situation where somebody builds their app/user experience on top of the distance API, and it just ends up unreliable and clunky.

Can you share how you want to use the distance information in your own app? We want to gather as much real-world feedback as possible before we make any decisions.

[udameli]

Hi @heypiotr! Thanks for the insight. I was hoping to use the distance API to check where a phone is relative to a beacon at any given time. This would allow me to create "hot zones" in a room. There is no pressing need for that API. I was just wondering if this was something you considered which seems like you did.

[jordansnyder]

I'd just like to have the distance that triggered an onZoneEnter event to be available on the context object. You're only giving us .tag and .deviceIdentifier, but you're obviously making assumptions about the distance because you're triggering onZoneEnter based on that zone/distance. Could you just pass .distance in that object?

[heypiotr]

Not including it was a design decision on our side. Based on our experience, we consider building interactions based on the distance (which is very finicky for Bluetooth-signal-based estimations) to be an anti-pattern, and we want to promote good/battle-tested practices in the Proximity SDK.

That said, we're very much open to discussions and feedback about that. What would you use the distance for in your app?

distance that triggered an onZoneEnter

Note that vast majority of the time, this will be very close to your defined trigger distance. How would you benefit from knowing that, say, the actual distance was 4 meters on your 5-meter-zone?

[jordansnyder]

Thank you for sharing that insight. I definitely appreciate the inaccurate nature of RF distance calculation, but I’m wondering, what is the intended use of the Proximity SDK if not to define and trigger zones, which are based on distance?

And my request for .distance being on the context is more architectural. At this point I have worked around it, but I needed to write a helper function to go to my config and pull the distance based on the tag, which is just an additional loop. I’m not going to assign a different onZoneEnter listener for every zone, and I’m just reporting the zone events to an internal tracking sever, so I pull of relevant info from the context object. I can post code if that doesn’t make sense, but I’m lying in bed typing on my phone atm. :)

js

On Jun 12, 2019, at 12:45 AM, Piotr Krawiec notifications@github.com wrote:

Not including it was a design decision on our side. Based on our experience, we consider building interactions based on the distance (which is very finicky for Bluetooth-signal-based estimations) to be an anti-pattern, and we want to promote good/battle-tested practices in the Proximity SDK.

That said, we're very much open to discussions and feedback about that. What would you use the distance for in your app?

distance that triggered an onZoneEnter

Note that vast majority of the time, this will be very close to your defined trigger distance. How would you benefit from knowing that, say, the actual distance was 4 meters on your 5-meter-zone?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[heypiotr]

Gotcha, I think I understand your case, and I can see how passing the zone's metadata (incl. the trigger range) to the enter/exit/change listeners could be useful if you want to reuse the listeners between zones. That's a sensible request! (:

That said, taking advantage of the fact that the listeners are closures, and so you can generate them and bind the trigger distance to them, sounds like a sensible/practical solution here. (I guess it becomes less viable the more zones you have, but using a lot of zones feels like it might not be a good design anyway.)

what is the intended use of the Proximity SDK if not to define and trigger zones, which are based on distance?

It's pretty nuanced.

With proximity zones, we're using distance sort of indirectly, we can be more aggressive with filtering, and we are encouraging a more rough-grained approach.

Whereas access to direct distance estimates encourages different, often sub-optimal usage patterns. For example, the most common trap is sorting by distance and taking the nearest beacon. But what if the distance estimation for the nearest beacon is 1.5 m, and for the second-nearest beacon it's 1.6 m? That's well within the error margin, and in the next second, the order may flip. And if the two beacons trigger completely different experiences in your app, you're now in trouble.

So with proximity zones, we're encouraging a different thinking: create a 2-meter zone, and if more than one beacon can be in range at the same time, that's just something you have to handle and design around, because that's the nature/limitations of this technology.

Sure, it's still all distance underneath, but if our plan works, developers using the Proximity SDK end up using a better pattern without even considering it, because we sort of took the choice away ^_^

[nandorojo]

@heypiotr Would you consider adding the distance as an UNRELIABLE_distance field, the way react does with UNSAFE_componentWillMount? Even if it isn't the best pattern in terms of accuracy, it can be nice to have the developer freedom to use it.