Skip to content

Conversation

@YarnoVdW
Copy link
Contributor

Added beacon monitoring so that we can scan for beacons close in range to iOS devices in the background.

@bardram bardram self-requested a review July 9, 2025 12:53
@bardram bardram self-assigned this Jul 9, 2025
@bardram bardram added the enhancement New feature or request label Jul 9, 2025
@bardram bardram changed the base branch from main to pr503-beacon-scan July 17, 2025 09:27
Copy link
Contributor

@bardram bardram left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will pull this into a separate branch on the CAMS repo so I can improve on the code and docs.

@bardram bardram merged commit 471f35f into carp-dk:pr503-beacon-scan Jul 17, 2025
1 check passed
@bardram
Copy link
Contributor

bardram commented Jul 17, 2025

Hi @YarnoVdW - I'm looking at the PR now and have some questions...

The main question is why the beacon scanning is part of the Bluetooth measure? Why don't we make a separate measure called beacon with its own configuration, date model, and probe? Then people can choose if they want to use BLE scanning or Beacon scanning, or both.

As it is implemented now, people have to choose between the two using the useBeaconMonitoring flag.

So - my question is - is there any problem in separating this into two measures, and hence data streams? What is the use case for you? And - are there any technical issues to consider? Can't you scan for BLE devices and beacons at the same time?

@bardram
Copy link
Contributor

bardram commented Jul 17, 2025

As it is implemented now, people have to choose between the two using the useBeaconMonitoring flag.

https://github.com/cph-cachet/carp.sensing-flutter/blob/e89dd3916e4087c1799c924a2a0b5e1b937cb833/packages/carp_connectivity_package/lib/connectivity_probes.dart#L104-L118

@bardram
Copy link
Contributor

bardram commented Jul 17, 2025

The other problem is that you're forcing the "old" BLE data model to this beacon data model and mapping almost everything to the beacon name.

https://github.com/cph-cachet/carp.sensing-flutter/blob/e89dd3916e4087c1799c924a2a0b5e1b937cb833/packages/carp_connectivity_package/lib/connectivity_data.dart#L165-L173

IMO it would be better to have a dedicated data class for beacons.

@bardram
Copy link
Contributor

bardram commented Jul 17, 2025

@YarnoVdW - if you agree, I can pretty easily fix this by just reshuffling your code. But before doing this, I need to make sure that I understand your use case for this.

@YarnoVdW
Copy link
Contributor Author

@bardram I'll update the code so that you do not have to spend time doing :) It is indeed better to have a dedicated class for the beacon scanning. Our use case is for iOS especially, since iOS does not allow bluetooth scanning while the app is in the background, using iBeacon ranging, we can have our app fully in the background while it is ranging for iBeacons.

@bardram
Copy link
Contributor

bardram commented Jul 22, 2025

Ok. If you can update it that's fine. Ping me when I can review and merge a pull request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants