Google Gears в деталях

О Google Gears можно услышать довольно много чего интересного. Дескать, есть такой мегаплагин, добавляет кучу возможностей. И еще - с ним можно оптимизировать сайты.

Посмотрим подробнее, что это такое, для чего он нужен, что умеет.

Эта статья не ставит своей целью заменить документацию по Google Gears (которой, к сожалению, нет на русском языке). Ее цель - показать основные возможности Google Gears и существующие способы их применения, включая использование Gears в Joomla, Wordpress, Youtube.

UPDATE: в связи с тем, что технология умерла, статья имеет интерес разве что исторический.

Google Gears (или просто Gears) - плагин для браузера. На момент написания статьи работает во всех современных браузерах, кроме Safari 4 и Opera Desktop до 10 версии включительно.

Конечно, этот плагин надо ставить. Обычно браузер предлагает это сделать в виде выпадающего сообщения.

Gears добавляет в javascript:

• Базу данных (SQLite)
• Реальную многопоточность (точнее многопроцессность)
• Возможность кросс-доменного общения для скриптов
• Локальный сервер для работы оффлайн
• Доступ из javascript к содержимому(только на чтение) выбранных пользователем файлов. Есть свой селектор для выбора нескольких файлов одновременно.
• Взаимодействие с OS в плане создания ярлыков и drag'n'drop
• Geolocation API для определения координат, включая устройства с GPS
• Простейшие возможности по работе с изображениями в javascript.

Большинство этих возможностей требуют разрешения на использование от посетителя. Редкие, самые безопасные, сработают и без.

Разберем все это поподробнее.

База данных SQLite

В спецификации HTML 5 предусмотрено хранение и доступ к данным при помощи SQL: Offline Web Applications. Эта возможность поддерживается в Safari.

Google Gears пошел другим путем и предоставляет свой SQL-интерфейс Database API.

Основное отличие - в Gears запросы к базе синхронные, а в HTML 5 - асинхронные (назначается callback на получение результата). Это удобно, т.к. для асинхронности в gears можно использовать многопоточность там, где это нужно.

• Удалены некоторые возможности SQLite - в основном это касается работы напрямую с файловой системой и системных опций.
• Жестко задана кодировка: UTF-8.
• Есть полнотекстовой поиск FTS2 (не для русского языка).
• Файл с базой хранится внутри домашней директории пользователя. Таким образом, разграничение доступа между пользователями компьютера осуществляется средствами OS.
• Одновременно в базу может писать только один процесс - иначе генерируется исключение.
• Много баз данных. Но базы привязаны к текущему протоколу-порту-домену. То есть, базы с одинаковым именем для разных сайтов никак не пересекаются (Same Origin), и залезть с одного сайта в базу другого нельзя.

Доступ к базе требует разрешения от посетителя.

Следующий пример создаст базу и таблицу (если не существует) и добавит туда запись. Многократный запуск добавит много записей, который сохранятся в базе на локальном компьютере.

var db = google.gears.factory.create('beta.database');

db.open('js');
db.execute('create table if not exists test(phrase text, created datetime)');

var phrase = prompt("Введите фразу")

db.execute('insert into test values (?, datetime())', [phrase])
var rs = db.execute('select * from test order by created desc')

while (rs.isValidRow()) {
  alert(rs.field(0) + ' создано ' + rs.field(1))
  rs.next()
}
rs.close()

var db = google.gears.factory.create('beta.database')
db.open('js')
db.remove()

Здесь, как и в дальнейших примерах, пропущена проверка ошибок выполнения. Например, посетитель может запретить Google Gears. При любых ошибках gears инициирует исключения, которые легко поймать конструкцией try..catch.

В SDK, которое предоставляет google, есть SQL-консоль для работы с базой.

Открыть консоль в ифрейме

API на сайте Google: http://code.google.com/apis/gears/api_database.html.

Многопоточность и кросс-доменное общение

Многопоточность, а точнее, многопроцессность - пожалуй, самая интересная возможность Google Gears.

Каждый новый поток является отдельным процессом со своими переменными и средой выполнения.

