Многие проекты на данный момент используют информацию о местонахождении своих клиентов. К таким относятся интернет-магазины, сайты знакомств, банковские операционные ресурсы и прочее. Именно об элементе указания такого рода информации и будет данная статья: Ext.ux.locationSelect реализованный в поле фреймворка ExtJS 2.
Маленькая демка поможет ответить на вопрос о необходимости вчитываться в дальнейшее.

Свершилось! То, о чем так много говорили внутри компании Yahoo! (и о чем — к моему личному сожалению — знало так мало людей вне компании), наконец произошло — Internet Location Platform стала публичным сервисом, как часть Yahoo! Developer Network

Выдержка с сайта:

The Yahoo! Internet Location Platform provides a resource for managing all geo-permanent named places on Earth. Our purpose in creating the Internet Location Platform is to provide the Yahoo! Geographic Developer Community with the vocabulary and grammar to describe the world's geography in an unequivocal, permanent, and language-neutral manner.

Кратко расскажу, что это такое. Ключевым понятием ILP является WOEID (читается: вое-ай-ди) — WhereOnEarth IDentifier — уникальный идентификатор любого места на земле (почти дословный перевод), 32-битное число. Идентификатор могут иметь (и имеют) страны, города, улицы, а также все, что можно объединить под понятием POI — place of interest. Например, WOEID Лондона, где и был разработан этот сервис — 44418.

Поиск можно осуществлять в самых разных вариациях — только по имени, по имени с указанием County/State/Country в любых комбинациях; если есть несколько вариантов, то выбирается «наиболее популярный» — не вдаваясь в подробности, критерием популярности является количество упоминаний этого места в Интернете.

Мама, он опять меня посчитал!
Мы находимся почти на самом пике популярности устройств, которые в любой момент готовы определить местонахождение своего владельца. Системы глобального позиционирования (GPS) входят в число самых популярных электронных устройств массового потребления – так считает Клинт Вилок, исследователь из ABI Research, которая отслеживает тенденции на рынке технологий. Всё больше мобильных телефонов выпускается со встроенными чипами GPS. Каждое из этих устройств генерирует данные, на основе которых можно многое сказать о том, как люди проводят свою жизнь.

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

Недавно, в журнале Nature была опубликована статья, посвящённая исследованию мобильных «гео-следов», которые оставляли 100,000 человек в одной европейской стране, на протяжении шести месяцев. По результатам исследования, в большинстве случаев, маршруты движения людей можно было легко предсказывать. Зная закономерности этих маршрутов, можно вычислять их вероятность и отслеживать их изменения.

Грегори Скибиски, слева, и Тони Джибейра из компании Sense Networks, которая с помощью гео-данных делает прогнозы и даёт рекомендации предпринимателям и просто потребителям.

Этот пост является переводом топика из блога android-developers. Далее повествование ведется от Рето Майера, автора книги Professional Android 2 Application Development. Он пишет о том, как можно улучшить приложения, использующие местоположение, в смысле кэширования результатов, скорости работы и так далее.

Без разницы, ищете ли вы место, где бы поесть, или ближайшее место велосипедов Boris Bike, всегда есть задержка при получении данных местоположения от GPS и заполнении абстрактного списка результатов в вакууме. Когда вы находитесь в месте, где хотели бы получить контекстную информацию, то часто вы сталкиваетесь с отсутствием подключения к данным.

Вместо того, чтобы грозить кулаком в небо, я написал open-source приложение, которое включает в себя советы и рекомендации по сокращению времени между открытием приложения и просмотром актуальной информации о близлежащих местах, вкупе с разумным обеспечением offline режима работы. И всё это, сохраняя использование аккумулятора на возможном минимуме.

Некоторое время назад на Хабре упоминалась инициатива одного из советников Google, цель которой — дать возможность пользователям точек доступа управлять возможностью участия своего устройства в геолокационных сервисах поискового гиганта. Главной причиной этого были, конечно, всем известные скандалы с Street View и другие проблемы в ряде европейских стран, когда Google был уличен в сборе «лишней» информации с точек доступа — такой как MAC-адреса устройств.

Вчера Google опубликовала способ влиять на факт включения своего Wi-Fi-устройства в базу данных геолокационных сервисов компании. Все оказалось довольно практично — пользователям предлагается изменить SSID точки доступа таким образом, чтобы, чтобы он оканчивался строкой "_nomap". После этого, если сигнал точки доступа потребуется одному из Google Location серверов для установления местоположения чего-либо, то такая точка доступа просто будет исключена из базы данных доступных устройств и впредь использоваться не будет.

Любопытно, что в Google, по всей видимости, сочли задачу изменения SSID нетривиальной операцией, поскольку предложили достаточно подробную инструкцию для пользователей о том, как это можно осуществить, описывая манипуляции с командной строкой не только в Windows и MacOS, а и для Linux в том числе.

[Источник, источник]

Библиотека jQuery — это общепризнанное средство манипуляции сразу несколькими форматами данных (XML, HTML, объекты DOM, обыкновенные объекты), да притом работающее посредством удобного (цепного) вызова методов с удобными (краткими) названиями. Поэтому ничуть не удивляют попытки приспособить jQuery не только к одному клиентскому, но также ещё и к серверному джаваскрипту — в частности, к Node.js.

