Филин Лаки
208,75
рейтинг
4 февраля 2014 в 14:06

Разработка → Разработка приложений для Chrome: обзор

На Хабре публиковалось немало статей о создании расширений для Chrome, но тема разработки Chrome приложений (они же Chrome apps) затрагивалась заметно реже. В последнее время она стала актуальнее из-за распространения устройств на ChromeOS. К тому же инфраструктура для создания приложений для Chrome стала более стабильной и удобной для использования. В этой статье я постараюсь ответить на основные вопросы: зачем вообще писать приложения для Chrome, чем они отличаются от расширений, веб-сервисов, десктопных приложений и т.п., а также как они разрабатываются, и какие на них накладываются ограничения. Если эта тема вызовет интерес, у статьи будут продолжения, затрагивающие более специальные вопросы.



Продолжение: Создание простого Chrome приложения

Зачем


Одну и ту же функциональность можно реализовать с помощью совершенно разных технологий: можно написать программу для Windows, сделать web-сервис, мобильное приложение для Android и/или iOS и т.д. Что может подтолкнуть автора сделать выбор в пользу приложения для Chrome?

  • Работа на ChromeOS. На данный момент Chrome app ­— основной способ донести вашу программу до пользователей Chromebook'ов. Стоит ли оно того? Chromebook'ов пока меньше, чем, скажем, компьютеров под Windows, но тенденция меняется. В прошлом году в США было продано в 5 раз больше Chromebook'ов чем Macbook'ов
  • Приложения Chrome без каких-либо дополнительных усилий работают на Windows, Linux и OS X. Конечно, есть множество других способов сделать приложение переносимым, но большинство из них оказываются заметно более затратными.
  • С недавних пор появилась возможность портировать Chrome apps на Android и iOS.
  • На большинстве систем приложения Chrome выглядят для пользователя как обычные программы. Они запускаются из меню «Пуск», открывают обычные окна без браузерных контролов, могут использоваться в качестве программ по умолчанию для открытия файлов, и в остальном ведут себя
    как полноправные программы.


Packaged apps и hosted apps


Все видели в списке установленных по умолчанию в Chrome приложений иконки Поиска, Gmail, Google Диска. Если нажать на одну из них, ничего похожего на приложение не открывается. Вместо этого, пользователь просто переводится на страничку соответствующего сервиса.

Дело в том, что существует два принципиально разных типа приложений: hosted app и packaged app. К сожалению, устоявшихся русских терминов для них нет. Поиск, Gmail и т. д. — относятся к hosted. Такое приложение состоит из файла manifest.json с URL и настройками безопасности, и иконки. Фактически, hosted app — это специальная закладка на онлайн-сервис.

В отличие от hosted, в случае packaged app, все файлы, необходимые для работы приложения хранятся на компьютере пользователя. Такие приложения, как правило, могут лучше работать offline, могут управлять своими окнами, и вообще имеют доступ к большему количеству программных интерфейсов Chrome.

В дальнейшем речь пойдёт о packaged apps.

Приложения и расширения


С точки зрения пользователя, расширения и приложения выполняют абсолютно разные функции: расширение изменяет то, как он пользуется браузером, а приложение выполняет какую-то отдельную от браузера задачу. Расширение меняет содержание страниц и, возможно, добавляет пару кнопок, а приложение как правило работает в своём собственном окне.

При этом, расширения и приложения изнутри устроены очень похоже. И те, и другие устанавливаются из Интернет-магазина Chrome, представляют собой .crx файлы, являющиеся zip-архивами. Свойства расширения/приложения описываются в файле manifest.json, а UI в них написан на HTML5. Многие программные интерфейсы Chrome доступны как расширениям, так и приложениям.

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

  • управлять своими окнами,
  • напрямую работать с файлами на компьютере пользователя,
  • назначаться программами для открытия операционной системой тех или иных типов файлов,
  • открывать TCP и UDP соединения (этим, к примеру пользуется SSH-клиент для Chrome),
  • работать с USB.

Особенности разработки


Я уже упоминал, что с точки зрения пользователя приложения Chrome мало отличаются от обычных программ. В то же время с точки зрения программиста они устроены совсем по-разному. Какие-то операции оказываются проще, какие-то — сложнее.

Многие интерфейсы, использующиеся приложениями, являются общепринятыми стандартами и хорошо известны всем веб-разработчикам. Для UI используются HTML и CSS, для работы с HTTP — XMLHTTPRequest и т.д.

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

