Najlepszy sposób na uzyskanie lokalizacji GPS w tle dla interfejsu API Androida na poziomie 30 i wyższym

Nov 30 2020

Moja aplikacja określa ograniczenie prędkości na podstawie lokalizacji użytkownika i informuje go, jeśli go przekroczył. Począwszy od poziomu 30 interfejsu API systemu Android i nowszych, Google zdefiniował IntentService jako przestarzały i sugeruje użycie WorkManager lub JobIntentService, a także stwierdza, że ​​konieczna jest migracja z Firebase JobDispatcher do WorkManager. Widzę dwa sposoby rozwiązania tego problemu:

  1. Uruchom OneTimeWorkRequest i określ okresowe ponowne uruchamianie tej metody w tej metodzie, gdy aplikacja działa w tle.
  2. Uruchom PeriodicWorkRequest z minimalnym dozwolonym interwałem 15 minut. W tej metodzie uruchom metodę JobIntentService, która działa przez maksymalnie około 10 minut , ale metoda może nie działać lub może zostać zniszczona przez system przed jej zakończeniem.

Martwię się o:

  • potencjalne wycieki pamięci;
  • potencjalne problemy z WorkManager lub JobIntentService podczas przechodzenia z pierwszego planu do tła i odwrotnie
  • możliwość wykorzystania wzorca MVVM

Odpowiedzi

5 NikolaDespotoski Dec 07 2020 at 23:42

Wolałbym wybrać drugą opcję, która daje więcej czasu między kolejnymi zmianami w harmonogramie Worker.

Jeśli chodzi o twoje obawy:

  • Jedynym możliwym wyciekiem jest niewłaściwe wywołanie lokalizacji. Można to łatwo wyśledzić, nie powinieneś się tym zbytnio przejmować.
  • Zaplanowane Workersą umieszczane w bazie danych i wykonywane niezależnie od aplikacji. Co oznacza, że ​​widoczność aplikacji dla użytkownika nie ma żadnego wpływu. W twoim przypadku zakładam, że chcesz anulować zaplanowaną pracę, gdy użytkownik wznowi aplikację, co oznacza, że ​​możesz przypisać a tagdo Workeri wyczyścić wszystkie zaplanowane lub trwające, gdy będą widoczne dla użytkownika.
  • Wolę trzymać Workers odizolowane od MVVM i po prostu wstrzyknąć przypadki użycia / interaktory do procesu roboczego i wykonać przypadek użycia / zapytanie interaktora. WorkerManageroferuje doskonałe interfejsy API do sprawdzania Workerstatusu, może być konieczne napisanie wspólnej podstawy między poprzednią implementacją i API> = 30. Traktuj ten Workerkontener jako inny kontener wykonywania dla swojego przypadku użycia.