Evaluate react-native-ble-plx native code

[jacobrosenthal]

The point of this library is to bring noble style bindings to react-native as I find noble to be a stable, enjoyable api for bluetooth thats incredibly multiplatform (mac/linux/osx as well as web and mobile web)

Our strong suit was never our native implementations. We dont have unit tests and many of us have touched that code at this point so we dont have a strong authorial voice.

Id love any feedback on react-native-ble-plx. (as well as send anyone there who doesnt care about noble, theyre probably going to serve you better)

Perhaps we can leverage their native work instead of our own? or learn from it at the very least.

[brycejacobs]

@jacobrosenthal I've used noble in the past, and done a PR for bleno as well, and think there library is great as far as being spec compliant.

I wouldn't think it would be too hard to do something like plx and use RX to wrap the noble bindings, if your looking to get away from doing any native programming. However, I think it benefits us some to learn and roll a binding wrap. Reason being, if there is any feature we need, we are two libraries deep if we go off what plx has done.

For instance, I need services that share the same UUID as a feature. Going through both plx and RX is going to be slow moving. I've used PLX some, but would love to get this library in shape to use RX directly or map our own bindings.

[brycejacobs]

@jacobrosenthal If you want, I can take a shot at doing the IOS bindings, since I have experience doing native swift with the CoreBluetooth library, and see if we can come to a cleaner abstraction?

Your call.

[jacobrosenthal]

Well, if we like the license ok, we can just fork their work and make it our own if it needs fundamental changes to fit our api.

The main thing is we dont have tests on any of the native, and different people are writing the ios and android so I cant eve be sure they act the same. Im working upstream on some basic tests on noble to make sure we align to that api properly.

[brycejacobs]

That sounds good, let me take a look and see what this will take. I much prefer the noble surface API, and think even simplifying their work to just call out events could work fine. I think in their case, there's more effort to handle the BLE operations in swift land than what really needs to happen. From the looks of it, they're going to do a large refactor soon of their library API for the 4.0 release.

My end goal is to use this and land noble/noble#597 and get this working so there is a more spec compliant alternative for RN.

If it's all the same to you @jacobrosenthal , I'm going to start on the ios side and see if I can come up with a simple API that resembles what they're doing in RXBluetoothKit.