Usprawnienia modułu Bluetooth

[mikolak]

Tematy usprawnień modułu Bluetooth

1. Przeniesienie użycia wszystkich obiektów związanych z działaniem Bluetootha do serwisu pracującego w oddzielnym procesie

Aktualnie na wciągnięcie do głównej gałęzi programu czeka #66
Po dodaniu będzie można przenieść użycie BluetoothBeaconIdExchangeManager z ProtegoApp do tego serwisu.

Motywacja: Foregroundowy serwis działający w oddzielnym procesie powinien być mniej narażony na zabicie przez system, gdy jednocześnie proces odpowiadający za interfejs użytkownika może zostać wymieciony w celu zwolnienia pamięci.

2. Automatyczne zarządzanie rozgłaszaniem i skanowaniem

Aktualna implementacja jest pierwszą działającą. Nie posiada funkcjonalności samoczynnego wznowienia działania przy sprzyjających warunkach.

Prawdopodobne miejsce wprowadzenia zmian: BluetoothBeaconIdExchangeManager

2a. Obserwacja stanu adaptera Bluetooth oraz ustawienia Location Services

W zależności od ustawienia adaptera należy włączyć lub wyłączyć ProteGoAdvertiser i ProteGoScanner. Odpowiednio, gdy Bluetooth jest włączony na telefonie, to oba obiekty też mogą zostać włączone. Gdy Bluetooth zostanie wyłączony, oba obiekty najpewniej zwrócą błędy w poprzez interfejs słuchacza.

Sprawa z Location Services jest o tyle bardziej skomplikowana, że najprawdopodobniej ProteGoAdvertiser będzie działał niezależnie od ich stanu, z poszanowaniem jednak stanu adaptera Bluetooth. ProteGoScanner natomiast w przypadku wyłączenia Location Services przestanie działać, gdyż takie są ograniczenia na większości urządzeń z systemem Android >=6.0.
Do rozważenia – w takim przypadku można ustawiać wersję w ProteGoAdvertiser (część Manufacturers Data), która by mówiła o tym, że dane urządzenie nie może skanować – wtedy wszystkie inne urządzenia Androida w pobliżu musiałyby się połączyć i zapisać swój BeaconId, gdyż wiadomo, że druga strona nie będzie mogła go zeskanować.

2b. Obsługa potencjalnych problemów raportowanych przez interfejsy słuchaczy ProteGoAdvertiser i ProteGoScanner

Obie klasy przy włączeniu przyjmują referencje do słuchaczy, którzy mogą zostać poinformowani w przypadku problemów, które mogą wystąpić już po włączeniu odpowiednich funkcjonalności.
W takim przypadku należy zidentyfikować problem i w miarę możliwości przełączyć w tryb pozwalający na utrzymanie możliwie dobrego działania.

Przykład myślenia (pseudokod):

var wynikInicjalizacjiAdvertisera = ProteGoAdvertiser.enable()
val wynikInicjalizacjiScanera = ProteGoScanner.enable()
if (wynikInicjalizacjiScanera == negatywny && wynikInicjalizacjiAdvertisera == pozytywny) {
  ProteGoAdvertiser.disable()
  wynikInicjalizacjiAdvertisera = ProteGoAdvertiser.enable(oznajmiajBrakMozliwosciSkanowania)
}
if (wynikInicjalizacjiAdvertisera == negatywny && wynikInicjalizacjiScanera == negatywny) {
  // aplikacja jest zupełnie nieużyteczna
  Notification.poinformujUżytkownikaONapotkanychProblemach
} else if (wynikInicjalizacjiScanera == negatywny) {
 // aplikacja może nie wymuszać połączeń od zewnętrznych urządzeń, jeśli przeszkody w inicjalizacji skanera zostaną usunięte
  Notification.poprosUżytkownikaOUsunięciePrzeszkód
} else if (wynikInicjalizacjiAdvertisera == negatywny) {
  ProteGoAdvertiser.disable() // pod spodem można wyłączyć serwer, który nie zostanie połączony jeśli się nie rozgłasza. Do rozważenia wydzielenie advertisera i serwera.
}

