Différence entre fermer() et disconnect()?

Android Bluetooth Low Energy API implémente la méthode 1 pour vous connecter à l'appareil connectGatt() mais 2 méthodes pour fermer la connexion disconnect() et close().

Documentation dit:

disconnect(): Déconnecte une connexion est établie, ou de l'annulation d'une tentative de connexion
actuellement en cours.
close(): Application doit appeler cette méthode dès que possible après qu'il est fait avec
cette GATT client.

Le code source de BluetoothGatt.java montre que close() annule la demande et disconnect() déconnecter le client. Cependant, il ne dit pas ce que cela signifie réellement. Je veux dire, si ce n'est que 1 façon de se connecter au client, pourquoi il y a 2 façons de fermer/fermer la connexion?

Je suppose que Close signifie que vous n'utilisez plus Gatt objet

InformationsquelleAutor Arturs Vancans | 2014-04-16

66

Avec disconnect() vous pouvez appeler plus tard connect() et continuer avec ce cycle.

Une fois que vous appelez close() vous avez terminé. Si vous souhaitez vous connecter à nouveau, vous aurez pour appeler connectGatt() sur le BluetoothDevice de nouveau; close() libèrent les ressources détenues par BluetoothGatt.
- Super utile seulement de l'appelant disconnect() et restent en cours d'exécution hors de BT interfaces de la prévention de toutes les nouvelles connexions. L'appel de close() empêche cela.
- Chaque fois que j'utilise disconnect() ou close() la méthode de rappel onConnectionStateChange jamais appelée indiquant STATE_DISCONNECTED.
- close() n'obtiendrez pas un appel à onConnectionStateChange, mais disconnect() devrait. Êtes-vous sûr que vous étiez vraiment connecté lorsque vous avez appelé disconnect()?
- Puis-je appeler close(), sans appel disconnect()? Et onConnectionStateChange être appelé dans le cas?
- Après l'appel de disconnect() et close() la onCharacteristicChanged() événement continue de tir. Quelqu'un at-il une solution pour cela?
- vous pouvez appeler close() sans disconnect (), mais vous n'obtiendrez pas une onConnectionStateChange rappel dans mon expérience.
- Ma pensée est que vous avez probablement plusieurs périphériques connectés et obtenir des rappels pour les autres périphériques, ou vous avez débranché et fermé pas ce que vous ne l'auriez pensé.
- Merci pour la réponse. Je suis sûr que je n'ai qu'un seul périphérique connecté. Je suis aussi sûr que je ne appel mBluetoothGatt = device.connectGatt() une seule fois.
- Jusqu'à présent, j'ai seulement utilisé close() au lieu de deux. Mais, je viens de découvrir sur un Nexus 6P fonctionnant sous Android 7.0, que si je l'appelle close() sur un appareil qui est actuellement en attente d'être connecté, mais pas encore connecté, le smartphone encore se reconnecte à l'appareil dès qu'il sera de nouveau visible...
- disconnect() n'aboutit pas à un onConnectionStateChange() si la connexion n'a pas déjà été créé.
- J'ai aussi été aux prises avec des comportements incompatibles. Si vous appelez le gatt.close(), la prochaine fois que vous vous connectez sur le même appareil, vous devrez refaire la découverte du service.Collé BTLE dispositifs ne sont pas censés le faire.Un cautionné par les pairs sait qui vous êtes (à la fois pour l'accouplement et si oui ou non les caractéristiques ont été activés) et peut (par spec) envoyer toutes les données immédiatement. Il suppose que vous savez de ses services. Si vous avez fait une gatt de près, vous ne saurez ses services et peut perdre des données. Je ne sais pas ce qu'est Android n'bas, mais le travail avec des incorporés de faible niveau des piles c'est certainement le cas.
InformationsquelleAutor Douglas Jones
13

Voici quelques éléments de réflexion:

Aussi longtemps que vous n'avez pas appelé à proximité du Gatt, vous pouvez toujours essayer de s'y connecter, ou de découvrir. Donc, lorsque j'essaie de découvrir des services pour une machine, je vais généralement exécuter un thread ou un exécutable qui en fait la demande à se connecter à la machine pour une certaine période de temps.

La première tentative avec une connexion de la machine, sera de retour avec un BluetoothGatt objet que vous pouvez ensuite utiliser pour essayer de découvrir les services de la BluetoothDevice objet. Il semble assez facile de se connecter, mais beaucoup plus difficile à découvrir la machine servces.
```
mBluetoothGatt = machine.getDevice().connectGatt(this, false, mGattCallback);
```
Donc dans mon thread /praticable, je vais vérifier pour voir si le BluetoothGatt est null. Si elle l'est, je vais appeler la ligne ci-dessus du code à nouveau, sinon je vais tenter de découvrir le BluetoothGatt services en tant que tels.
```
mBluetoothGatt.discoverServices();
```
Oh, et j'ai TOUJOURS assurez-vous d'appeler BluetoothAdapter.cancelDiscovery() avant toute tentative de raccordement de découvrir le service.
```
mBluetoothAdapter.cancelDiscovery();
```
Ici est une méthode qui est utilisée pour se connecter à mon exécutable, etc:
```
public void connectToMachineService(BLEMachine machine) {
    Log.i(SERVICE_NAME, "ATTEMPTING TO CONNECT TO machine.getDevice().getName());

    mBluetoothAdapter.cancelDiscovery();

    if(mBluetoothGatt == null)
        mBluetoothGatt = machine.getDevice().connectGatt(this, false, mGattCallback);
    else
        mBluetoothGatt.discoverServices();
}
```
Enfin, assurez-vous de fermer BluetoothGatt les objets que vous avez connecté. Il semble que Android peut gérer les cinq BluetoothGatt objets avant qu'il commence en disant: "impossible de se connecter au Gatt de serveur" ou autre chose comme ça.

Sur chaque BluetoothGatt que j'ai créer, je vais appeler close sur elle, puis la diffusion d'une mise à jour, indiquant que la connexion est fermée. Il semble que il ya beaucoup de fois où la BluetootGatt ne répondra pas par un changement d'état lorsqu'il est déconnecté. Ma méthode de fermeture de la BluetoothGatt va quelque chose comme ceci. Je laisse la méthode qui s'est ouverte pour l'Activité d'appeler le service et la débrancher si une machine ne répond plus et le débrancher de l'état n'est pas appelé.
```
public void disconnectGatt(BluetoothGatt gatt) {
    if(gatt != null) {
        gatt.close();
        gatt = null;
    }

    broadcastUpdate(ACTION_STATE_CLOSED);
}
```
- C'est un peu confus ce que vous appelez la méthode disconnectGatt lorsque vous appelez réellement close() au lieu de disconnect().
InformationsquelleAutor Droid Chris

Vous devez vous connecter pour publier un commentaire.