Closed MrCsabaToth closed 10 months ago
Somehow the fork is behind although GitHub doesn't indicate it. There should be only 3 file changes, I'll fix it.
Ok, somehow there was a wrong merge while syncing the fork? I'll probably nuke the fork and recreate the PR. The other thing is that I used an API level 33 call (ScanRrecord.getAdvertosimgDataMap
), so I'll add support for level 21+ ScanRrecord.getBytes
.
merged. will be in next release 1.31.10
this code was reverted. see comments in https://github.com/boskokg/flutter_blue_plus/pull/772
tested working?
we should have it in the example app too
New virgin PR: https://github.com/boskokg/flutter_blue_plus/pull/794
FlutterBluePlus Version
1.31.8
Flutter Version
3.19.0-0.1.pre
What OS?
Android
OS Version
12, 13
Bluetooth Module
.
What is your feature request?
Appearance type is a Bluetooth LE standard feature.
Many applications have to deal with various types of BLE devices. One way to identify them is to look at the service data in the advertisement. However that is often vague, and it's even advised to first look at the Appearance data, especially when multiple services mentioned in the services list (see https://stackoverflow.com/a/44292698/292502 where it's a Herta Rate Sensor + a Running Cadence and Speed Sensor).
It's extremely costly (and kind of infeasible) to connect to devices just to categorize them. This is why somewhat surprising that iOS is not supporting this standard (#202), however there are already multiple features which iOS holds back but the Android side of FBP supports. This would be another one, and the PR IMHO is not an invasive change.
Logs