что такое manifest json

Пишем правильный манифест для сайта

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

Манифест для сайта – это простой JSON-файл, который позволяет вам настроить следующие вещи:
1. Какая будет иконка у пользователя, после того как он добавит ваш сайт на рабочий стол
2. Как будет запускаться ваш сайт (с адресной строкой, без нее или в полноэкранном режиме)
3. Splash screen
4. Цветовую тему
5. Ориентацию экрана
6. Начальный url
и многое другое

Подробнее

Чтобы показать, как manifest влияет на отображение сайта, я создал простое, тестовое веб-приложение, которые возвращает название региона по коду.

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

После того как пользователь добавил иконку, она будет выглядеть так (на Андроид 5.0)
Название браузер выдернул из тега tilte. Так что, если у вас нету файла манифеста, то хотя бы title должен быть нормальным. А вот иконка в виде буквы “G” появилась сама (не понятно, почему именно G).
А сам сайт будет выглядеть так

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

Встречайте, manifest.json!

Генерируй и властвуй.

Конечно, можно написать весь манифест ручками, но это скучно, долго и можно ошибиться. Уже нашлось немало умельцев, которые автоматизировали этот процесс. Ниже небольшой обзор инструментов для автоматической генерации манифеста.

brucelawson.github.io/manifest — все что вам нужно – заполнить поля (есть краткое описание каждого параметра, так что процесс довольно легкий), остальное за вас сделает генератор.

www.favicon-generator.org — хоть прямое назначение этого сайта генерировать иконки, а не манифест. Он все же его создает и в отличии от предыдущего у вас уже будут и иконки (для iOS и Аднроид) и манифест. Правда, манифест придется подправить (изменить имя и прочее настройки).

manifest-validator.appspot.com — этот инструмент предназначен для валидации вашего манифеста.

Результат

Итак иконки нарисовали, манифест сделали. Дальше надо сообщить браузеру о манифесте, добавив в тег head следующие

Все. Смотрим, что получилось
Иконка:

Слева до. Справа после (иконка получилась невпечатлительная, с удовольствием поменяю, если пришлете лучше). Тут уже заметно, что Android использовал имя из поля short_name, так как name не помещается, видимо.

Загрузка приложения:

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

Сам сайт:

Тут тоже все стало лаконично. Без UI браузера сайт смотрится гораздо лучше и больше похож на нативное приложение.

Я перечислил не все свойства, которые можно указать в файле манифеста. С полным списком можно ознакомиться здесь
Демо приложение
Репозиторий приложения

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

Источник

Манифест? А? Что? Зачем?

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

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

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

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

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

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

Что такое «установка»?

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

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

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

Очень простой манифест

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

Типичный манифест

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

Название приложения

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

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

Иконки

Назначение иконки

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

Режимы отображения и ориентация

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

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

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

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

Стартовый адрес

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

«Область» приложения

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

С вебом все иначе: это огромная гипертекстовая система, в которой веб-приложение может охватывать несколько доменов: вы можете с легкостью перейти с gmail.com на docs.google.com и пользователь даже этого не заметит. На практике, идея существования границ приложения является абсолютно чуждой для веба. Ведь, в действительности, веб-приложение — это просто серия HTML-документов (представьте «серию труб»… м-м, нет, забудьте!).

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

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

Интернационализация: lang и dir

Распространение приложения

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

Цвет темы и цвет фона

Как мне определить, что пользователь «установил» приложение?

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

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

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

Кто это внедряет?

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

Взаимодействие с поисковыми роботами

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

Если разработчик веб-приложения хочет известить поисковых роботов о запрете на сканирование файла, он может сделать это включив манифест веб-приложения в файл robots.txt. Это описано подробнее в протоколе robots.txt. Разработчик веб-приложения также может использовать HTTP-заголовок X-Robots-Tag.

Авторы

Основная часть этого пояснения первоначально появилась в статье « 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

Пример манифеста для коннектора с открытым кодом

Ниже приведен пример заполненного манифеста.

Источник

Что такое manifest json

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

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

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

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

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

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

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

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

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

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

manifest.json

