Пользователи жалуются, что Google Chrome и Android System WebView перестали обновляться на Android в РФ с 9 мая

Проблема исправлена: https://t.me/mercdev/1908.

Google ответила отпиской на жалобы российских пользователей по поводу проблем с обновлением Chrome на Android

Проблема исправлена. Подробности: https://t.me/mercdev/1908.

Web PUSH Notifications быстро и просто

Можно узнать, сколько push-уведомлений было доставлено, открыто и закрыто, добавив в service worker обработчики событий push, notificationclick и notificationclose (пример: service-worker.js) и отправляя данные в Google Analytics с помощью протокола передачи статистических данных Measurement Protocol (пример: analytics-sw.js).

Web PUSH Notifications быстро и просто

// регистрируем пустой ServiceWorker каждый раз
navigator.serviceWorker.register('messaging-sw.js');

// запрашиваем права на показ уведомлений если еще не получили их
Notification.requestPermission(function(result) {

Регистрировать каждый раз ещё один пустой service worker со своим собственным жизненным циклом только для того, чтобы показать уведомление — костыль. Так как мы используем Firebase Cloud Messaging, то в момент вызова messaging.onMessage у нас уже должен быть зарегистрирован service worker firebase-messaging-sw.js с областью видимости /firebase-cloud-messaging-push-scope, и можно использовать его.

Насколько я понимаю, запрашивать права на показ уведомлений в messaging.onMessage тоже не нужно.

Таким образом, messaging.onMessage должен выглядеть как-то так:

messaging.onMessage((payload) => {
  navigator.serviceWorker.getRegistration('/firebase-cloud-messaging-push-scope').then((registration) => {
    registration.showNotification(payload.notification.title, payload.notification);
  });
});

MP3 окончательно переходит в общественное достояние

А ещё недавно истёк последний патент на AC-3 – https://ac3freedomday.org (https://web.archive.org/web/20170401170436/https://ac3freedomday.org).

Натив или гибрид? Специалисты Яндекса отвечают на главный вопрос мобильной разработки

На самом деле чистое веб-приложение сейчас не сделать.

Сделать

Веб-вью все равно нужно положить внутрь iOS или Android-приложения, то есть в любом случае нужен контейнер, который написан с помощью Java, Swift или Objective-C.

Не нужен.

Есть такая штука — прогрессивные веб-приложения (progressive web apps, PWA) и WebAPK. Советую почитать, что это такое.

Поэтому на вопрос

Натив или гибрид?

ответ будет — прогрессив.

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

Так и количество различных зарекомендовавших себя макетов интерфейса (layouts), используемых в современных приложениях, тоже не бесконечно. Есть готовые решения, например: https://polymerelements.github.io/app-layout/

Кроме того, встает вопрос, хотите ли вы трижды рисовать разный дизайн для каждого приложения. Ведь гайдлайны операционных систем сильно отличаются друг от друга, и как лебедь, рак и щука двигаются в разные стороны в мелочах. Если внимательно прочитать гайды Windows Phone, Android и iOS, то окажется, что нужно хорошо продумать, как ваша пользовательская задача будет оптимально решаться на каждой из платформ.

Есть Material Design, который является кроссплатформенным: https://material.io/guidelines/platforms/

Web PUSH Notifications быстро и просто

Кстати, есть ещё отличная книга о service workers — https://serviceworke.rs, в ней есть раздел о web push — https://serviceworke.rs/web-push.html с примерами использования https://github.com/web-push-libs/web-push.

Web PUSH Notifications быстро и просто

В Chrome этот метод не отрабатывает.

Какой именно метод?

К этому проекту прилагается видео https://youtu.be/BsCBCudx58g, в котором подробно объясняется, что к чему.

Обратите особое внимание на примечание о фокусе на странице https://github.com/firebase/quickstart-js/tree/master/messaging:

When the app has the browser focus, the received message is handled through the onMessage callback in index.html. When the app does not have browser focus then the setBackgroundMessageHandler callback in firebase-messaging-sw.js is where the received message is handled.

The browser gives your app focus when both:

1. Your app is running in the currently selected browser tab.
2. The browser tab's window currently has focus, as defined by the operating system.

Следует также принять во внимание, что поведение одного и того же браузера на разных платформах может различаться. Например, 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. ;)

Web PUSH Notifications быстро и просто

Если использовать Firebase Cloud Messaging, то очередь не нужна: https://firebase.google.com/docs/cloud-messaging/js/send-multiple.

Web PUSH Notifications быстро и просто

Стандарт до сих пор не утвержден. И лучше не изобретать свой велосипед, а использовать один из кучи готовых сервисов, которые и о передрягах стандарта позаботятся и поддержку iOS/Safari обеспечат.

Да, спецификация 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, но это не повод их не использовать.

Web PUSH Notifications быстро и просто

Попробуйте Firebase Cloud Messaging JavaScript Quickstart и отпишитесь здесь о результате.

Проверял отправку со стороны клиента в браузере с помощью Fetch на Chrome и Firefox, на Windows и Android — всё работает.

Web PUSH Notifications быстро и просто

Отвечу сразу на несколько комментариев разных людей одним сообщением.

Нельзя отправить сообщение с клиента. То есть отправить запрос с помощью AJAX или веб-формы на сервер, чтобы тот отправил push-уведомление нам на клиентскую сторону. Не работает.

Можно. Работает: https://gauntface.github.io/simple-push-demo/.

Не смотря на заявленную поддержку Firefox, в нем уведомления не работают.

Работают. Проверял на 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.

Библиотека Firebase скрывает в себе много тайн и её исследование могло бы дать ответы на некоторые вопросы, но это уже выходит за рамки этой статьи.

А жаль, там много интересного. ) Думаю, я созрел для своей первой статьи для Хабра. :)

Трансляция WebRTC-видеопотока из браузера на YouTube Live в 65 строк JavaScript/HTML-кода

Возможно, даже можно сегментировать поток с помощью JS прямо в браузере и отправлять на YouTube напрямую без сервера-посредника.

Трансляция WebRTC-видеопотока из браузера на YouTube Live в 65 строк JavaScript/HTML-кода

А почему был выбран RTMP?

Судя по документации, YouTube Live Streaming API поддерживает также DASH, который помимо кодеков H.264 и AAC в контейнере ISO BMFF также поддерживает кодеки VP8/VP9 и Vorbis/Opus в контейнере WebM.

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

Трансляция WebRTC-видеопотока из браузера на YouTube Live в 65 строк JavaScript/HTML-кода

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

Трансляция WebRTC-видеопотока из браузера на YouTube Live в 65 строк JavaScript/HTML-кода

Так уже. :) Если аппаратное кодирование доступно, то используется аппаратное, иначе – программное.

Думаю, пункт

WebRTC в Chrome не поддерживает кодек H.264 на мобильных устройствах

нужно удалить из статьи, так как

1. это не так. :)
2. из текущей формулировки не понятно, идёт речь о поддержке кодирования или декодирования.

Трансляция WebRTC-видеопотока из браузера на YouTube Live в 65 строк JavaScript/HTML-кода

WebRTC в Chrome не поддерживает кодек H.264 на мобильных устройствах, там используется кодек VP8.

Chrome для Android поддерживает программное кодирование в H.264 для WebRTC, начиная с версии 52 — https://www.chromestatus.com/features/6417796455989248.

Аппаратное кодирование в H.264 для WebRTC в Chrome для Android включается с помощью флага chrome://flags/#enable-webrtc-hw-h264-encoding.

Использование Service Worker для создания ботнета

Я убежден, что нужно добавить флажок для отключения Service Worker.

Я тоже за то, чтобы предоставлять пользователю возможность как можно большего контроля над происходящим. Но вопрос в том, насколько эта возможность будет востребована у обычных пользователей. Многие ли блокируют выполнение JavaScript в браузере?

Лично мне эта технология пользы не приносит.

Например, Push и Cache/Precache, — одни из основных концепций прогрессивных web-приложений (Progressive Web Apps, PWA), основаны на Service Workers, а у PWA светлое будущее.

Вы читали документацию Cache? Это же как китайская грамота.

Есть отличный учебник по Service Workers — https://serviceworke.rs, есть https://github.com/GoogleChrome/sw-precache и https://github.com/GoogleChrome/sw-toolbox, которые довольно просты в использовании и хорошо документированы.

Проблема не в Service Workers, проблема в сознании. Нужно перестать относиться к сайтам как к наборам отформатированных страниц, а начать воспринимать их как полноценные приложения, а web как платформу, причём самую большую. Современные браузеры предоставляют возможности, ранее доступные только нативным приложениям: доступ к местоположению, камере, микрофону, USB, NFC, возможность получать push-уведомления, работать без доступа к интернету и т.д. И к вопросу безопасности и доверия к web-приложениям нужно относиться так же как и к нативным приложениям.

Использование Service Worker для создания ботнета

И Chrome, и Firefox теперь поддерживают W3C Push API.

Использовать Firebase Cloud Messaging не обязательно, есть Web Push Libraries.

Парсинг JSON — это минное поле

Большинство не используют всех возможностей JSON, описанных в этой статье, а используют некоторое их подмножество, работа с которым вполне безопасна, например для написания package.json, bower.json, babelrc.json, .eslintrc и т.д., для которых есть JSON Schema.