Реализуется она при помощи WorkerPool API, которое представляет собой вольную переработку черновика Web Workers из HTML5.

Новые процессы запускаются вызовом createWorker/createWorkerFromUri класса WorkerPool.

// получить разрешение на доступ к WorkerPool
workerPool = google.gears.factory.create('beta.workerpool')

// создать новый процесс, загрузить для выполнения скрипт worker.js
int childId = workerPool.createWorkerFromUrl('/files/gears/worker.js')

Эти методы возвращают идентификатор, который мы можем использовать для общения с процессом.

Это делается методом workerPool.sendMessage:

workerPool.sendMessage("Ответь мне, процесс!", childId)

Чтобы принять сообщение, в скрипте дочернего процесса (worker.js) должен быть определен метод onmessage на неявно передаваемом в дочерний поток объекте google.gears.workerPool:

google.gears.workerPool.onmessage = function(a,b, message) {
  var reply = "Пришло: "+message.body

  // ответить пославшему 
  google.gears.workerPool.sendMessage(reply, message.sender);
}

У метода onmessage - три аргумента. Первые 2 устарели и не нужны, а третий - собственно, сообщение message со свойствами:

body

Переданное в sendMessage сообщение. В примере - строка, а вообще - может быть любой объект

sender

ID процесса, пославшего сообщение. В примере - ID родителя, основного javascript-процесса

origin

URL, с которого работает пославший сообщение процесс, в форме ПРОТОКОЛ://ДОМЕН(PORT), причем порт отсутствует для стандартных портов 80 и 443

В ответ наш основной процесс может вывести то, что получил:

workerPool.onmessage = function(a,b, message) {
  alert("От потомка: "+message.body)
}

Итак, полный код примера:

workerPool = google.gears.factory.create('beta.workerpool')

// работает синхронно, т.е. к следующей строке кода поток будет готов 
childId = workerPool.createWorkerFromUrl('/files/gears/worker.js')

workerPool.onmessage = function(a,b, message) {
  alert("От потомка: "+message.body)
}

workerPool.sendMessage("Ответь мне, процесс!", childId)

Файл worker.js: /files/gears/worker.js.

Кросс-доменное общение

Скрипт, загруженный createWorkerFromUrl с другого URL, будет выполняться в контексте безопасности этого URL, и при этом общаться с основным процессом.

Соответственно, можно наладить кросс-доменную коммуникацию без всяких трюков с iframe и проксированием, и даже без postMessage/XDomainRequest.

Об этом написано в секции документации Cross-origin workers WorkerPool API.

Ограничения и недостатки

• Дочерние процессы не имеют доступа к объектам document и window. Для рисования используйте основной javascript-процесс. А вместо XmlHttpRequest и setTimeout/setInterval, которые есть в window, Gears предоставляет сходные аналоги: HttpRequest и Timer.
• Невозможна одновременная запись в базу с разных потоков. Один запишет, другие получат исключения. Соответственно, нужно закладывать в код обработку исключений и повторение SQL-запроса.
• Метод createWorkerFromUrl не работает из дочерних процессов. В них можно использовать метод createWorker, которому передается не URL, а текст скрипта.

API на сайте Google: http://code.google.com/intl/ru/apis/gears/api_workerpool.html.

Локальный сервер

Локальный сервер - пожалуй, самая востребованная часть Google Gears API.
По смыслу - это не совсем тот сервер, о котором привык слышать веб-разработчик.

Он умеет две основные вещи.

1. Загружать одну страницу или их список в локальное хранилище
2. Неявно перехватывать обращения браузера к загруженным страницам и отдавать их из локального хранилища.

Разумеется, поддерживается и обновление локального хранилища.

Хранилище работает в рамках стандартного контекста безопасности Same Origin, так что сохранить локально можно только страницы с текущего протокола-домена-порта.

Локальное хранилище

Для инициализации хранилища используется фабричный класс LocalServer

var localServer = google.gears.factory.create('beta.localserver')

Этот вызов требует разрешения от посетителя.

Основные методы LocalServer:

• createStore / openStore / removeStore - для управления хранилищем типа ResourceStore
• createManagedStore / openManagedStore / removeManagedStore - для управления хранилищем типа ManagedResourceStore

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

Если запрошенная посетителем страница есть в хранилище - запрос будет перехвачен LocalServer'ом, и она будет взята из локального хранилища, а не с удаленного сервера.

Функции LocalServer предусматривают также атрибут requiredCookie, который может ограничивать доступ к хранилищу и требовать наличия, либо отсутствия у посетителя заданного cookie.

Таким образом, можно например привязать хранилище к ID посетителя:

var localServer = google.gears.factory.create('beta.localserver')
// создать или открыть, если есть
var store = localServer.createManagedStore('data', 'userid=123')

Данные этого хранилища будут доступны только посетителю с cookie: userid=123.
Конечно, эта мера скорее нацелена на удобство, нежели на безопасность.
Но часто бывает, что у одного человека есть несколько аккаунтов, скажем, почтовых, и здесь ограничение requiredCookie может быть как нельзя более удобно.

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

Тип хранилища ResourceStore

Это хранилище целиком настраивается на клиенте. Оно позволяет получать с сервера произвольные страницы (или сразу много страниц).

Основной метод: capture(urlOrUrlArray, callback) - получает и сохраняет страницы с сервера.

Для примера посмотрим на таймер. Это обычный div, для которого javascript при помощи xmlhttprequest раз в секунду запрашивает с сервера страницу time.php с текущим серверным временем и выводит ее в div с id="timer".

Кликните, пожалуйста, на кнопку запуска для активации кода таймера:

// используется jQuery функция load, получающая данные
// при помощи XMLHttpRequest
setInterval(function() { $('#timer').load('/files/gears/time.php') }, 1000)

После того, как вы запустите следующий код, время застынет, т.к. страница time.php, содержимое которой ежесекундно попадает в div, станет отдаваться не с сервера, а с вашей машины.

var localServer = google.gears.factory.create('beta.localserver')
var store = localServer.createStore('time-store')
store.capture(
  "/files/gears/time.php", 
  function() { alert('Страница загружена в хранилище') }
)

А этот код удалит страницу из хранилища, после чего таймер опять заработает.

var localServer = google.gears.factory.create('beta.localserver')
var store = localServer.createStore('time-store')
store.remove("/files/gears/time.php")
alert('Страница удалена из хранилища')

Для хранилища нет разницы, как запрашивается страница: напрямую или через xmlhttprequest - оно проверяет точное совпадение URL и возвращает страницу из хранилища, если она там есть.

Тип хранилища ManagedResourceStore

Это, пожалуй, самый востребованный тип хранилища. У него есть два важных свойства:

1. Он получает список URL для локального-хранения с сервера, в виде файла-"манифеста" в формате JSON. Кроме того, манифест содержит версию.
2. Каждый URL в манифесте может содержать дополнительные опции поиска совпадения:
   

   ignoreQuery

   при поиске в хранилище параметры (все после вопр. знака) будут игнорироваться

   matchQuery

   Набор условий на параметры запроса, при совпадении страница будет возвращена из хранилища

После получения манифеста Gears скачивает все перечисленные там страницы и сохраняет их локально.

При каждом изменении версии манифеста все файлы будут скачаны заново.

Типичный способ использования:

1. Создать хранилище:
   

   var localServer = google.gears.factory.create('beta.localserver')
   var store = localServer.createManagedStore('store')
   

2. Запросить с сервера манифест:
   

   store.manifestUrl = '/files/gears/manifest.php'
   

3. Запустить процесс обновления:

   store.checkForUpdate()
   

   Метод checkForUpdate работает асинхронно, ход обновления можно узнать, прикрепив обработчики к хранилищу для событий onprogress/onerror/oncomplete.

Если не запускать обновления явным образом при помощи checkForUpdate - Gears будет проверять обновления (запрашивать сервер) самостоятельно при каждом получении страницы из хранилища, но не чаще чем раз в 10 секунд.

В этом - важное отличие от обычного ResourceStore, которое обновляется только "вручную".

