Finish writing messages in the write queue before moving on…

…to the next command.

If you call BleManager.write() multiple times without awaiting, there was a chance the message fragments could get interleaved and corrupted. This change keeps the current command active while the write queue is not empty, so that new writes don't clobber it.

I also created a test branch to verify this fix, but I had to make a bunch of changes to get it to run as a unit test. I don't know if those changes will break anything else, so I left them out. It's here if you're interested: https://github.com/perfectco/react-native-ble-manager/tree/feat/test

Hi @gtbX , thank you for your work, if you confirm that you have tested it and it works correctly I will proceed with the merge.

Hi @marcosinigaglia Sorry it took a while to get back to this, but I was able to reproduce the issue on a physical device, and verify the fix.

Essentially, calling write() too fast could cause corruption:

const payloadA = new TextEncoder().encode("AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA");
const payloadB = new TextEncoder().encode("BBBBBBBBBBBBBBBBBBBBBBBB");
BleManager.write(peripheral.id, characteristic.service, characteristic.characteristic, Array.from(payloadA));
BleManager.write(peripheral.id, characteristic.service, characteristic.characteristic, Array.from(payloadB));

could result in some "B" bytes being received before all the "A" bytes. With the fix, all bytes are received in order, despite the lack of await. Verified by running that snippet in the example app on one device, while watching the receive log in nRF Connect on another.

Is that possible to be launched alongside with apple devices too?

I don't have an apple device handy to test, but I don't see why it wouldn't work. IIRC the iOS code didn't have the same issue.