¿Por qué no envía trabajos cuando el navegador está cerrado?
Esta pregunta surge bastante, en gran medida porque hay algunas situaciones que hacen que sea difícil razonar y comprender.
Comencemos con Android. El SO Android está diseñado para detectar mensajes push y, cuando los recibe, activa la app para Android adecuada para que maneje los mensajes push, independientemente de si la app está cerrada o no.
Esto es exactamente igual con cualquier navegador en Android: este se activará cuando se reciba un mensaje push y el navegador activará a tu service worker y despachará el evento push.
En los SO de computadoras de escritorio, tiene más matices y es más fácil de explicar en Mac OS X porque hay un indicador visual que ayuda a explicar las diferentes situaciones.
En Mac OS X, puedes distinguir si un programa se está ejecutando con una marca debajo del ícono de la app en el conector.
Si comparas los dos íconos de Chrome en el siguiente conector, el de la izquierda se está ejecutando, como se muestra en la marca debajo del ícono, mientras que el de Chrome de la derecha no se está ejecutando, por lo que no hay una marca debajo.
![Ejemplo de OS X](https://web.dev/static/articles/push-notifications-faq/image/example-os-x-72bc3d5fa52ff.png?authuser=7&hl=es)
En el contexto de la recepción de mensajes push en computadoras de escritorio, recibirás mensajes cuando se esté ejecutando el navegador, es decir, cuando haya una marca debajo del ícono.
Esto significa que el navegador no puede tener ventanas abiertas, y seguirás recibiendo el mensaje push en tu service worker porque el navegador se está ejecutando en segundo plano.
El único momento en que no se recibirá un envío es cuando el navegador está completamente cerrado, es decir, no se ejecuta en absoluto (sin marcas). Lo mismo se aplica para Windows, aunque es un poco más complicado determinar si Chrome se ejecuta en segundo plano o no.
¿Cómo hago para que mi app web de pantalla principal se abra en pantalla completa desde un envío?
En Chrome para Android, se puede agregar una aplicación web a la pantalla principal y, cuando la aplicación web se abre desde la pantalla principal, se puede iniciar en modo de pantalla completa sin la barra de URL, como se muestra a continuación.
![Ícono de pantalla principal a pantalla completa](https://web.dev/static/articles/push-notifications-faq/image/home-screen-icon-fullscr-e034b276ccc7e.png?authuser=7&hl=es)
Para mantener la coherencia de esta experiencia, los desarrolladores quieren que las notificaciones en las que hacen clic también abran su app web en pantalla completa.
Chrome "en cierto modo" implementó esto, aunque puede que te resulte poco confiable y difícil de entender. Los detalles de implementación relevantes son los siguientes:
Esto significa que, a menos que el usuario visite tu sitio a través del ícono de la pantalla principal con cierta frecuencia, tus notificaciones se abrirán en la IU normal del navegador.
Trabajaremos más en este problema.
¿Por qué esto es mejor que los sockets web?
Un service worker puede revivir cuando se cierra la ventana del navegador. Un socket web solo funcionará siempre y cuando el navegador y la página web estén abiertos.
¿Cuál es el acuerdo con GCM, FCM, Web Push y Chrome?
Esta pregunta tiene varias facetas y la manera más fácil de explicarla es recorrer el historial del push web y de Chrome. (No te preocupes, es breve).
Diciembre de 2014
Cuando Chrome implementó por primera vez el servicio push web, Chrome usaba Google Cloud Messaging (GCM) para impulsar el envío de mensajes push desde el servidor al navegador.
Esto no era un servicio web push. Hay varias razones por las que esta configuración temprana de Chrome y GCM no fue "real" un push web.
- GCM requiere que los desarrolladores configuren una cuenta en la consola de Google Developers.
- Chrome y GCM necesitaban que una app web compartiera un ID de remitente especial para poder configurar los mensajes correctamente.
- Los servidores de GCM aceptaron una solicitud a la API personalizada que no era un estándar web.
julio de 2016
En julio se lanzó una nueva función de envío web: las claves del servidor de aplicaciones (o VAPID, como se conoce en la especificación). Cuando Chrome agregó compatibilidad para esta nueva API, usó Firebase Cloud Messaging (también conocido como FCM) en lugar de GCM como servicio de mensajería. Esto es importante por varios motivos:
- Las claves del servidor de Chrome y de aplicaciones no necesitan ningún tipo de proyecto para configurar con Google o Firebase. Funcionará.
- FCM es compatible con el protocolo de envío web, que es la API que admitirán todos los servicios push web. Esto significa que independientemente del servicio push que utilice un navegador, solo tienes que hacer el mismo tipo de solicitud y se enviará el mensaje.
¿Por qué es confuso hoy?
Actualmente, existe bastante confusión respecto a que el contenido se escribió sobre el tema de web push, y gran parte del cual hace referencia a GCM o FCM. Si el contenido hace referencia a GCM, probablemente deberías tratarlo como una señal de que es contenido antiguo O que se enfoca demasiado en Chrome. (Soy culpable de haberlo en varias publicaciones antiguas).
En cambio, piensa que el servicio web push consiste en un navegador, que utiliza un servicio push para administrar el envío y la recepción de mensajes, en el que el servicio push aceptará una solicitud de “protocolo push web”. Si piensas en estos términos, puedes ignorar qué navegador y qué servicio push está usando y ponerlo en funcionamiento.
Esta guía se redactó para enfocarse en el enfoque estándar de los envíos web, y se ignora deliberadamente todo lo demás.
Firebase tiene un SDK de JavaScript. ¿Qué y por qué?
Si encontraste el SDK web de Firebase y notaste que tiene una API de mensajería para JavaScript, es posible que te preguntes en qué se diferencia del push web.
El SDK de mensajería (conocido como Firebase Cloud Messaging JS SDK) hace algunos trucos en segundo plano para facilitar la implementación web push.
- En lugar de preocuparte por un
PushSubscription
y sus distintos campos, solo debes preocuparte por un token de FCM (una cadena). - Con los tokens para cada usuario, puedes usar la API exclusiva de FCM para activar los mensajes push. Esta API no requiere encriptación de cargas útiles. Puedes enviar una carga útil de texto sin formato en el cuerpo de una solicitud POST.
- La API, propiedad de FCM, admite funciones personalizadas, por ejemplo, los temas de FCM (también funciona en la Web, aunque no está bien documentada).
- Por último, FCM es compatible con Android, iOS y la Web, por lo que algunos equipos es más fácil de usar en proyectos existentes.
Para ello, se utiliza la tecnología web push en segundo plano, pero su objetivo es abstraerla.
Como dije en la pregunta anterior, si consideras que el push web es solo un navegador y un servicio push, puedes usar el SDK de Messaging en Firebase como una biblioteca para simplificar la implementación de push web.
Próximos pasos
- Descripción general de las notificaciones push web
- Cómo funciona Push
- Cómo suscribirte a un usuario
- UX de permisos
- Envía mensajes con bibliotecas push web
- Protocolo de envío web
- Manejo de eventos push
- Muestra una notificación
- Comportamiento de las notificaciones
- Patrones de notificaciones comunes
- Preguntas frecuentes sobre las notificaciones push
- Cómo informar errores y problemas habituales