no initial stateChange

[jacobrosenthal]

The existing bindings seem to just happen to catch the initial statechange, but with all the react setup that event is lost before we're all set up to catch it.

Currently I'm not waiting for a stateChange event, Im just scanning as soon as the app opens.

[jacobrosenthal]

For more background, I can request state in an noblebindings.init, but it arrives before the component is created..

2015-10-01 13:31:21.200 [info][tid:com.facebook.React.JavaScript] 'calling RNBLE.getState'
2015-10-01 13:31:21.210 [info][tid:com.facebook.React.RNBLEQueue][RNBLE.m:61] getState
2015-10-01 13:31:21.233 [info][tid:com.facebook.React.JavaScript] 'stateChange poweredOn'
2015-10-01 13:31:21.236 [info][tid:com.facebook.React.JavaScript] 'Running application "BabelES6" with appParams: {"rootTag":1,"initialProps":{}}. __DEV__ === true, development-level warning are ON, performance optimizations are OFF'
2015-10-01 13:31:21.282 [warn][tid:com.facebook.React.JavaScript] 'devtools socket errored', [Error: The operation couldn’t be completed. Connection refused]
2015-10-01 13:31:21.334 [info][tid:com.facebook.React.JavaScript] 'peripheral discovered (7338CDAA-609D-F579-53C6-DCD965D11483 with address <unknown, unknown>, connectable true, RSSI -68:'

[sandeepmistry]

@jacobrosenthal I've removed the bindings self "init"ing themselves pattern from noble and bleno. Now init gets called externally in the Noble or Bleno constructor:

• noble/noble@8a47c9f
• noble/bleno@918e8d6

[jacobrosenthal]

Ill give it a shot today!

On Sat, Oct 3, 2015 at 6:30 PM, Sandeep Mistry [email protected]
wrote:

Noble

[jacobrosenthal]

Fixed in v0.0.5 Thanks!

[jacobrosenthal]

This is back again since I upgraded rn
https://github.com/jacobrosenthal/react-native-ble/blob/master/examples/BabelES6/index.ios.js#L18

[jacobrosenthal]

Using a super shitty hack to fix this for the moment.
e96a34f

Better ideas accepted

[rclai]

We may need to consider the case that in a mobile app, even though there is Bluetooth functionality, you may never use it unless you hit a particular scene via the Navigator component. You may hit a scene where you want to search for stuff, and then all of a sudden cancel out of it, and then later on want to go back to it again. If I'm not mistaken, the current noble pattern seems to indicate that you get to catch that Bluetooth state once and only in the beginning of the app's runtime. In a mobile app, I think you need to have the ability to request the Bluetooth state on-demand given the scenarios that I stated above. I think the noble library needs to have a getState method that a custom bindings needs to implement. For example,

// noble.js
noble.prototype.getState = function(callback) {
  if (callback) {
    this.once('stateChange', callback);
  }
  this._bindings.getState();
};

// bindings.ios.js
nobleBindings.getState = function() {
  // Calls the native module (we have it already)
  RNBLE.getState();
};

Thoughts?

[jacobrosenthal]

I dont think it should be needed. noble.state is updated as the os emits the state changes.

[rclai]

I thought you didn't want to depend on that state property to start Bluetooth operations.

[jacobrosenthal]

Were talking about 2 separate issues. A lot of existing code just waits for
a state change to do anything. We were always losing this initial state
change, and I wanted to support that existing code out of the box.

Secondly, yes you may check and or poll noble.state if you like.

On Sun, May 1, 2016 at 8:22 PM, Richard Lai [email protected]
wrote:

I thought you didn't want to depend on that state property to start
Bluetooth operations.

—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub
#1 (comment)