1
votes

I'm currently working on a project which has a part that relates to beacons, as I saw and read different articles and websites it's not recommended to use non-ibeacon for ios to be detectable in terms of time and accessibility for background detection. I read this article: "Can we detect non-iBeacon beacons on iOS?" So Basically, we can use ibeacon protocol to wake our phone up and then use our packets, so my question is that after waking up our phone how can we connect to our related app with our self-made protocol? do we have to use CoreBluetooth for our own packets? if yes does it have side effects in terms of how fast ios can detect that or even permissions? Another problem would be that how many bytes can we send to our iOS after we wake our phone up? is it still certain amount? or we can extend it? basically, can we send a 100KB file after our first ibeacon packet?

Thanks...

1

1 Answers

5
votes

On iOS, there are two very different APIs you can use to detect beacon-like Bluetooth LE devices, each of which offers its own pros an cons:

CoreLocation

Pros:

  • Very fast detections even in the background
  • Wake up your app on Bluetooth LE beacon detection
  • Much simpler to use for beacon use cases
  • Off-the-shelf beacons are cheap and available from many vendors

Cons:

  • You must know the 16 byte ProximityUUID identifier to detect
  • Other than the above identifier, there are only four data bytes (a two byte major and two byte minor)

CoreBluetooth

Pros:

  • Much more flexible than CoreLocation
  • You can receive around 20 bytes of useful data in an advertising packet
  • You can receive much, much more data if you establish a Bluetooth GATT connection and exchange multiple packets. Transferring 100K is certainly possible.

Cons:

  • No ability to detect in the background using manufacturer advertisements
  • Detecting service advertisements in the background is slow
  • Often requires a custom built beacon (unless you are using AltBeacon or Eddystone)
  • Will not let you read iBeacon -- it is blocked by Apple

You can try to get the best of both worlds by combining both APIs. You do this by using two different hardware beacons (one iBeacon, one custom) or a single hardware beacon that sends out two different advertisement types.

The main trick with these techniques is to correlate the two advertisements, as the iOS APIs are completely sandboxed from one another and no identifiers can be shared between them. The approach I usually take is to simply use the iBeacon to wake up my app and then have it start scanning for a separate Bluetooth GATT service with a known Service UUID (either in the foreground or the background). Once I find this, I connect to it and use it for data exchange. Using this technique, I don't need to correlate any identifiers. I just know that if I see a beacon with a specific ProximityUUID, then that means there is supposed to be a Bluetooth GATT service being advertised in the vicinity that I can use to do my data exchange.