Archivo para la categoría "iPhone"
Notificaciones ‘push’ en dispositivos móviles
¿Qué es una notificación push?
Es un mensaje que una aplicación servidora envía a una aplicación cliente indicándole que tiene algún tipo de información nueva disponible. Lo que distingue a las notificaciones push es que el servidor inicia la comunicación, no espera a que el cliente pregunte si hay algo nuevo. La ventaja es la inmediatez: la información llega al cliente (y por tanto al usuario) en cuanto está disponible en el servidor.
El ejemplo más clásico de este tipo de notificaciones es el correo electrónico. Un usuario tiene una aplicación de correo electrónico ejecutándose en su dispositivo. Alguien le envía un correo, que queda almacenado en el servidor. A partir de ahí pueden ocurrir dos cosas:
- El cliente de correo electrónico está configurado para consultar al servidor, con una frecuencia predeterminada, si hay nuevos correos. Si la frecuencia es de una vez cada 5 minutos el usuario puede tardar ese tiempo en enterarse de que ha recibido un correo nuevo.
- El cliente (y el servidor) soportan notificaciones push. En este caso el servidor envía un mensaje al cliente para avisarle de que ha llegado un nuevo correo, y el cliente a su vez se lo notifica de alguna forma al usuario para que lo lea si le interesa.
En el caso de las aplicaciones de mensajería instantánea la necesidad de la inmediatez es aún más manifiesta: para que la conversación sea fluida necesitamos que los mensajes nos lleguen en cuanto son enviados, e incluso queremos saber cuándo nuestro interlocutor está escribiendo algo.
¿Cómo se implementa una notificación push?
La manera habitual de implementar una notificación push es establecer una conexión TCP de larga duración. El cliente abre una conexión TCP con el servidor y la deja abierta. Sobre esta conexión TCP el servidor enviará las notificaciones al cliente, usando algún protocolo de aplicación. IMAP y XMPP son ejemplos de protocolos estándar usados para correo y mensajería respectivamente, aunque existen múltiples protocolos propietarios.
Notificaciones push en BlackBerry
El éxito de las BlackBerry se debe en parte a su sistema de push email. Cuando leer el correo desde el móvil era una experiencia dolorosa en otros sistemas, las BlackBerry ya conseguían que sus usuarios recibiesen el correo de manera instantánea. RIM subscribe un acuerdo con los operadores de telefonía, por el cual se establece una conexión permanente con unos servidores especiales operados por RIM. Estos servidores reciben el correo del usuario desde los servidores BES, y lo notifican de forma inmediata a las BlackBerry.
La tecnología de notificaciones push de RIM está disponible para terceros a través de la BlackBerry Push API.
Notificaciones push en iPhone
Apple incorporó desde el principio un sistema de notificaciones push para el correo electrónico de Yahoo. La aparición de MobileMe añadió notificaciones push tanto para el correo como para el calendario y los contactos.
Cuando Apple diseñó la SDK del iPhone tomó la decisión de no permitir a los desarrolladores crear aplicaciones que se ejecutasen en segundo plano. Como consecuencia, las aplicaciones desarrolladas por terceros sólo se ejecutan mientras están en primer plano, deteniéndose cuando el usuario quiere realizar otra actividad.
La nueva versión de la SDK incorpora el Apple Push Notification service, un servicio que envía notificaciones a las aplicaciones del iPhone aunque estas no se estén ejecutando. Para ello la notificación pasa primero por los servidores de Apple, con los que el móvil mantiene siempre una conexión abierta. La notificación se envía al móvil y se muestra al usuario como un mensaje de texto o como una ventana de notificación, que servirán además para lanzar la aplicación y procesar la notificación recibida.
Notificaciones push en Android
Android proporciona notificaciones push para el correo electrónico, calendario y contactos, tanto en el HTC Dream como en el HTC Magic. Como en los casos anteriores, el sistema establece un canal siempre abierto con los los servidores del proveedor (en este caso Google).
Aunque los desarrolladores de Android tienen la opción de programar aplicaciones que se ejecuten en segundo plano el sistema se reserva el derecho de detener cualquier aplicación cuando así lo decida, en función de los recursos disponibles en la máquina. Así que podemos desarrollar un cliente que mantenga conexiones TCP de larga duración con el servidor ejecutándose en bakcground, pero no podemos garantizar que la aplicación se esté ejecutando para mantener esta conexión abierta. Claro que este problema se presenta aunque queramos traernos la información usando pull, es decir, consultando al servidor de periódicamente.
En las versiones beta de la SDK se incluía un servicio llamada XMPPService o GTalkService, que permitía a los desarrolladores enviar notificaciones utilizando la infraestructura de Google Talk. Este servicio fue retirado de la versión final de la SDK por problemas de seguridad, como se explica aquí: Some information on APIs removed in the Android 0.9 SDK beta. No sería extraño que Google incluyese una versión mejorada en alguna de las próximas versiones de Android.
Los problemas de desarrollar para el iPhone
El iPhone 3G has sido sin duda la estrella tecnológica del verano. Eso es bueno para Apple, pero probablemente también para los usuarios que deseen utilizar su móvil para navegar por Internet, y por dos motivos. Uno, ha estimulado a las operadoras para competir, aunque tímidamente, con sus tarifas de datos. Dos, presiona a los fabricantes para que las características de sus nuevos modelos de gama alta estén a la altura del iPhone. Es decir, pantallas grandes e interfaces intuitivas.
Para los desarrolladores la aparición del iPhone y su SDK ha venido acompañada de cierta polémica, causada por las estrictas condiciones impuestas en la licencia de uso de la SDK. ¿Beneficia o perjudica al desarrollador la actitud de Apple?
La App Store
La única manera de instalar legalmente un 
programa en un iPhone es a través de la App Store. El desarrollador envía la aplicación finalizada a Apple, quien decide si la publica o no, basándose en criterios no del todo claros. Antonio Ortiz menciona varios ejemplos en Apple e iPhone, el paradigma de la plataforma cerrada. La clave en este caso está en el éxito de la plataforma: la demanda del consumidor final obliga a los desarrolladores a seguir trabajando sobre el iPhone, pese a que Apple impide la competencia con su propio software.
Una aplicación a la vez, por favor
No se permite más de una aplicación ejecutándose a la vez, y las aplicaciones de terceros no pueden ejecutarse en segundo plano. Con esta restricción Apple se evita un montón de problemas de duración de la batería, a costa de hacer volver a los programadores a los tiempos de la multitarea cooperativa. Además de tener que garantizar el buen funcionamiento de la aplicación cuando otra aplicación reemplace su lugar, no será posible diseñar programas que se ejecuten en el escritorio o que esperen aletargadas a la espera de algún evento. Es casi lógico que no exista la funcionalidad de copiar y pegar si las aplicaciones no van a poder utilizarla.
Conclusiones
Apple ha diseñado un sistema pensado como teléfono móvil, reproductor multimedia y plataforma para juegos. Precisamente los videojuegos son el tipo de aplicaciones que menos sufre las restricciones de la plataforma. Para el resto de cosas siempre quedará la web.
Ninguna plataforma puede ofrecerlo todo, y esta es la propuesta de Apple. Veremos qué proponen Google, Nokia y Microsoft en los próximos meses.