Начинаем редактировать файл, руководствуясь таблицей описания его параметров. В значении вы можете использовать ссылку на языковые сообщения, если нужно. Внимание! С ноября 2018 года добавилось 3 ОБЯЗАТЕЛЬНЫХ поля в manifest.json. Первые два поля отвечают за обратную связь и располагаются в кнопке “Обратная связь” (необходимо указать ссылку на сайт поддержки, либо email). Обратите внимание, email является менее приоритетным способом связи. Краткое описание виджета будет располагаться в левой части модального окна. С ноября 2019 года добавлено ОБЯЗАТЕЛЬНОЕ свойство в manifest.json – тур. Тур — это набор картинок, на которых демонстрируется функционал виджета. Обязательными поля данного свойства являются: поле с указанием включением тура для виджета, ключи локализаций для картинок тура и ключ ланга, содержащего краткий текст, который будет выведен в момент показа тура виджета. Подробнее можно узнать в статье.

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

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

widget/description Обязательное поле. Полное описание виджета, показывается в окне настроек виджета. Должно содержать путь к переводу в языковых файлах. Вы можете использовать html-тэги, а также специальные short-теги для того, чтобы сформировать максимально персонифицированное описание. К примеру, вам нужно показать описание, подсказав пользователю субдомен аккаунта amoCRM в котором он работает. Список доступных тэгов:
#HOST# – текущий хост;
#SUBDOMAIN# – субдомен аккаунта;
#LOGIN# – логин текущего пользователя, авторизованного пользователя;
#API_HASH# – хеш-ключ пользователя;
#ACCOUNT_ID# – id текущего аккаунта в системе;
#LINK#http://example.test/link_to_copy#/LINK# – тег данного вида преобразуется в поле и кнопку, при нажатии на которую скопируется ссылка;
#USER_ID# – id текущего пользователя в системе.

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

widget/short_description Обязательное поле. Короткое описание для вывода в списке виджетов. Должно содержать путь к переводу в языковых файлах. widget/code Обязательное поле только для виджетов загруженных через раздел API. То, что нужно ввести латинскими символами при генерации ключа на странице разработчика. Ваш код виджета widget/secret_key Обязательное поле только для виджетов загруженных через раздел API. Секретный ключ виджета, который вы сгенерировали на странице разработчика widget/version Версия виджета. Носит только информативную нагрузку. (Рекомендуется увеличивать версию при каждой загрузки архива виджета для того, чтобы иметь актуальные файлы в системе) widget/interface_version (int) Версия интерфейса (1,2) для какого именно интерфейса системы загружается виджет. По умолчанию необходимо оставлять 2. Интерфейс 1 — предыдущая версия интерфейса всей системы amoCRM, без использования AJAX. Регистрация на старую версию сейчас закрыта. widget/init_once (true/false) указывает на то, нужно ли собирать js объект виджет 1 раз за сеанс работы с интерфейсом amocrm. При инициализации виджета вызываются функции render(), init() и bind_actions() (подробнее о них в части script.js). Указание true или false регулирует возможность каждый раз при переходе из области в область (подробнее об областях подключения) вызывать функции init() и bind_actions(), или вызвать их только один раз. К примеру, виджеты телефоний постоянно удерживают WebSocket соединение и его обрыва происходить не должно, поэтому init_once должно иметь значение true. Если же общего для всех страниц контекста нет, то лучше ставить в false. widget/locale Обязательное поле c массивом кодов языков, на которых будет доступен виджет. Под каждый язык должен быть свой файл с переводом в папке i18n. Доступные языки: ru, en, es (русский, английский и испанский соответственно).

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

