¿Puede la postría de server a cliente confiar en APNS?

Estoy trabajando en una aplicación de postría y tengo un dilema sobre cómo enviar datos de un server a otro.

Estoy usando un layout de server centralizado, donde los clientes usan NSURLConnection para enviar posts al server, el server no mantiene y administra sockets abiertos y no puede enviar un post para uno de los clientes. Entonces, los clientes usan un timer y consultan el server cada 2 segundos para ver si hay nuevos datos esperándolos.

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

* use APNS – si el cliente lo permite, el cliente, por supuesto, puede deshabilitar esta opción. Por lo tanto, verifico si se permite la inserción cada vez que la aplicación entra en primer plano y, si no, regresaré al enfoque de sondeo.

** La nueva información puede ser cualquier cosa, desde posts de text hasta posts de administración del server. (y hay muchos posts de administrador …)
Por ejemplo, en mi aplicación, los usuarios pueden ver el estado de sus amigos (en línea / sin connection), de modo que si user1 y user2 son amigos, y user2 solo cambia su estado de línea en línea, entonces el server necesita enviar esta nueva información (admin = user2_offline ) al usuario1.

*** Los envíos del server de notifications push están vacíos (sin datos / sonido), es solo un desencadenador para que el cliente obtenga la nueva información, por lo que si se envió un push al cliente y la aplicación del cliente estaba cerca, no lo hará Noten cualquier cosa. (si la aplicación se está ejecutando, entonces obtendrá la nueva información del server)

¿Funcionará este enfoque con una aplicación de postría masiva que requiere usos masivos de notifications push?

Para ser más claras, mis principales preocupaciones son:
1. ¿El APNS es lo suficientemente confiable como para utilizarlo como mi mecanismo principal de postría de server a cliente?
2. ¿Apple aprobará potencialmente miles o cientos de miles de notifications push un día desde mi server?

¿APNS es lo suficientemente confiable como para utilizarlo como mi mecanismo de postría principal de server a cliente?

NO Solo por completar, permítanme repetir por las razones.

  1. Apple se niega a la fiabilidad leer la Guía de progtwigción
  2. Además, APNS tiene un componente de QoS que puede boost la confiabilidad a costa de ser en time real (Por ejemplo, puedo pedirle a APNS que entregue la notificación en cualquier momento dentro de las 4 semanas y vuelva a intentar si los dispositivos no son accesibles) que no es útil en su caso .
  3. Según su requerimiento, si envía un empuje silencioso (un empuje sin post visible para el usuario), no puede enviarse como un impulso de prioridad ALTA que disminuye aún más la fiabilidad. Aquí hay una cita relevante

    "Las notifications silenciosas no tienen la intención de mantener su aplicación despierta en segundo plano, ni están destinadas a actualizaciones de alta prioridad. Las APN tratan las notifications silenciosas como de baja prioridad y pueden estrangular su entrega por completo si el número total se vuelve excesivo. Los límites reales son dynamics y pueden cambiar según las condiciones, pero trate de no enviar más que unas cuantas notifications por hora ".

¿Apple aprobará potencialmente miles o cientos de miles de notifications push diarias desde mi server?

Generalmente, APNS no tendrá ningún problema con esto en términos de carga, pero tiene un estrangulamiento en su lugar y podría estrangular sus notifications, vea el punto 3 anterior

En mi humilde opinión, deberías mirar a XMPP, ya que este protocolo está diseñado solo para casos de uso como el tuyo y tienen un amplio soporte comunitario en todas las plataforms. Te sugeriré que mires algo así como https://github.com/robbiehanson/XMPPFramework y configuras un server XMPP en tu backend que se encargará de los posts de postría y presencia, así como de los posts de administrador.

Si ya ha evaluado XMPP y no quiere seguirlo, le sugiero que cree un sistema inteligente en la aplicación iOS que utiliza diferentes estrategias basadas en App State, algo así como seguir, puede tener las siguientes estrategias

  1. Un enfoque basado en el zócalo en time real -> Establezca una connection de zócalo 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)
  2. El sistema de sondeo del que habló en cuestión, que se puede utilizar cuando se invoca su aplicación para get actualizaciones de background / location, etc.
  3. Use APNS con postría visible del usuario + datos personalizados, cuando su server detecte que el dispositivo no tiene el zócalo activo y tampoco ha sido interrogado por mucho time

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

  1. Los APN no son confiables, no están 100% garantizados para llegar al cliente.
  2. A partir de la documentation de Apple, los APN son el mejor esfuerzo , por lo que muchas veces no llegan.
  3. Los APN no contienen datos dentro de ellos, por lo que incluso si llegan a su aplicación de cliente, no contienen nada dentro de ellos para la aplicación.
  4. Los APN son solo notifications para el usuario de que se ha producido algo relacionado con su aplicación, mientras que el iOS (y el text que aparece en el Cuadro de alertas de APN) no se encarga de su aplicación. Esta es la razón por la que los dispositivos con iOS 4 mostrarán el APN de una manera diferente a los dispositivos con iOS 5, el trabajo del sistema operativo no es su aplicación.
  5. El valor de la tarjeta que aparece en el ícono de la aplicación cuando llegan las notifications es responsabilidad de su server y no del sistema operativo del dispositivo. Dicho de otra manera, cuando un APN llegue al dispositivo, debería venir teniendo el nuevo valor de conteo de notifications para su aplicación. El sistema operativo no hará nada por esto.

Dicho esto, me gustaría explicar un poco cómo suelen diseñarse dichas aplicaciones. En primer lugar, no lo hace URL Connections y los clientes no verifican el server cada período de time. Por lo general, tiene una architecture de cliente / server donde su cliente es la aplicación en el dispositivo y el server es un progtwig de server real que reside en una máquina de server. El server podría ser Microsoft (usando C # por ejemplo) o MAC (usando el Objetivo C). El server tiene una database que almacena información dentro de ella. Alguna información importante (relacionada con su pregunta) es el valor de conteo de APN, el post 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 server quiere enviar algo a un cliente (o a todo el cliente), se hace una comprobación al cliente receptor para ver si está en línea o fuera de línea. Si está en línea, el post se envía directamente y, por lo general, las comunicaciones se realizan en sockets TCP. Si el usuario está fuera de línea, el server almacenará el post que debe enviarse al cliente, boostá el valor del conteo APN y enviará un APN a ese destinatario. Cuando ese destinatario se convierte en línea, el server lo notará (porque hay connection de establecimiento y enlace) y, por lo tanto, obtendrá todos los posts no entregados de la database y se los enviará …

Es un process largo, espero poder explicarte un poco. En todos los casos, no creo que tu path sea práctico o te permita alcanzar un trabajo real.