Практически любой сервис можно сделать геосоциальным. Т.е. расширить его функционал за рамки привычного интернета и дать пользователям сервиса возможности для взаимодействия и в реальной жизни.
Первый вопрос, который возникает, а надо ли это пользователям? Ответ очень сильно зависит от того, что это за сервис. Например, сервисы знакомств очень популярны, поскольку решают множество проблем. Они позволяют тем, кто хочет познакомиться, сэкономить время на поиски партнера. Помогают преодолеть скромность и избежать множества конфликтных ситуаций.
Ну а если подумать, что интересного может предложить геосоциальный сервис Хабрахабра?
Варианты настроек приватности:
1) Виден всем – для тех, кто хочет максимум общения
2) Виден только тем членам хабрасообщества, которые подписаны со мной на несколько общих хабов – умеренный вариант
3) Виден только тем, на кого я подписан и, при этом, кто подписан на меня – минимум контактов при максимальном взаимном интересе.
Думаю, что при такой схеме почти каждый найдет подходящий для себя вариант. Кстати, я против паказа пользователей на карте, как это делают некоторые сервисы. Гораздо интереснее, когда пользователям просто сообщают об их случайных встречах. И для достижения реальной эффективности, локация должна осуществляться не on-demand (по принципу чекинов), а on-line.
Техническая реализация
Чтобы сделать сервис геосоциальным нужно разработать клиентские приложения для мобильных устройств и реализовать на серверной стороне Геолокационный сервис.
Функции Геолокационного сервиса:
1) Валидация данных приходящих с устройств
2) Поиск встреч (сближений устройств)
3) Анализ настроек приватности встретившихся пользователей
4) Информирование сервиса и заинтересованных пользователей о встрече.
5) Дополнительные функции, необходимые для взаимодействия пользователей, например, модуль для чатов и т.д.
Функции мобильных клиентских приложений
1) Геолокация
2) Передача текущих координат на сервер
3) Нотификация пользователей о встречах и других событиях
4) Дополнительные функции, необходимые для взаимодействия пользователей, например, чаты и т.д.
Нюансы
Нужно понимать, что реализация полноценного клиентского приложения довольно трудозатратная вещь. А если говорить про реализацию клиентских приложений для разных платформ, то затраты еще более возрастают. Можно упростить задачу, воспользовавшись, например, HTML 5 для верстки пользовательского интерфейса приложений, но локационный модуль придётся делать нативными средствами.
Локация должна быть энергоэффективна. Проще всего этот вопросом решается на Androidе. Вы можете регулировать энергопотребление написав умный алгоритм локации. Т.е. в определенных случаях получать точную, но затратную с точки зрения энергозатрат, GPS-координату. Если в зоне видимости есть WiFi, то, конечно, использовать для локации его (погрешность 50-100 метров, почти без затрат энергии). Иногда использовать для определения координат соты. Получим достаточно большую (но в некоторых случаях приемлемую) погрешность, но без энергозатрат.
Еще нужно учесть, что телефон, который осуществляет локацию, в это время не спит. И его процессор также потребляет энергию. Если мы просыпаемся для получения локации, то не всегда это можем сделать так быстро, как хочется. Модуль GPS, получивший информации о спутниках, выдает нам координаты очень быстро, но для его инициализации может потребоваться несколько минут.
Еще проблема – родные локационные сервисы устройства могут иногда давать большие погрешности. Т.е. не координату с большой погрешностью, а просто неверную координату, которая может, запросто, оказаться в километре от реальной. Будет нелишне на серверной стороне вести учет таких «черных дыр» для повышения достоверности треков.
Большой экономии энергии можно достичь, включая разные режимы локации для случаев:
— устройство неподвижно
— устройство движется с небольшой скоростью
— устройство движется быстро
В данном случае имеют место две основные идеи. Когда устройство неподвижно, то оно не генерирует никаких событий. Когда устройство движется быстро (человек в машине) событий много, но пользователь, все равно, не сможет на них реагировать.
Еще, неплохо бы, синхронизировать отправку координат устройствами. Т.е. нужно время клиентов синхронизировать с серверным временем. Это важно для движущихся объектов. Пример – два человека едут в трамвае на соседних сиденьях, но отправка координат их устройствами рассинхронизирована. Тогда сервер будет получать скачкообразные смещения то одного, то другого устройства и не зафиксирует встречу…
Делать отправку единовременно для всех устройств тоже неправильно. Таким образом, мы создадим пиковые нагрузки на сервере. Т.е. нужно продумать алгоритм, который привяжет время отправки координат к текущим координатам.
И еще, если мы используем для получения координат не только GPS, то посмотрев на трэк устройства, окажемся недовольны. Движение будет выглядеть как некие скачки то вперед, то назад, то вправо, то влево. Неплохо подумать, а как перерабатывать поступающие от устройства координаты, учитывая, что погрешность постоянно меняется? Если кому-то интересно, могу описать алгоритм в одной из следующих статей.
Дела с локацией на iOS обстоят хуже. У нас есть возможность только запросить координату с определенной точностью и нет возможности руководить, какими средствами (за какое время и с каким энергопотреблением) она будет получена. Кроме того, нет простой возможности выводить телефон из режима sleep. А если не уходить в этот режим, то процессор потребляет очень много энергии (гораздо больше, чем на современных Android). Определенные возможности для решения задач энергоэффективной локации есть, но реализация достаточно сложна. Единственный простой вариант, который во многих случаях будет достаточен, использовать Геозоны.
Symbian. Полноценная локация возможна только на устройствах с операционной системой не ниже S60. Кроме того, на устройстве должен присутствовать WiFi и GPS (а таких моделей совсем немного), иначе погрешность локации будет просто огромной. Будут проблемы с автостартом приложения. Трудозатраты разработки приложения для Symbian в разы превышают, например, iOS.
Windows Phone. 7 версия данной система, видимо, оказалась достаточно тяжела для мобильных устройств, и возможности для полноценной фоновой локации там не была реализованы. В 8-й версии был сделан большой шаг вперед. Появился обширный геолокационный API, представляющий собой нечто среднее между Android и iOS. Однако не надо забывать формулу:
«новая операционная система» + «устройства разных производителей» = «неизбежные баги».
И это может не лучшим образом отразится на трудоемкости разработки.
Ну и, конечно, нужно можно разработать клиент для Google Glass. Тут ничего сказать не могу, поскольку в руках не держал. И вообще, думаю, не шутка ли это?
Нотификация
В определенных случаях нужно будет сообщать пользователям о встречах и других событиях. Для каждой платформы нужно будет делать отдельную нативную реализацию. Однако, в нашем случае, имеется уникальная возможность, организовать нотификацию не через сервисы вендоров, а через собственную обратная связь.
Если устройство подключается к нашему серверу по TCP, то мы можем в рамках сессии в любой момент контактировать с ним. Если даже устройство отправляет нам UDP пакеты (что разумно, если думать о нагрузке), то мы имеем некоторое время, чтобы отправить ответный пакет. Это время зависит от интернет-провайдера, но, в любом случае, составляет не менее 10 секунд.
Агрегаторы
Можно сэкономить силы и средства и воспользоваться услугами агрегаторов, которые предоставляют API для интеграции сторонних сервисов и самостоятельно решают вопросы с локацией мобильных устройств. Они предоставляют готовые шаблонные нативные приложения для разных платформ с уже реализованным функционалом для общения пользователей, отображения их на карте (в случае необходимости) и многое другое, а также дают возможность встраивать через web-view специфичный для каждого сервиса функционал.
P.S. В данной статье описаны лишь общие идеи и принципы технической реализации геосоциальных сервисов. Применительно к Хабрахабру, конечно же, можно придумать еще множество интересных и полезных фич. Хотелось узнать ваше мнение, уважаемые хабравчане.
This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends:
- Massacres That Matter - Part 1 - 'Responsibility To Protect' In Egypt, Libya And Syria
- Massacres That Matter - Part 2 - The Media Response On Egypt, Libya And Syria
- National demonstration: No attack on Syria - Saturday 31 August, 12 noon, Temple Place, London, UK
Комментариев нет:
Отправить комментарий