Признаюсь честно, что когда разработчики jQuery превозмогли проблему №7102, то её название («Register jQuery as a CommonJS async module») на какое-то время даже заставило меня обмануться: я сперва подумал было, что и в Node.js (так как модули Node.js и СommonJS имеют немало общего) отныне jQuery станет работать невозбранно. Ан нет, не тут-то было. Пристальное вглядывание в коммит и в запрос на слияние позволяет осознать, что jQuery, в сущности, обрёл возможность регистрироваться только как AMD-модуль и даже проверяет свойства define.amd и define.amd.jQuery перед саморегистрацией.

Собственно говоря, архитектура jQuery «затóчена» под употребление в условиях браузерной DOM: код jQuery полагается на существование объекта window, который служит аргументом главного замыкания, окаймляющего весь код jQuery. Прежде же таких неявных предположений было ещё больше, и только с устранением проблемы №6690 библиотека jQuery перестала полагаться на существование глобальных объектов navigator и location, начав вместо того получать их как свойства объекта window. (Понятно, что такое предположение никак не подходило для Node.js, где глобальные объекты служат свойствами объекта global, а вовсе не window; а равно не подходило и ко многим прочим реализациям CommonJS.)

Потому для запуска jQuery в Node.js применяются готовые реализации браузерной DOM — такие, как пакет jsdom, на основе которого невозбранно работает, например, вот какой код, предлагаемый в качестве примера:

Для разработчиков мобильных приложений существует много сервисов и веб-инструментов. Продвинутые компании и разработчики-одиночки знакомы со всеми этими сервисами не понаслышке. А вот новичок может запутаться и сделать неправильный выбор. Перейти на другой сервис можно без проблем, но ведь классно с самого начала пользоваться лучшим и удобным.

В нашей компании используется много подобных сервисов и инструментов, поэтому я решил рассказать вам кратко о лучших из них. О базовых вещах на подобии Basecamp, GitHub и т.п. речи не будет, т.к. это не сугубо специфические вещи для мобильной разработки.

Пройдемся по дизайну, серверным решениям, тестированию и аналитике.

Как известно Android предоставляет отличную возможность поручить часть функционала своего приложения стороннему посредством интентов. Иначе говоря, мы можем послать в систему нужный интент и стороннее приложение сделает всю необходимую работу за нас, вернув нам готовый результат.

Примерами таких действий могут быть сканирование QR кода, отправка СМС сообщения, звонок, захват изображения камерой телефона, просмотр адреса или координат на карте и т.д.

Для разных задач в интенте необходимо указывать различные action, category, type, extras. А так как этот код повторяется из приложения в приложение и чтобы каждый раз не искать информацию о нужном интенте на stackoverflow, я решил собрать такие интенты в библиотеку.

Итак, если вы счастливый владелец nginx, знатный параноик и за каким-то чертом решили поставить wordpress, то… Первое, что пришло в голову — это «надо ограничить сему творению свободу!».

Настройки учетной записи, как и настройки php5-fpm, я опущу, так как у каждого свои тараканы, а кто-то вообще на apache запускает. Но вот общие для Wordpress я опишу в этой части. Напишу о том, что сделал, что получилось и почему.

И снова, здравствуйте!

Сегодня мы продолжаем знакомство с картами Bing Maps. В предыдущей статье мы разобрались с тем, как добавить карту в Windows приложение, а также посмотрели, как работать с метками на карте.

В этой части мы будем продолжать улучшать нашу карту и добавлять различные полезные функции, такие как определение GPS-координаты, построение маршрутов и отображение информации о дорожной ситуации.

Привет Хабр!



Как-то раз была поставлена задача разработать движок для вычисления времени начала заката и рассвета, основаной на местоположении телефона.

В дополнение, дабы облегчить работу, меня нагрузили аномальными математическими формулами, от которых в голове ничего не укладывалось. Итак, мною было принято решение искать альтернативу этим адским формулам.

Представляю публичную базу геопозиций телефонных вышек и Wi-Fi роутеров. Мне понадобилась стабильная и безлимитная база для приложения Android, в котором нужна была точная геолокация из всех доступных источников (GPS, Wi-Fi, Mobile). Пришлось создать базу данных положений сотовых вышек и Wi-Fi. Всех заинтересовавшихся прошу под кат.

Здравствуйте!
После предыдущей статьи (часть 1) я получил много отзывов о работе открытого API геолокации по WiFi и вышкам мобильных сетей.
В этот раз я хочу представить свои исправления, лицензирование проекта, геопозиционирование по нескольким точкам доступа, кейсы использования и самое главное — текущие проблемы

Это третья, пока заключительная статья из серии Wi-Fi позиционирования «дешево и сердито»: когда не используются специализированные клиентские устройства и специализированная инфраструктура, а используются только общедоступные персональные устройства (смартфоны, планшеты, ноутбуки) и обычная инфраструктура Wi-Fi.