3. Dostrajanie działania funkcjonalności BLE

Ekosystem Androida jest bardzo rozbity. Mnogość urządzeń różnych producentów, często niestandardowych implementacji systemu, różnych wersji systemów, różnych czipów Bluetooth i różnych sterowników oraz firmware'ów na tych chipach nie pozwala na napisanie jednej implementacji, która będzie działała optymalnie w każdych warunkach.

3a. Stworzenie różnych implementacji logiki BluetoothBeaconIdExchangeManager

Przykładowe pomysły:

1. (Początkowa implementacja) Rozgłaszanie i skanowanie odbywa się ciągle. Próby połączeń nie powodują przerwania rozgłaszania i skanowania. Połączenia w trybie bezpośrednim (autoConnect == false.
   Alternatywą mogą być połączenia w trybie autoConnect == true
2. Rozgłaszanie odbywa się ciągle. Skanowanie trwa tak długo aż znajdzie się pierwsze urządzenie do połączenia, następnie przez 10 sekund inne zeskanowane urządzenia są łączone w trybie bezpośrednim (druga wersja w trybie autoConnect)
3. Rozgłaszanie i skanowanie jest przerywane na czas wykonywania połączeń

Dodatkowym parametrem który można wprowadzić jest zmiana trybu skanowania z niskomocowego na zbalansowany.

3b. A/B testy i zbieranie metryk

Ponieważ jest potencjalnie wiele taktyk i nie wiemy na jakim urządzeniu która będzie najlepsza, potrzebujemy robić testy i zbierać metryki z urządzeń.

Pomysły na metryki:

• marka / model / wersja system telefonu
• przyjęta taktyka połączeń (patrz punkt wyżej)
• ilość skanowanych urządzeń / 1h
• ilość prób połączeń do urządzeń / 1h
• ilość udanych połączeń do urządzeń / 1h
• czas trwania udanego połączenia
• czas trwania nieudanego połączenia

Celem zbierania metryk jest zrozumienie która taktyka na danym urządzeniu sprawuje się najlepiej, tak by następnie móc przełączyć wszystkie urządzenia właśnie na nią.

Oryginalna wiadomość

Wyniesione z #65

Do zrobienia:

1. Zarządzanie obiektami rozgłaszająco-skanującymi w kontekście zmian stanu adaptera Bluetooth, ustawień lokalizacji i zezwoleń
2. Implementacja docelowego zarządzania BeaconId
3. Przeniesienie obiektów związanych z Bluetooth do oddzielnego serwisu pracującego w oddzielnym procesie
4. Potencjalnie naprzemienne skanowanie (+ rozgłaszanie?) i próby połączeń
5. A/B testy skuteczności różnych rozwiązań połączeń dla danego modelu telefonu
   a. Czy naprzemienne skanowanie i łączenie poprawia skuteczność połączeń? (Najpewniej tak, patrz tutaj)
   b. Czy jednoczesne rozgłaszanie wpływa na skuteczność połączeń?
   c. Jak wzajemnie wpływają na siebie: rozgłaszanie, odbieranie połączeń, skanowanie i wykonywanie połączeń?
6. Fallback w przypadku gdy skanowanie nie jest możliwe z powodu braku dostępu do lokalizacji, tak by inne urządzenia mogły się połączyć i przekazać swój BeaconId?
7. Obsługa problemów związanych z asynchronicznym raportowaniem błędów przez advertiser i scanner

Zadanie jest do rozbicia na poszczególne punkty.

[mikolak]

@dariuszseweryn jak coś, to tutaj wyniosłem Twoje uwagi z PR.

[dariuszseweryn]

Dorzuciłem swoje trzy grosze
Być może dorzucę więcej, ponieważ Trace Together opublikowało swój kod, który będę starał się obejrzeć i zrozumieć. Może jakieś ciekawe lekcje także z niego płyną.

[jakublipinski]

Na prośbę @MateuszRomanow zamykam issues'y związane z wersją 1.0. Jeśli ten temat dotyczy również aktualnej wersji, proszę o otwarcie.