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:
- Uruchom OneTimeWorkRequest i określ okresowe ponowne uruchamianie tej metody w tej metodzie, gdy aplikacja działa w tle.
- 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
Worker
są 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ć atag
doWorker
i wyczyścić wszystkie zaplanowane lub trwające, gdy będą widoczne dla użytkownika. - Wolę trzymać
Worker
s odizolowane od MVVM i po prostu wstrzyknąć przypadki użycia / interaktory do procesu roboczego i wykonać przypadek użycia / zapytanie interaktora.WorkerManager
oferuje doskonałe interfejsy API do sprawdzaniaWorker
statusu, może być konieczne napisanie wspólnej podstawy między poprzednią implementacją i API> = 30. Traktuj tenWorker
kontener jako inny kontener wykonywania dla swojego przypadku użycia.