1

I have to following scenario: My app requests and receives data from an BLE peripheral (a glucometer). It it possible that the user has another app (from another developer) installed, that also communicates with the peripheral. I noticed that my app receives characteristic notifications for requests that where initiated by the other app. This causes my app to receive some data twice.

Is there any way to distinguish between responses to my request and responses that are caused by another app? Or how can I handle it?

hendra
  • 2,531
  • 5
  • 22
  • 34
  • Are you talking about that responses to requests (like write and read) are being delivered to both apps? Or that notifications are being delivered to both apps? – Emil Jan 24 '18 at 21:29
  • I'm talking about notifications (whenever the characteristic’s value changes) – hendra Jan 24 '18 at 21:39

1 Answers1

2

While the stack obviously knows which app a certain (read, write) response belongs to (because there may only be one pending request, and it knows who sent the request), there is no logical or sound reason why it should dispatch a notification to a single app (among those who have enabled notifications).

Note that the GATT specification does not define "multiple gatt clients per link", there is only one client, so the peripheral doesn't even know there might be two apps talking to it. Hence when it sends a notification, it doesn't include a "target app" field.

The feature of multiplexing multiple apps to the same GATT connection is something iOS and Android teams etc. came up with.

Emil
  • 16,784
  • 2
  • 41
  • 52
  • I think this is bad design of the OS. In my case I write a request to a "Record Access Control Point" (RACP) characteristic. This request causes the peripheral to notify the "Glucose Measurement" characteristic. Once all measurements are sent, the peripheral notifies the RACP with a response code (success/error). Problem is, that I don't know if this notification belongs to my request or to a request of another app. Any idea how to solve that? Because the receiving takes place in the background I only have 10 seconds to receive the measurements and send them to a server or iOS stops my app. – hendra Jan 25 '18 at 07:52
  • I think the 10 seconds timeout before stopping gets reset after every notification is received. – Emil Jan 25 '18 at 09:29
  • The issue is that your thought "notiifcation belonging to a particular request" is nothing standardised in GATT. That's a custom thing for this peripheral. Notifications generally do not "belong" to a previous GATT operation. Again, GATT is defined and designed around the idea of a single GATT client so it can become a bit strange when you run protocols over GATT with notifications if you have multiple "apps" on smartphones talking to the same GATT server. If such thing needs to be supported, the fw of the peripheral can include some app identifier as the first byte in each notification. – Emil Jan 25 '18 at 09:32
  • Ok, I get that. Does this also mean that the other app can disable notifications for a characteristic, even though my app still wants to receive notifications? Or is this handled by the OS? – hendra Jan 25 '18 at 11:08
  • I'm not sure but I would assume iOS keeps reference counting how many apps want notifications. Only when no apps want notifications anymore, I guess it unsubscribes, and only those apps subscribed actually receives notifications. – Emil Jan 25 '18 at 11:58
  • Okay, i will test it. Thanks for your help. – hendra Jan 25 '18 at 12:57