В первых двух статьях я делал основной акцент на точности и достоверности позиционирования, не касаясь вопроса частоты замеров. Если Клиент находится в статическом положении, частота замеров не имеет критичного значения, а если Клиент движется, то частота замеров начинает играть существенную роль.

Отправной точкой при расчёте частоты замеров является такая характеристика как характерная скорость движения Клиентов. Для человека это 5км/ч или 1.5 м/с. Для обеспечения позиционирования в реальном времени промежуток времени между двумя замерами не должен превышать удвоенную точность позиционирования, что позволяет строить достаточно точные для практических целей траектории движения.

Точность классического позиционирования по тестам, проведенным в предыдущей статье, составляла порядка пяти метров с достоверностью 90%. В этом случае частота замеров должна быть не менее 6,6с (либо 13,3 секунды для точности 10 метров). Теперь осталось выяснить, какова реальная частота замеров и соответствует ли она заявленной точности позиционирования.

Для тестов используется смартфон на Android 4.4.4 и ноутбук с Windows 7.

Что ж, цель ясна, средства понятны, приступим!

Чем дальше погружаюсь в тему Wi-Fi позиционирования, тем очевиднее становится факт, что основная задача заключается не в достижении необходимой точности, а в получении необходимого количества замеров! Почему я так думаю?

Требования к плотности размещения точек доступа с каждым годом увеличиваются, что положительно сказывается на точности позиционирования, а вот частота замеров по Probe Request не становится выше, скорее наоборот.

В связи с этим многие производители разработали свои собственные инструменты для увеличения частоты замеров. Традиционно, одним из инноваторов в этой области выступает компания Cisco, которая вывела на рынок инструмент под названием Cisco FastLocation.
Давайте попробуем разобраться во всех нюансах этого инструмента.

Компонент ViewModel — предназначен для хранения и управления данными, связанными с представлением, а заодно, избавить нас от проблемы, связанной с пересозданием активити во время таких операций, как переворот экрана и т.д. Не стоит его воспринимать, как замену onSaveInstanceState, поскольку, после того как система уничтожит нашу активити, к примеру, когда мы перейдем в другое приложение, ViewModel будет также уничтожен и не сохранит свое состояние. В целом же, компонент ViewModel можно охарактеризовать как синглтон с колекцией экземпляров классов ViewModel, который гарантирует, что не будет уничтожен пока есть активный экземпляр нашей активити и освободит ресурсы после ухода с нее (все немного сложнее, но выглядит как-то так). Стоит также отметить, что мы можем привязать любое количество ViewModel к нашей Activity(Fragment).

Компонент состоит из таких классов: ViewModel, AndroidViewModel, ViewModelProvider, ViewModelProviders, ViewModelStore, ViewModelStores. Разработчик будет работать только с  ViewModel, AndroidViewModel и для получения истанца с ViewModelProviders, но для лучшего понимания компонента, мы поверхностно рассмотрим все классы.

Люди, живущие в городах, сами того не осознавая, весь день находятся в зоне действия сетей Wi-Fi: домашних и городских, на работе и в метро, в торговом центре и в ресторане — они везде. Вывод один: если вы живете в мегаполисе, от Wi-Fi вам не скрыться.

Только московская городская сеть Wi-Fi охватывает 24 открытые территории: Московский зоопарк, ВДНХ, парки и пешеходные улицы, 14 общественных пространств (библиотеки и культурные центры), 150 зданий студенческих общежитий. Всего в столице действует более 8,5 тыс. точек доступа (хот-спотов). Бесплатный Wi-Fi доступен в метро и наземном общественном транспорте(1).

Глобальная база местоположения всех точек доступа Wi-Fi

Производители персональных портативных устройств (смартфонов, планшетов) уже давно научились использовать широкое распространение Wi-Fi в своих целях как вспомогательный инструмент в помощь сервису геолокации для определения местоположения устройства.

Изначально служба геолокации смартфонов применяет для определения местоположения модуль GPS, технологию A-GPS, которая ускоряет «холодный старт» GPS-приемника посредством получения альманаха и эфемерид через сеть Интернет (то есть через 3G/LTE/Wi-Fi), а также трилатерацию по сотовым вышкам GSM. Если позиция успешно вычислена, устройство сканирует Wi-Fi-эфир и отправляет через тот же Интернет данные о географическом положении близлежащих точек доступа Wi-Fi, которые собираются в общую базу данных производителя системы геолокации операционной системы (ОС):

— для смартфонов Android — в базу данных Google;
— для смартфонов iPhone — в базу данных Apple2 (2).

Эта информация используется как приложениями Google и Apple, так и другими, установленными на смартфоне (фитнес-трекерами и др.).

Все началось с того, что министерство торговли США включило Huawei в список компаний, с которыми запрещено вести бизнес американским компаниям. Ответом Huawei стала операционная система Harmony OS для своих смартфонов, и отказ использовать в ней сервисы Google. И чтобы не потерять часть рынка, мы интегрировали в inDriver ее поддержку. Хотя «интеграция OS» звучит громко – наше приложение, как и любое другое, написанное под Android, запустится на Harmony, но для полноценной работы необходимо заменить Google-сервисы на аналогичные Huawei.