flutter_reactive_ble
flutter_reactive_ble copied to clipboard
Add support for writing to descriptors
Extends the plugins to support writing to specific descriptors.
I have copied the approach from QualifiedCharacteristic to become a QualifiedDescriptor.
There are quite a few generated files (tests, protobuf) which are a bit tedious to handle. Appreciate if someone could point me to a developer docs page.
iOS implementation is still TBD.
thanks! so far it looks good
@werediver @remonh87 944e2a9cae75e937431dc843693033462694d53f is not strictly part of this MR, but was needed for compatibility when including this package on iOS. Should it be separate?
Some comments regarding 944e2a9.
I suppose it's fine to include those changes in this pull request, but please go through all the comments already left by me.
Aside from those comments, the commit history of this pull request is dirty: contains merge commits (better rebase your feature branches), doesn't seem well structured and includes commit messages mentioning work-in-progress (WIP). If you are not going to clean the history up at some point (through interactive rebase), the pull request should be squashed before merging (can be done at the moment of merging through GitHub interface). It's okay, just don't be surprised.
Some comments regarding 944e2a9.
I suppose it's fine to include those changes in this pull request, but please go through all the comments already left by me.
OK & yes will do.
Aside from those comments, the commit history of this pull request is dirty: contains merge commits (better rebase your feature branches), doesn't seem well structured and includes commit messages mentioning work-in-progress (WIP). If you are not going to clean the history up at some point (through interactive rebase), the pull request should be squashed before merging (can be done at the moment of merging through GitHub interface). It's okay, just don't be surprised.
Oh yes, I was fully expecting to squash all the commits before removing the Draft label.
Thank you for the reviews.
I can test the project setup on the m1 machine (I have one) if needed.
Reminding of my earlier question:
@ened Do descriptors always have 16-bit IDs and cannot have longer or shorter IDs?
CBDescriptor.id has type CBUUID and that thing can contain IDs of different length, typically 128, 32, or 16 bits, while strictly 16 bits is reserved in Protobuf structure.
I'd suggest to find a suitable example in existing Protobuf structures and reuse it.
- [x] Rework or clarify Protobuf descriptor ID format
Reminding of my earlier question:
@ened Do descriptors always have 16-bit IDs and cannot have longer or shorter IDs?
CBDescriptor.idhas typeCBUUIDand that thing can contain IDs of different length, typically 128, 32, or 16 bits, while strictly 16 bits is reserved in Protobuf structure.I'd suggest to find a suitable example in existing Protobuf structures and reuse it.
- [x] Rework or clarify Protobuf descriptor ID format
At the moment, the code defines DescriptorAddress like this:
message DescriptorAddress {
string deviceId = 1;
Uuid serviceUuid = 2;
Uuid characteristicUuid = 3;
Uuid descriptorUuid = 4;
}
and Uuid is defined as:
message Uuid {
bytes data = 1;
}
So that looks good?
At the moment, the code defines
DescriptorAddresslike this:message DescriptorAddress { string deviceId = 1; Uuid serviceUuid = 2; Uuid characteristicUuid = 3; Uuid descriptorUuid = 4; }and
Uuidis defined as:message Uuid { bytes data = 1; }So that looks good?
Oh, sure, it looks good. I misread a piece of protobuf specification, sorry.
I need to be able to read a characteristic's user descriptor... Does this PR just include writes?