Bitácora de Javier Cancela

Posts Tagged ‘iPhone

Notificaciones ‘push’ en dispositivos móviles

¿Qué es una notificación push?

Jeff Henshaw: Apples Push Notification Service

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

indivisualist - 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.

Written by Javier Cancela

13 \13\UTC julio \13\UTC 2009 at 7:00

Los problemas de desarrollar para el iPhone

iphone, de shapeshift 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 iPhone SDK, por Dekuwaprograma 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.

Written by Javier Cancela

21 \21\UTC septiembre \21\UTC 2008 at 17:14

Publicado en iPhone

Tagged with ,

¿Cuándo es antiguo un móvil?

Un lector del blog me ha escrito un correo a una de las cuentas de Ipoki y me ha hecho pensar en un par de cosas.

Primero, en que no tenía formulario de contacto. El plugin cformsII para WordPress se ha encargado de arreglarlo.

Segundo, en lo difícil que resulta decidir cuándo un móvil es “antiguo”. El correo hablaba de la dificultad de trabajar con números en punto flotante(1) en móviles con CLDC 1.0, ya que no hay soporte nativo. Estos móviles no tienen hardware dedicado a trabajar con punto flotante y las emulaciones por software son excesivamente lentas. El caso es que, pese a ser móviles antiguos (creo el último de Nokia con CLDC 1.0 es el 3230 y es del 2004), todavía existe un número importante de ellos en uso.

Así que la pregunta es: ¿cuándo compensa tener en cuenta estos móviles en el desarrollo? Mi respuesta: nunca. No debemos ser tímidos a la hora de descartar dispositivos por su antigüedad, ya que el número de potenciales usuarios perdidos disminuye con el tiempo, y a mucha velocidad. Preocuparnos de cómo hacer que algo funcione en un dispositivo de hace tres años consumirá recursos que estarán mejor empleados en una versión para el iPhone, o para S60 3rd Ed. FP2, o para Android. Si es posible que funcione en mi viejo N70 con algunos cambios menores, estupendo. Pero los dispositivos más recientes proporcionan formas cada vez más cómodas y eficaces de hacer las cosas, y generalmente no vale la pena tomarse el trabajo de pensar cómo hacer las mismas cosas para teléfonos de una generación anterior. Hablo por supuesto de desarrolladores amateurs, o de autónomos o pequeñas empresas. Las empresas grandes (o veteranas) tienen herramientas, recursos y metodologías para sacar el último juego Java para un montón de modelos distintos y rentabilizar el desarrollo. Pero no es mi caso, e imagino que tampoco el da la mayoría de lectores de este blog.

(1) Realmente en español lo correcto es “coma flotante”, pero no puedo evitar que me suene raro. Históricamente el punto es utilizado sobre todo en el mundo anglosajón, con la coma siendo la norma en Europa y Sudamérica, entre otros sitios. Imagino que la influencia de Internet acabará decantando la balanza a favor del punto.

Written by Javier Cancela

1 \01\UTC abril \01\UTC 2008 at 20:41

Publicado en Varios

Tagged with , , , ,

Primeras impresiones sobre la SDK del iPhone

Con algo de retraso, algunas ideas sobre el anuncio de Apple:

  • Sólo Mac OS X v10.5. Nada de desarrollo sobre Windows o Linux, ni siquiera sobre Tiger. Supongo que tiene sentido, pero aún así es una lástima para los que no tenemos (ni planeamos tener) un Mac.
  • Aplicaciones sandbox. Nada de interaccionar con otras aplicaciones. Nada de ejecutarse en segundo plano.
  • Distribución de aplicaciones sólo a través de Apple. Lo que garantiza que sólo se distribuyan aplicaciones ortodoxas, que hagan uso sólo de las APIs oficiales de la manera aprobada por Apple.
  • Lo importante es el negocio. Y para demostrarlo, con la SDK se presentaron videojuegos y correo push. El iPhone como sustituto de BlackBerry y NintendoDS a la vez.

De momento la SDK está en beta, y sólo disponible desde estados unidos. A ver si en los próximos días va apareciendo más información para hacer un comentario algo más técnico.

Written by Javier Cancela

8 \08\UTC marzo \08\UTC 2008 at 18:02

Publicado en Noticias

Tagged with ,

Nueva fecha para la SDK del iPhone: el 6 de Marzo

Al menos eso es lo que se deduce de una invitación que varios periodistas (Apple to talk iPhone software plans on March 6, Apple event confirmed for March 6th for the “iPhone software roadmap”) han recibido para un evento que Apple celebrará en esa fecha, y en el que presentará sus planes para el software del iPhone, incluyendo la SDK y “algunas nuevas y excitantes caracterísitcas empresariales”.

