Tracking connect, services, characteristics, reads and writes about react-native-ble

[arahansen]

Hey everyone, the discussion on introducing peripheral support is of interest to me. Has there been any work done to this repo (or maybe another repo) to add peripheral support for React Native?

[rclai]

As some of you might know, I have been doing a lot of work to add the extra functionality on my fork, updates branch. I am not ready to submit a PR, but I am actively working on it since I am currently using it on this big project that involves using BLE. I expect to have the rest of the functionality completely done and conforming to the noble API more or less in the coming weeks.

[jacobrosenthal]

Yep, noble abstraction is way to go, as for cordova, theres really nothing to port from thin abstractions like this sadly.

No good reason, I just havent needed any more than this for my work yet. PRs welcome

[export-mike]

This is exciting! sadly the projectim on still hasn't moved to react native.

[jacobrosenthal]

@rclai Good job man. I still havent gotten around to getting back to this project or looking at your code. A big goal of mine is keeping the noble files as untouched as possible and pushing any needed changes upstream to @sandeepmistry eventually deduping them in our repo or merging into his domain. Whatever works.

[joelwass]

@rclai I don't see an updates branch in your fork, could you link us?

[rclai]

You're looking at the wrong fork. It's here.

Also, keep in mind that I'm not a super expert on Objective-C, so if any of you know of more efficient ways to juggle the data back and forth via better data types, feel free to pitch in. However, I do share the goal of being able to keep the Noble layer untouched and only modify the custom bindings.

Also, I have a big feeling that I can literally do away with all the JS files that were copied from Noble, and literally use noble as an NPM dependency. I'm going to try that soon.

[rclai]

I managed to get rid of all the copies of Noble files and directly depend on the noble NPM package itself. You can check it out here. Right now if you test it you'll get a binding variable not found error, but that has been fixed, we just need to wait for NPM package to get bumped up to reflect the fix.

[sandeepmistry]

@rclai noble v1.5.0 has been published with your fix :)

[rclai]

Thanks.

[jacobrosenthal]

@rclai just made a huge pr with what looks like all this. I published as 1.0.0 beta1 while I look at it myself.
Check it out everyone and give any feedback here
npm install [email protected]

[jacobrosenthal]

Looks like you just npm install [email protected] actually

[jacobrosenthal]

@rclai Im still losing the initial getState in order to use the typical noble pattern of only scanning once we get a poweredOn state. Are you catching it with current code? Care to share a gist of your index.ios.js?

[rclai]

I know that the BlueTooth state gets lost sometimes, but in my experience it's not all the time. In an effort to make it more reliable, I moved the iOS setup code into the init function, which I believe is a more appropriate and reliable place to put and we should be guaranteed to have an initial BlueTooth state. Try it now.

Edit: even with this change, I still get an initial state of unknown but once in a blue moon and I end up having to disable and enable the BlueTooth to make it come alive.

[rclai]

Here's my test gist: https://gist.github.com/rclai/104ffcd953ecfe6bad18b21fc0536f1b

[rclai]

Why does NPM still show the library as 0.0.7? https://www.npmjs.com/package/react-native-ble

[rclai]

FYI, I just rebased my PR and organized my commits in a more comprehensive way that is not an eye-sore. Thankfully and surprisingly using git rebase -i was a very nice, intuitive learning process that wasn't painful at all.

[jacobrosenthal]

Its a beta release, you have to ask for it by name to get it. I THOUGHT you had to ask with the beta version but apparently not?

[rclai]

Oh okay. So were you able to test my new change with the Bluetooth state?

[jacobrosenthal]

Ive was fighting NPM. Your new code is released as
npm i [email protected]

Im not sure what changed as it was overwritten, but note in you're not using the typical noble pattern of waiting for a state event, you're forcing it by checking the noble.state and scanning based on that -- because were still losing the state
https://gist.github.com/rclai/104ffcd953ecfe6bad18b21fc0536f1b#file-react-native-ble-test-index-ios-js-L36

[rclai]

There's no way of guaranteeing that the Bluetooth state is poweredOn even though my iPhone says that Bluetooth is on, that's why I'm doing that. I believe this is an iOS bug and the only way to fix it is to toggle the Bluetooth button, and let the stateChange event take care of it. I check the state on the init function in order to always have the state, especially during Live Reload mode. Also, when you say we're still losing the state, are you implying that you had the state and then all of a sudden it gets lost later? How does that happen?

How would you suggest I handle this?

[jacobrosenthal]

Agreed. Thats why the noble pattern is to just wait until you get that
first onstatechange event
Heres my patched branch, this hack is what will have to do.
https://github.com/jacobrosenthal/react-native-ble/blob/1.0.3/bindings.ios.js#L137

I also pulled out the peripheral stuff. We should start a
react-native-bleno for that in order to stay true to node

On Wed, Apr 27, 2016 at 10:50 PM, Richard Lai [email protected]
wrote:

There's no way of guaranteeing that the Bluetooth state is poweredOn even
though my iPhone says that Bluetooth is on, that's why I'm doing that. I
check the state on the init function in order to always have the state,
especially during Live Reload mode.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#4 (comment)

[rclai]

Oh yeah, I was about to take out the peripheral stuff after noticing that since I'm depending on noble, that stuff was going to break. I'm actually working on removing that stuff from my PR.

[rclai]

Okay I updated my PR and the peripheral stuff is no longer there.

[rclai]

Is it necessary to put a setTimeout to getState? I think the issue of the state being unknown may still arise. I'm sure I've tried that and the only way to fix it was to just toggle the Bluetooth button, go figure.

[jacobrosenthal]

Were trying to be like noble, and I dont believe noble guarantees has a known state on startup. It asks you to wait for an onchange event. Our problem has been were always missing that event, hence my final terrible hack.

You dont have to update, Ill used my patched fork, itll maintain all your authorship.

[rclai]

Cool, I see you updated your example. Did it all work?

[jacobrosenthal]

Yep. Havent used it super thoroughly but looks good. Nobody else tested
anything yet?

On Thu, Apr 28, 2016 at 8:11 AM, Richard Lai [email protected]
wrote:

Cool, I see you update your example. Did it all work?

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#4 (comment)

[jacobrosenthal]

Well with no other feedback the few tests Ive run work well. Good job and thanks @rclai . Published it as 1.0.3 (.3 because of my previous fighting with npm--dont ask)

[rikardwissing]

I'm also interested in peripheral support for react native