Consider API breaking changes.

[Cierpliwy]

Consider following API breaking changes before going 1.0:

• Move all advertisement data related fields (including name and rssi) to advertisement object which will be included in Device if possible.
• Change (error, T) => void callback types to (Result<T>) => void which will allow to apply better Flow type checking.
• Change Device.uuid to Device.id as it's not UUID
• Convert iOS library to Swift 3
• Consider filtering out value updates from notification listener when read is performed on iOS. In that case behaviour will be in line with Android.
• Change Base64 API to ArrayBuffer and do conversion on implementation side. This will allow to optimize it in further RN versions on iOS10+.

[brycejacobs]

@Cierpliwy Any update on the base64 API? Is there any consideration to disabling the encoding / decoding?

We have a scenario with some embedded devices, running on a TI cc2650, that is fighting for bytes. The base64 encoding / decoding is a killer for when you want to send raw bytes across the wire.

[Cierpliwy]

In our internal project we are currently doing Data -> Base64 -> Data which is definitely suboptimal and I would love to remove that step for library. RN team doesn't seem to work on it unfortunately:
facebook/react-native#1424.

Maybe I could check if it is difficult to add binary bridging between JSC and native modules, but to be honest I don't have so much time at my disposal.

As a side note: still when you are passing Base64 to API calls it is converted to binary form by native libraries used by react-native-ble-plx and then send to BLE radio. So you can definitely manipulate bytes and there is only Data -> Base64 -> Data inefficiency during bridging.

[brycejacobs]

Hm, maybe I read the source wrong.

I was under the assumption, that if I were to read a characteristic on a remote peripheral, that the library assumes the data received is in base64. Is this correct? If it's simply reading the data, then encoding to base64 for the trip back to js land then that should be fine, and may actually be the best way.

The scenario that I'm in, is where I have a device out in the wild that's broadcasting some advertisement data when not connected, that serves as service data, that contains some status values. I actually just booted back up the prototype, let me test my theory and get back to you before I waste any more time.

[Cierpliwy]

Data is read from peripheral in binary form and converted to Base64 only when it needs to be sent to JS side, so everything should be fine.

[rclai]

Yeah, you don't have to send base64 data to your TI cc2650.

[jchirschy]

Hi @Cierpliwy,

As I read this issue, could you confirm that data written to or read from a characteristic is not base64 encoded ? That means, peripheral doesn't need to encode or decode base64 ?

[Cierpliwy]

@jchirschy That's correct

[brycejacobs]

I can confirm that's the case. It get's a little tricky when working with Buffers, but overall not that huge of a deal.

…

On Tue, Jun 27, 2017 at 9:30 AM, Przemysław Lenart ***@***.*** > wrote: @jchirschy <https://github.com/jchirschy> That's correct — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABWHjf1Ke7BjF5E0el0WZoVynDuH-DXlks5sIRIigaJpZM4Keo_V> .

[Cierpliwy]

Closing in favour of #299