2014-10-22 15 views

Odpowiedz

5

Nie otrzymujesz konkretnego powiadomienia, gdy centrala łączy się z usługą peryferyjną świadczoną przez twoją aplikację. Można wywnioskować, połączenie z poniższego CBPeripheralManagerDelegate metod miano -

  • didSubscribeToCharacteristic
  • didReceiveReadRequest
  • didReceiveWriteRequest

Jeśli otrzymałeś subskrypcję poprzez didSubscribeToCharacteristic wtedy można wywnioskować odłączenie kiedy odebrać odpowiednie połączenie z numerem didUnsubscribeFromCharacteristic. Jeśli centrala nie używa subskrypcji, nie masz żadnych wskazówek, że się odłączyły - po prostu nie otrzymasz więcej żądań odczytu/zapisu.

Nie można odrzucić połączenia z centrali. Możesz ustawić wymaganie szyfrowania dla jednej lub więcej swoich cech. Spowoduje to zainicjowanie procesu parowania opartego na styku, gdy centrala najpierw spróbuje odczytać/zapisać/powiadomić o tej charakterystyce.

Można również zaimplementować pewien rodzaj procesu uwierzytelniania, w którym centrala musi odpowiedzieć na wyzwanie/wpisać hasło do charakterystyki itp., Zanim odpowie na inne żądania odczytu/zapisu centrali.

+0

Cześć Paulw11, dziękuję za odpowiedź. Ale nie jestem pewien co do procesu budowania połączenia zainicjowanego przez centralę. Czy oznacza to, że centrala odczytuje sygnały rozgłoszeniowe z urządzeń peryferyjnych podczas łączenia, nie powiadamiając o tym urządzeń peryferyjnych, o ile nie ma to wpływu na charakterystykę? –

+0

Nie, w warstwie Bluetooth jest powiadomienie urządzenia peryferyjnego, że połączenie jest inicjowane i odbywa się komunikacja w celu nawiązania połączenia, ale framework Core Bluetooth nie ujawnia metody delegowania w celu poinformowania CBP o komputerze, że połączenie zostało nawiązane – Paulw11

+0

@Paulw czy znasz racjonalność, która nie ujawnia tych informacji? Czy istnieje jakiś sposób symulacji "złego" łącza BTLE (jak możemy powiedzieć, że łącze WiFi spowoduje spadek 50% pakietów za pomocą Ustawień -> Deweloper)? –