Alexey Rodionov @FluorescentHallucinogen
PWA-разработчик, адвокат Web-платформы
Информация
- В рейтинге
- Не участвует
- Откуда
- Краснодар, Краснодарский край, Россия
- Дата рождения
- Зарегистрирован
- Активность
Специализация
Специалист
Lead
PWA-разработчик, адвокат Web-платформы
Проблема исправлена: https://t.me/mercdev/1908.
Проблема исправлена. Подробности: https://t.me/mercdev/1908.
Можно узнать, сколько push-уведомлений было доставлено, открыто и закрыто, добавив в service worker обработчики событий
push
,notificationclick
иnotificationclose
(пример: service-worker.js) и отправляя данные в Google Analytics с помощью протокола передачи статистических данных Measurement Protocol (пример: analytics-sw.js).Регистрировать каждый раз ещё один пустой service worker со своим собственным жизненным циклом только для того, чтобы показать уведомление — костыль. Так как мы используем Firebase Cloud Messaging, то в момент вызова
messaging.onMessage
у нас уже должен быть зарегистрирован service workerfirebase-messaging-sw.js
с областью видимости/firebase-cloud-messaging-push-scope
, и можно использовать его.Насколько я понимаю, запрашивать права на показ уведомлений в
messaging.onMessage
тоже не нужно.Таким образом,
messaging.onMessage
должен выглядеть как-то так:А ещё недавно истёк последний патент на AC-3 – https://ac3freedomday.org (https://web.archive.org/web/20170401170436/https://ac3freedomday.org).
Сделать
Не нужен.
Есть такая штука — прогрессивные веб-приложения (progressive web apps, PWA) и WebAPK. Советую почитать, что это такое.
Поэтому на вопрос
ответ будет — прогрессив.
Так и количество различных зарекомендовавших себя макетов интерфейса (layouts), используемых в современных приложениях, тоже не бесконечно. Есть готовые решения, например: https://polymerelements.github.io/app-layout/
Есть Material Design, который является кроссплатформенным: https://material.io/guidelines/platforms/
Кстати, есть ещё отличная книга о service workers — https://serviceworke.rs, в ней есть раздел о web push — https://serviceworke.rs/web-push.html с примерами использования https://github.com/web-push-libs/web-push.
Какой именно метод?
К этому проекту прилагается видео https://youtu.be/BsCBCudx58g, в котором подробно объясняется, что к чему.
Обратите особое внимание на примечание о фокусе на странице https://github.com/firebase/quickstart-js/tree/master/messaging:
Следует также принять во внимание, что поведение одного и того же браузера на разных платформах может различаться. Например, Firefox для Android и Mac могут после закрытия работать в фоновом режиме и, соответственно, принимать push-уведомления, а Firefox для Windows — нет.
Можно передавать сообщения из service worker'а на страницу: https://web-push-book.gauntface.com/chapter-05/04-common-notification-patterns/#message-page-from-a-push-event
Советую всё-таки прочитать книгу https://web-push-book.gauntface.com полностью, в ней есть ответы почти на все вопросы о web push. ;)
Если использовать Firebase Cloud Messaging, то очередь не нужна: https://firebase.google.com/docs/cloud-messaging/js/send-multiple.
Да, спецификация W3C Push API не утверждена в том смысле, что ещё пока не достигла статуса рекомендации W3C, но её уже можно активно использовать. Куда более важна поддержка спецификации различными браузерами: http://caniuse.com/#feat=push-api. Более детальные сведения: https://github.com/web-push-libs/web-push#browser-support. Хотя эти сведения тоже неполные — нет деления на платформы, что важно, так как, например, на iOS все браузеры вынуждены использовать движок WebKit со всеми вытекающими из этого последствиями в виде поддержки спецификаций.
Многие спецификации, например Service Workers и Web Components до сих пор не получили статус рекомендации W3C, но это не повод их не использовать.
Попробуйте Firebase Cloud Messaging JavaScript Quickstart и отпишитесь здесь о результате.
Проверял отправку со стороны клиента в браузере с помощью Fetch на Chrome и Firefox, на Windows и Android — всё работает.
Отвечу сразу на несколько комментариев разных людей одним сообщением.
Можно. Работает: https://gauntface.github.io/simple-push-demo/.
Работают. Проверял на Windows и Android.
Смотря что подразумевается под сервером.
См.: https://github.com/mozilla-services/autopush.
Есть отличный учебник по Web Push — https://web-push-book.gauntface.com.
К этой книге прилагается демонстрационный проект на Node.js: https://github.com/gauntface/web-push-book/tree/master/src/demos/node-server.
Использовать Firebase Cloud Messaging не обязательно, есть Web Push Libraries. Для Node.js: https://github.com/web-push-libs/web-push, для PHP: https://github.com/web-push-libs/web-push-php.
А жаль, там много интересного. ) Думаю, я созрел для своей первой статьи для Хабра. :)
Возможно, даже можно сегментировать поток с помощью JS прямо в браузере и отправлять на YouTube напрямую без сервера-посредника.
А почему был выбран RTMP?
Судя по документации, YouTube Live Streaming API поддерживает также DASH, который помимо кодеков H.264 и AAC в контейнере ISO BMFF также поддерживает кодеки VP8/VP9 и Vorbis/Opus в контейнере WebM.
Т.е. используя DASH, на сервере-посреднике можно не перекодировать видео и аудио из одного кодека в другой, а лишь разбивать их на сегменты, что требует значительно меньших ресурсов.
Не обязательно собирать самому. ) На официальном сайте есть ссылки на сторонние ресурсы, с которых можно загрузить скомпилированный FFMPEG для различных платформ.
Так уже. :) Если аппаратное кодирование доступно, то используется аппаратное, иначе – программное.
Думаю, пункт
нужно удалить из статьи, так как
Chrome для Android поддерживает программное кодирование в H.264 для WebRTC, начиная с версии 52 — https://www.chromestatus.com/features/6417796455989248.
Аппаратное кодирование в H.264 для WebRTC в Chrome для Android включается с помощью флага chrome://flags/#enable-webrtc-hw-h264-encoding.
Я тоже за то, чтобы предоставлять пользователю возможность как можно большего контроля над происходящим. Но вопрос в том, насколько эта возможность будет востребована у обычных пользователей. Многие ли блокируют выполнение JavaScript в браузере?
Например, Push и Cache/Precache, — одни из основных концепций прогрессивных web-приложений (Progressive Web Apps, PWA), основаны на Service Workers, а у PWA светлое будущее.
Есть отличный учебник по Service Workers — https://serviceworke.rs, есть https://github.com/GoogleChrome/sw-precache и https://github.com/GoogleChrome/sw-toolbox, которые довольно просты в использовании и хорошо документированы.
Проблема не в Service Workers, проблема в сознании. Нужно перестать относиться к сайтам как к наборам отформатированных страниц, а начать воспринимать их как полноценные приложения, а web как платформу, причём самую большую. Современные браузеры предоставляют возможности, ранее доступные только нативным приложениям: доступ к местоположению, камере, микрофону, USB, NFC, возможность получать push-уведомления, работать без доступа к интернету и т.д. И к вопросу безопасности и доверия к web-приложениям нужно относиться так же как и к нативным приложениям.
И Chrome, и Firefox теперь поддерживают W3C Push API.
Использовать Firebase Cloud Messaging не обязательно, есть Web Push Libraries.