muse manifest xml что это
Пишем правильный манифест для сайта
Думаю, многие знают о возможности добавления иконки сайта на рабочий стол мобильного устройства. Это удобно и причины могут быть разные (нету мобильного приложения, предоставляющего туже информацию, либо вы хотите сразу открыть определенную страницу сайта и т.д.). За некоторые свойства того, как будет отображаться сайт и как будет выглядеть иконка после добавления и отвечает файл манифеста.
Манифест для сайта – это простой 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 браузера сайт смотрится гораздо лучше и больше похож на нативное приложение.
Я перечислил не все свойства, которые можно указать в файле манифеста. С полным списком можно ознакомиться здесь
Демо приложение
Репозиторий приложения
Также необходимо подчеркнуть, что все это не будет работать на яблочных устройствах. На них можно достичь приблизительно такого результата, только надо использовать другой способ.
Muse manifest xml что это
Я собираюсь выгрузить страничку на поддомен, а затем уже размножить ее по другим поддоменам копируя файлы из папки этого подомена на другие поддомены через панель хостинга.
Со всеми файлами понятно как и что копировать и менять кроме одного
muse_manifest.xml можете подсказать за что отвечает данный файл?
У него в коде есть цифры которые различаются у каждого поддомена,
и если копировать таким образом у всех поддоменов они будут одинаковые, в отличие от того если бы загружать на хостинг каждый поддомен отдельно с компьютера.
У поддоменов будут меняться только тексты без изменения стилей и шрифтов через файл index, возможно в таком случае скопировав их оставить одинаковыми?
И как к этому файлу относиться яндекс, обращает он на этот фаил внимания?
Яндексу на его содержимое должно быть безразлично.
Алексей133, это типичный мультисайтовый движок. Вам нужно вынести фактические данные в базу данных или даже разнести их по базам данных, а файлы движка хранить в одном экземпляре и лишь файлы пользователей для каждого свои. Детект сайта, к кот. идет обращение, делаете по входящему имени хоста.
P.S. Мы обычно имя хоста транслируем в префикс таблиц и храним данные всех сайтов в одной БД, разнося их по таблицам. Можно использовать и централизованный подход на уровне таблиц – в одной список сайтов с числовыми id, а в др. уже принадлежность записей тому или иному сайту определяется по полю с числовыми id сайтов.
Я не совсем хорошо разбираюсь в этом, я правильно понял что файл muse_manifest.xml является файлом движка?
и его можно скопировать в каждый поддомен в одинаковом виде? ну или оставить его в одном экземпляре при правильной структуре базы данных?
Что такое файлы пользователей?
«Детект сайта, к кот. идет обращение, делаете по входящему имени хоста.»
Или нужно редактировать каждый файл muse_manifest.xml у каждого поддомена меняя в коде имя хоста(домен)?
В таком случае в коде есть еще цифры которые разные у поддоменов, при копирование они останутся одинаковыми, достаточно будет изменить только имя хоста и оставить цифры у всех одинаковыми?
Что такое детект сайта?
Я вам написал, как это должно работать. Мусей никогда не пользовался и пользоваться не собираюсь. Возможно, этот файл является своеобразным конфигом или файлом проекта и вовсе не нужен в продакшене. Даже если он нужен и должен содержать специфичное для сайта доменное имя, это элементарно решается путем использования единого шаблона и подстановки в него доменного имени.
Если вы в этом всем не совсем хорошо разбираетесь, то вариант у вас только один – клепать копии сайта. Я написал, как следовало бы это сделать.
да я бы сделал если понял как это все делать)
по поводу файла в поддержке хостинга ответили что:
В ином случае необходимо будет указать корректный путь к директории поддомена.
Вот только меня слово «попробуйте» смущает, типа вы сделайте а если все накроется то значит не правильно
Мне важен только один вопрос, как данный файл может влиять на поисковые системы, если ни как то и пусть остается как есть, сайт отображается корректно и все работает
Манифест? А? Что? Зачем?
Многие из нас, кто работает над вебом, активно стараются уменьшить разрыв между нативными и веб-приложениями.
Но что это за разрыв? Всего несколько лет назад этот разрыв был, в большей степени, технологическим. Если вы хотели получить доступ к 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, и была написана Маркусом Касересом и Брюсом Лоусоном. Данный материал публикуется на основе лицензии для некоммерческое использования. Вы можете спокойно изменять, повторно использовать, модифицировать и расширять это пояснение. Некоторые авторы сохраняют свои авторские права на отдельные статьи.
Add a web app manifest
The web app manifest is a JSON file that tells the browser about your Progressive Web App and how it should behave when installed on the user’s desktop or mobile device. A typical manifest file includes the app name, the icons the app should use, and the URL that should be opened when the app is launched.
Manifest files are supported in Chrome, Edge, Firefox, UC Browser, Opera, and the Samsung browser. Safari has partial support.
Create the manifest file #
Key manifest properties #
short_name and/or name #
You must provide at least the short_name or name property. If both are provided, short_name is used on the user’s home screen, launcher, or other places where space may be limited. name is used when the app is installed.
For PWAs running in standalone mode, Chromium will prepend the short_name (or, if short_name is not set, alternatively the name ) to what is specified in the of the HTML document to prevent disguies attacks where standalone apps might try to be mistaken, for example, for operating system dialogs.
In consequence, developers should not repeat the application name in the when the app is running in standalone mode.
icons #
When a user installs your PWA, you can define a set of icons for the browser to use on the home screen, app launcher, task switcher, splash screen, and so on.
For Chromium, you must provide at least a 192×192 pixel icon, and a 512×512 pixel icon. If only those two icon sizes are provided, Chrome will automatically scale the icons to fit the device. If you’d prefer to scale your own icons, and adjust them for pixel-perfection, provide icons in increments of 48dp.
To be on the safe side, you should always specify a rasterized icon as a fallback for browsers that do not support SVG icons.
start_url #
The start_url is required and tells the browser where your application should start when it is launched, and prevents the app from starting on whatever page the user was on when they added your app to their home screen.
Your start_url should direct the user straight into your app, rather than a product landing page. Think about what the user will want to do once they open your app, and place them there.
background_color #
The background_color property is used on the splash screen when the application is first launched on mobile.
display #
You can customize what browser UI is shown when your app is launched. For example, you can hide the address bar and browser chrome. Games can even be made to launch full screen.
display_override #
Web apps can choose how they are displayed by setting a display mode in their manifest as explained above. Browsers are not required to support all display modes, but they are required to support the spec-defined fallback chain ( «fullscreen» → «standalone» → «minimal-ui» → «browser» ). If they don’t support a given mode, they fall back to the next display mode in the chain. This inflexible behavior can be problematic in rare cases, for example, a developer cannot request «minimal-ui» without being forced back into the «browser» display mode when «minimal-ui» is not supported. Another problem is that the current behavior makes it impossible to introduce new display modes in a backward compatible way, since explorations like tabbed application mode don’t have a natural place in the fallback chain.
These problems are solved by the display_override property, which the browser considers before the display property. Its value is a sequence of strings that are considered in the listed order, and the first supported display mode is applied. If none are supported, the browser falls back to evaluating the display field.
In the example below, the display mode fallback chain would be as follows. (The details of «window-control-overlay» are out-of-scope for this article.)
The browser will not consider display_override unless display is also present.
scope #
A few other notes on scope :
theme_color #
The theme_color sets the color of the tool bar, and may be reflected in the app’s preview in task switchers. The theme_color should match the meta theme color specified in your document head.
As of Chromium 93 and Safari 15, you can adjust this color based on a media query with the media attribute of the meta theme color element. The first one that matches will be picked. For example, you could have one color for light mode and another one for dark mode. At the time of writing, you can’t define those in your manifest. See w3c/manifest#975 GitHub issue.
shortcuts #
description #
The description property describes the purpose of your app.
screenshots #
In Chrome, the image must respond to certain criteria:
The description and screenshots properties are currently used only in Chrome for Android when a user wants to install your app.
Add the web app manifest to your pages #
The request for the manifest is made without credentials (even if it’s on the same domain), thus if the manifest requires credentials, you must include crossorigin=»use-credentials» in the manifest tag.
Test your manifest #
To verify your manifest is setup correctly, use the Manifest pane in the Application panel of Chrome DevTools.
This pane provides a human-readable version of many of your manifest’s properties, and makes it easy to verify that all of the images are loading properly.
Splash screens on mobile #
When your app first launches on mobile, it can take a moment for the browser to spin up, and the initial content to begin rendering. Instead of showing a white screen that may look to the user like the app is stalled, the browser will show a splash screen until the first paint.
Chrome automatically creates the splash screen from the manifest properties, specifically:
The background_color should be the same color as the load page, to provide a smooth transition from the splash screen to your app.
Chrome will choose the icon that closely matches the device resolution for the device. Providing 192px and 512px icons is sufficient for most cases, but you can provide additional icons for pixel perfection.
Further reading #
There are several additional properties that can be added to the web app manifest. Refer to the MDN Web App Manifest documentation for more information. You can learn more about display_override in the explainer.
Файл манифеста AndroidManifest.xml
Файл манифеста AndroidManifest.xml предоставляет основную информацию о программе системе. Каждое приложение должно иметь свой файл AndroidManifest.xml. Редактировать файл манифеста можно вручную, изменяя XML-код или через визуальный редактор Manifest Editor (Редактор файла манифеста), который позволяет осуществлять визуальное и текстовое редактирование файла манифеста приложения.
Назначение файла
Общая структура манифеста
Файл манифеста инкапсулирует всю архитектуру Android-приложения, его функциональные возможности и конфигурацию. В процессе разработки приложения вам придется постоянно редактировать данный файл, изменяя его структуру и дополняя новыми элементами и атрибутами.
Описание
Элемент является корневым элементом манифеста. По умолчанию Eclipse создает элемент с четырьмя атрибутами:
Атрибуты
объявляет разрешение, которое используется для ограничения доступа к определенным компонентам или функциональности данного приложения. В этой секции описываются права, которые должны запросить другие приложения для получения доступа к вашему приложению. Приложение может также защитить свои собственные компоненты (деятельности, службы, приемники широковещательных намерений и контент-провайдеры) разрешениями. Оно может использовать любое из системных разрешений, определенных Android или объявленных другими приложениями, а также может определить свои собственные разрешения.
android:name название разрешения android:label имя разрешения, отображаемое пользователю android:description описание разрешения android:icon значок разрешения android:permissionGroup определяет принадлежность к группе разрешений android:protectionLevel уровень защиты
Элемент запрашивает разрешение, которые приложению должны быть предоставлены системой для его нормального функционирования. Разрешения предоставляются во время установки приложения, а не во время его работы.
android:name имеет единственный атрибут с именем разрешения android:name. Это может быть разрешение, определенное в элементе
данного приложения, разрешение, определенное в другом приложении или одно из стандартных системных разрешений, например: android:name=»android.permission.CAMERA» или android:name=»»android.permission.READ_CONTACTS»
Наиболее распространенные разрешения
объявляет базовое имя для дерева разрешений. Этот элемент объявляет не само разрешение, а только пространство имен, в которое могут быть помещены дальнейшие разрешения.
определяет имя для набора логически связанных разрешений. Это могут быть как объявленные в этом же манифесте с элементом
разрешения, так и объявленные в другом месте. Этот элемент не объявляет разрешение непосредственно, только категорию, в которую могут быть помещены разрешения. Разрешение можно поместить в группу, назначив имя группы в атрибуте permissionGroup элемента