Probablemente ya sabes que Firebase Cloud Messaging
no solo envía mensajes a dispositivos Android
sino que también dirige notificaciones a través de APNs
o Apple Push Notification services, para comunicarse con dispositivos de iOS.
Creo que vale la pena explicar cómo lo hace
en parte porque es interesante
pero sobre todo porque te puede dar una idea
de lo que debes buscar si algo no funciona.
Exploremos esto en este episodio de Firecasts.
Se necesitan dos cosas para que cualquier servicio
se comunique con APNs.
Primero necesitas un certificado
que básicamente te permite comunicarte con los servidores APNs en primer lugar.
Hoy en día, sé que puedes usar algo como la clave de autenticación de APNs
el cual es conveniente si escribes tu propio código de comunicación.
Pero voy a enfocarme en el certificado por ahora
porque esto es lo que usa Firebase Cloud Messaging.
Segundo, deberás decirle a APNs a qué dispositivo quieres enviar notificación.
Y para eso necesitas un token de dispositivo.
Es en esencia una manera de identificar unívocamente
el dispositivo usando un identificador que solo funcione en tu app.
Este token de dispositivo es algo que típicamente se pide al APNs
desde el dispositivo y que luego es enviado a tu servidor.
Ya que Firebase Cloud Messaging está tomando el papel del servidor aquí
necesita estas dos cosas, el certificado y el token de dispositivo.
Así que uno de los primeros pasos al establecer el Firebase Cloud Messaging
es cargar tu certificado de APNs en formato .p12
en la consola de Firebase.
Esto permitirá al servidor de FCM comunicarse con APNs.
Luego, cuando tu app arranque, el dispositivo solicitará el token a APNs.
Luego se enviará ese token a Firebase Cloud Messaging.
Entonces Firebase Cloud Messaging creará y enviará de vuelta
la copia de un token propio como respuesta al dispositivo.
En este punto, FCM tiene todo lo necesario
para comunicarse con tu dispositivo usando APNs
y ya estás listo para enviar mensajes a través de Firebase Cloud Messaging.
Al igual que con APNs, necesitas dos cosas para hacer solicitudes a través de FCM:
una manera de comunicarte con el servicio y otra para identificar al dispositivo.
Primeramente, en lugar de un certificado, vas a usar una clave de API
que puedes imaginar como una contraseña secreta
para hablarle al servidor de FCM en representación de tu app.
Puedes obtenerla desde la consola de Firebase.
Luego, asumiendo que quieres comunicarte con dispositivos específicos,
necesitarás también el token de FCM que obtendrás de tu cliente.
Estas dos piezas de datos se empaquetan en una notificación
que se envía a Firebase Cloud Messaging.
Así, Firebase puede buscar las entradas que tiene para el dispositivo
que corresponden con el token de dispositivo de FCM,
y verá que estén asociadas con un token APNs.
Y dirá: "Ah, quizás debo dirigir este mensaje a través de APNs
para comunicarme con este dispositivo".
Entonces lo que hará Firebase
es crear una nueva versión APNs de esta notificación
usando el certificado y el token almacenado de su lado.
La nueva notificación se envía a APNs, que notificará al dispositivo iOS,
y la notificación llega finalmente al usuario.
Excelente. Es mucho procesamiento, ¿verdad?
Pero si hay dos cosas que quiero que te lleves de la explicación, es esto.
Primero, gran parte del trabajo ocurre tras bastidores para ti.
La mayor parte no lo necesitas conocer ni preocuparte por nada de esto.
Segundo, llegado a este punto, esto es solo una ordinaria notificación de APNs.
Para el funcionamiento de tu app
esta notificación es como cualquier otra que haya recibido de Apple.
Detengámonos un momento para ver el trabajo
que el dispositivo hace durante este proceso.
Debemos, primero, preguntar a APNs por un token de dispositivo.
Segundo, enviar ese token APNs a FCM.
Y tercero recibir como respuesta un token FCM.
Para obtener un token de dispositivo de APNs
llamas a registerForRemoteNotifications de la manera típica.
Y para los siguientes pasos realmente no necesitas hacer nada
para que todo funcione.
Mientras tu app tenga Firebase habilitado hacemos la mayor parte del trabajo por ti
a través de un truco de method swizzling.
Si eres nuevo en el concepto de method swizzling
es básicamente una manera en que los desarrolladores
agregan funcionalidades a un método ya existente en iOS
a través de una versión del método que luego llama al método original.
Con frecuencia los desarrolladores usan estos métodos particulares
que son parte de la biblioteca estándar de iOS.
Pero en nuestro caso, los usamos para implementar
cualquier delegado de método que hayas escrito.
Así que en nuestra llamada a didRegisterForRemoteNotification
recibimos el token de APNs y lo enviamos al Firebase Cloud Messaging
para obtener un token de dispositivo FCM.
Sinceramente, te he mentido un poquito.
Este token en realidad lo conocemos como InstanceID token
que en teoría puede ser utilizado para identificar tu dispositivo
en otros servicios además de Firebase Cloud Messaging.
Y es por eso que puedes encontrar referencias a InstanceID en nuestro código
y por qué a veces hablamos de un token de registro en la documentación.
Pero para los propósitos de entender FCM
creo que es mejor para ti llamarlo token de dispositivo FCM,
porque básicamente es eso.
También debo apuntar que cambiamos con swizzling
algunos métodos que reciben notificaciones.
Y lo que hacemos básicamente aquí es asegurarnos que registramos
toda información estadística sobre estas notificaciones.
Así es como podemos darte algunas de esas bonitas ¡hey!
30 % de estas notificaciones eran reportes abiertos
que ves en el panel de notificaciones.
Si te siente incómodo con la idea de alguien diversificando tus métodos
te es permitido deshabilitar esta función. Solo debes agregar tu código manualmente
para que haga el trabajo que haríamos. Y tenemos documentación para eso.
Por último, una acotación sobre estos métodos reformados
es que no llamamos automáticamente cualquier cosa que despliegue
ese cuadro de diálogo estándar de iOS
preguntando al usuario si puede mostrar cualquier notificación visible al usuario.
Sabemos que esto es algo que quizás no quieras llamar
a menos que estés muy seguro que el usuario te dirá que sí.
Así que este método queda a tu disposición
para que lo llames al momento que sea conveniente para tu app.
Claro, ahora que te he dicho esto
no es más que solo una ordinaria notificación de APNs
y no tienes que hacer nada especial para usar Firebase Cloud Messaging.
Notarás en la sección de nuestra documentación
donde pedimos que te conectes explícitamente a Firebase Cloud Messaging.
¿Y a qué se debe eso? Bien, verás
además de poder comunicarte con tu dispositivo a través de APNs
también puedes conectarte a través de Firebase Cloud Messaging
para recibir notificaciones directamente a través del servicio.
Pero hay ciertas restricciones aquí.
Primero y principal, esto solo funciona si tu app está en primer plano.
Segundo, esto solo funciona para mensajes de datos
nada con las claves de "alert", "badge", "sound", ni nada por el estilo.
Tampoco funciona con "content-available". Esos siempre deben ir a APNs.
De hecho, en territorio de APNs, no creo que puedas enviar
una notificación silenciosa que no tenga "content-available".
Este tipo de mensaje solo es válido en Firebase Cloud Messaging,
es lo que puedo decir por los momentos. Así que si envías ese tipo de notificación
y tu app no está en primer plano y no se ha conectado explícitamente a FCM
no se va a recibir este mensaje hasta que te reconectes.
Así que la pregunta que debes tener es por qué querrías hacer esto.
Comunicarse directamente a través de Firebase Cloud Messaging
tiene algunas ventajas. Una de ellas
FCM tiende a ser más agresivo al llevar estos mensajes al dispositivo destino.
Otra, solo son pocos saltos los que da tu mensaje, lo cual es bueno.
Y también, tu dispositivo puede devolver mensajes de vuelta a través de FCM
para hacerte saber, por ejemplo, que este mensaje ha sido recibido.
Pero como solo trabaja con apps en primer plano
los casos de uso casi están limitados a apps que generalmente aceptan
no recibir estas notificaciones en el segundo plano.
¿Un buen ejemplo? YouTube. Su app para iOS usa la conexión FCM
para el envío del chat en los eventos de YouTube Live.
Ya que el gran trabajo de esta app es sobre todo manejar la avalancha
de mensajes del chat cuando está en primer plano
es un buen caso de uso para Firebase Cloud Messaging.
Pero si no crees que tu app va a necesitar este tipo de mensajes
te recomiendo no conectarte al servicio de FCM directamente
al menos hasta que tengas al resto de Firebase Cloud Messaging funcionando.
Es un factor adicional del que preocuparse
cuando estás resolviendo problemas en tu implementación de APNs.
Ya lo tienes. Así es como FCM trabaja con dispositivos iOS
en una explicación muy, muy breve.
Espero que esto te dé un poco más de idea de lo que ocurre tras de bastidores.
Y si encuentras este video útil, asegúrate de suscribirte.
Te veremos pronto en otro episodio de Firecasts.
Muchas gracias por vernos.
¿Quieres más contenido interesante de Firebase?
Bien, revisa estos videos aquí.
¡Manos de jazz!