search

jacobrosenthal / react-native-ble

Central role BLE for react native noble api surface
MIT License
168 stars 45 forks source link

Evaluate react-native-ble-plx native code #39

Open jacobrosenthal opened 7 years ago

jacobrosenthal commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 sandeepmistry/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.