Ещё одна особенность Chrome — управление безопасностью. В Chrome оно устроено иначе, чем в классических операционных системах и больше напоминает систему безопасности в Android. К добавлению програмных интерфейсов разработчики Chrome всегда подходили консервативно. При разработке системы легче со временем ослабить ограничения безопасности, чем сделать их более строгими. В результате, например, у приложений отсутствует неограниченный доступ к файловой системе. Главным образом, они работают с файлами, либо принадлежащими приложению, либо явно открытыми пользователем.

Чем можно пользоваться кроме HTML + JavaScript


Основным языком программирования для Chrome является, естественно, JavaScript. Но это не значит, что весь ваш код необходимо переписывать на нём. Есть несколько решений, позволяющих использовать в Chrome приложении код на других языках программирования. Среди них:

  • Native Client. Код компилируется таким образом, чтобы позволить как его выполнение процессором, так и верификацию браузером. Код NaCl использует для общения с внешним миром достаточно богатый набор интерфейсов Pepper API, включающий, в частности, работу с файловой системой, OpenGL и звук.
  • Emscripten Если NaCl вам не подходит, можно скомпилировать свой код из C++ непосредственно в JavaScript. На современных браузерах получающийся JavaScript работает лишь в несколько раз медленнее, чем если бы он компилировался в машинный код. Из плюсов — совместимость со всеми интерфейсами, доступными из JavaScript.

Пример




В заключении приведу пример приложения, над которым я сам работал (и
работаю). Это текстовый редактор Text. Код редактора доступен на гитхабе. Для собственно редактирования используется библиотека CodeMirror. Приложение реализует работу с файлами, окнами, сохранений настроек и прочие необходимые функции.

Опрос

Какие из следующих тем стоит раскрыть более подробно в следующих статьях:

Проголосовало 680 человек. Воздержалось 116 человек.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Автор: @eterevsky
Google
рейтинг 208,75
Филин Лаки

