Closed izivkov closed 3 months ago
Hello, I believe you're referring to Android BLE Library instead of this one, right? The Kotlin one (which I'm rewriting, actually) is aiming to replace the Java-baseed one.
You might be right. I followed the Blinky example referenced from your Kotlin-BLE-Library. I basically extended the BleManager class, and this is where I got these callbacks. I assumed that the Blinky code was using your Kotlin library. Sorry for the confusion.
My goal is to separate the BLE communications from the UI and place it in a separate, domain-specific module. The examples in the README file in this project refer to some UI elements, like buttons and viewModelScope. I would love to see an example of pure BLE connection, scanning, etc.
In this class you have "Blinky" implementation of the Bluetooth LE layer. It is build using this library (Android BLE Library).
Remote device is exposed to the app via an interface named Blinky
. The implementation is private and can be replaced with a mock, for example.
The library does not support scanning, just Client or Client+Server connection mode. Instead, I would recommend 3 options:
BluetoothLeScanner
) - if you like callbacks and buildersCurrent version of nRF Blinky is using the first approach, you may find it here.
I would recommend option 3 and waiting for version 2.0, if you have time, otherwise any other implementation.
[^1]: I am working on client side at the moment and how to publish something in coming weeks
Awesome, thanks for the info! I will be checking on this repository for changes.
We can now close this issue if you like.
On Tue, May 7, 2024, 4:12 PM Aleksander Nowakowski @.***> wrote:
In this https://github.com/NordicSemiconductor/Android-nRF-Blinky/blob/main/blinky/ble/src/main/java/no/nordicsemi/android/blinky/ble/BlinkyManager.kt class you have "Blinky" implementation of the Bluetooth LE layer. It is build using this library (Android BLE Library).
Remote device is exposed to the app via an interface named Blinky https://github.com/NordicSemiconductor/Android-nRF-Blinky/blob/main/blinky/spec/src/main/java/no/nordicsemi/android/blinky/spec/Blinky.kt. The implementation is private and can be replaced with a mock, for example.
The library does not support scanning, just Client or Client+Server connection mode. Instead, I would recommend 3 options:
- Using Android Compat Scanner library - if you plan to support Android 4.3+
- Native Android API (e.g. BluetoothLeScanner) - if you like callbacks and builders
- Kotlin BLE Library
- The current version will soon1 <#m_5183440670372789126_user-content-fn-1-df8601b71409ac3db9b9f9ab657e8fbd> be replaced with a new implementation
Current version of nRF Blinky is using the first approach, you may find it here https://github.com/NordicSemiconductor/Android-nRF-Blinky/blob/main/scanner/src/main/java/no/nordicsemi/android/scanner/repository/ScannerRepository.kt .
I would recommend option 3 and waiting for version 2.0, if you have time, otherwise any other implementation. Footnotes
1.
I am working on client side at the moment and how to publish something in coming weeks ↩ <#m_5183440670372789126_user-content-fnref-1-df8601b71409ac3db9b9f9ab657e8fbd>
— Reply to this email directly, view it on GitHub https://github.com/NordicSemiconductor/Android-BLE-Library/issues/561#issuecomment-2099220722, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7M37TIHFTCPKPT74PWJOTZBEYTZAVCNFSM6AAAAABHLUMKZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJZGIZDANZSGI . You are receiving this because you authored the thread.Message ID: @.***>
I experience a couple of problems, which I think are bugs, at least with version 1.0.14:
In the callback
override fun onDeviceReady(device: BluetoothDevice)
,device.name
is sometimes null. Why?The callback
override fun isRequiredServiceSupported(gatt: BluetoothGatt)
is sometimes not called beforeonDeviceReady()
, so my read and write characteristics cannot be initialized properly.I don't want to describe these as bugs, because there is not enough documentation to determine if I am not using these callbacks properly.
Thank you.