Определение, если GPS не может получить блокировку

Question

Ситуация: в моей программе есть детали, которые в значительной степени основаны на местоположении, но для устранения проблем, когда местоположение действительно необходимо, у меня нет времени для блокировки. Решение, которое я разработал, состоит в том, чтобы получать информацию о местоположении во время основной операции (читай: главный экран), чтобы местоположение было доступно, когда оно требуется конкретным элементам.

Прямо сейчас я регистрируюсь на обновления и в onLocationChanged проверяет, является ли местоположение достаточно точным. Если это так, он вызывает removesUpdates.

Проблема: Если устройство находится где-то, что оно не может получить точное местоположение (или любое другое местоположение), GPS не отключается, батареи перегреваются, и пользователи очень расстраиваются.

Вопрос: Есть ли хороший чистый способ проверить, не удается ли GPS получить блокировку, и сказать, чтобы он сдавался в определенной точке? Я создал таймер потока, но поскольку запрос привязан к onPause / onResume, я не хочу создавать дополнительные потоки, которые могут запутаться.

Answer 1

Используйте сервис для инкапсуляции этой функциональности.Запустите асинхронную задачу изнутри.

Вы можете использовать привязку для управления взаимодействием с действиями, где это необходимо

Answer 2

Есть ли хороший чистый способ проверить, не удается ли GPS получить блокировку

Да, есть некоторые случаи, когда GPS не может получить исправление в течение длительного времени. Из моего опыта это:

• Нет вспомогательных данных . Видите ли, наборы микросхем GPS в телефоне имеют несколько ограничений (батарея, скорость и т. Д.), Следовательно, они не спешат исправлять ошибки. Чипсет GPS должен сканировать спектр для спутника, и это занимает некоторое время. Информация о помощи отправляется через Интернет. Он содержит данные альманаха, которые содержат информацию о положении спутников и частотах, что сокращает время поиска сигнала GPS. Отсутствие интернета означает, что для получения исправления чипсету GPS потребуется более 2 минут (это называется автономным GPS). Это время зависит от чипсета, местности, погоды и т. Д.

  (tldr: проверить, доступен ли интернет, если нет, то следует ожидать длительного TTFF (время для первого исправления)

• Низкая видимость спутника : Это происходит в закрытых помещениях. Даже если в чипсете GPS есть вспомогательные данные. Он не может видеть спутники, потому что он находится в помещении. Это означает, что отношение сигнал-шум спутника низкое, или число видимых спутников меньше 4. В теории достаточно двух спутников. Но на практике я видел как минимум 4 спутника, необходимых для правильного исправления.

  (tldr: Используйте прослушиватель NMEA / Слушатель статуса GPS , чтобы узнать, сколько спутников видно / используется. Для фиксирования необходимо использовать спутники Atleast 4)

• Аппаратные / программные проблемы : С этим ничего не поделаешь. Некоторые наборы микросхем GPS позволяют отправлять дополнительную информацию для «сброса» данных из кэша GPS. Обращайте внимание на огромное время TTFF и другие подобные ненормальные шаблоны GPS, используйте механизм тайм-аута.

Это в основном написано с точки зрения GPS, так что не возражайте, если это не имеет большого смысла.

Answer 3

В дополнение к ответу Мерлина (я просто печатал этот лот в блокноте, когда он появился) - я согласен. Мое предложение:

Столкнувшись с подобной проблемой, я решил, что лучше всего будет отделить весь GPS от основной деятельности с помощью службы.

Под этим я подразумеваю службу, которая выполняет requestsLocationUpdates() и removeLocationUpdates() и реализует LocationListener. Этот сервис предоставляет методы, которые основная деятельность может вызывать с помощью интерфейса IBinder. Он также отправляет широковещательные сообщения активности, которая реализует BroadcastReceiver для прослушивания этих сообщений.

Таким образом, один из сервисных методов, которые может вызвать ваша основная деятельность, будет (скажем)

mLocnServ.startGPS(int timeout, float requiredAccuracy, int minUpdatePeriod, int minResendDistance)

где mLocnServ - интерфейс связующего, предоставляемый службой.

Последние два аргумента - это те, которые передаются в качестве аргументов requestLocationUpdates в сервисе. (лично я не думаю, что это имеет какое-либо значение, когда GPS отключается, насколько я вижу, он работает все время, пока не будет вызван removeUpdates()). В любом случае, первый аргумент (тайм-аут) должен быть временем, когда вы готовы ждать исправления требуемой точности (аргумент 2).

Таким образом, в вашем сервисе вам понадобится Runnable в качестве таймера, который, если истечет время ожидания, отправит трансляцию типа TIMED_OUT (скажем) и removeUpdates, чтобы остановить GPS. В onLocationChanged вы можете проверить полученное местоположение с требуемой точностью и, если оно достаточно хорошее, отправить трансляцию типа GOT_A_FIX (скажем) и передать местоположение (широта / долгота и точность) в качестве дополнений в трансляции, а затем удалить остановить GPS. (TIMED_OUT и GOT_A_FIX являются просто примерами имен для перечислений, которые вы можете составить, чтобы различать типы широковещательных сообщений)

Основное действие может решить, что делать затем в его BroadcastReceiver onReceive (), т. Е. Делать ли повторную попытку, если он получил TIMED_OUT трансляцию, или что делать с данными, полученными из сообщения GOT_A_FIX.

Вам, вероятно, также понадобится mLocnServ.stopGPS в переплете, чтобы можно было отключить GPS независимо от того, что делает служба

Answer 4

У меня была похожая проблема.Я хотел иметь возможность получать GPS-координаты во всех своих действиях, но не хотел реализовывать суперкласс с прослушивателем GPS, иногда, если намерение вызывало ту же самую деятельность, я сталкивался с некоторыми проблемами с застреванием GPS.Не хотел отключать его во время onPause ..

По сути, я создал службу, которая получает обновления GPS, затем подсчитываю, сколько слушателей подключилось / отключилось от моей службы.Если обратные вызовы = 0, то я останавливаю GPS.Если обратные вызовы = 1, я запускаю его.

Это, кажется, работает довольно хорошо, и кажется довольно надежным способом обработки обновлений GPS во всем приложении.Хорошо, что когда я отменяю регистрацию своих обратных вызовов в onStop, мой onStart на самом деле сначала подключается до того, как onStop вызывается из предыдущего действия.Это означает, что мой GPS не пропустит удар.

Я реализовал суперкласс, который подключает и реализует обратные вызовы для моего сервиса (через aidl).Таким образом, каждый класс деятельности имеет доступ к информации, как если бы он был реализован в действии.