web-dev-qa-db-fra.com

Que peuvent faire exactement les applications CoreBluetooth en arrière-plan?

Le sujet dit tout, vraiment. La documentation, dans la mesure où elle existe, suggère que les applications écrites contre le framework CoreBluetooth fonctionnant sur les appareils iOS peuvent ajouter "bluetooth-central" à leur liste de privilèges en arrière-plan et ainsi traiter une sorte d'événements Bluetooth tout en étant inactifs, mais qui exact les événements sont-ils et ne sont-ils pas livrés?

Par exemple:

  1. Puis-je continuer les communications avec un appareil avec lequel j'ai déjà établi un appairage?
  2. Puis-je émettre des demandes de découverte périodiques pour trouver des appareils hors de portée/que je n'ai jamais vus auparavant? (Par exemple, si je voulais être en mesure de délivrer une notification lorsqu'un nouvel appareil intéressant est rencontré)
  3. Que se passe-t-il si un appareil est hors de portée et revient ensuite? Vais-je recevoir des événements déconnectés et connectés sans intervention de l'utilisateur, ou dois-je être mis au premier plan et demander à l'utilisateur de demander explicitement la reconnexion?
ioscore-bluetooth
78
Chris Smowton

Personne ne semblait le savoir, j'ai donc acheté un compte de développeur iOS et effectué quelques expériences. Voici ce que j'ai trouvé:

Lors de l'exécution au premier plan, vous pouvez démarrer une analyse à l'aide de CBCentralManager :: scanForPeripheralsWithServices. Votre analyse peut être restreinte aux appareils annonçant un service particulier, ou non restreinte (passez zéro pour le paramètre de cet appel). Il peut également autoriser ou interdire les doublons; dans le premier cas, vous obtiendrez un rappel didDiscoverPeripheral chaque fois que l'iPhone reçoit un paquet de publicité; dans ce dernier, vous ne recevrez qu'un seul rappel par appareil trouvé.

Lorsque vous entrez en arrière-plan, les règles semblent être les suivantes:

  • Si vous exécutiez une analyse sans restriction, elle sera annulée en silence. Vous n'obtiendrez aucun rappel didDiscover.
  • Si votre analyse était restreint (c'est-à-dire que vous avez spécifié un ou plusieurs UUID de service que vous cherchiez), votre analyse continuera de s'exécuter, mais le l'indicateur autoriser les doublons sera ignoré. Cela signifie que vous n'obtiendrez désormais que les rappels didDiscoverPeripheral pour les appareils nouveaux. Si tous les appareils ont été vus au premier plan, vous ne recevrez aucun rappel.
  • Démarrage et arrêt de l'analyse ne le fait pas réinitialisez les périphériques considérés comme nouveaux. Si un seul appareil est présent, vous n'obtiendrez qu'un seul rappel, même sur plusieurs analyses, sauf si ...
  • Si vous connectez à un périphérique, puis déconnectez, puis scannez à nouvea, le périphérique sera à nouveau énuméré (c'est-à-dire que vous recevrez un appel supplémentaire vers didDiscoverPeripheral). Je suppose que iOS considère cela comme ayant "manifesté de l'intérêt" pour l'appareil.

Je ne sais pas si les tentatives de connexion à des appareils non connectables (par exemple, les annonceurs BLE, comme ceux qui implémentent le profil de proximité) sont assez bonnes car mes exemples d'appareils sont connectables. Cependant, au moins pour les périphériques connectables, cette procédure de numérisation/connexion/déconnexion/numérisation suffit pour interroger la présence d'un périphérique en arrière-plan.

Les résultats ci-dessus ont été recueillis à l'aide d'un iPhone 4S exécutant iOS 5.0.1

119
Chris Smowton

En plus de la réponse de Chris:

  • Si votre application dispose du mode d'arrière-plan "bluetooth-central" et est connectée à un périphérique, vous pouvez recevoir des notifications (peripheral:didUpdateValueForCharacteristic:error:) du périphérique en arrière-plan, même après 10 minutes.

Ainsi, lorsque vous souhaitez exécuter en continu en arrière-plan, vous avez 2 options:

  • Exécutez la boucle "se connecter, se déconnecter, scanner à nouveau"
  • Faire des notifications d'envoi par le périphérique

Plus tard devrait être le "Contexte de l'événement" des vidéos Bluetooth de base de la WWDC 2012 https://developer.Apple.com/videos/wwdc/2012/ Mais le premier ressemble à un hack, je ne veux pas compter sur elle.

J'ai testé cela sur iPhone5, iOS6.1.4

Apple a finalement publié le Core Bluetooth Programming Guide et voici la note officielle sur

Traitement d'arrière-plan Bluetooth principal pour les applications iOS

9
mash

Il est également bon de noter le comportement de l'arrière-plan et de CoreBluetooth liés aux iBeacons, bien que Apple aime à penser à cela comme une fonctionnalité CoreLocation:

  1. Lorsque les notifications pour une région iBeacon sont activées, elles avisent l'utilisateur de l'entrée ou de la sortie de la région. Ces notifications peuvent être effectuées selon que l'affichage est allumé ou éteint. Ces notifications fonctionnent même lorsque l'application demandant des notifications est en arrière-plan. (Cela est clair dans la documentation).

  2. Pas si évident: si vous utilisez l'API de télémétrie iBeacon, votre application doit être au premier plan. Il ne le dit pas explicitement dans la documentation - en fait, on peut être trompé en pensant que la plage devrait fonctionner en arrière-plan à partir de la documentation. Cependant, un ingénieur Apple Apple clarifie cela dans un message enterré quelque part dans un long fil sur le forum des développeurs Apple, et j'ai également vu cela échouer. ne fonctionnera qu'au premier plan.

  3. On peut découvrir d'autres services annoncés par un iBeacons publicitaire périphérique. Mais cela ne fonctionnera qu'au premier plan. Donc, si vous souhaitez que le central soit informé de la proximité à l'aide d'iBeacons, puis effectuez d'autres transactions à l'aide d'autres services basés sur BLE, cela fonctionnera, mais uniquement au premier plan. Cela ne fonctionnera pas en arrière-plan. Pour les transactions avec des services basés sur BLE en arrière-plan, la publicité doit être une publicité BLE régulière, pas une iBeacon. Vous ne pouvez pas utiliser une publication iBeacon pour aider le processus de découverte en arrière-plan, puis passer à l'utilisation des services BLE en arrière-plan. (J'aurais beaucoup aimé que cela fonctionne, mais pas de dés).

7
user108

Je viens d'apprendre le mode d'arrière-plan pour les appareils BLE sur iOS8.3 et 8.4 et j'ai trouvé quelques différences par rapport au dessus:

  1. si je commence

    [centralManager scanForPeripheralsWithServices: @ [[CBUUID UUIDWithString: kServiceUUID]] options: @ {CBCentralManagerScanOptionAllowDuplicatesKey: @YES}];

de

- (void)applicationDidEnterBackground:(UIApplication *)application

J'ai trouvé que l'énumération renvoie le même périphérique à chaque appel avec un RSSI différent, donc CBCentralManagerScanOptionAllowDuplicatesKey n'est pas ignoré.

  1. Si l'application est au premier plan, elle a découvert le périphérique BLE 50 fois en secondes. Si l'application est en arrière-plan mais que l'écran du téléphone est actif, l'application a détecté les appareils BLE 6 fois par seconde. Si l'écran du téléphone est bloqué, l'application a détecté les appareils BLE 1 fois en sec.
4
Igor Vlasov