Notificación push iOS con aplicaciones muertas – swift

Estoy desarrollando un chat iOS con notifications push y uso Firebase Cloud Messaging, pero tengo este problema:

Cuando la aplicación se mata (no en segundo plano), hay una forma de get una callback de la notificación para get el contenido (el post de chat)?

La única forma de get un post y savelo en la database interna es verificar en mi server cuando inicio la aplicación si hay un post no leído.

El documentantion de Firebase no parece muy claro en este argumento. Solo si envío una notificación silenciosa (sin el campo "notificación"), la aplicación didReceiveRemoteNotification callback se llamó cuando abro la aplicación, pero solo puedo recibir la última notificación. Esta callback no se llama en segundo plano

ACTUALIZACIÓN 12/02/2016:

Después de muchas testings, contacté con el soporte de Apple y me han respondido con este correo electrónico:

Estoy respondiendo a tu pregunta sobre las notifications push de background.

Este tema se discutió por primera vez en la session WWDC 2013 204 WWDC 2013: ¿Qué hay de nuevo con la multitarea? Las notifications push silenciosas (aquellas cuyas cargas útiles contienen solo la key de contenido disponible y sin alerta, distintivo o teclas de sonido) se aceleran para que se entreguen solo cuando iOS determina que es eficiente en términos de energía hacerlo.

Las notifications push con las teclas visibles por el usuario, como la alerta, el sonido o la insignia enviada con alta prioridad (prioridad 10) siempre se muestran. Sin embargo, si la notificación también contiene la key de contenido disponible, la notificación se puede acelerar y, por lo tanto, no se enviará a la aplicación en segundo plano a less que el usuario toque la notificación.

Las notifications enviadas con baja prioridad (prioridad 5) se aceleran, independientemente de la carga. Las notifications push silentes siempre deben enviarse con poca prioridad.

Como dice la session WWDC, puede esperar hasta varias notifications push silenciosas por hora en todas las aplicaciones de un dispositivo. Pero es completamente posible y apropiado que no reciba ninguno.

El propósito del acelerador es pnetworkingecir cuándo el usuario lanzará una aplicación y, por lo tanto, permitirá que la actividad de background actualice el contenido de la aplicación de una manera eficiente de la energía. También sirve para evitar que las aplicaciones consumn demasiada batería o datos celulares del usuario con tráfico de background.

Una vez agotados los presupuestos de batería o datos de todo el dispositivo, no se enviarán más notifications de background hasta que se reinicien los presupuestos. Los presupuestos se restablecen cada 24 horas, y este progtwig no puede ser modificado por la acción del usuario o desarrollador.

Dado que estos presupuestos se aplican a todas las aplicaciones en un dispositivo, es posible que una aplicación que no sea la suya agote los presupuestos. Puede verificar el uso general de la batería de una aplicación en Configuración> General> Uso> Uso de batería.

El acelerador también rastrea cuando el dispositivo tiene poca conectividad de networking, ya que los bashs repetidos de conectarse a los APN cuando la conectividad de la networking es irregular pueden causar una importante descarga de energía. Esta es la razón más común por la que las notifications push no llegan a un dispositivo. Para verificar si la mala conectividad de networking está afectando sus notifications push, puede usar los pasos en Observación de posts de estado push.

El acelerador está deshabilitado si ejecutas tu aplicación con un depurador conectado. Esto le permite probar que sus notifications se reciben correctamente, pero solo debe considerarse el mejor escenario.

Además, a partir de iOS 9, los usuarios tienen la capacidad de activar el acelerador en cualquier momento que deseen al activar el modo de bajo consumo en Configuración> Batería.

Para probar notifications push de background, sigue estos pasos.

  1. Conecte su dispositivo a su Mac.
  2. Comienza tu aplicación desde Xcode.
  3. Cuando se haya iniciado, detenga su aplicación desde Xcode haciendo clic en el button Detener (icono cuadrado en la esquina superior izquierda).
  4. En Xcode, haga Depurar -> Adjuntar al process -> [Rellene el nombre del process para esperar] -> Adjuntar
  5. Envía la notificación push con contenido disponible: 1 y tu aplicación recibirá la notificación cada vez.

Puede usar la list de processs en Instrumentos para confirmar que su aplicación se está ejecutando en segundo plano.

También puede probar usando Wi-Fi y un dispositivo que está conectado a la alimentación de la panetworking.

Si envía notifications push en silencio, asegúrese de que está utilizando la API de proveedor APN o la API de proveedor binary para que pueda establecer la prioridad de notificación en 5. (La prioridad pnetworkingeterminada es 10.)

Si crees que la aceleración no funciona correctamente, presenta un informe de error en https://developer.apple.com/bug-reporting . Los detalles de cómo funciona el estrangulamiento no son API públicas, pero iOS Engineering analiza estos informes de errores y puede determinar si las notifications están siendo aceleradas como se esperaba.

El punto importante es que las aplicaciones nunca deben diseñarse esperando que se reciba cada notificación de inserción. Esta no es la forma en que funcionan las APN; está destinado a informar al usuario o a la aplicación que se ha producido algún evento de interés. Se espera que las aplicaciones funcionen correctamente, aunque tal vez con funcionalidad degradada, si no se reciben notifications push. El usuario puede desactivar las notifications push o las actualizaciones de la aplicación de background en cualquier momento y, por supuesto, las notifications push no se recibirán si el dispositivo no tiene conectividad a Internet.

A partir de iOS 7, todas las categorías de background, excepto la location y VoIP (en iOS 9.3 y posteriores) se comportan de forma coherente cuando una fuerza de usuario abandona una aplicación de la pantalla multitarea. Una aplicación no se lanzará de nuevo automáticamente hasta que el usuario opte por volver a iniciarla. Esto respeta la intención del usuario de no tener la aplicación en funcionamiento, lo que puede ser una técnica de recuperación muy importante si una aplicación se porta mal y falla al iniciarse.

Si cierra una aplicación que se ha configurado para recibir notifications en segundo plano, no las recibirá hasta que se haya vuelto a abrir.

Después de este correo electrónico, he intentado enviar una notificación con Telegram asesinado. Telegram recibe la notificación push y la muestra, pero si abro la aplicación después de configurar el modo fuera de línea, el post no se muestra en el chat (¡esto significa que seguramente el server de contacto de telegtwigs verificará el post no leído cuando lo abra!). En cambio, WhatsApp puede agregar un post en segundo plano porque es una aplicación de VoIP y puede llamar a una callback de background.

Entonces, la única forma de agregar un post es contactar al server y get el post no leído.

Existe el mismo problema en Android, pero probablemente puedas solucionarlo con un service en segundo plano (y reiniciarlo cuando sea eliminado).

Ahora tengo que elegir si utilizo notifications Apple Push o notifications push FCM. ¿La confiabilidad es la misma? (Porque, por ejemplo, Telegram en Android usa un service push exclusivo y FCM porque dicen que FCM no es muy confiable)

Las aplicaciones de postría en iOS necesitan verificar el server cuando se inician para recuperar una database local con el estado del server. Las notifications push no son el mecanismo correcto para usar para mantener su database interna iOS sincronizada con su server.