Estoy trabajando en una aplicación de mensajería (algo así como WhatsApp) y tengo un dilema sobre la implementación de su funcionalidad principal: enviar un mensaje de client1 a client2.Uso de APN en una aplicación de mensajería
Lo que sucede es que 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, para que los clientes tengan un temporizador y consulten el servidor cada 2 segundos para ver si hay un nuevo mensaje esperándolos.
El problema con este enfoque es que consultar el servidor cada 2 segundos parece matar la batería muy rápido, así que pensé que quizás en vez de que el cliente consultara el servidor, use APNS para que cuando el cliente1 envíe un mensaje al servidor, el servidor enviará una notificación push a client2, luego client2 buscará los datos del servidor.
¿Funcionará este enfoque con una aplicación de mensajería masiva que requiera notificaciones masivas?
"Pero APNS-way (su forma de preferencia) también funcionará cuando el usuario haya abandonado su aplicación". De cualquier manera, estaba planeando usar APNS cuando el usuario está desconectado. Mi principal preocupación es: 1. ¿Es APNS lo suficientemente nuevo como para poder usarlo como mi mecanismo central de mensajes? 2. ¿Apple aprobará potencialmente miles o cientos de miles de notificaciones push al día desde mi servidor? – Eyal
1. Si no rompes la "ley" de Apple (no spam, ni material publicitario), entonces sí. WhatApp y co. también depende de APNS. Y no hay otra manera de hacerlo cuando le gusta recibir mensajes en el modo "sin aplicación en primer plano". 2. Sí. No rechazarán la aplicación debido a la alta carga en el APNS (excepto que el contenido en sus mensajes push no es válido desde la perspectiva de Apple [spam, anuncios, etc.]) –