Manifest json что это за файл

Обновлено: 04.07.2024

Если у вас еще нет amoCRM

После того, как вы распакуете архив, вы увидите в корне папку widget_example, структуру которой мы рассмотрим:

Файл Описание
manifest.json
require		 Файл в формате json, содержащий описание виджета, настройки виджета, параметры виджета, выводимые пользователю, локализации, с которыми работает виджет.
script.js JS-файл, который будет подключен на стороне пользователя в указанных в manifest.json областях
images/ Папка для размещения файлов изображений, которые используются в виджете. Должна содержать в себе 5 файлов в формате (png, jpeg,jpg или gif), которые будут использоваться как логотип виджета в разных областях видимости. Размер каждого файла не должен превышать 300 КБ. logo_min.jpg и logo_medium.jpg — обязательно, если виджет работает в карточках, используется во всех списках и карточках контактов или сделок в свернутом и развернутом состоянии соответственно. Изображения logo_main и logo_small дублируют цели logo_min соответственно, обязательны к отгрузке с ноября 2018 года. Также необходимо загрузить logo.jpg для поддержки старых версий.

Как видите, обязательным является только файл manifest.json

Начинаем разработку

В качестве примера, мы возьмем виджет, который основан только на JS. Он выводит кнопку в карточке контакта, при клике на которую данные из карточки отправляются во внешнюю систему, где для примера обрабатываются php-скриптом заглушкой, которая может быть написана на любом языке.

Это частая задача, т.к. не редко требуется по бизнес процессу передавать данные из amoCRM, по действиям сотрудника, во внутреннюю систему компании. Или наоборот выводить дополнительные данные из внешней системы в карточки amoCRM.

Кроме того, API amoCRM поддерживает событийную модель вызова сторонних скриптов через WebHooks- механизм. Он позволяет при определенных событиях, к примеру, изменение статуса сделки или изменение контакта, обращаться по указанному в настройках URL-скрипту и передавать в него актуальные данные.

Также, публичные виджеты могут взаимодействовать с функционалом digital воронок сделок и покупателей. Подробнее можно узнать в разделе Digital pipeline

Итак, сначала копируем папку с примером виджета и называем ее widget. Это основа нашего будущего виджета.

Файл widget.php мы пока использовать не будем, поэтому можете его смело удалить. Далее начинаем разбираться со всеми файлами по очереди.

manifest.json

Параметр Описание
widget Блок содержит все основные настройки виджета
widget/name Обязательное поле. Название виджета, в том числе для отображения в списке виджетов. Должно содержать путь к переводу в языковых файлах. В примере стоит значение widget.name, а это значит, что значение будет взято из соответствующего файла папки i18n, в зависимости от локализации.

Если виджет загружен из интеграции, то будет использоваться имя, указанное в интеграции, при этом поле пока что остается обязательным.

