Es fácil encontrar en las aplicaciones móviles las necesidades de actualización de datos en -pseudo- tiempo real. La idea está clara: quiero que mi aplicación se entere de un suceso en el instante justo en que sucede… tipo Facebook, GMail… – aunque con cierto margen de error 
– . Y aquí es donde empiezan los problemas: ¿cómo hacer esto?
Desde hace tiempo se optó por la vía más directa para implementar esta solución, llamada Polling (encuesta). Al menos es una alternativa muy utilizada ya que minimiza los dolores de cabeza a los desarrolladores. ¿En qué consiste?
En caso de Polling la aplicación interroga periódicamente al servidor, acosándolo continuamente, para saber si existen nuevos datos disponibles. Esta solución es fácil de implementar, pero a efectos prácticos es como si cada vez que necesitamos saber si hemos recibido una 
postal tuvieramos que pasarnos por correos – y molestar a nuestro amigo funcionario -. ¿Fácil? Si, pero ineficiente…tanto para el cliente como para el funcionario…perdón, servidor!
Entrando en el mundo de las aplicaciones móviles el impacto es grande, sólo hay que ver los siguientes datos aproximados:
- Consumo medio del dispositivo en modo normal (sin conexiones, ni actividad, ni llamadas, ni conexión de ningún tipo): 7mA (miliAmperios)
- Consumo por uso de red: 200mA (ojo, envíar datos consume mucho más que enviar! )
- Consumo en modo Polling cada 5 minutos: 144mA / día
- Consumo en modo Polling cada 15 minutos: 48mA / día
Como dato, teniendo en cuenta que una batería proporciona unos 1000mAH – de media, hay mejores y peores -, vemos que disponer de una App encuestando cada 5 minutos nos puede consumir en un día aproximadamente el 10% de la batería…¡una única aplicación! Si tenemos en cuenta que podemos tener más de 15 activas…calculemos, y el resultado es un usuario que desinstalará nuestra aplicación en cuanto sea posible.
Entonces, ¿cómo se encuentra el equilibrio entre datos lo más actualizados posible y eficiencia de la aplicación? Para esto 
tenemos la tecnología PUSH: oye, servidor, te informo que necesito los datos en cuanto estén disponibles, envíamelos lo antes posible! Es decir, en lugar de preguntar de forma ansiosa si hay datos disponibles, el servidor notifica al dispositivo que dispone de nuevos datos. Y eso es todo: el cliente deja una conexión abierta para que el servidor le notifique esta información, así de sencillo.
En más de una ocasión me han preguntado lo mismo: pero, si el servidor y el dispositivo mantienen viva constantemente la conexión, ¿por que debería consumir menos batería? Sencillo: mantener una conexión esmucho más eficiente en ordenes de magnitud que enviar continuamente datos.
Y simplificando, que alternativas tenemos para implementar esta solución en las distintas plataformas -iPhone, iPad, iOS en 
general, Android, Blackberry…-. Aquí hay varias posibles soluciones: frameworks ya existentes para crear toda la comunicación cliente / servidor, pero mi experiencia al tener que customizar estos frameworks me dice que mejor no reinventar la rueda…
Para las plataformas, las soluciones más comunes son:
- iOS: Apple Push Notifications Service
- Android: C2DM (Cloud to Device Messaging)
- BlackBerry: BlackBerry Push Service
- Windows Phone: Microsoft Push Notifications Service
Como se puede ver, en todas las plataformas se aporta este tipo de servicios, previo a realizar el registro del servidor que aportará los datos. Proximamente espero entrar más detalladamente en cada una de ellas para analizar los entresijos y pros y contras. Lo que queda por ver es si realmente se respeta la confidencialidad de los datos, pero eso ya es otra historia…(-:
Related articles
- Aplicaciones para modificar el iPhone (maidenkrystal.wordpress.com)
- Free app brings easy penetration testing to Android (moisesbm.wordpress.com)
- Exploring iOS 5 -Notification Center (allthingzmac.wordpress.com)
- iOS 5.0 Review (dangreco.com)
- Protect Your Phone – Protege Tu Telefono (atropregor.wordpress.com)
- Feature: iOS 5 reviewed: Notifications, iMessages, and iCloud, oh my! (arstechnica.com)
