P.S. вот еще нашлась дискуссия на YC по теме генерации статических сайтов
Вот здесь можно прочитать больше про BDP
Вот здесь еще есть авторская презентация и статья.
А вот здесь есть полный список анонсов Google I/O 2014
/via Geo Messages
/via Coldbeans
Вот еще нашлось Getting Started iBeacons от Apple.
P.S. Из комментариев: руководство по Swift на русском.
Тема статьи относится к услугам мобильной сети, связанным с местоположением. Рассматривается задача подсчета мобильных пользователей (мобильных телефонов) в некоторой выделенной области. Для подсчета используется информация, доступная из анализа беспроводных протоколов (Wi-Fi, Bluetooth). Цель исследования состоит в построении аналога систем веб-статистики, оперирующих с реальными мобильными абонентами (вместо данных о посещении веб-страниц, как в веб-статистике). В результате получаем информацию о посещаемости, определение и анализ трендов в пользовательском трафике, поиск ядра постоянных посетителей и раскрытие его динамики. В статье приведены алгоритмы вычисления сетевой близости, примеры использования.
Актуально в свете грядущих проблем с анализом данных о мобильных посетителях. Собственно говоря, в статье и идет речь о том, что вместо подсчетов посетителей нужно заниматься сравнением трендов. А на это решения Apple о маскировке пользователей (случайные MAC-адреса в служебных Wi-Fi пакетах) не повлияет.
Во всей этой истории с iBeacons главный бенефициар - это сама компания Apple. Ограничения на сбор адресов существуют, естественно, только на уровне приложений. Тег (вещатель) ничего такого не знает, мобильная ОС, естественно, собирает данные от всех вещателей. Таким образом именно Apple накапливает поведенческие данные. Пока разработчики приложений расставляют теги и борются с искусственными ограничениями :). Но это же и означает, что над всеми разработчиками висит топор от Apple. В какой-то момент все прикладные программы станут не нужны. Аpple вполне может сказать: "cпасибо, что расставили теги" и обслуживать мобильных пользователей вокруг них самостоятельно.
Вот еще одна интересная ссылка в этой связи - iOS 8 будет отправлять случайный MAC-адрес в Wi-Fi probe request/response. Именно эти запросы (отклики) от мобильных клиентов являются основой для программ сбора статистики о мобильных посетителях. То есть, подсчет iPhone (по Wi-Fi !) будет невоможен. А с BLE - да. Но только не в прикладных программах, которые могут отмечать пользователя только против предписанных тегов. А собственно iOS сможет это делать именно для всех тегов. Да еще и наложить это на карту помещений.
Согласен с авторами дискуссии в том, что одна из причин этого - iBeacons. Трекинг мобильных пользователей с iPhone должен быть только от Apple.
P.S. в этом контексте - посмотрите еще раз Core Bluetooth теги - Bluetooth Data Points.
1. Пример технического задания для системы на базе iBeacon
2. Новый подход к Single Sign-on. Ждем комментарии. Очень интересны сторонние отзывы.
3. Интересный перевод доклада Стивена Вольфрама
4. Хороший русскоязычный обзор - платформы для создания приложений с iBeacons
5. Все переиграли. Теперь американский суд решил, что © распространяется и на API. Это все об использовании Java в процессе Oracle vs. Google
Принимаем статьи во 7-й номер журнала на 2014 год (том 2). Здесь можно посмотреть архив журнала.
/via OIT Lab
P.S. вот еще нашлась дискуссия с интересными добавлениями.
Рассматриваются вопросы разработки мобильных сервисов, связанных с беспроводными тегами. Основные положения были опубликованы в журнале INJOIT: Намиот, Д. Е. (2014). Мобильные Bluetooth теги. International Journal of Open Information Technologies, 2(5), 17-23
В работе предложен способ создать опознаваемый Bluetooth тег из мобильного телефона. При этом речь идет о Core Bluetooth, что значительно повышает применимость по сравнению с BLE. К тегу (телефону) можно привязать какую-либо информацию (объявление). Отсюда и название Bluetooth Data Points - данные, ассоцированные с точками Bluetooth. После этого другие телефоны (мобильные пользователи), находящиеся в зоне действия (видимости) Bluetooth смогут читать информацию, связанную с данным тегом. Отметим также, что речь идет именно о чтении (как в браузере). В отличие от подхода iBeacon с уведомлениями, здесь пользователи по собственной инициативе решают, просматривать им локальные объявления или нет. Это решает проблемы со спамом и нежелательными уведомлениями.
Вместе с тем можно заметить, что принципиальных запретов сделать уведомления нет. Возможно, мы добавим эти возможности в следующих версиях.
Схема работы может быть проиллюстрирована так:
Тот факт, что используется Core Bluetooth, позволяет применять этот подход практически на всех смартфонах. Как это выглядит на практике:
1. Просматриваем "местные" объявления:
|
|
2. Другой пользователь размещает свое объявление:
|
|
В тексте можно указывать ссылки, email-адреса, телефоны или ссылаться на Twitter: @abava
3. При публикации объявления включается Bluetooth:
|
|
Естественно, Bluetooth можно выключить и сделать объявления недоступными. А потом включить опять и т.д. А пока обявления доступны, их будут видеть другие пользователи (мобильные абоненты), находящиеся поблизости:
Мобильное приложение для Android, которое иллюстрирует этот подход можно загрузить непосредственно с Google Play: BDP on Google Play. Вот соответствующий QR-код:
Также его можно загрузить непосредственно с нашего сайта: BDP on servletsuite. Вот соответствующий QR-код:
Как области применения данного подхода можно назвать приложения для торговых и сервисных организаций, навигацию в помещениях, а также контекстно-зависимые приложения для Smart Cities.
P.S. Аналогичный подход мы использовали ранее для Wi-Fi: SpotEx