Если виджет загружен из интеграции, то будет использоваться описание, указанное в интеграции, при этом поле пока что остается обязательным.

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

  • text
  • pass
  • users(список пользователей системы с 1 текстовым полем на каждого, требуется в случае если нужно ввести какую-то информацию по каждому сотруднику, например внутренний телефонный номер для IP-телефонии)
  • users_lp (список пользователей системы с 2 полями (login,password) на каждого.

Подробно типы полей разобраны в разделе Типы полей раздела settings manifest.json

Пример manifest.json

Особенности, связанные с oAuth интеграциями:

  1. В данный момент, логотип интеграции и логотип виджета это два разных файла. Логотип интеграции отображается в списке и на странице получения доступов, если у интеграции нет виджета. Если виджет есть, то он отображается только на странице получения доступов.
  2. Если виджет загружен в интеграции, то в его модальном окне будет отображаться название и описание, указанные в настройках интеграции, а не те, что указаны в manifest.json.

i18n Файлы локализации

В примере manifest.json используются конструкции вида widget.name. Они необходимы, если ваш виджет должен работать более, чем на одном языке.

ВАЖНО: Если используется 2 локализации, то необходимо, чтобы файлы были одинаковыми по структуре.

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

Но что это за разрыв? Всего несколько лет назад этот разрыв был, в большей степени, технологическим. Если вы хотели получить доступ к GPS устройства, вам приходилось писать нативное приложение. Сейчас ситуация несколько улучшилась: теперь мы можем получать доступ к датчикам устройства, вроде GPS, камеры и ориентации устройства — хотя впереди ещё долгий путь. Благодаря последним успехам веб-технологий, теперь у нас есть платформа, которая может конкурировать с нативными приложениями уже почти на равных.

Сегодня разрыв между нативными и веб-приложениями не столько технологический — дело в удобстве пользователей: они предпочитают устанавливать приложения, которые уютно живут на домашнем экране (или даже на рабочем столе, если речь про десктопные браузеры).

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

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

Мы в веб-сообществе, как правило, называем это «прогрессивными веб-приложениями».

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

Спецификация манифеста предлагает вам стандартный способ сделать это с помощью файла JSON. Просто сошлитесь на файл манифеста в HTML-странице следующим образом:

Но что находится в этом загадочном файле манифеста? Хорошо, что вы спросили!

Самый простой манифест может состоять всего-то из имени и одной или нескольких иконок.

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

Приложению нужно настоящее название или набор названий (которые обычно совсем не совпадают с содержимым элемента <title> документа). Для этого используются ключи name и short_name .

Ключ short_name служит названием приложения при отображении в условиях ограниченного пространства (например, под значком на домашнем экране телефона). Ключ name может быть немного длиннее, отображая название приложения полностью. Также он служит дополнительной информацией для пользователя, который ищет ваше приложения на телефоне. Так что, набрав «улётный» или «фото», пользователь сможет найти приложение на своем устройстве.

Если вы опустите название, то браузер может использовать <meta name="application-name"> или элемент <title> .

Но будьте внимательны: некоторые браузеры могут требовать указать название — иначе, ваше приложение может лишиться статуса «прогрессивное веб-приложение».

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

Если вы не укажете иконки, браузер будет искать запасные варианты: <link rel="icon"> , favicon.ico или, если не найдёт их, может даже использовать скриншот вашего сайта.

Больше подробностей о назначении иконок можно найти в спецификации Web App Manifest.

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

Доступные значения режимов отображения:

  • Полноэкранный fullscreen занимает весь экран.
  • Автономный standalone открывает приложение со строкой состояния.
  • Минимальный minimal-ui , когда приложение отображается в полноэкранном режиме, как на iOS, но некоторые действия могут вызывать панель навигации и появление кнопок назад и вперед.
  • Браузерный browser открывает приложение со стандартным набором кнопок и панелью инструментов.

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

Также вы можете применить другие стили для приложение в определённом режиме с помощью характеристики display-mode :

Используйте метод window.matchMedia() , чтобы проверить это медиавыражение в JavaScript.

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

Нативные приложения имеют чёткие границы: как пользователь, вы уверены, что когда вы открываете нативное приложение, оно неожиданно не откроет другое незаметно для вас. Чаще всего, вам предельно ясно, что вы переключились с одного нативного приложения на другое. Обычно эти визуальные подсказки предоставляет операционная система (например, вызов диспетчера задач и выбор другого приложения или нажатие Cmd Tab или Alt Tab на компьютере).

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

Формат манифеста решает эту проблему позволяя указывать «область адреса» для вашего приложения. Эта область устанавливает границы для приложения. Это может быть либо домен, либо директория на этом домене.

Нужно написать с подробностями и скриншотами.

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

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

В ходе обсуждения спецификации шли оживленные дискуссии об использовании тегов <meta> в HTML вместо создания нового формата. В конце концов, реализация функции «добавить на домашний экран» в Chrome использует теги <meta> , да и с самых первых дней веба эти теги были родным домом для всякой нестандартной ерунды.

Причины для использования отдельного файла:

В спецификации есть более подробная информация о том, почему мы выбрали JSON вместо HTML-тегов.

Манифест и прогрессивные веб-приложения реализованы в Chrome, Opera и Samsung Internet для Android. Firefox также подаёт обнадёживающие сигналы, что будет поддерживать эти стандарты (реализации в Gecko уже больше двух лет, но она не используется ни в одном из продуктов).

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

Основная часть этого пояснения первоначально появилась в статье «The W3C App Manifest specification» на HTML5 Doctor, и была написана Маркусом Касересом и Брюсом Лоусоном. Данный материал публикуется на основе лицензии для некоммерческое использования. Вы можете спокойно изменять, повторно использовать, модифицировать и расширять это пояснение. Некоторые авторы сохраняют свои авторские права на отдельные статьи.

Манифест – это файл JSON ( appsscript.json ) из проекта коннектора на платформе Apps Script. Он содержит информацию о вашем коннекторе, необходимую для его развертывания и использования в Студии данных. Подробнее о манифестах проектов Apps Script…

Ниже описана информация, которая должна быть представлена в манифесте.

AuthType

Вы можете выбрать один из следующих методов аутентификации:

Перечисляемое значение Описание
NONE Показывает, что для коннектора не требуется аутентификация.
OAUTH2 Показывает, что коннектор использует для аутентификации протокол OAuth 2.0.
KEY Показывает, что коннектор использует для аутентификации ключ API.
USER_PASS Показывает, что коннектор использует для аутентификации имя пользователя и пароль.
USER_TOKEN Показывает, что коннектор использует для аутентификации имя пользователя и токен.

FeeType

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

Значение перечисляемого типа Описание
FREE Плата за использование коннектора не взимается.
FREE_TRIAL У коннектора есть бесплатный пробный период.
PAID За использование коннектора взимается плата.

Sources

Sources – это список названий источников (все источники, которые могут быть в этом списке, перечислены здесь). Если источника, к которому вы подключаетесь, нет в списке, отправьте запрос на его добавление. Название источника может содержать только заглавные буквы и символы подчеркивания (например, для Google Аналитики будет использоваться название GOOGLE_ANALYTICS ). В манифесте коннектора с открытым кодом используйте значение свойства id источника данных, например GOOGLE_ANALYTICS .

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

Манифесты веб-приложений являются частью набора веб-технологий, называемых прогрессивными веб-приложениями (PWA, progressive web apps), представляющими собой веб-сайты, которые можно установить на домашний экран устройства без магазина приложений.

В отличие от обычных веб-приложений с простыми ссылками на домашний экран или закладками, PWA можно загружать заранее и работать в автономном режиме, а также использовать обычные Web API.

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

Содержимое манифеста¶

Манифест может содержать следующие элементы:

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

Внедрение манифеста¶

Манифест веб-приложения внедряется в вашу HTML-страницу, с помощью тега ссылки в заголовке вашего документа:

Расширение .webmanifest указывается в разделе спецификации Media type registration section of the specification (ответ файла манифеста должен возвращать Content-Type: application/manifest+json ). Браузеры обычно поддерживают манифесты с другими соответствующими расширениями, такими как .json ( Content-Type: application/json ).

Если для получения манифеста требуются учетные данные - атрибут crossorigin должен иметь значение use-credentials , даже если файл манифеста находится в том же источнике, что и текущая страница.

Заставки¶

В Chrome 47 и более поздних версиях заставки отображаются при загрузке веб-приложения с домашнего экрана. Эти заставки автоматически генерируются с использованием свойств, указанных в манифесте приложения, например: name , background_color и иконки в массиве icons , которые ближе к 128dpi для устройства.

Читайте также: