Эта функция обратного вызова, обслуживающая ситуацию «успеха», принимает единственный аргумент — объект с информацией о местонахождении:

function geo_success(p) {

alert("Вы нашлись в точке с долготой " + p.coords.latitude + " и широтой " + p.coords.longitude);

}

Если функция getCurrentPosition() не сумела установить координаты пользователя (из-за того что он отказался посылать их, или из-за какого-либо сбоя в API геолокации), то будет вызвана функция, переданная ей как второй аргумент. В данном примере функция обратного вызова, обслуживающая ситуацию «неудачи», называется geo_error:

geo_position_js.getCurrentPosition(geo_success, geo_error);

Она не принимает никаких аргументов:

function geo_error() { alert("Вы не нашлись!");

}

Поддержки функции watchPosition() в geo.js пока нет. Чтобы постоянно следить за местонахождением пользователя, надо активным образом «опрашивать» его устройство, вызывая getCurrentPosition().

Живой пример

Изучим следующий пример использования geo.js для нахождения координат пользователя и вывода на экран карты местности, в которой он находится.

При загрузке страницы надо вызвать geo_position_js.init(), чтобы выяснить, доступен ли хотя бы один интерфейс геолокации из тех, которые поддерживает geo.js. Если API доступен, то можно вывести ссылку, щелкнув на которой, пользователь сможет увидеть свое местоположение на карте. Переход по ссылке будет вызывать функцию lookup_location() следующего вида:

function lookup_location() { geo_position_js.getCurrentPosition(show_map, show_map_error);

}

Если пользователь соглашается на пересылку данных, а геолокационному сервису удается установить его координаты, то geo.js запустит первую функцию обратного вызова — show_map() — с единственным аргументом loc. Свойство coords объекта loc содержит широту, долготу и сведения о точности измерений (в этом примере точность измерений не учитывается). Затем функция show_map() с помощью API Карты Google выводит на страницу карту с маркером:

function show_map(loc) { $("#geo-wrapper").css({'width':'320px','height':'350px'}); var map = new GMap2(document.getElementById("geo-wrapper"));

var center = new GLatLng(loc.coords.latitude, loc.coords.longitude);

map.setCenter(center, 14); map.addControl(new GSmallMapControl()); map.addControl(new GMapTypeControl());

map.addOverlay(new GMarker(center, {draggable: false, title: "Вы нашлись приблизительно здесь"}));

}

Если geo.js не может определить местоположение пользователя, будет вызвана вторая функция обратного вызова — show_map_error():

function show_map_error() { $("#live-geolocation").html('Вы не нашлись!');

}

Для дальнейшего изучения

Стандарт API геолокации на сайте W3C (http://www..w3..org/TR/geolocation-API/).Gears (http://tools..google..com/gears/).

API геолокации платформы BlackBerry (http://www..tonybunce..com/2008/05/08/ Blackberry-Browser-Amp-GPS..aspx).

API геолокации платформы Nokia (http://wiki..forum..nokia..com/index..php/Bondi_ Widget_porting_example_-_geolocation_API).

API геолокации платформы Palm (http://developer..palm..com/index..php?option=com_ content&view=article&id=1673#GPS-getCurrentPosition).

API геолокации платформы OMTP BONDI (http://bondi..omtp..org/1..0/apis/ geolocation..html).

geo.js — сценарий-обертка для разных геолокационных API (http://code..google.. com/p/geo-location-javascript/).

7 Локальное хранилище: прошлое, настоящее, будущее

Приступим

Постоянное локальное хранилище данных — одна из областей, в которой обычные клиентскиеприложениятрадиционноимелипреимуществопередвеб-приложениями. Для первых операционная система, как правило, предоставляет такой уровень абстракции, где можно хранить собственные данные приложений (например, пользовательские настройки и состояние) и откуда эти данные можно запрашивать. В качестве хранилища могут выступать реестр, INI-файлы, XML-файлы или что-либо еще взависимостиотправилсистемы.Есликлиентскаяпрограммануждаетсявхранении данных иного типа, нежели пары «ключ — значение», то можно встроить в нее (программу)своюсобственнуюбазуданных,придуматьсобственныйформатфайловили реализовать какое-либо из других возможных решений.

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

Cookies входят в состав каждого HTTP-запроса и поэтому замедляют работу вашего веб-приложения, которое вынуждено снова и снова бесцельно передавать одни и те же данные.

Поскольку cookies входят в состав каждого HTTP-запроса, они посылают данные через Интернет в незашифрованном виде (если только все веб-приложение не шифруется с помощью SSL).

По объему cookies ограничены приблизительно 4 Кбайт. Этого достаточно, чтобы замедлить работу приложения (см. выше), но недостаточно, чтобы принести взамен какую-либо ощутимую выгоду.

Нам нужно совсем другое, а именно:большое по объему хранилище…на клиентской стороне…

данные которого не меняются при обновлении страницы…и не передаются на сервер.

Известно о нескольких попытках воплотить этот идеал, но до недавнего времени все они оказывались в конечном счете неудачными — и притом по-разному неудачными.

Краткая история прототипов локального хранилища до HTML5

ВначалебылонеСлово,аInternetExplorer.ПокрайнеймереразработчикиMicrosoft хотят, чтобы все думали именно так. Надо отдать должное специалистам Microsoft: во время первой из «великих войн браузеров» они придумали множество новинок, которые и включили в свой браузер-победитель Internet Explorer. Одна из новинок называлась DHTML Behaviors; в числе форм «поведения» браузера была одна под названием UserData.

ФормаUserData разрешаетвеб-страницамхранитьдо64Кбайтданныхнакаждый домен в иерархической структуре на основе XML. (Доверенные сайты, в частности интранет-сайты, могут хранить в десять раз больше данных. Да-да, еще недавно считалось, что 640 Кбайт хватит всем и на любые нужды!) Никакого диалога об увеличении объема хранимых данных IE вести не умел, поэтому способа расширить хранилище не существовало.

В2002 году специалисты Adobe ввели во Flash 6 функцию, которая была неудачно и обманчиво названа Flash-cookies. В среде Flash эта функция известна под названием Local Shared Objects (распределенные локальные объекты, или LSO). Если говорить кратко, то LSO позволяет Flash-объектам хранить до 100 Кбайт данных на каждый домен. В 2005 году Брэд Ньюберг (Brad Neuberg) разработал прототип системы взаимодействия Flash с JavaScript, которая получила название AMASS (AJAX Massive Storage System). Некоторые конструктивные особенности Flash ограничивалиработуAMASS,ноужев 2006году,послепоявленияExternalInterface во Flash 8, оперировать LSO с помощью JavaScript стало на порядок легче и быстрее. Тогда Брэд, переписав AMASS, ввел ее в состав популярного набора инструментов Dojo Toolkit под названием dojox.storage. При использовании dojox.storage каждый домен может безвозмездно получить от Flash стандартные 100 Кбайт на хранение данных. Более того, пользователь может последовательно увеличивать объем хранимых данных на порядок (до 1 Мбайт, затем до 10 Мбайт и т. д.).

В2007годукомпанияGoogleсоздалаGears—браузерноерасширениесоткрытым исходнымкодом,придающеебраузерамдополнительнуюфункциональность(говоря обAPIгеолокациивInternetExplorer,яужеупоминалGears:см.раздел«АчтовIE?» главы 6). Gears предоставляет API для встроенной базы данных на основе SQLite. Один раз получив согласие пользователя, Gears сможет хранить неограниченное количество данных для каждого домена в таблицах базы данных SQL.

Тем временем Брэд Ньюберг и его коллеги продолжали работать над dojox. storage. Их целью было обеспечить единый интерфейс для всех существующих приложений и API. Уже к 2009 году система dojox.storage была способна автоматически распознавать (и оснащать единым интерфейсом доступа) Adobe Flash, Gears, Adobe AIR и один прообраз хранилища HTML5, реализованный только

встарых версиях Firefox.