Open testexit29 opened 1 month ago
This is a bit of a different setup than I've seen. Why not use the fully qualified UUID in this case?
As a matter of fact the devices we are using are not capable of changing their behaviour of providing fully qualified UUIDs for services and characteristics. Its a repeating list of multiple same structured Parameters. Their are already shipped to customers and can't be updated because this characteristics and services are used for our updateprocess via BLE.
As this was working with Xamarin.Forms we implemtend it this way, now we are forced to upgrade to MAUI so we have to update to your new library, which doesn't support this feature any more. This is a huge problem for us.
A breaking change in the device Bluetooth API (characteristics and services) is not possible any more.
As this was working with Xamarin.Forms we implemtend it this way, now we are forced to upgrade to MAUI so we have to update to your new library, which doesn't support this feature any more. This is a huge problem for us.
Tone down your messaging. This is a free library, not a product. I don't owe you anything and your problem is not my problem. That being said, I'm happy to help, but I need to ask questions in order to figure things out.
i apologize for choosing the wrong words. maybe my words were a little bit affected by the words of our PM. i apologize sincerely
in the meantime we figured out a dirty way(currently just for android) with reflections to mitigate our problem however we would be happy to use the functionality out of the box without reflections also we would not prefer a fork which we would need to maintain
if you are interested in our workaround, we would be happy to help you out
Component/Nuget
BluetoothLE Client (Shiny.BluetoothLE)
What operating system(s) are effected?
Version(s) of Operation Systems
We tried with: Samsung S22 (Android 14) and iPhone 15 (iOS 17.5.1). Actually the Versions doesn't matter as the logic of the library hides available native logic.
Hosting Model
Steps To Reproduce
This probably applies to WriteCharacteristic() as well, however we didn't needed it for our purpose, therefore we didn't test it.
Expected Behavior
Speaking for Android (equivalent to iOS), the Library offers Mehtods like:
BluetoothGattService.getCharacteristics() BluetoothGatt.readCharacteristic()
https://developer.android.com/reference/android/bluetooth/BluetoothGattService#getCharacteristics() https://developer.android.com/reference/android/bluetooth/BluetoothGatt#readCharacteristic(android.bluetooth.BluetoothGattCharacteristic)
which would do the trick, as these methods rely on a reference not just the UUID of the service
Actual Behavior
If you try to read the Characteristic with ReadCharacteristic(serviceUuid: "S123", characteristicUuid: "C987") or ReadCharacteristicAsync(serviceUuid: "S123", characteristicUuid: "C987") you will always read the Value "Hello" but never "World"
This probably applies to WriteCharacteristic() as well, however we didn't needed it for our purpose, so we didn't test it.
Exception or Log output
No Exceptions, just misbehaviour, which makes it not useable for our purpose. Also it was always working with Xamarin Forms. Found while migrating to Maui.
Code Sample
` // just a sample array, this is actually provided by the connected BLE device BleCharacteristicInfo[] characteristics = new BleCharacteristicInfo[] { new BleCharacteristicInfo(new BleServiceInfo("S123"), "C987"), // containing Data "Hello" new BleCharacteristicInfo(new BleServiceInfo("S123"), "C987") // containing Data "World" };
// this would be the client code connecting to the BLE device foreach (BleCharacteristicInfo characteristic in characteristics) { BleCharacteristicResult result = await peripheral.ReadCharacteristicAsync(characteristic.Service.Uuid, characteristic.Uuid, token).ConfigureAwait(false); }
// result contains for both iterations the same result.Data, actually it is "Hello", "Hello" but should be "Hello" and "World" `
Code of Conduct