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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

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

Answer 2

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

При необходимости вы можете использовать привязку для взаимодействия с действиями.

Answer 3

Есть ли хороший чистый способ проверить, не может ли GPS получить блокировку?

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

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

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

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

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

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

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

Answer 4

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

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

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

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