Пример манифеста

Следующий пример манифеста содержит основные используемые опции с комментариями к ним.

{
  // версия манифеста
  "betaManifestVersion": 2,

  // версия манифеста
  "version": "123456789",

  // список страниц,
  // относительные пути - идут относительно URL манифеста 
  "entries": [
      // загрузить ресурс с сервера и сохранить локально
      { "url": "main.js" }

      // локальный URL: main.html, удаленный - main_offline.html
      // при запросе main.html, LocalServer вернет main_offline.html
      { "url": "main.html", "src": "main_offline.html" },

      // вместо src указана опция redirect
      // LocalServer перенаправит браузер на main.html со статусом 302
      { "url": ".", "redirect": "main.html" },

      // выдавать локально сохраненный formHandler.html
      // при любых запросах вида formHandler.html?param1=..&param2...
      { "url": "formHandler.html", "ignoreQuery": true }
    ]
}

Более подробную информацию вы можете получить в документации к манифесту.

Оптимизация сайта при помощи LocalServer

Как правило, набор статических файлов (картинок, стилей, скриптов) - не меняется в пределах версии сайта/релиза/"апа"/"деплоя на продакшн".

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

Все картинки, скрипты и т.п. Gears будет возвращать из соответствующего ManagedResourceStore.

Таким образом оптимизируют свои админки контент-системы, такие как Joomla, Wordpress и т.п.

Аналогичная оптимизация на сервере.

Грамотно настроенный веб-сервер/приложение, использующие технологии Умное Кеширование и Версионность в Javascript/CSS, могут быть так же эффективны, и при этом не нужно плагина на клиенте.

Хотя для такой настройки сервера есть ряд ограничений, в частности, в URL лучше не иметь знак вопроса - некоторые браузеры не будут жестко кешировать такие страницы, она вполне применима и отлично работает. Без Gears. Более подробно - описано в самой статье.

Сравнение ManagedResourceStore, по сравнению с "умным кешированием"

• Умное кеширование не требует плагина.
• ManagedResourceStore почти не требует изменения в приложении, просто пишется небольшой дополнительный код для создания и обновления манифеста.
• Умное кеширование позволяет обновить один ресурс, не затрагивая остальные
• ManagedResourceStore позволяет:
  • указать опции сравнения: ignoreQuery/matchQuery
  • выбирать хранилище по имени в методе openManagedStore
  • ограничить хранилище указанием requiredCookie

Как видите, есть место для обоих технологий.

Доступ к локальным файлам

Все начинается с класса Desktop, метода openFiles.

Он позволяет посетителю выбрать несколько файлов "родным" селектором операционной системы. Например, в Windows можно выделить файлы мышкой.

Первый аргумент - функция, которой будут передан
ы выбранные файлы, вторым можно указать объект опций с параметрами filter/singleFile (см. OpenFileOptions).

var desktop = google.gears.factory.create('beta.desktop');
desktop.openFiles(
  function (files) { alert('Выбрано файлов: ' + files.length) }
)

Вызвать эту функцию можно, например, при клике на кнопку, то есть вообще без элемента типа <input type="file">.

function resize() {
  var desktop = google.gears.factory.create('beta.desktop');
  // опция singleFile для выбора не более одного файла
  desktop.openFiles(resizeAndShow,
    { singleFile : true, filter: ['image/jpeg', 'image/gif', 'image/png'] }
  )
}

function resizeAndShow(files) {
  // (1)
  var canvas = google.gears.factory.create('beta.canvas');
  canvas.decode(files[0].blob)
  canvas.resize(150,150)
  var blob = canvas.encode("image/jpeg")

  // (2)
  var localServer = google.gears.factory.create('beta.localserver')
  var store = localServer.createStore('store')
  // (2.1)
  var url = '/img.jpg?'+Math.random()
  store.captureBlob(blob, url, "image/jpeg")  
  // (3)
  $('#resized').css('background-image', 'url('+url+')')
  $('#resized')[0].scrollIntoView()

  // (4)
  setTimeout(function (){store.remove(url)},0)
}