Задача: наступает лето, дети все больше времени проводят где-то на улице, и я бы хотел знать, где они находятся. Идеальный вариант — я просто даю им с собой старый андроидный телефон, и затем наблюдаю за ними по карте на большом домашнем мониторе.
В этой статье я расскажу, почему и как я написал свое первое приложение для Андроид с функциями GPS «KidsTrack», и какие открытия при этом сделал. Статья будет полезна тем, кто недавно начал программировать под Android.
Поиски на Google Play выдали мне сотни различных приложений с функциями GPS-мониторов. Я уж начал их было перебирать, но примерно на 2-м десятке я осознал, что затраты времени на выбор могут оказаться вполне сравнимыми с затратами времени на разработку. Ведь мои функциональные требования очень просты:
Это все!
Есть еще требования, которые не связаны с функциональностью, но которые не менее важны:
Одним словом, попробовав несколько приложений из Google Play, я решил написать трекер сам.
Далее, все тривиально: установил Android Studio, нарисовал единственный экран с 3-мя кнопками, написал, как мне казалось, сервис, отладил все в эмуляторе, затем в USB-дебаггере, вроде все заработало.
Но как только попробовал запустить на физическом устройстве — начались сюрпризы. О некоторых из них я хотел бы рассказать.
Реальные андроид-устройства стремятся отключить себе питание при любой возможности. Постоянно получают питание лишь весьма примитивные системные часы (модуль мобильной связи здесь он не рассматривается). В часах есть регистр(ы), куда посредством AlarmManager можно записать время следующей пробудки процессора телефона. Если процессор не разбудят часы, то он так и будет продолжать спать ничего не делая. Сделано это по простой причине: включенный процессор разрядит батарею за час. Поэтому если надо, чтобы сервис что-то делал раз в минуту, то приемы десктопного программирования вроде Thread.sleep(60000) не подойдут, а вместо этого надо пользоваться AlarmManager, примерно вот так:
В этом примере мы программируем AlarmManager разбудить телефон через 1 минуту, и отправить интент START_ALARM всем приложениям, кто на него подписан.
Прием интентов во всех учебниках осуществляется объектом BroadcastReceiver, однако если нам нужно, чтобы:
то BroadcastReceiver не подойдет, и вместо него надо использовать WakefulBroadcastReceiver — этот объект гарантировано не допустит впадения телефона в сон до тех пор, пока не будет вызван метод completeWakefulIntent. Во всяком случае у меня так и не получилось заставить BroadcastReceiver работать надежно на физическом устройстве.
Если ваш сервис теоретически может выходить в интернет через WiFi, то вам необходимо позаботится, чтобы у WiFi-модуля во время соединения тоже было включено питание, так как оно у него отдельное. Если этого не сделать, то бывает трудно понять почему приложение не работает на физическом устройстве: ведь при отладке на эмуляторе или устройстве, подключенном к дебаггеру через USB, питание модуля WiFi не выключается, и все отлично работает. Запретить отключать питание WiFi можно так:
В первой версии приложения я сделал определение координат устройства только с использованием провайдера «GPS». И очень было мне удивительно наблюдать на сервере, как более 90% устройств не смогли определить координаты и присылали нули.
Как оказалось, GPS – довольно капризная технология с множеством ограничений, низкой скоростью и непредсказуемой точностью. При использовании традиционной GPS сенсор приемника должен получить данные обо всех GPS-спутниках (а их более 2х десятков), среди всех них выбрать наиболее подходящие, и уже по ним вычислять координаты. Получение данных и перебор могут занимать 5 минут и более, поэтому первый «холодный» старт GPS всегда самый медленный.
Если GPS-приемник имеет часы и помнит прошлые координаты и положения спутников, то он может использовать эти данные для определения тех спутников, к которым можно привязаться в данный момент. Поэтому повторный запуск GPS обычно происходит намного быстрее.
В современных смартфонах первоначальное грубое определение координат может осуществляться по близлежащим передающим сотовым вышкам, что так же позволяет ускорить «холодный старт» GPS. Для использования этого способа требуется разрешение на использование провайдера «network» в Manifest-е, так для определения я координат вышек может использоваться интернет.
Еще одна функция провайдера «network» — определять координаты по видимым WiFi — сетям. Определение осуществляется путем поиска координат видимых в данный момент сетей по их именам и MAC-адресам на серверах Google через интернет. Разумеется, в фоновом режиме и без лишних уведомлений идет и обратный трафик: телефон, когда определил свои координаты по GPS, может по-тихому послать данные об окружающих его WiFi-сетях на серверы Google, чтобы таким образом поддерживать актуальное состояние базы WiFi-сетей. Грустные размышления о потенциальной власти Google над владельцами Андроидов и WiFi-сетей оставим за рамками этой статьи…
Прояснив все эти нюансы я в авральном порядке подправил приложение, чтобы оно использовало не только провайдера «GPS» но и «network». После этого типичная последовательность вызовов метода onLocationChanged стала выглядеть так:
Я все-таки очень хотел задействовать GPS, так как обычно это самый точный способ, поэтому я установил время ожидания сигнала от GPS-сенсора 30 секундам, а если это первый пуск — 2-м минутам. И если GPS-сенсор так и не сработал, то используются координаты от провайдера «network». После этого изменения устройства стали присылать на сервер нормальные, ненулевые координаты.
Точность GPS также оказалась весьма условной. Например нередко точность координат, получаемых с сенсора неподвижного лежащего устройства может выглядеть так:
Из этих данных ясно, что GPS хорош для нахождения зданий или других больших объектов, но найти человека в толпе, или телефон в сугробе будет непросто.
Отдельно стоит упомянуть питание GPS. Модуль GPS весьма прожорлив, поэтому в учебниках рекомендуют при вызове requestLocationUpdates не устанавливать слишком короткие параметры минимального интервала по времени и по расстоянию. Но в моих опытах с 3-мя различными физическими устройствами оказалось, что постоянно включенный модуль GPS садит батарею одинаково при различных параметрах. Потом уже я нашел где-то упоминание, что эти параметры влияют только на частоту вызова метода onLocationChanged, но не обязательно на энергопотребление самого сенсора.
Google Play: Первая версия пролежала на Google Play два дня, после чего была заменена новой, с исправленным алгоритмом определения координат. Несмотря на то, что это произошло уже две недели назад, я на сервере продолжаю видеть, что очень часто продолжают происходить активации старой версии. Я уже и добавил сообщение о необходимости обновления на веб-странице мониторинга, но это не всегда помогает. Непонятно откуда вообще люди берут старую версию. Я не знаю чем это объяснить.
Пользователи: Почти треть пользователей, установивших приложение, никогда не открывала страницу, на которой устройство можно мониторить. Без страницы мониторинга приложение бесполезно, поэтому объяснить это феномен я тоже не могу.
Яндекс.Карты: Страница мониторинга изначально была реализована с использованием API Яндекс.Карт, так как там не требуется ID, и нет ограничений на количество загрузок карты в день. Но оказалось, что на слабых устройствах Яндекс.Карты или тормозят, или вообще не открываются. Пришлось эту страничку делать в 2-х вариантах: Яндекс.Карты для настольных компьютеров, и Google Maps для слабых мобильных устройств. Google Maps оказались существенно быстрее.
С практической точки зрения итоги, конечно, скромные, так как уже существует множество гораздо более продвинутых GPS-мониторов. Но судя по отзывам, именно простотой KidsTrack и приглянулся многим.
Для меня лично итоги значительно более внушительные. Главный итог — бесценный опыт, который невозможно было бы получить из статей или учебников. Грабли, описанные выше, заставили пересмотреть реалистичность и дизайн других более крупных проектов, над которыми я работаю.
В этой статье я расскажу, почему и как я написал свое первое приложение для Андроид с функциями GPS «KidsTrack», и какие открытия при этом сделал. Статья будет полезна тем, кто недавно начал программировать под Android.
Поиски на Google Play выдали мне сотни различных приложений с функциями GPS-мониторов. Я уж начал их было перебирать, но примерно на 2-м десятке я осознал, что затраты времени на выбор могут оказаться вполне сравнимыми с затратами времени на разработку. Ведь мои функциональные требования очень просты:
- приложение должно периодически отправлять анонимные координаты на сервер,
- сервер должен показывать карту с маркером в соответствующем месте.
Это все!
Есть еще требования, которые не связаны с функциональностью, но которые не менее важны:
- отсутствие необходимости регистрации, и привязки аккаунтов
- бесплатность
- отсутствие рекламы
- отсутствие ненужных функций, которые уже есть или в телефоне, или в других приложениях, типа обмена сообщениями, тревожных кнопок, уведомлений, стираний данных, блокировок телефона, чата, и т.п.
Одним словом, попробовав несколько приложений из Google Play, я решил написать трекер сам.
Далее, все тривиально: установил Android Studio, нарисовал единственный экран с 3-мя кнопками, написал, как мне казалось, сервис, отладил все в эмуляторе, затем в USB-дебаггере, вроде все заработало.
Экран с 3-мя кнопками
Но как только попробовал запустить на физическом устройстве — начались сюрпризы. О некоторых из них я хотел бы рассказать.
Сюрпризы управления питанием
Реальные андроид-устройства стремятся отключить себе питание при любой возможности. Постоянно получают питание лишь весьма примитивные системные часы (модуль мобильной связи здесь он не рассматривается). В часах есть регистр(ы), куда посредством AlarmManager можно записать время следующей пробудки процессора телефона. Если процессор не разбудят часы, то он так и будет продолжать спать ничего не делая. Сделано это по простой причине: включенный процессор разрядит батарею за час. Поэтому если надо, чтобы сервис что-то делал раз в минуту, то приемы десктопного программирования вроде Thread.sleep(60000) не подойдут, а вместо этого надо пользоваться AlarmManager, примерно вот так:
public class YourService extends Service {
public int onStartCommand(Intent intent, int flags, int startId) {
/* Что-то делаем */
...
/* Планируем следующий страрт */
Intent ai = new Intent("info.izhforum.kidstrack.START_ALARM");
PendingIntent pai = PendingIntent.getBroadcast(mInstance, 0, ai, 0);
mAlarmManager.set(AlarmManager.RTC_WAKEUP,System.currentTimeMillis()+60000, pai);
...
}
}
В этом примере мы программируем AlarmManager разбудить телефон через 1 минуту, и отправить интент START_ALARM всем приложениям, кто на него подписан.
Прием интентов во всех учебниках осуществляется объектом BroadcastReceiver, однако если нам нужно, чтобы:
- телефон пробуждался из глубокого сна
- запускал наш сервис,
- не засыпал до завершения работы
то BroadcastReceiver не подойдет, и вместо него надо использовать WakefulBroadcastReceiver — этот объект гарантировано не допустит впадения телефона в сон до тех пор, пока не будет вызван метод completeWakefulIntent. Во всяком случае у меня так и не получилось заставить BroadcastReceiver работать надежно на физическом устройстве.
Если ваш сервис теоретически может выходить в интернет через WiFi, то вам необходимо позаботится, чтобы у WiFi-модуля во время соединения тоже было включено питание, так как оно у него отдельное. Если этого не сделать, то бывает трудно понять почему приложение не работает на физическом устройстве: ведь при отладке на эмуляторе или устройстве, подключенном к дебаггеру через USB, питание модуля WiFi не выключается, и все отлично работает. Запретить отключать питание WiFi можно так:
private WifiManager mWifiManager = null;
private WifiManager.WifiLock mWifiManagerLock = null;
...
mWifiManagerLock = mWifiManager.createWifiLock(WifiManager.WIFI_MODE_FULL, "MyWFL");
mWifiManagerLock.acquire();
/* Здесь осуществляем сетевой ввод/вывод */
mWifiManagerLock.release();
Сюрпризы GPS
В первой версии приложения я сделал определение координат устройства только с использованием провайдера «GPS». И очень было мне удивительно наблюдать на сервере, как более 90% устройств не смогли определить координаты и присылали нули.
Как оказалось, GPS – довольно капризная технология с множеством ограничений, низкой скоростью и непредсказуемой точностью. При использовании традиционной GPS сенсор приемника должен получить данные обо всех GPS-спутниках (а их более 2х десятков), среди всех них выбрать наиболее подходящие, и уже по ним вычислять координаты. Получение данных и перебор могут занимать 5 минут и более, поэтому первый «холодный» старт GPS всегда самый медленный.
Если GPS-приемник имеет часы и помнит прошлые координаты и положения спутников, то он может использовать эти данные для определения тех спутников, к которым можно привязаться в данный момент. Поэтому повторный запуск GPS обычно происходит намного быстрее.
В современных смартфонах первоначальное грубое определение координат может осуществляться по близлежащим передающим сотовым вышкам, что так же позволяет ускорить «холодный старт» GPS. Для использования этого способа требуется разрешение на использование провайдера «network» в Manifest-е, так для определения я координат вышек может использоваться интернет.
Еще одна функция провайдера «network» — определять координаты по видимым WiFi — сетям. Определение осуществляется путем поиска координат видимых в данный момент сетей по их именам и MAC-адресам на серверах Google через интернет. Разумеется, в фоновом режиме и без лишних уведомлений идет и обратный трафик: телефон, когда определил свои координаты по GPS, может по-тихому послать данные об окружающих его WiFi-сетях на серверы Google, чтобы таким образом поддерживать актуальное состояние базы WiFi-сетей. Грустные размышления о потенциальной власти Google над владельцами Андроидов и WiFi-сетей оставим за рамками этой статьи…
Прояснив все эти нюансы я в авральном порядке подправил приложение, чтобы оно использовало не только провайдера «GPS» но и «network». После этого типичная последовательность вызовов метода onLocationChanged стала выглядеть так:
1) 00:00.234 провайдер = “network”, точность = 1672m // пришли координаты по сотовым вышкам 2) 00:00.933 провайдер = “network”, точность = 52m // пришли координаты по WiFi 3) 00:16.310 провайдер = “gps”, точность = 28m // пришли координаты по GPS
Я все-таки очень хотел задействовать GPS, так как обычно это самый точный способ, поэтому я установил время ожидания сигнала от GPS-сенсора 30 секундам, а если это первый пуск — 2-м минутам. И если GPS-сенсор так и не сработал, то используются координаты от провайдера «network». После этого изменения устройства стали присылать на сервер нормальные, ненулевые координаты.
Точность GPS также оказалась весьма условной. Например нередко точность координат, получаемых с сенсора неподвижного лежащего устройства может выглядеть так:
05:13:05 76m 05:14:36 68m 05:15:58 37m 05:17:20 79m 05:19:00 116m
Из этих данных ясно, что GPS хорош для нахождения зданий или других больших объектов, но найти человека в толпе, или телефон в сугробе будет непросто.
Отдельно стоит упомянуть питание GPS. Модуль GPS весьма прожорлив, поэтому в учебниках рекомендуют при вызове requestLocationUpdates не устанавливать слишком короткие параметры минимального интервала по времени и по расстоянию. Но в моих опытах с 3-мя различными физическими устройствами оказалось, что постоянно включенный модуль GPS садит батарею одинаково при различных параметрах. Потом уже я нашел где-то упоминание, что эти параметры влияют только на частоту вызова метода onLocationChanged, но не обязательно на энергопотребление самого сенсора.
Прочие сюрпризы
Google Play: Первая версия пролежала на Google Play два дня, после чего была заменена новой, с исправленным алгоритмом определения координат. Несмотря на то, что это произошло уже две недели назад, я на сервере продолжаю видеть, что очень часто продолжают происходить активации старой версии. Я уже и добавил сообщение о необходимости обновления на веб-странице мониторинга, но это не всегда помогает. Непонятно откуда вообще люди берут старую версию. Я не знаю чем это объяснить.
Пользователи: Почти треть пользователей, установивших приложение, никогда не открывала страницу, на которой устройство можно мониторить. Без страницы мониторинга приложение бесполезно, поэтому объяснить это феномен я тоже не могу.
страница мониторинга
Яндекс.Карты: Страница мониторинга изначально была реализована с использованием API Яндекс.Карт, так как там не требуется ID, и нет ограничений на количество загрузок карты в день. Но оказалось, что на слабых устройствах Яндекс.Карты или тормозят, или вообще не открываются. Пришлось эту страничку делать в 2-х вариантах: Яндекс.Карты для настольных компьютеров, и Google Maps для слабых мобильных устройств. Google Maps оказались существенно быстрее.
Итоги
С практической точки зрения итоги, конечно, скромные, так как уже существует множество гораздо более продвинутых GPS-мониторов. Но судя по отзывам, именно простотой KidsTrack и приглянулся многим.
Для меня лично итоги значительно более внушительные. Главный итог — бесценный опыт, который невозможно было бы получить из статей или учебников. Грабли, описанные выше, заставили пересмотреть реалистичность и дизайн других более крупных проектов, над которыми я работаю.