Комментарии (34)

  • +1
    Мне было бы интересно почитать про создание приложений, работающих в kiosk mode. Например, использование chrome (apps) для создания интерфейса к платежным терминалам. Осветить проблемы перехвата горячих клавиш, silent печати и т.п.
    • 0
      Для этого разумнее использовать CEF
      • 0
        Спасибо, сейчас почитаю
    • 0
      Я точно не уверен, но мне кажется, в Chrome OS планировалось ввести «анонимные аккаунты» примерно для таких use case'ов — когда компьютер стоит в общем пользовании.

      Для того чтобы переключиться в fullscreen, есть fullscreen API. В отличие от веб-страницы, в случае Chrome app, пользователь не может закрыть fullscreen-приложение, просто нажав Escape. Какие системные горячие клавиши дальше будут доступны пользователю, а какие нет — зависит от системы. Под Chrome OS, вероятно, невозможно перехватить функциональные клавиши (типа громче/тише, включить/выключить). Если очень хочется, чтобы клавиши физически были, но не работали, наверное, легче всего пропатчить версию Chrome OS.

      На счёт silent печати я почти ничего не знаю. Стандартный способ печати из Chrome — это Cloud Print, но там, кажется, это невозможно (я могу уточнить). Если это специфичные принтеры, типа принтеров для чеков, можно попробовать работать с ними напрямую с помощью интерфейсов chrome.serial и chrome.usb.
    • 0
      На самом деле я уже пробовал реализовать подобный функционал. Проблему решал очень некрасиво, запуском chrome в fullscreen вместе со стартом системы. Перехват клавиш с помощью внешней сидящей в памяти утилиты. Silent печать так и не удалось реализовать, и как следствие использовать в реальной работе не удалось(все равно можно было покинуть приложение). Поэтому время от времени ищу нормальные методы решения.
      • 0
        А на какой системе? Linux? Windows?
        • 0
          windows (embedded)
      • 0
        А запускать Chrome с ключем --kiosk вместо explorer.exe и навесить на него работу с переферией через Native Client developers.google.com/native-client/dev/ не пробовали?
        Надеюсь у вас киоск без полноценной клавиатуры, а то Alt-F4 — это, да, проблема :)
        • 0
          1) "- Надеюсь у вас киоск без полноценной клавиатуры" спросил я с надеждой у заказчика… К сожалению с ней. Поэтому использование утилиты для перехвата — показалось наименьшим злом, т.к. я смог перехватывать сочетания клавиш chrome и системные в одном конфиг. файле.
          2) «запускать Chrome с ключем --kiosk» так и делаю просто назвал «запуском chrome в fullscreen»
          В итоге можно было назвать это решением, если бы не диалог печати. Собственно после этого я и начал смотреть в сторону создания chrome app в поисках решения с печатью. И тут появляется данная публикация. Вот и подумал, что может что-то упустил и все давно решено.

          Сейчас смотрю CEF
  • +1
    Есть ли возможность вешать баджи на иконку приложения?
    • +1
      В смысле, чтобы иконка работала как виджет? Пока нет, такое невозможно. Самое близкое что есть — это API chrome.notifications для сообщений в systray.
  • +1
    eterevsky можно сколько угодно пиарить приложения, но пока нет пути заработка на них в российской части вебстора, это все очень грустно.

    Но есть один вопрос: я заметил, что в новых приложениях от гугла и его разработчиков используется одинаковый UI для окон. Этот UI где-то открыт на гитхабе? Очень хотелось бы тоже его использовать.
    • 0
      На счёт заработка — это вне моей компетенции. Но вообще интересно, в чём конкретно проблема? Приложения и расширения в Chrome Web Store можно делать платными.

      > Но есть один вопрос: я заметил, что в новых приложениях от гугла и его разработчиков используется одинаковый UI для окон.

      На данный момент это не совсем так. Но где-то в районе Chrome 34 можно ожидать появление стандартных контролов. Будет называться <window-controls>. См. crbug.com/240719
      • 0
        > это вне моей компетенции. Но вообще интересно, в чём конкретно проблема? Приложения и расширения в Chrome Web Store можно делать платными.
        Понимаю, что не в вашей. Проблема в том, что платить можно из любой страны. А вот принимать платежи можно только будучи зарегистрированным в Google Wallet как merchant, из России это все еще невозможно.

        За issue спасибо, послежу.
      • 0
        eterevsky вам ведь лучше задавать больше технические вопросы? У меня давно есть вопрос на тему chrome.syncFilesystem — периодически есть жалобы от пользователей на тему того, что файлы не синхронизируются между компьютерами. Один раз напрямую получилось посмотреть через teamviewer, было очень удивительно увидеть такое. То есть в google drive в Chrome Syncable Filesystem в папке приложения все файлы были, а в папке внутри приложения — нет. В chrome://sync чисто и девственно — проблем не было. Тогда я удалил все файлы из папки в Google Drive, после чего снова их загрузил — и кажется на второй такой раз (в первый нотификаций не было) все сработало и Хром увидел эти файлы. Впрочем это не помешало ему потом опять их развидеть.

        Такие вещи я обычно пишу в трекер, но все, связанное с синхронизацией трудно описывать + я сам как разработчик не очень люблю таски, начинающиеся со слов «Sometimes smth goes wrong ...»
        • 0
          Это очень недавняя фича, и возможно она не до конца стабильна. Я ей не занимался, так что лучше либо напишите багрепорт на crbug.com (добавьте тэги Cr-Blink-Storage-FileSystem и Cr-Services-Sync), либо задайте вопрос на StackOverflow, многие разработчики Хрома там отвечают.
          • 0
            Говорят «Stable since Chrome 27». OK, буду знать.
            • 0
              Это меньше года назад. С синхронизацией всегда сложности. Напишите всё-таки баг, если руки дойдут.
  • 0
    Простите, скриншот разместить не могу.

    Если промотать эту страницу вверх, справа будет… О боже! Вы сфоткали Захара Прилепина?
  • 0
    Все это напомнило мне XULRunner и Prism от Mozilla.
    • 0
      Есть существенные отличия: в XULRunner предлагается писать UI на XUL'е и в результате получается stand-alone приложение, полность независимое от Firefox.

      Что касается Prism — я с ним не работал, но кажется, тот проект не взлетел.
    • +1
      Chrome Apps выглядят во многом как обычные приложения, но установка их легка и непринуждённа — почти как у «настоящих» web-приложений.

      XULRunner и Prism же… это машина без колёс. Уже даже неважно какой там двигатель, салон и крыша: оно просто не ездит.

      Как среда для разработки приложений HTML5 — дерьмо. Только сегодня кое-как её дотянули до того уровня где нативные toolkit'ы были в начале века. Кое-где даже лучше сделали — но только очень и очень «кое где»!

      Но ведь web-приложения получили популярностью далеко не вчера? Как же так? Главным и долгое время единственным преимуществом web-приложений является то, что их не нужно устанавливать. Всё. И вот именно долгое время чуть ли не единственное, но и сейчас ещё самое основное преимущество XULRunner и Prism выкидывают. Ну и кто эти люди после этого? Как эти творения можно сравнивать с Chrome Apps если нет самого главного?
      • 0
        Вобщем-то я не говорил, что XULRunner или Prism были супер, просто идеи схожи, был еще проект Chromeless и из всего этого и родилась в итоге Firefox OS. Была еще история с ява-апплетами, те же самые веб-приложения, данные + софт для их просмотра на любом браузере. Chrome Apps все же это старые песни о главном.

        Лично мне никакие браузерозависимые приложения не нужны, я предпочитаю standalone.
  • 0
    Чем отличается hosted app и обычная ссылка(например в закладках) на сайт?
    Что понимается под словом «специальная закладка»?
    • +1
      Hosted apps могут иметь разрешения делать вещи, которые обычному web-сайту не положены. Скажем использовать Native Client, который упоминался в статье.
    • +1
      В manifest'е для hosted apps могут указываться настройки безопасности. Плюс там же можно разрешить открывающейся страничке пользоваться API, которые обычно вебсайтам недоступны.
  • +1
    Скажите, а почему Chrome Apps (даже те, что являются по сути просто ссылкой с манифестом) нельзя добавлять, не имея google-аккаунта?
    • 0
      Потому что установленые приложения, также как и расширения, привязаны к аккаунту. Если вы залогинетесь в Chrome на другом компьютере, они сразу появятся там и возможно даже сохранят ваши настройки с прежнего компьютера.
  • 0
    Олег, несколько вопросов, по планам «когда» (ориентировочно), если есть такая инфа:
    1. Релиз Chrome Mobile Apps на андроид
    2. Dart VM в Chrome Apps
    3. Полная поддержка ES6 (destructuring assignment, fat arrow functions, «class» sugar etc.). Я понимаю, что это больше к v8 вопрос, но ФФ стэйбл уже давно это поддерживает. И хотелось бы уже это видеть в v8 хотя бы в packaged apps.
    • +2
      Ну, вы же понимаете, что если бы даже я знал сроки, я не имел бы полномочий их озвучивать. :-)

      1. Недавно появился SDK, позволяющий делать Android app из Chrome app. Я давал ссылку в посте. Непосредственно перенести все расширения и аппы с десктопа на мобильные системы сложно, так как UI сильно разный.

      2. Ничего конкретного сказать не могу. В ближайшем будущем (~3 месяца) — вряд ли. После — возможно.

      3. Активных багов на эту тему я не нашёл: code.google.com/p/v8/issues/
  • +1
    Какие из следующих тем стоит раскрыть более подробно в следующих статьях:
    • Обмен данными с периферийными устройствами USB HID.
    • Работа с акселерометром (датчик положения в пространстве).
    • Работа с данными геонавигации.
    • Работа с тачскрином.
    • Способы адаптации полноэкранных приложений под различные форматы дисплея.
    • 0
      Хороший список. По пунктам:

      > Обмен данными с периферийными устройствами USB HID.
      > Работа с акселерометром (датчик положения в пространстве).

      Насколько мне известно, отдельного API для этого пока нет.

      > Работа с данными геонавигации.

      developer.chrome.com/extensions/location.html Могу написать подробнее, но пока что это экспериментальный API.

      > Работа с тачскрином.

      Тут особой специфики для apps нет. Общий API: www.w3.org/TR/touch-events/.

      > Способы адаптации полноэкранных приложений под различные форматы дисплея.

      Это общий вопрос HTML+CSS. К сожалению, я не чувствую себя в достаточной степени экспертом по этой теме.
  • 0
    Рассмотрите подробнее процесс создания hosted app и packaged app, сравнивая в процессе с преимуществами над простым расширением. Я сейчас как раз в процессе «окончательного осмысления» реализации приложения с активным использованием запросов к серверу и локальным хранением с бэкапом на сервер и такая статья была бы очень полезна.

    О наболевшем — раньше процесс публикации расширения в магазине приложений Chrome занимал максимум 10 минут (по крайней мере у меня), теперь же (с осени прошлого года) я жду исчезновения статуса Pending Review неделями и то постоянно напоминая Joe Marini о том, что так делать нехорошо.
  • 0
    Спасибо. А я уж все думаю, как задействует свой Chromebook Pixel с IO 2013. Все собирался попробовать, теперь есть и статья :)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка