| Автоматически проверять наличие обновлений | Указывается периодичность проверки наличия обновлений на сервере:
ДоступНа закладке выполняется настройка прав доступа групп пользователей к управлению ресурсами Главного модуля.
Публичная частьФорма предназначена для ограничения доступа посетителей к сайту, например, на время выполнения технических работ.
С помощью кнопки Закрыть доступ пользователей/Открыть доступ для всех посетителям может быть разрешен или запрещён доступ к публичной части сайта. Контроллер
Слабые паролиВыбор базы данных для проверки паролей. Можно использовать штатную или собственную базу.
Дополнительно
© «Битрикс», 2001-2022, «1С-Битрикс», 2022 Наверх |
Push and Pull. Настройки модуля
Недоступно в редакциях: Стандарт, Старт
При использовании продуктов Bitrix Framework на базе виртуальной машины BitrixVM v4.2 либо BitrixEnvironment, то необходимости в настройке модуля нет: всё работает «из коробки».
О принципах работы модуля можно узнать из главы Push&Pull учебного курса
| Поле | Описание |
|---|---|
| Состояние модуля | Индикация активности модуля. |
| Используют модули | Список модулей, использующих Push&Pull. |
| Отправлять PUSH уведомления на мобильные телефоны | Включение отправки уведомлений на мобильные телефоны. После включения опции становится активным окно для задания Максимального количества push-уведомлений в пакете при отправке. |
| Включить модуль для не авторизованных пользователей | Сообщения будут доставляться пользователям, даже если они не авторизованы на сайте. |
| Использовать «Push server» | Выбор типа сервера.
|
| На сервер установлена: (для локального сервера) | Указание на используемую виртуальную машину. Доступны значения:
Указанные ниже версии объявлены устаревшими и скоро перестанут поддерживаться.
|
| Настройка адреса для публикации команд со стороны сервера | |
| Путь для публикации команд (для локального сервера) | Укажите пути до папки с командами. |
| Код-подпись для взаимодействия с сервером (для локального сервера | Ключ, которым подписываются сообщения, отправляемые на пуш-сервер. Рекомендуется для создания ключа использовать случайную строку длиной от 32 символов. Ключ указывается в настройках пуш-сервера:
/etc/push-server/push-server*.json:
"security": {
"key":
},
В виртуальной машине это поле создается автоматически при первом старте службы или при настройке/обновлении и прописывается в настройки сайта. Секретный ключ можно получить в /etc/push-server/push-server-pub-*.json. |
| Настройка адреса для публикации команд со стороны клиента | |
| Путь для публикации команд (для локального сервера | Пути указываются отдельно по протоколам. |
| Настройка адреса чтения команд для браузеров | |
| Путь для чтения команд (для локального сервера) | Пути указываются отдельно по протоколам. Рекомендуется использовать стандартный порт для HTTP или HTTPS.
Используйте 8893 (HTTP) и 8894 (HTTPS) только для версии модуля nginx-push-stream-module 0.3.4 |
| Настройка адреса чтения команд для браузеров с поддержкой Web Socket | |
| Включить поддержку WebSocket | Включает использование Веб-сокетов. Активна только при использовании nginx-push-stream-module в версии 0.4.0 |
| Путь для чтения команд через WebSocket (HTTP) (для локального сервера) | Пути указываются отдельно по протоколам. |
| Блокировка работы с модулем на определенных сайтах | |
| Не использовать модуль на сайтах (для локального сервера) | Активно только при наличии нескольких активных сайтов в системе. Укажите на каких сайтах модуль не должен использоваться. С помощью клавиши Ctrl можно выбрать несколько сайтов. |
Сайт будет использовать
облачный сервер Битрикса
1. Для выбора облачного сервера необходимо иметь активную лицензию.
Примечание. Домен при написании путей можно указать #DOMAIN#: такая нотация будет автоматически заменяться под нужный домен для многодоменных конфигураций. Пример: http://#DOMAIN#:8893/bitrix/sub/
Смотрите также:
- Настройки модуля Push and Pull
© «Битрикс», 2001-2022, «1С-Битрикс», 2022
Наверх
Встраивание и совместное использование визуально насыщенных ссылок — WWDC19 — Видео
Больше видео
Новая структура представления ссылок позволяет разработчикам приложений легко представлять URL-адреса богатым, красивым и согласованным образом. Узнайте, как использовать Link Presentation для извлечения метаданных из URL-адреса, представления расширенного содержимого ссылки внутри вашего приложения и предоставления метаданных ссылки для нового интерфейса обмена листами в iOS.
Ресурсы
Похожие видео
Технические переговоры
Скачать
Привет, я Тим Хортон из команды Safari и WebKit.
Я здесь, чтобы показать вам, как представить расширенные ссылки в вашем приложении.В iOS 10 и macOS Sierra мы представили расширенные ссылки в сообщениях, чтобы сделать URL-адреса более красивыми и полезными. Чтобы получить максимальную выгоду, мы построили специализации для определенных видов ссылок. Это включает в себя такие вещи, как встроенное воспроизведение видео и аудио, специальную презентацию для твитов, в том числе с несколькими изображениями, и многие другие вещи, такие как ссылки Apple Maps.
В этом году в iOS 13 и macOS 10.15 представлены новые API-интерфейсы, которые позволяют вам отображать расширенные ссылки в ваших собственных приложениях, чтобы вы могли получить те же преимущества с минимальным объемом работы.
В этом видео мы будем следить за развитием этого очень простого приложения для маркировки книги рецептов, постепенно внедряя функции новой структуры представления ссылок, чтобы перейти от простого списка URL-адресов к богатой сетке ссылок, подобных этой в совсем нет времени.
Для этого я рассмотрю 3 темы. Во-первых, как представить метаданные по URL-адресу. Во-вторых, как легко представить эти метаданные пользователю. И в-третьих, как использовать извлеченные метаданные для ускорения представления нового интерфейса Share Sheet в iOS 13.
Начнем с извлечения метаданных.
Допустим, в приложении рецептов у вас уже есть какой-то механизм, с помощью которого пользователи могут получать URL-адреса в приложении.
Вы могли бы просто представить их в таблице и на этом закончить, но URL-адреса не очень удобны для пользователя, и в этом случае их довольно сложно различить.
Вместо этого вы можете запросить у пользователя заголовок для каждой ссылки, но мы можем сделать это еще проще.
Используя новую структуру представления ссылок, очень легко использовать класс поставщика метаданных LP для получения расширенных метаданных с веб-сайта. Вы просто передаете ему URL-адрес, и он возвращает вам объект LPLinkMetadata с репрезентативным заголовком на любом доступном носителе.
Давайте посмотрим, как это выглядит. Сначала вы создаете LPMetadataProvider, а затем вызываете startFetchingMetadata с интересующим вас URL-адресом. Когда вызывается обработчик завершения, обязательно проверьте ошибку. Если сервер не отвечает или работает слишком медленно, или у вашего пользователя нет сетевого подключения, получение метаданных может завершиться ошибкой. Наконец, вы можете использовать метаданные для всего, что хотите. Мы вернемся к этому через мгновение.Прежде чем мы продолжим, необходимо помнить о нескольких вещах при использовании metadataProvider и LinkMetadata. Во-первых, результирующий объект метаданных может включать любой заголовок, значок, изображение или видео или вообще ничего, если сайт ничего не указывает. Он также может сериализоваться в рамках безопасного кодирования. Это важно, потому что LPMetadataProvider подключается к Интернету, чтобы выполнить свою работу, а вы не хотите ни выполнять эту работу, ни заставлять своих пользователей платить за данные и производительность каждый раз, когда вы представляете одну и ту же ссылку.
Вы должны максимально кэшировать полученные метаданные локально.Кроме того, вы можете получить метаданные для URL-адресов локальных файлов, и в этом случае новый API эскизов QuickLook будет использоваться для получения репрезентативного эскиза для файла, если это возможно.
Теперь давайте поговорим о том, как использовать полученные метаданные, представив их в нашем приложении.
Опять же, все просто. Вы можете просто взять ранее созданный объект и создать с ним LPLinkView.
Это так просто.
Вернемся к приложению рецептов и поместим LPLinkViews в ячейки нашего табличного представления.
Гораздо лучше. Теперь у вас есть очень знакомая презентация, которая позволяет легко идентифицировать каждый рецепт с первого взгляда. LPLinkView имеет внутренний размер, но он также реагирует на размер, который соответствует идеальному размеру для использования с учетом ограниченного размера, и мы постараемся представить что-то разумное при любом размере.
Последнее, о чем я собираюсь рассказать, это как использовать LinkMetadata для ускорения представления нового интерфейса «Общий лист» в iOS 13. по ссылке вверху карточки. Однако для этого требуется обращение к серверу для получения метаданных после представления общего листа. Таким образом, заголовок и значок отображаются асинхронно. Давайте посмотрим это снова. Внимательно следите за заголовком Share Sheet. Если у вас уже есть объект LPLinkMetadata для URL, вы должны просто передать его на общий лист, и предварительный просмотр появится мгновенно, без загрузки из сети. Вы можете использовать новый метод метаданных activityViewControllerLink в своей реализации UIActivityItemSource и просто вернуть объект метаданных. Давайте посмотрим на разницу в нашем приложении рецепта, если мы предоставим данные, которые мы уже используем в табличном представлении.
Гораздо приятнее. Также полезно отметить, что если пользователь решит поделиться с сообщениями, одни и те же метаданные передаются напрямую, обеспечивая плавную и беспроблемную работу без ненужной загрузки.
И последнее. Допустим, в вашем приложении уже есть база данных рецептов с названиями и изображениями, которые не были получены связанной презентацией. Вам не нужно повторно получать метаданные из Интернета, чтобы ускорить общий лист или предоставить расширенную ссылку. Вместо этого вы можете просто заполнить поля LPLinkMetadata самостоятельно из уже существующего источника данных. Вы просто создаете объект LPLinkMetadata и заполняете как минимум исходный URL-адрес и поля URL-адреса, а также любую дополнительную информацию, которая у вас есть.
Итак, наши 3 ключевых вывода сегодня: вы можете использовать поставщика метаданных LP для получения расширенных метаданных для URL-адреса, чтобы предоставить больше контекста для произвольных URL-адресов. Вы должны использовать представление ссылок LP, чтобы представить ссылки в своем приложении таким образом, чтобы они были красивыми и совместимыми с системой, и вы должны предварительно выбрать или использовать существующие LPLinkMetadata для ускорения предварительного просмотра Share Sheet в вашем приложении.
Для получения дополнительной информации посетите сайт developer.apple.com.
Спасибо за ваше время.
Ищете что-то конкретное? Введите тему выше и сразу переходите к интересным материалам.
Я здесь, чтобы показать вам, как представить расширенные ссылки в вашем приложении.
Давайте посмотрим, как это выглядит. Сначала вы создаете LPMetadataProvider, а затем вызываете startFetchingMetadata с интересующим вас URL-адресом. Когда вызывается обработчик завершения, обязательно проверьте ошибку. Если сервер не отвечает или работает слишком медленно, или у вашего пользователя нет сетевого подключения, получение метаданных может завершиться ошибкой. Наконец, вы можете использовать метаданные для всего, что хотите. Мы вернемся к этому через мгновение.
Вы должны максимально кэшировать полученные метаданные локально.
Включение расширенного предварительного просмотра общих ссылок
Практический обзор включения расширенного предварительного просмотра ссылок в iMessage, Facebook и других приложениях. Впервые опубликовано 9 января 2017 года на сайте markcarlson.io
Приложение iMessage в iOS 10 обеспечивает расширенный предварительный просмотр ссылок, когда они правильно отформатированы, чтобы воспользоваться преимуществами этой новой функции. Кроме того, эти же ссылки будут содержать расширенные предварительные просмотры и в других приложениях, таких как Facebook, Reddit, WhatsApp, Skype, Twitter и других с той же конфигурацией. На приведенных ниже снимках экрана вы можете увидеть, как эти простые ссылки на apple.
com и yahoo.com отображают большие логотипы и заголовки, когда они передаются через приложение iOS iMessage:
Расширенные предварительные просмотры в приложении iMessage для iOS полностью генерируются парой тегов Open Graph Facebook. Эти теги размещаются внутри раздела веб-сайта. Facebook поддерживает некоторые из этих тегов, но iMessage использует только 2, «og:title» и «og:image»
Например, взгляните на эту простую HTML-страницу:
> веб-страница идет
Несмотря на то, что эта страница создает простой сайт с одной строкой текста, в iMessage будет создано следующее расширенное превью: Длина текста заголовка ограничена примерно 44 символами в iMessage.
Дополнительный текст обрезается и заменяется многоточием. GIF и динамические изображения не работают, если они указаны в теге изображения. Рекомендуемый размер изображения для предварительного просмотра — 1200 x 1200 или больше. Reddit использует квадратное изображение размером 70 x 70 для миниатюры. Изображения всех размеров автоматически уменьшаются до этого. Facebook рекомендует 1200 x 630 для размера og:image. Это дает вашему общему сообщению полноразмерное изображение над текстом сообщения. Разрешение изображения до 600 x 315 также будет обрабатываться таким же образом.
Давайте посмотрим, что произойдет, когда мы попытаемся поделиться одним и тем же сайтом с полным изображением 1200 x 1200 на Facebook:
Очевидно, что это не идеально. Facebook обрезал наше изображение с 1200 x 1200 до 1200 x 630. Теперь, когда мы знаем, что в некоторых социальных сетях отображается квадрат, а в некоторых – прямоугольник, мы должны создать изображение, которое будет хорошо работать в обоих случаях.
Давайте попробуем что-то вроде этого (я добавил фон, чтобы показать, где 1200 x 630 поместится внутри этого изображения 1200 x 1200):
Это изображение имеет размер 1200 x 1200, но основное содержимое содержится в пространстве размером 1200 x 630. Теперь, когда мы делимся в iMessage, мы получаем это:
Не так уж и плохо. Лучше всего то, что это же изображение прекрасно работает и с Facebook:
Что произойдет, если ваш og:image намного меньше 1200 x 1200? Давайте взглянем. Вот то же изображение, сохраненное в разрешении 150 x 150, что является наименьшим размером, поддерживаемым iMessage:
Вот что мы получаем, когда размещаем изображение на сайте с разрешением 150 x 150 og:image size:
Несмотря на то, что оно отображает изображение такого размера, оно становится заметно пикселизированным на дисплее Retina. Как это же изображение выглядит в публикации на Facebook?
Как видите, лучшее, что мы получаем при таком разрешении, — это уменьшенное изображение в той же строке, что и текст поста.