widget/installation (true/false) Если выбрано false, то виджет будет отображаться только в списке виджетов, не запрашивая настройки или установку в аккаунте. Это актуально, когда все настройки происходят в другой системе, взаимодействующей с amoCRM через API. widget/is_showcase (true/false) True изменяет название кнопки “Установить” на “Посмотреть”. Это необходимо, когда виджет носит информационный характер, не устанавливается напрямую. installation при этом должен быть false. locations Интерфейсы в которых должен быть отображен виджет. Массив, обязательный для заполнения, в случае если необходимо использовать js часть виджета. Подробнее об областях.
Возможные местоположения:
llist — список сделок, clist — список контактов, tlist — список задач, lcard — карточка сделки, ccard
— карточка контакта, card_sdk — SDK карточки, culist – cписок покупателей, cucard – карточка
покупателя, digital_pipeline – digital воронка сделок и покупателей, catalogs – SDK списков,
whatsapp_modal – модальное окно интеграций, работающих с WhatsApp, advanced_settings – страница
расширенных настроек виджета, salesbot_designer – возможность использовать виджет в конструкторе Salesbot, sms – возможность отправки системных SMS виджетом, mobile_card – возможность использования виджета в мобильных приложениях. Так же необходимо сообщить нашей системе будет
ли виджет использовать правую колонку для отображения, сделать это можно дописанием 0 или 1 после
указания зоны. То есть, если указать “clist-0”, виджет инициализируется в данной зоне, но не будет
использовать правую колонку. К примеру, панель для WEB-фона находится не в правой колонке виджетов, а
внизу в любом интерфейсе. Поэтому для всех мест подключения в настройках виджета должно быть написано
0, но при этом на каждой странице он инициализируется.
amoforms – возможность использования виджета в веб-формах. tour Блок содержит все основные настройки для тура виджета. Пример реализации можете посмотреть ниже tour/is_tour (true/false) указывает на то, нужно ли включать тур для виджета tour/tour_images Содержит ключи локализаций для картинок тура tour/tour_images/(en|ru|es) (Array) Содержит путь до изображений для тура в зависимости от локализации tour/tour_description Ключ ланга, содержащего краткий текст, который будет выведен в момент показа тура виджета settings Массив настроек виджета, доступных пользователю, т.е. поля, которые будут присутствовать в окне настроек виджета и заполняться пользователем. Данный раздел требуется только если installation = true, если installation = false, то данный раздел не нужен, т.к. в окне настроек будет выводиться только описание виджета.Ключем в массиве является код поля FIELD_CODE settings/FIELD_CODE/name Название поля (только ссылка на элемент в lang файле) settings/FIELD_CODE/type Тип поля. Доступные варианты:

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

settings/FIELD_CODE/required true/false обязательность заполнения поля пользователем. dp Блок настройки виджетов в digital pipeline.
Данный блок необходимо включать в manifest.json, только если есть область видимости digital_pipeline.
С функционалом digital pipeline могут работать только публичные виджеты, имеющие файл widget.php, в котором присутствует endpoint digital_pipeline (подробнее Digital pipeline) dp/settings Аналогичен блоку settings, но будет выводится при настройке виджета в digital воронке. dp/action_multiple Обязательное поле в блоке dp, значения – true/false, определяет, может ли действие виджета растягиваться на несколько этапов dp/webhook_url Если функционал вашего виджета реализует только отправку данных из Digital Pipeline на ваш собственный URL по вебхук (то есть другой бизнес-логики на стороне виджета нет), используйте это поле. В случае указания webhook_url amoCRM будет отправлять вебхук напрямую по указанному адресу, поэтому php-часть виджета делать не нужно. dp/title Название вашего триггера, которое отображается в настройках Digital Pipeline. Принимает ключ ланга из i18n. widget/support/link Ссылка на поддержку интеграции (обязательно) widget/support/email Email технической поддержки (обязательно в случае отсутствия ссылки на поддержку интеграции) advanced/title Ключ в ланг файле для названия страницы виджета в настройках. salesbot_designer Параметры для добавления виджета в конструкторе Salesbot. Подробней читайте по ссылке. sms/endpoint Адрес, на который будет отправлен запрос для отправки системного SMS. Подробней читайте по ссылке. mobile/frame_url Адрес, который будет открыт в специальной области в мобильном приложении. Подробней читайте по ссылке. mobile/color HEX код цвета, который будет использован как подложка под заголовкам блока с виджетом. amoforms_settings/title Ключ в ланг файле для отображения названия пункта виджета в веб-формах. amoforms_settings/required Обязательность в веб-формах, прежде чем клиент нажмет обычную кнопку “Отправить”, ему необходимо нажать на кнопку виджета. Необязательный параметр amoforms_settings/error_text Ключ в ланг файле для отображения ошибки виджета в веб-формах. Необязательный параметр

Пример manifest.json

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

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

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

В таком случае необходимо создать в папке i18n два файла локализации для русского и английского языка ru.json и en.json. За тем, в зависимости от языка аккаунта как в JS части, так и в PHP, будут доступны языковые сообщения на соответствующем языке.

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

Источник