You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, reads do not give any opportunity to allow event-driven behaviour. This is worked around in the examples by periodically writing to the value data in the characteristic, but this is a brittle approach when the application is more than very simple, and introduces the possibility of data and logic races.
To address this, there should be a read call-back mechanism that allows application logic to be run prior to sending bytes over the air. An example of how to do this for HCI is here. It should be relatively straightforward to inject a callback path in the Windows code, and from a relatively shallow look into BlueZ, there appears to be a way to inject this into the Linux code as well, though my understanding of D-Bus Bluetooth is weak (I have seen examples of this kind of thing in the python BlueZ stack).
The text was updated successfully, but these errors were encountered:
Currently, reads do not give any opportunity to allow event-driven behaviour. This is worked around in the examples by periodically writing to the value data in the characteristic, but this is a brittle approach when the application is more than very simple, and introduces the possibility of data and logic races.
To address this, there should be a read call-back mechanism that allows application logic to be run prior to sending bytes over the air. An example of how to do this for HCI is here. It should be relatively straightforward to inject a callback path in the Windows code, and from a relatively shallow look into BlueZ, there appears to be a way to inject this into the Linux code as well, though my understanding of D-Bus Bluetooth is weak (I have seen examples of this kind of thing in the python BlueZ stack).
The text was updated successfully, but these errors were encountered: