Preguntas frecuentes

Acerca del identificador único de usuario user_str

1. Durante la inicialización, el desarrollador debe proporcionar una cadena única (user_str) para generar el identificador único del usuario (UID). Este UID se utiliza para el reconocimiento de identidad en las notificaciones push y es independiente del dispositivo del usuario.
   

2. Si un usuario se suscribe en varios navegadores o dispositivos usando el mismo user_str, el sistema lo identificará como el mismo usuario. La nueva información de suscripción sustituirá a la anterior, lo que garantiza que el usuario reciba mensajes en el dispositivo o navegador utilizado para la suscripción más reciente. Esto evita que el mismo usuario reciba mensajes duplicados en varios dispositivos o navegadores. El backend del sistema solo almacena la información de suscripción más reciente para cada UID.
   

3. Los usuarios pueden darse de baja en cualquier momento, y nuestro SDK proporciona la interfaz correspondiente para implementar esta función. La operación de baja desvinculará el UID de la información de suscripción, pero no cambiará la configuración de permisos de notificaciones del navegador.
   

4. En teoría, user_str debería corresponder de forma unívoca con la cuenta del usuario. En algunos escenarios, los usuarios pueden estar en modo invitado. En ese caso, los desarrolladores deben generar un user_str único en función de la situación real. Nuestro SDK no gestiona automáticamente este paso para evitar datos estadísticos inexactos causados por una gestión inadecuada de user_str.
   

Para los usuarios en modo invitado, los desarrolladores pueden usar la siguiente función de ejemplo para generar un user_str basado en la unicidad del navegador del usuario. Sin embargo, ten en cuenta que este enfoque puede provocar que se genere un nuevo user_str si el usuario cambia de navegador, cambia de dispositivo o borra la caché.
Función de ejemplo

function randomUid() { const keyStr = 'mtWebPushRandomUid'; let uid = window.localStorage.getItem(keyStr); if (!uid) { uid = new Date().getTime().toString(36) + Math.floor(Math.random() * 10000000).toString(36); window.localStorage.setItem(keyStr, uid); } return uid; } var user_str = randomUid();

              
              function randomUid() {
  const keyStr = 'mtWebPushRandomUid';
  let uid = window.localStorage.getItem(keyStr);
  if (!uid) {
    uid = new Date().getTime().toString(36) + Math.floor(Math.random() * 10000000).toString(36);
    window.localStorage.setItem(keyStr, uid);
  }
  return uid;
}
var user_str = randomUid();

            

Este bloque de código se muestra en una ventana flotante

¿Qué plataformas son compatibles con Web Push?

Compatibilidad de navegadores por sistema operativo

Nota 1: Microsoft Edge (actualizado en 2019), Opera, Samsung Internet, Yandex y UC Browser son navegadores basados en Chromium y se marcarán como Chrome en EngageLab.
Nota 2: Internet Explorer ya no recibe actualizaciones de funciones. Microsoft ha trasladado el desarrollo del navegador a la plataforma Edge.
Nota 3: El modo incógnito, el modo de navegación privada y el modo invitado del navegador no son compatibles con las notificaciones push web.

Compatibilidad por versión del navegador

Problemas de notificaciones Web Push relacionados con el navegador Safari

Las notificaciones Web Push en Safari son compatibles con macOS (11.1+) e iOS/iPadOS 16.4+.

¿Qué funciones admite Safari Push?

¿Cómo pueden los usuarios de iOS y iPadOS recibir notificaciones push web de Safari?

1. ¿Cómo deben configurar los desarrolladores los ajustes para que los usuarios puedan recibir notificaciones web en iOS/iPadOS 16.4+?

Las notificaciones Web Push pueden utilizarse en iOS/iPadOS 16.4+. Sin embargo, el sitio web debe tener un archivo manifest adecuado y las propiedades correctas configuradas para que las notificaciones funcionen correctamente. Añade el siguiente código al HTML de la página de integración correspondiente: <link rel="manifest" href="manifest.json" />

Incluye el archivo manifest:

              
              {
  "$schema": "https://json.schemastore.org/web-manifest-combined.json",
  "display": "standalone",
  "start_url": "/webpush/index.html",
  "name": "Engagelab WebPush Example",
  "short_name": "Engagelab",
  "icons": [
    {
      "src": "/icon-large-cb438cac.png",
      "type": "image/png",
      "sizes": "1024x1024"
    }
  ]
}

            

2. Para que los usuarios puedan suscribirse y recibir notificaciones Safari Web Push en dispositivos móviles, deben añadir la aplicación web a la pantalla de inicio

El envío de notificaciones Safari Web Push en dispositivos móviles (para iOS y iPadOS 16.4+) requiere que los destinatarios de las notificaciones hagan lo siguiente:

• Visitar tu sitio web en el navegador Safari de un dispositivo móvil Apple con versión 16.4+.
• Tocar el botón Compartir en Safari en el dispositivo móvil.
• Tocar la opción "Añadir a pantalla de inicio".
• Guardar la aplicación en el dispositivo.
• Abrir la aplicación desde la pantalla de inicio.
• Suscribirse a las notificaciones (antes de que aparezca la solicitud nativa de permisos, deben tocar el botón de suscripción). Estos pasos son necesarios para poder recibir notificaciones Web Push en dispositivos móviles.

Como este flujo de interacción es relativamente complejo para los usuarios finales, debes ayudarles a comprender las ventajas de suscribirse a las notificaciones.

3. Añade una notificación de banner en tu sitio web para guiar a los usuarios a "Añadir a pantalla de inicio"

Puedes añadir un banner a tu sitio web para informar a los usuarios finales sobre el valor de las notificaciones Web Push en dispositivos móviles y guiarles sobre cómo suscribirse.
Recomendamos añadir un banner a tu sitio web que aparezca en dispositivos móviles Apple y guíe a los visitantes para que toquen el botón Compartir y la opción "Añadir a pantalla de inicio".
También existe un popular proyecto open source que puede ayudarte a proporcionar estas instrucciones a los usuarios:
Enlace de GitHub de ejemplo de banner inferior: https://github.com/rajatsehgal/add-to-home-screen

¿Pueden los usuarios recibir notificaciones si el navegador está cerrado?

• Al usar el canal de EngageLab, las notificaciones solo pueden recibirse cuando el sitio web está abierto.
• Al usar el canal del sistema, las notificaciones pueden recibirse incluso cuando el navegador está cerrado, aunque el comportamiento varía según la plataforma. Consulta la siguiente tabla para obtener más detalles:

En Windows, si todas las ventanas están cerradas pero el navegador sigue ejecutándose en segundo plano, las notificaciones del sistema aún pueden recibirse. Si el proceso del navegador se ha cerrado, no se recibirán notificaciones del sistema.
En macOS, aunque todas las ventanas estén cerradas, la mayoría de los procesos del navegador siguen ejecutándose en segundo plano, por lo que las notificaciones del sistema aún pueden recibirse. Si el proceso del navegador se cierra forzosamente, no se recibirán notificaciones del sistema. Safari no necesita estar ejecutándose para recibir notificaciones, porque se entregan directamente al sistema operativo. Los usuarios deben registrar primero las notificaciones de Safari, y después podrán seguir recibiendo notificaciones incluso si Safari está completamente cerrado.

Problemas relacionados con las solicitudes de permisos de notificaciones

Después de que un usuario cierre la solicitud de Web Push, ¿cuándo volverá a aparecer?

Si un usuario hace clic en "Block" (Chrome), "Don't Allow" (Safari) o "Never Allow" (Firefox) en la solicitud nativa de permisos, el sitio web no podrá volver a mostrársela a menos que el usuario realice varios pasos en la configuración del navegador para suscribirse o restablecer permisos. Por eso se recomienda usar la solicitud de EngageLab (Ir a configuración).

Solicitud nativa de permisos

Las suscripciones Web Push requieren la solicitud nativa de permisos del navegador, y esta no puede personalizarse. Utiliza el idioma configurado en el navegador del usuario. Solo los sitios web HTTPS pueden mostrar la solicitud nativa del navegador.

Chrome: Tienes 3 oportunidades para conseguir que los usuarios se suscriban. Después de que el usuario haga clic en la "X" de la solicitud nativa de permisos por tercera vez, no volverá a recibir la solicitud durante una semana. Para obtener más información sobre esta función de Chrome, consulta aquí.
Firefox: A partir de Firefox 70, después de que un usuario haga clic en el botón de cerrar, necesita hacer clic en el pequeño icono de notificación del navegador para volver a recibir la solicitud. Además, en Firefox 72+ se ha bloqueado la visualización de la solicitud nativa del navegador. Para más detalles, consulta aquí.
Safari: Al igual que Firefox, Safari añadió una interfaz más discreta para los usuarios que suelen rechazar permisos y muestra automáticamente solicitudes a los sitios web a los que se les han denegado permisos push, Safari 12.1+

Solicitud suave de EngageLab

Como la ventana emergente nativa solo da una oportunidad, si el usuario la rechaza, el sitio web no podrá volver a solicitar autorización. Por ello, EngageLab recomienda usar una "solicitud suave" para obtener la autorización del usuario:
Si el usuario hace clic en "Allow" o "Cancel" en la solicitud de EngageLab (Ir a configuración) y todavía no se ha suscrito mediante la ventana emergente nativa, la solicitud de EngageLab puede volver a aparecer.

• Después de que el usuario haga clic en "Allow" en la solicitud de EngageLab, se activará la ventana emergente nativa. Sin embargo, si en ese momento el usuario hace clic en "Cancel" en la solicitud nativa, la próxima vez que entre en el sitio web, la solicitud de EngageLab seguirá apareciendo y preguntará si quiere permitir las notificaciones del sitio web.
  
• Después de que el usuario haga clic en "Allow" en la solicitud de EngageLab, se activará la ventana emergente nativa. Si en ese momento el usuario hace clic en "Allow" en la solicitud nativa, autoriza al sitio web para las notificaciones web; si hace clic en "Deny" en la solicitud nativa, el sitio web ya no podrá obtener autorización de ese usuario.
  
• Si el usuario hace clic en "Cancel" en la solicitud de EngageLab, puede determinarse que en ese momento no desea recibir notificaciones del sitio web. Dado que es probable que en ese momento lo rechace, no activaremos la ventana emergente nativa, y la próxima vez que visite el sitio podremos volver a preguntarle mediante la solicitud de EngageLab si quiere recibir notificaciones.

Solución de problemas cuando no se reciben notificaciones

1. Comprueba si los permisos de notificación están habilitados para la página web

2. Comprueba si los permisos de notificación están habilitados para la aplicación del navegador
Configuración de notificaciones de Windows:

• Desactiva Focus Assist. Para más detalles, consulta la documentación oficial de Microsoft.
• Comprueba Configuración > Notificaciones y acciones > Obtener notificaciones de aplicaciones y otros remitentes. Asegúrate de que tu sitio y tu navegador también estén habilitados. Para más detalles, consulta la documentación oficial de Microsoft.

Configuración de notificaciones de macOS:

• En Preferencias del Sistema > Notificaciones > Chrome o el navegador seleccionado, asegúrate de que Permitir notificaciones esté activado.
• En Preferencias del Sistema > Notificaciones > Concentración > No molestar y Reposo, asegúrate de que este modo no esté activado o de que estés dentro de un periodo horario permitido para las notificaciones.
• macOS también dispone de una configuración temporal de notificaciones No molestar en el menú superior derecho; desplázate hacia arriba para verla.

3. Los canales de los proveedores de navegadores pueden ser inestables, así que cambia para priorizar la entrega a través del canal EngageLab

              
              {
  "from": "web_push",
  "to": {
    "registration_id": [
      "xxx"
    ]
  },
  "body": {
    "platform": "web",
    "notification": {
      "web": {
        "title": "web_push",
        "alert": "Hi,MTPush !",
        "url": "http://www.google.com",
        "extras": {
          "web-key1": "web-value1"
        }
      }
    },
    "options": {
      "time_to_live": 30,
      "third_party_channel": {
        "w3push": {
          "distribution": "mtpush"
        }
      }
    },
    "request_id": "12345678",
    "custom_args": "business info"
  }
}

            

¿Safari no puede mostrar notificaciones emergentes?

Paso 1: Comprueba los permisos del navegador Safari y asegúrate de que el interruptor para permitir esté activado. A continuación se muestra un estado normal:

Paso 2: Haz clic para comprobar el estado del servicio push y los permisos de notificación del navegador. A continuación se muestra un estado normal:

Paso 3: En Safari, haz clic en Preferencias.

Haz clic en Sitios web > Notificaciones y comprueba si el sitio está permitido en el Centro de notificaciones. A continuación se muestra un estado normal:

Nota especial:

1. Al hacer clic en Stop Push, se impedirá la recepción de mensajes de JPush y será necesario actualizar la página.
2. Si hay varias páginas HTML configuradas bajo un mismo dominio, no elimines el permiso del sitio web del Centro de notificaciones. Tras eliminarlo, todas las páginas HTML dejarán de recibir notificaciones (el usuario tendrá que buscar la página principal y volver a obtener el permiso de notificaciones del sitio web).

Si el mismo usuario utiliza varios navegadores al mismo tiempo y se envía un mensaje a ese usuario, ¿cómo se mostrará en el dispositivo del usuario?

Si la estrategia de entrega seleccionada es priorizar el canal del sistema, este mensaje solo se entregará a través del canal del proveedor del navegador utilizado más recientemente por el usuario. Si se selecciona la entrega solo a través del canal JPush, se entregarán varios mensajes.

Si el usuario borra la caché y las cookies del navegador, ¿podrá seguir recibiendo Web Push de este sitio web?

Cuando el usuario está en línea, el canal JPush todavía puede recibir push.
En el caso de los canales de los proveedores de navegadores, cuando los usuarios borran las cookies y la caché del navegador, se darán de baja de las notificaciones. Esto se debe a que los datos del usuario suscrito se almacenan en el almacenamiento IndexedDB del navegador. Al eliminar estos datos, el navegador "olvida" al suscriptor. Sin embargo, borrar estos datos no elimina el permiso que el usuario ya había concedido para recibir notificaciones en ese navegador. En este punto, se requiere la inicialización del SDK para que el usuario pueda volver a suscribirse automáticamente cuando regrese al sitio web.
Sin embargo, si el usuario cambia el permiso de notificaciones del navegador a "Ask" o "Block", no volverá a suscribirse automáticamente.
Si el usuario borra las notificaciones desde la configuración de notificaciones del navegador, tampoco volverá a suscribirse automáticamente.

Cómo borrar las notificaciones en cada navegador:

• Chrome: chrome://settings/content/notifications
  

• Firefox: about:preferences#privacy > Permissions > Notifications
  

• Safari: Preferencias > Sitios web > Notificaciones > Eliminar
  

Cuando el usuario vuelva a suscribirse, obtendrá un nuevo registro de Registration ID. Puedes usar window.MTpushInterface.getRegistrationID() para obtener el RID.

Si se envían varios mensajes al mismo usuario al mismo tiempo, ¿se mostrarán todos los mensajes?

El mecanismo de visualización de mensajes varía según el canal push:
Canal EngageLab: No hay mecanismo de sobrescritura. Si se envían varios mensajes al mismo usuario al mismo tiempo, se mostrarán varios mensajes al usuario simultáneamente. El Centro de notificaciones conservará varios mensajes; excepto el mensaje más reciente, los demás se contraerán.
Safari: No hay mecanismo de sobrescritura. Si se envían varios mensajes al mismo usuario al mismo tiempo, se mostrarán varios mensajes al usuario simultáneamente. El Centro de notificaciones conservará varios mensajes; excepto el mensaje más reciente, los demás se contraerán.
Chrome: Tiene un mecanismo de sobrescritura. Si se envían varios mensajes al mismo usuario al mismo tiempo, cada notificación será sustituida por la notificación actualizada y solo se mostrará el último mensaje enviado.
Edge: Tiene un mecanismo de sobrescritura. Si se envían varios mensajes al mismo usuario al mismo tiempo, cada notificación será sustituida por la notificación actualizada y solo se mostrará el último mensaje enviado.
Firefox: Tiene un mecanismo de sobrescritura. Si se envían varios mensajes al mismo usuario al mismo tiempo, cada notificación será sustituida por la notificación actualizada y solo se mostrará el último mensaje enviado.

¿EngageLab WebPush permite cambiar de dominio?

Los navegadores ya han implementado Web Push de una manera que vincula a los suscriptores con un origen específico (nombre de dominio/URL del sitio web).
Por motivos de seguridad y debido a la política del mismo origen del navegador, los navegadores no permiten mover suscriptores a otro origen. Esto no es una limitación de EngageLab. Si algún proveedor afirma que puede mover suscriptores de un sitio web a otro, asegúrate de confirmar que aquello a lo que se están suscribiendo es realmente tu sitio web.
Si has cambiado tu sitio web, la mejor solución es configurar una nueva aplicación WebPush para el nuevo sitio web y hacer que tus usuarios se suscriban al sitio web bajo esta nueva aplicación. No puedes importar suscriptores de un origen a otro.
Puedes seguir enviando notificaciones push a los suscriptores del sitio web antiguo (aplicación WebPush antigua), pero tus usuarios deben volver a suscribirse al nuevo sitio web para recibir push del nuevo dominio. Los pasos de migración recomendados son los siguientes:

• Configura una nueva aplicación WebPush para el nuevo dominio del sitio.
  
• Sigue enviando push desde la aplicación WebPush antigua usando el dominio del sitio antiguo. En la "Launch URL" de la notificación, usa el dominio del sitio nuevo.
  
• Después de entre 2 semanas y 2 meses (según cuántas notificaciones envíes al día y cuántos suscriptores consigas en el nuevo sitio web), puedes dejar de usar la aplicación WebPush antigua y utilizar solo la nueva.
  
• Si envías el mismo mensaje desde la aplicación WebPush antigua y la nueva, los suscriptores de ambas recibirán mensajes duplicados. Por eso recomendamos seguir esta línea temporal.
  
• Puedes enviar varios mensajes como "Nos hemos mudado. Haz clic aquí para visitar nuestro nuevo sitio web y volver a suscribirte para seguir al día". Esto ayudará a recordar a los usuarios que pueden dejar de recibir push de tu sitio web si no vuelven y se suscriben de nuevo. Se recomienda enviar este tipo de notificación al inicio de la migración y con el último mensaje enviado desde la aplicación.
  
• Por desgracia, cada sitio web y cada grupo de usuarios es diferente. Prepárate para perder suscriptores a corto plazo.
  

Al llevar a cabo los pasos de migración anteriores, asegúrate de prestar atención a la experiencia de usuario para evitar inconvenientes.

¿EngageLab WebPush admite push de PWA?

1. ¿Qué es una PWA?

El push de PWA se refiere al proceso de usar tecnología Web Push en Progressive Web Apps (PWA) para enviar notificaciones a los usuarios. Una PWA es una aplicación creada con tecnologías web que ofrece una funcionalidad y una experiencia de usuario similares a las de una aplicación nativa, al mismo tiempo que es accesible a través de un navegador sin necesidad de instalación.
El push de PWA se implementa mediante la tecnología Web Push proporcionada por el navegador. La tecnología Web Push permite que las aplicaciones web envíen notificaciones push como las aplicaciones nativas, incluso cuando la aplicación no está activa o está completamente cerrada.
A diferencia de las aplicaciones tradicionales, las PWA no necesitan descargarse ni instalarse desde una tienda de aplicaciones, y se puede acceder a ellas directamente mediante una URL en el navegador. Al mismo tiempo, el push de PWA puede proporcionar alertas de mensajes oportunas a los usuarios, mejorando la experiencia de usuario y la interacción.
En resumen, el push de PWA es un método para usar tecnología Web Push y enviar notificaciones a los usuarios de Progressive Web Apps, mejorando la interacción y la participación del usuario, al tiempo que proporciona a las aplicaciones web una experiencia de usuario más cercana a la de las aplicaciones nativas.

2. ¿EngageLab WebPush admite push de PWA?

El servicio EngageLab WebPush admite push de PWA. Debes usar el Web SDK proporcionado por EngageLab WebPush para integrar la funcionalidad de Web Push en tu aplicación PWA y seguir el código de ejemplo de la documentación para registrar un Service Worker e inicializar la funcionalidad de Web Push. Una vez completada la integración, puedes usar la API de EngageLab WebPush para enviar notificaciones push a los usuarios de tu aplicación PWA.

Nota: Hay dos condiciones necesarias para que el Web SDK admita PWA:

1. La aplicación se ejecuta en un navegador y el navegador es compatible con las notificaciones W3C.
2. Existe un nombre de dominio específico y utiliza el protocolo HTTPS.

3. ¿Entrará en conflicto el service worker de la PWA con el service worker de EngageLab WebPush?

El service worker de una PWA (Progressive Web App) y el service worker de EngageLab WebPush pueden entrar en conflicto, porque ambos se ejecutan en segundo plano en el navegador y, para un mismo origen, normalmente solo puede haber un service worker activo a la vez.

Los service workers son scripts instalados por los sitios web en el navegador y pueden ofrecer experiencias offline, mensajería push, sincronización en segundo plano y mucho más. Como los service workers controlan las páginas dentro de su ámbito, varios service workers no pueden controlar páginas simultáneamente bajo el mismo ámbito.

Si intentas registrar varios service workers bajo la misma aplicación o dominio, el que se registre después puede sustituir al anterior, o pueden producirse conflictos cuando los ámbitos de ambos service workers se solapen. Este conflicto puede provocar comportamientos inesperados, como que la mensajería push funcione correctamente solo a través de un canal.

Para evitar este conflicto, puedes:

1. Asegurarte de usar un único service worker en tu aplicación. Si la funcionalidad Web Push proporcionada por EngageLab y la funcionalidad de tu PWA pueden implementarse mediante el mismo service worker, lo mejor es combinarlas en un único script de service worker.

2. Si necesitas usar dos service workers independientes, debes asegurarte de que sus ámbitos no se solapen. Esto puede lograrse especificando rutas de ámbito diferentes al registrar los service workers.

Antes de la implementación, se recomienda leer detenidamente la documentación pertinente y realizar pruebas suficientes tanto en entornos de desarrollo como de producción para garantizar que los service workers puedan coexistir sin interferir entre sí.

4. Diferencias en el comportamiento de la ventana emergente de permisos de notificaciones de apps PWA en dispositivos iOS y Android

• Restricciones del sistema iOS (política de Safari/WebKit):
  · Por motivos de privacidad, iOS requiere una acción del usuario (como un clic) antes de que pueda activarse una ventana emergente de permisos.
  · Esta es una política obligatoria de WebKit y se aplica a todas las PWA y aplicaciones web.
  · Después de instalar una PWA por primera vez, sigue siendo necesaria la interacción del usuario antes de solicitar permisos.

• Características del sistema Android:
  · Chrome/WebView permite solicitar permisos automáticamente cuando se carga la página.
  · Sigue un modelo de solicitud de permisos más flexible.
  · Algunas versiones de Android incluso admiten solicitudes de permisos progresivas.

¿Por qué el Registration ID puede ser el mismo en distintos navegadores?

Respuesta: Para el mismo nombre de dominio integrado configurado para una aplicación y el mismo usuario userStr, se generará el mismo RID, independientemente de si se trata del mismo navegador.

• Para comprobar si es el mismo usuario, usa el siguiente método: consulta el código fuente HTML y busca la función de inicialización.

              
              // Registre los detectores de eventos antes de la inicialización
// Devolución de llamada cuando se desconecta el canal JPush
MTpushInterface.mtPush.onDisconnect(function () {
  console.log("onDisconnect");
});

// Recibir mensajes push (web push, canal del proveedor del navegador)
MTpushInterface.onMsgReceive((msgData) => {
  // Estructura de datos de msgData {data:{xxx},type:0} type:0 es el canal JPush, 1 es el canal del sistema
  console.log("Mensaje push recibido:", msgData);
});

// Inicialización push
MTpushInterface.init({
  appkey: "", // Obligatorio. Consulta arriba cómo obtener la información de la aplicación
  user_str: visitorId, // Obligatorio. Identificador de usuario utilizado para identificar al usuario
  fail(err) {
    console.log("Error al crear el push en línea", err);
  },
  success(data) {
    console.log("Push en línea creado correctamente", data);
  },
  webPushcallback(code, tip) {
    console.log("Código de estado y mensaje recibidos por el usuario", code, tip);
  },
  swUrl: '', // Predeterminado "/sw.min." + sdkEnv.version + ".js". Este elemento de configuración es la dirección del archivo service worker. El nombre de dominio debe ser el dominio actual y la ruta determina el ámbito del service worker.
  canGetInfo(data) {
    // En este momento, puedes obtener algunos datos de configuración de notificaciones y, después de esta función de devolución de llamada, puedes obtener el RegId
    console.log(data); // Información de configuración relacionada
    console.log("Obtener RegId", MTpushInterface.getRegistrationID());
  },
  custom: (fuc) => {
    // Al usar una configuración de solicitud personalizada, debes llamar manualmente a fuc() para solicitar permiso de notificación.
    // La función para solicitar permiso de notificación solo puede obtenerse mediante custom.
    // Llamar a fuc() solicitará permiso de notificación
  },
});

            

Si encuentras cualquier problema durante el uso que no esté cubierto en este documento, no dudes en ponerte en contacto con nosotros en cualquier momento. Te proporcionaremos soporte profesional y respuestas.