iphone - mail - ¿Puede la mensajería de servidor a cliente depender de APNS?

push mail iphone (2)

He trabajado en esta área por un tiempo y desde mi modesta experiencia, creo que su enfoque para resolver sus problemas no llegará a ninguna parte. Permítanme primero resaltar algunos hechos importantes sobre las características de APN:

Las APN no son confiables, no están 100% garantizadas de llegar al cliente.
A partir de la documentación de Apple, las APN son el mejor esfuerzo , tantas veces que es posible que no lleguen.
Los APN no contienen datos dentro de ellos, por lo que incluso si llegan a su aplicación cliente, no tienen nada dentro de ellos para la aplicación.
Los APN son solo notificaciones para el usuario de que algo relacionado con su aplicación ha ocurrido, mientras que el mensaje (el texto que aparece en el Cuadro de alerta de APN) es manejado por el iOS y no por su aplicación. Esta es la razón por la que los dispositivos con iOS 4 mostrarán el APN de una manera diferente que los dispositivos con iOS 5, es el trabajo del sistema operativo, no su aplicación.
El valor de la insignia que aparece en el icono de su aplicación cuando llegan las notificaciones es responsabilidad de su servidor y no del sistema operativo del dispositivo. Dicho de otro modo, cuando un APN llega al dispositivo, debe tener el nuevo valor de recuento de notificaciones para su aplicación. El sistema operativo no hará nada por esto.

Una vez dicho esto, me gustaría explicar un poco cómo suelen diseñarse esas aplicaciones. En primer lugar, no se realiza mediante las conexiones de URL y los clientes no verifican el servidor cada período de tiempo. Usualmente tiene una arquitectura de cliente / servidor donde su cliente es la aplicación en el dispositivo y el servidor es un programa de servidor real que reside en una máquina servidor. El servidor podría ser Microsoft (usando C # por ejemplo) o MAC (usando Objective C). El servidor tiene una base de datos que almacena información dentro de él. Alguna información importante (relacionada con su pregunta) es el valor de recuento de APN, el mensaje que desea entregar, el estado del cliente si está en línea o fuera de línea.

Cuando a un cliente le gusta enviar algo a otro cliente, o cuando el servidor desea enviar algo a un cliente (o a todo el cliente), se realiza una verificación al cliente receptor para ver si está en línea o fuera de línea. Si está en línea, el mensaje se envía directamente y, por lo general, las comunicaciones se realizan en los sockets TCP. Si el usuario está desconectado, el servidor almacenará el mensaje que debe enviarse al cliente, aumentará el valor del conteo de APN y enviará un APN a ese destinatario. Cuando ese destinatario se conecta, el servidor se dará cuenta de que (porque hay una conexión establecida y un protocolo de enlace) y, por lo tanto, recuperará todos los mensajes no enviados de la base de datos y se los enviará ...

Es un proceso largo, espero poder explicarles un poco las cosas. En todos los casos, no creo que su manera sea práctica o le permita alcanzar un trabajo real.

Estoy trabajando en una aplicación de mensajería y tengo un dilema sobre cómo enviar datos del servidor al cliente.

Estoy usando un diseño de servidor centralizado, donde los clientes usan NSURLConnection para enviar mensajes al servidor, el servidor no guarda y administra los sockets abiertos y no puede enviar un mensaje para uno de los clientes. Entonces los clientes usan un temporizador y consultan el servidor cada 2 segundos para ver si hay nuevos datos esperándolos.

El problema con este enfoque es que sondear el servidor cada 2 segundos parece matar la batería muy rápido, así que pensé que tal vez en lugar de clientes sondear el servidor, usar APNS * para que cuando el servidor tenga información nueva ** para el cliente, el servidor enviará una notificación de inserción * ** al cliente, luego el cliente obtendrá los datos del servidor.

* use APNS : si el cliente lo permite, el cliente puede, por supuesto, desactivar esta opción. Por lo tanto, verificaré si se permite la inserción cada vez que la aplicación ingrese en primer plano y, de no ser así, volveré al método de votación.

** La nueva información puede ser cualquier cosa, desde mensajes de texto hasta mensajes de administrador del servidor. (y hay muchos mensajes de administrador ...)
Por ejemplo, en mi aplicación, los usuarios pueden ver el estado de sus amigos (en línea / fuera de línea), por lo que si user1 y user2 son amigos y user2 solo cambian su estado de online a offline, el servidor debe enviar esta nueva información (admin message = user2_offline ) a usuario1.

*** Los envíos del servidor de notificaciones automáticas están vacíos (sin datos / sonido), es solo un desencadenante para que el cliente obtenga la nueva información, por lo que si se envió un empujón al cliente y la aplicación del cliente estaba cerca, no lo hará. notar cualquier cosa (si la aplicación se está ejecutando, obtendrá la nueva información del servidor)

¿Funcionará este enfoque con una aplicación de mensajería masiva que requiera un uso masivo de notificación push?

Para ser más claro, mis principales preocupaciones son:
1. ¿Es APNS lo suficientemente confiable como para usarlo como mi mecanismo central de mensajería de servidor a cliente?
2. ¿Apple aprobará potencialmente miles o cientos de miles de notificaciones push por día desde mi servidor?

¿Es APNS lo suficientemente confiable como para usarlo como mi mecanismo central de mensajería de servidor a cliente?

NO . Solo por el hecho de estar completo, déjame repetir las razones.

Apple mismo niega la fiabilidad lea la Guía de programación
Además, APNS tiene un componente de QoS que puede aumentar la confiabilidad a costa de ser en tiempo real (por ejemplo, puedo solicitar a APNS que entregue la notificación en cualquier momento dentro de 4 semanas y vuelva a intentar si los dispositivos no son accesibles) lo cual no es útil en su caso .
Según su requerimiento, si envía un impulso silencioso (un impulso sin mensaje visible para el usuario), no puede enviarse como un impulso de ALTA prioridad, lo que disminuye la confiabilidad aún más. Aquí hay una cita relevante
"Las notificaciones silenciosas no son una forma de mantener su aplicación activa en segundo plano, ni están pensadas para actualizaciones de alta prioridad. APN trata las notificaciones silenciosas como de baja prioridad y puede acelerar su entrega por completo si el número total se vuelve excesivo. son dinámicos y pueden cambiar según las condiciones, pero trate de no enviar más de unas pocas notificaciones por hora ".

¿Apple aprobará potencialmente miles o cientos de miles de notificaciones push por día desde mi servidor?

En general, APNS no tendrá ningún problema con esto en términos de carga, pero tiene una regulación en su lugar y podrían limitar sus notificaciones, consulte el punto 3 anterior

En mi humilde opinión, debería mirar a XMPP ya que este protocolo está diseñado solo para casos de uso como el suyo y tienen un amplio respaldo de la comunidad en todas las plataformas. Sugeriré que vea algo como https://github.com/robbiehanson/XMPPFramework y configurará un servidor XMPP en su backend que manejará los mensajes y mensajes de presencia, así como también los de administrador.

Si ya ha evaluado XMPP y no quiere hacerlo, le sugiero que necesite armar un sistema inteligente en la aplicación iOS que emplea diferentes estrategias basadas en el estado de la aplicación, algo así como seguir, puede tener las siguientes estrategias

Enfoque basado en Socket en tiempo real -> Establezca una conexión de socket permanente y mantenga los datos sincronizados tanto como sea posible (Esto es cuando su aplicación se ejecuta en primer plano o en segundo plano)
El sistema de votación del que hablaste en cuestión, que puede utilizarse cuando se invoca tu aplicación para actualizaciones de localización / búsqueda de fondo, etc.
Use APNS con mensajes personalizados del usuario + datos personalizados, cuando su servidor detecte que el dispositivo no tiene un socket activo y que tampoco ha sondeado durante mucho tiempo