L'implementazione nativa di Android BLE è di natura sincrona?

Ricordo di aver letto nel "Guide and Hint" -doc al Samsung BLE API (archived page):L'implementazione nativa di Android BLE è di natura sincrona?

Uno dei concetti più importanti del Samsung F/W e la pila è sua natura sincrona. Cioè, se chiamiamo per esempio, writeCharacteristic per una caratteristica particolare, se restituisce true, la chiamata successiva a qualsiasi BluetoothGatt o BluetoothGattServer metodo dovrebbe essere fatto dopo la richiamata onCharacteristicRead è ricevuto. Questo perché lo stack è stato progettato per sostenere e processo di una sola GATT chiamata alla volta, e se, ad esempio, si chiama writeCharacteristic o readCharacteristic su qualsiasi caratteristica presto dopo la prima, viene ignorato.

non che si applicano anche alla realizzazione di Nativ BLE introdotto in Android 4.3?
Samsung API supporta anche solo un dispositivo GATT connesso alla volta. È cambiato nell'API nativa?

fonte

2013-08-02 OneWorld

C'è un filo continuo legati alla natura sincrona delle API di Google sulle issue tracker: https://code.google.com/p/android/issues/detail?id=58381 –

Ho appena implementato un coda per tutte le scritture e questo sembra funzionare bene finora. –

@Ash Secondo i documenti forniti da SAMSUNG, il comportamento non è limitato alle operazioni di scrittura. Sì, usare una coda è un modo comune per risolvere questo problema. 'funziona bene finora': è difficile testare e riprodurre l'annullamento di un comando da parte di un altro. Spesso si incontrano problemi una volta che il codice BLE diventa più complesso, perché si fanno più cose in base alle chiamate precedenti.Faccio solo la prossima operazione BLE dopo quella prima della fine (risposta ricevuta) o dopo quella che non è terminata in un tempo appropriato. A proposito, i tuoi commenti si adatterebbero meglio come risposta a questa domanda. – OneWorld

Samsung ha recentemente pubblicato un -document "migrazione" sulla stessa pagina che ho collegato nella mia domanda. Rispondono esattamente alla mia domanda mentre confrontano la nuova API BLE nativa con l'API BLE Samsung:

La natura sincrona dello stack e del F/W non è stata influenzata. Cioè, se chiamiamo per esempio, writeCharacteristic per un particolare caratteristica, se restituisce vero, la chiamata successiva a un modo BluetoothGatt o BluetoothGattServer dovrebbe essere fatto dopo la richiamata onCharacteristicRead è ricevuto. Ciò è dovuto al fatto che lo stack è progettato per supportare ed elaborare solo una chiamata GATT alla volta e se, per esempio , si chiama writeCharacteristic o readCharacteristic di qualsiasi characteristic subito dopo il primo, viene ignorato.

fonte

2013-08-05 09:23:58 OneWorld

Sono davvero contento di aver trovato questa domanda. Google non si fa in quattro per renderlo chiaro. Restituire true quando una richiesta di lettura/scrittura è in realtà ignorata è abbastanza confusa. – svens

Qualcuno può confermare se android.bluetooth.BluetoothGatt può gestire solo un'operazione GATT in attesa ** PER DEVICE **, ** PER PROCESSO **, o ** PERIODO ** (ovvero tra tutti i processi). Presumo che sia PER DEVICE, ma questo problema è talmente pasticciato che non mi sorprenderebbe se fosse diversamente. Se la limitazione è solo PER DISPOSITIVO, il sistema operativo/dispositivo in grado di gestire più operazioni simultanee sta fumando la prova della pistola che questo problema è dovuto esclusivamente a un'implementazione ingenua nell'istanza BluetoothAdapter che il sistema operativo gestisce ogni processo (che avevo ipotizzato fosse un singleton in tutti i processi). – swooby

È una operazione in sospeso per oggetto BluetoothGatt. – Emil

-1

No. la maggior parte delle chiamate di funzione sono asincrone.
Non so. I documenti ufficiali non lo menzionano, ma non dice che supporta solo un dispositivo. Credo che sia possibile farlo. Controllare questo articolo: http://blog.lemberg.co.uk/getting-bottom-android-bluetooth-low-energy-api#.UfvK6ZK-1cY

Si dice (non so quale sia la sua origine è) che più periferiche possono collegarsi al dispositivo una centrale Android

fonte

2013-08-02 15:07:36 edoardotognoni

L'API Samsung ble è anche asincrona in qualche modo. Si ottiene la risposta in un callback (l'API è molto simile tra l'altro) Tuttavia, se si licenziano 2 richieste in breve tempo Mentre il primo non è stato completamente completato, il primo potrebbe essere cancellato. Quindi la domanda è, se anche l'API nativa ha questo comportamento. – OneWorld

Ah ok, ora capisco. Non so se le API native seguano questo comportamento. Penso che sia così. Se sparate 2 scanBLE, quello precedente viene cancellato, ma non ne sono sicuro. – edoardotognoni

L'implementazione nativa di Android BLE è di natura sincrona?

risposta

Problemi correlati