Impacientes estamos.

Written by Javier Cancela

28 \28\UTC febrero \28\UTC 2008 at 10:57

Publicado en Noticias

Tagged with ,

Debate en la red sobre el futuro de las aplicaciones móviles

Una entrada publicada por Michael Mace, un consultor especializado en tecnología móvil, ha provocado un intenso debate sobre el futuro de las aplicaciones nativas para móviles. La entrada se titula Mobile applications, RIP, y comienza con un resumen que traduzco a continuación:

El negocio de  hacer aplicaciones nativas para dispositivos móviles está muriendo, aplastado por un mercado fragmentado y prácticas de negocio restrictivas. Los problemas son tan graves que la web móvil, pese a sus muchas deficiencias técnicas, es ahora una forma mejor de proporcionar nueva funcionalidad a los móviles. Creo que esto conducirá a un rápido auge del desarrollo de la web móvil, reemplazando en gran parte al negocio de las aplicaciones móviles. Esto tiene enormes implicaciones para los operadores móviles, los fabricantes de dispositivos, los desarrolladores y los usuarios.

Mace vivió el auge y caída de Palm desde dentro, y percibe que se ha llegado a un punto en el que la falta de modelo de negocio de las aplicaciones nativas moverá gran parte de las aplicaciones a la web, técnicamente inferior pero con un modelo de negocio superior.

El artículo ha provocado respuestas de varios bloggers del mundo del desarrollo móvil. Mike Rowehl de Mowser está básicamente de acuerdo (Native Mobile Apps vs Mobile Web Apps) en esa tendencia hacia la web, aunque precisa que lo mismo ocurre con los ordenadores personales y las aplicaciones de escritorio. Simon Judge opina (Mobile Apps vs Web) que el modelo de negocio tradicional está efectivamente muerto, pero hay sitio para modelos alternativos como las aplicaciones nativas con publicidad integrada. Menos convencido se muestra Rafe Blandford, de allaboutsymbian.com, que considera (The future of mobile development?) que lo importante es que en el futuro los usuarios accederán a las aplicaciones de una manera uniforme, sin ser plenamente conscientes de si están accediendo a algo nativo o algo web. El que más se opone a la decadencia de las aplicaciones nativas es David Beers, otro veterano de Palm, para el cual (Have mobile apps had their moment?) a este tipo de aplicaciones les espera una época de esplendor, provocado, entre otras cosas, por los servicios basados en localización (LBS) y la creciente percepción por parte de los usuarios de que los dispositivos móviles son realmente una plataforma para ejecutar aplicaciones.

El debate todavía continúa, constituyendo un interesante ejemplo de conversación a través de blogs, tanto a través de los comentarios como con enlaces entre entradas que se contestan entre sí.

Mi opinión sobre el asunto: el iPhone y Android van a ser dos factores determinantes. Si alguna plataforma con un modelo de programación razonablemente abierto  gana una importante cuota de mercado arrastrará a la competencia hacia el mismo modelo. El iPhone está teniendo un gran éxito comercial, pero falta ver cómo de abierta es su SDK; Android plantea una plataforma muy abierta, pero está por ver que consiga una cuota de mercado significativa. Pero si Android tiene la mitad de éxito que el iPhone, y Apple libera una SDK la mitad de abierta que la de Android, a las aplicaciones nativas para móviles les espera una época dorada.

Written by Javier Cancela

26 \26\UTC febrero \26\UTC 2008 at 16:26

Publicado en Web móvil

Tagged with , , , ,

Seguridad y libertad en la telefonía móvil

Varios medios de comunicación se han hecho eco (News.com, Reuters UK, MobileCrunch) de unas declaraciones del jefe de investigación de F-Secure, Mikko Hypponen, durante el pasado Mobile World Congress de Barcelona. En ellas alertaba del peligro que una plataforma abierta como Android puede suponer para la seguridad de los dispositivos móviles. Traduzco:

Si Android se convierte en una plataforma totalmente abierta… y cuando una plataforma así se vuelve más común, los riesgos son más grandes que con las actuales plataformas reina como Symbian.

En el mismo evento McAfee presentó un estudio realizado a dos mil usuarios de telefonía móvil, según el cual tres de cada cuatro usuarios estaban preocupados por la seguridad de los nuevos servicios móviles, y uno de cada siete había sufrido un virus para móviles o conocía a alguien que lo había hecho. Su vicepresidente, Victor Kouznetsov, declaró:

Los miedos de los consumidores crecen a la vez que se incrementan las funcionalidades móviles.

No he podido evitar pensar en el paralelismo existente entre este discurso y el tipo de mensaje, cada vez más habitual en Europa y Estados Unidos, que algunos políticos utilizan para hablar de terrorismo y delincuencia. Dicho mensaje se resume más o menos así: las sociedades libres están cada vez más amenazadas por peligros externos, y es responsabilidad de los líderes de dichas estas sociedades hacer todo lo que sea necesario para protegerlas. Consecuencia: el abandono de la libertad como valor irrenunciable de la sociedad en favor de la seguridad. Libertad y seguridad son valores que se oponen, al menos en este ámbito, y al menos mientras confiemos en que los que restringen nuestra libertad lo hacen por nuestra seguridad. Y por lo que parece no hay límite a la cantidad de libertad que estamos dispuestos a cambiar por (supuesta) seguridad.

Esta oposición libertad-seguridad puede que exista en la sociedad civil, pero no hay ningún motivo para pensar que exista en el mundo tecnológico. En este las opciones libres se han caracterizado hasta ahora por ser tanto o más seguras que las opciones restrictivas. Si los problemas de seguridad existentes en Linux son inferiores a aquellos existentes en Windows, ¿qué lleva a F-Secure y a McAfee a pensar que Android será más vulnerable a virus y troyanos que Symbian?

Para ser honesto, el paralelismo Linux vs. Windows con Android vs. Symbian no es total. La diferencia entre Android y Symbian no es que el código fuente de uno sea abierto y el otro no, o que uno sea gratis y otro de pago. La diferencia fundamental es que Android será una plataforma sobre la que programar y desarrollar servicios libremente, que espera tener una comunidad de desarrolladores que aporte aplicaciones de calidad de forma similar a lo que ocurre en el mundo GNU/Linux. Symbian, por otro lado, pone impedimentos a que las aplicaciones de la comunidad libre (e incluso de programadores profesionales pero con recursos limitados) se extiendan entre sus dispositivos, utilizando un sistema de firma de aplicaciones caro y complicado. El razonamiento detrás de esta estrategia es: si es difícil que cualquiera desarrolle una aplicación para Symbian, entonces es difícil que alguien introduzca un virus o un troyano en los dispositivos Symbian.

Se me ocurren algunas objeciones a este planteamiento. La percepción del teléfono móvil como aparato que sirve básicamente para hablar por teléfono probablemente tenga los días contados. Algunas aplicaciones se han ido añadiendo de forma natural, como el envío de mensajes y la capacidad para sacar fotos, de forma que consideramos los SMS como algo propio del teléfono móvil y hablamos de la cámara del móvil como un añadido natural a este dispositivo. Sin embargo el futuro parece pasar más bien por un dispositivo portátil que vaya incorporando cada vez más funciones; algunas, como el GPS, parecen estar haciéndose ya un hueco en los dispositivos de gama alta; otras, como la televisión, ya son perfectamente comunes en Japón, mercado que nos lleva algunos años de adelanto. Con estas expectativas, una plataforma capaz de atraer todo tipo de servicios innovadores, permitiendo que sea la demanda de los usuarios la que decida qué servicios triunfan, presenta más posibilidades de supervivencia a largo plazo que otra que limite la capacidad de innovación.

Apple ha intentado hacer del iPhone un dispositivo cerrado y ha sido víctima del éxito de su producto: inmediatamente han aparecido parches para abrir el sistema, parches que pese a suponer cierto riesgo de inutilizar el aparato han tenido un uso masivo. Esta situación de dispositivo “cerrado pero no” es la que más fácil se lo pone a potenciales creadores de malware. En cuanto a Nokia, la situación no es mucho mejor: las posibilidades de la plataforma S60 quedan ocultas tras las complicaciones del proceso de firma de aplicaciones, pese a que programadores como Samir han mostrado que los usuarios están dispuestos ha emplear tiempo y esfuerzo a cambio de un poco de innovación en sus móviles.

¿Triunfará la plataforma Android? Eso nadie lo sabe aún. El mercado de la telefonía móvil es muy dinámico y complejo, y ni todo el respaldo de Google puede garantizar el éxito de algo que va a necesitar el apoyo de los fabricantes de dispositivos, las operadoras de telefonía, los desarrolladores de software y, por supuesto, los usuarios. Sin embargo, una cosa sí tengo clara: ser una plataforma abierta jugará en su favor.

Written by Javier Cancela

21 \21\UTC febrero \21\UTC 2008 at 13:11

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.