Pamiętam czytania w "Guide and Hint" -doc do Samsung BLE API (archived page):Czy natywna implementacja Androida BLE jest z natury synchroniczna?
Jednym z najważniejszych pojęć Samsung F/W i stos jest jego synchroniczny charakter. Oznacza to, że jeśli nazywamy na przykład
writeCharacteristic
dla konkretnej charakterystyki, jeśli zwracatrue
, następne wywołanie dowolnejBluetoothGatt
lubBluetoothGattServer
metody należy wykonać po otrzymaniuonCharacteristicRead
zwrotna. Dzieje się tak, ponieważ stos jest zaprojektowany do obsługi i przetwarzania tylko jednego wywołania GATT na raz, a jeśli, na przykład, wywołaszwriteCharacteristic
lubreadCharacteristic
na dowolnej charakterystyce wkrótce po pierwszym, zostanie zignorowany.
- to ma również zastosowanie do realizacji Nativ z BLE wprowadzono w Androidzie 4.3?
- Samsung API obsługuje również tylko jedno podłączone urządzenie GATT naraz. Czy to się zmieniło w natywnym API?
Jest ciągłym wątek związany z synchronicznym charakter API na trackerze emisyjnej Google: https://code.google.com/p/android/issues/detail?id=58381 –
Właśnie wdrożył kolejka do wszystkich zapisów i wygląda na to, że działa dobrze. –
@Ash Według dokumentów dostarczonych przez firmę SAMSUNG zachowanie nie jest ograniczone do operacji zapisu. Tak, używanie kolejki jest popularnym sposobem rozwiązania tego problemu. "działa dobrze do tej pory": Trudno jest przetestować i odtworzyć anulowanie polecenia przez inne. Często zdarza się, że napotkasz problemy, gdy kod BLE stanie się bardziej skomplikowany, ponieważ robisz więcej rzeczy na podstawie poprzednich połączeń.Wykonuję tylko następną operację BLE po tym, jak zakończyłem (otrzymałem odpowiedź) lub po tym, jak poprzednia nie zakończyła się w odpowiednim czasie. Przy okazji, twoje komentarze lepiej by pasowały jako odpowiedź na to pytanie. – OneWorld