PastryKit ★

Tuesday, 15 December 2009

Uno de los temas comentados recientemente son las aplicaciones web para el sistema operativo del iPhone — aplicaciones para el iPhone y el iPod Touch creadas usando únicamente HTML, CSS y JavaScript. Concretamente, lo satisfactoria que puede resultar la experiencia ofrecida por una aplicación web para el iPhone, y lo fácil que es desarrollarlas, comparadas con las aplicaciones nativas creadas con Cocoa Touch.

Un aspecto en el que las aplicaciones web para el iPhone salen peor paradas que las aplicaciones nativas es el scroll. Tomemos un ejemplo en el que hay una lista muy larga, como la libreta de direcciones de la aplicación Contactos, o el listado completo de canciones en la aplicación iPod. Cuando haces scroll en estas listas, puedes darle un buen impulso con el dedo, y la lista seguirá desplazándose a gran velocidad al soltar el dedo. El efecto es parecido a girar una rueda con muy poca fricción. Con las aplicaciones web para el iPhone se puede crear una lista que tenga casi el mismo aspecto que una lista nativa del iPhone. Pero en el iPhone, todas las vistas web hacen scroll casi sin inercia. No se les puede dar impulso. Las vistas web en el iPhone dan la impresión de tener muchísima fricción.

Esta fricción puede que tenga sentido en una página web normal renderizada en la pequeña pantalla del iPhone, entendiendo “normal” como “no optimizada específicamente para mostrarse en el iPhone”. Pero se mueve con lentitud — como si estuviera trabada — en aplicaciones web optimizadas para el iPhone.

Si nunca lo habías notado, haz la prueba ahora, comparando por ejemplo la lista que se muestra en la aplicación Contactos con una aplicación web para el iPhone como Showtime. (En Showtime, pulsa “Watchlist” y después el botón “+” para que aparezca una lista bien larga en la que hacer scroll). Otra buena comparativa de los dos tipos de scroll: clientes nativos de Twitter para el iPhone, como Tweetie y Birdfeed, frente a clientes de Twitter para el iPhone creados como aplicaciones web, como por ejemplo Hahlo y el nuevo Mobile Twitter. La diferencia es significativa, y mucho más que estética. Justin Williams escribía hace poco lo siguiente:

Creo que con la actual generación de tecnologías Web disponibles en MobileSafari, aplicaciones como Hahlo, PocketTweets y Showtime podrían tener futuro como alternativa a sus aplicaciones nativas homólogas si Apple permitiera a los programadores ajustar el coeficiente de scroll/arrastre de Mobile WebKit. Si comparas la velocidad de scroll de tu historial de Twitter en Hahlo y en Tweetie, los resultados son radicalmente distintos. Tweetie da la impresión de hacer scroll sin esfuerzo alguno en función del impulso aplicado al realizar el scroll, mientras que Hahlo tiene que luchar constantemente contra el peso de cincuenta kilos que lleva colgado a la espalda.

El scroll no es la única faceta del interfaz o de la experiencia de uso en la que las aplicaciones web no parecen capaces de igualar las capacidades de la aplicaciones nativas para el iPhone. Otro ejemplo es que MobileSafari no permite emplear elementos colocados mediante CSS en una posición fija, lo que significa que no se puede crear una barra de herramientas que permanezca fija en la parte superior o inferior de la pantalla sin que desaparezca al hacer scroll.

Y sólo me he ceñido a aquello que afecta a la experiencia del usuario. La otra faceta está en el desarrollo de aplicaciones. El mes pasado escribí lo siguiente:

Cuando se crea una aplicación para el iPhone con Cocoa Touch, no se parte de cero. Se parte de la plataforma de Cocoa Touch. Faruk Ates escribe en su perspicaz respuesta a Koch que ignorar la plataforma equivale a ignorar todo lo que diferencia al iPhone como plataforma de desarrollo. Las aplicaciones nativas para el iPhone no sólo son más rápidas y capaces que sus aplicaciones web homólogas, sino que además son más fáciles de crear.

Algunos lectores cuestionaron esto, argumentando, más o menos, que sin importar lo buena que sea la plataforma Cocoa Touch, las aplicaciones nativas para el iPhone son más difíciles de programar que las aplicaciones web porque se debe aprender a usar la plataforma de desarrollo de aplicaciones (Cocoa) y un nuevo lenguaje de programación, Objective-C. Pero no es una comparación del todo justa. Es como decir que es más fácil correr que ir en bici porque uno no sabe montar en bicicleta.

Aclaremos las cosas. Dejemos claro que estoy hablando de crear aplicaciones para el iPhone bien diseñadas y que proporcionan una excelente experiencia al usuario. Reconozcamos que, para hacer que cualquier cosa sea genial — en cualquier ámbito, ya se trate de software u otra cosa —, hace falta talento, experiencia y dominar las herramientas necesarias. Si ya eres un desarrollador web experto pero nunca has programado software en Cocoa con anterioridad, entonces sí, tienes por delante ese gran primer paso antes de poder crear una aplicación nativa en Cocoa Touch para el iPhone. Pero, de forma parecida, hay programadores veteranos que han trabajado con Cocoa Mac (y unos cuantos aún más veteranos de los tiempos de NeXT) que no tienen ni idea de crear una aplicación web moderna con funcionalidad AJAX utilizando HTML, CSS y JavaScript — y que piensan que JavaScript es en realidad el lenguaje de programación extraño.

Lo que quiero decir es que los programadores de Cocoa Touch con talento lo tienen más fácil a la hora de implementar una aplicación determinada para el iPhone que los desarrolladores web con talento. La plataforma Cocoa Touch hace muchas cosas por sí sola, o al menos las facilita. Cosas como transiciones fluidas y rápidas de una vista a otra. Cosas como botones y listas y barras de herramientas con el mismo aspecto que cualquier botón, lista o barra de herramientas estándar para el iPhone.

Existen varias plataformas de código abierto para desarrolladores de aplicaciones web para el iPhone, gracias a las cuales no es necesario empezar desde cero para realizar cosas como simular elementos del interfaz de Cocoa Touch. iUI, puesto en marcha por Joe Hewitt unas pocas semanas después de que el iPhone original se pusiera a la venta en Julio de 2007, es una de esas plataformas. jQTouch, creada por David Kaneda y basada en jQuery, es otro ejemplo. (Showtime se ha creado con jQTouch).

Pero estas plataformas no solucionan el problema de la velocidad y la fricción del scroll, o la imposibilidad de utilizar elementos con posición fija.

Después de todo, resulta que hay una empresa que ha creado una plataforma sorprendente para el desarrollo de aplicaciones web para el iPhone, y que permite:

• Ocultar por completo la barra de dirección, incluso al ejecutar la aplicación web desde una página en MobileSafari, en lugar de hacerlo desde un icono guardado junto a las aplicaciones.
• Emplear barras de herramientas con posición fija que nunca se mueven de la parte superior aunque el usuario haga scroll.
• Y además: Fijar su propio coeficiente de fricción, lo que permite dar impulso a una lista larga.

La empresa que ha creado esta plataforma es Apple. Y parece que dicha plataforma se llama PastryKit.

La mejor aplicación web del mundo para el iPhone

Si tienes un iPhone o un iPod Touch a mano, no sigas leyendo y visita la siguiente página:

http://help.apple.com/iphone/3/mobile/

No se trata de ningún sitio web secreto. De hecho, es muy posible que ya la tengas en los favoritos del iPhone — es donde te manda el navegador al seleccionar el favorito titulado “iPhone Manual del usuario” que está incluido entre los favoritos por defecto en MobileSafari. No sé cuándo ha puesto visible Apple esta versión del sitio web creada con PastryKit, pero lleva ya un tiempo delante de nuestras narices, sin que apenas nos hayamos percatado. [1. Alguien hizo una pregunta en Stack Overflow el 22 de Octubre sobre PastryKit, y el creador de  jQTouch, David Kaneda, lo ha mencionado varias veces en Twitter; estas son las únicas referencias que he podido encontrar.]

Si no tienes a mano un iPhone o un iPod Touch, o si lo tienes y ya has mirado la página en cuestión y quieres echarle un vistazo con el Inspector Web de Safari, puedes cargar la URL en Safari para Mac o Windows sustituyendo la cadena de agente de usuario por MobileSafari en el menú Desarrollo de Safari. (Si no sustituyes la cadena de agente de usuario por MobileSafari, el navegador será redireccionado a una página diferente de ayuda sobre el iPhone). Reduce el tamaño de tu ventana de Safari a lo que serían más o menos las dimensiones del iPhone antes de cargar el sitio web, puesto que el interfaz de usuario se distribuirá en el momento de cargar de forma que llene las dimensiones de la ventana.

El código fuente en JavaScript ha sido minimizado/optimizado, pero no está realmente ofuscado, así que resulta fácil ver que la plataforma se llama PastryKit, e incluso un aficionado a toquetear código JavaScript como yo es capaz de seguir el que se usa en esta web y comprender parte de lo que hace. PastryKit cumple las tres cosas mencionadas con anterioridad — esconder la barra de dirección de MobileSafari, permitir barras de herramientas con posición fija y simular el scroll con inercia — cosa que logra deshabilitando el scroll normal, configurando su propia jerarquía de vista e implementando su propio sistema de scroll.

Desde el punto de vista de WebKit, todo lo que contiene este manual del usuario de iPhone está dentro de una vista que tiene exactamente el tamaño de la ventana, así que no hay nada sobre lo que hacer scroll. PastryKit gestiona todo lo que ve el usuario como contenidos sobre los que se puede hacer scroll. Así es como el iPhone permite un scroll con menor fricción que el del propio Mobile WebKit — PastryKit realiza sus propios cálculos para hacer funcionar el scroll. Y resulta aún más evidente cuando se ejecuta la aplicación en la versión de Safari para ordenadores de escritorio con el truco de cambiar el agente de usuario, puesto que en ningún momento llegas a ver las barras de scroll de Mac, y no puedes emplear la rueda de scroll del ratón para moverte por los contenidos. Todo lo concerniente al scroll está implementado en la propia aplicación, en JavaScript.

Tras instalar en la pantalla de aplicaciones el manual de usuario del iPhone en cuestión y ejecutarlo desde allí, realmente hay muy pocas cosas que lo delaten como una aplicación web. Ni barra de dirección de MobileSafari en la parte superior, ni tampoco barra de herramientas en la parte inferior. El scroll es rápido y con inercia. Incluso funciona de forma perfecta sin conexión, gracias a que los contenidos del manual de usuario se almacenan en una base de datos local mediante HTML5.

Tampoco es perfecto. El scroll funciona con suavidad en mi iPhone 3GS, pero da unos cuantos tirones en mi viejos iPhone 3G y iPhone original. (Sigue siendo mejor que el scroll en cualquier otra aplicación web que haya visto — simplemente no es tan fluido como el de una aplicación nativa). Las pulsaciones y los gestos a veces no son detectados — cuando más lo noto es cuando intento realizar un scroll lo más veloz posible arrastrando con el dedo en un movimiento rápido. Los gestos muy rápidos, imagino, a veces pasan desapercibidos a los filtros de eventos JavaScript.

El scroll “elástico” — que hace que, al intentar hacer scroll más allá del límite, la página muestre un espacio en blanco más allás del límite de los contenidos y vuelva a su posición como impulsada por un resorte — se fastidia al tirar hasta el límite inferior de la pantalla. Lo que ocurre entonces es que la vista se queda “trabada” en la posición en la que muestra el espacio en blanco en la parte superior de la vista; se puede desbloquear pulsando en cualquier lugar de la zona de contenidos.

Por último, no funciona con el gesto estándar del iPhone que permite hacer scroll hasta el inicio de los contenidos tocando la zona superior de la pantalla (en la barra horizontal que muestra el nombre del operador, la cobertura, la hora y la carga de la batería). En MobileSafari, si se toca la barra de estado mientras se ejecuta la aplicación del manual de usuario del iPhone, toda la vista de MobileSafari hace scroll hasta el inicio, lo que deja a la vista la barra de dirección del navegador. Al ejecutar la misma aplicación desde la pantalla de inicio, no ocurre nada si se toca la barra de estado. Imagino que el problema está en que no hay ningún evento JavaScript en Mobile WebKit que detecte las pulsaciones en la barra de estado — el evento va a parar a la aplicación iPhone, y la aplicación web que está ejecutándose sobre WebKit dentro de la aplicación iPhone no es capaz de verlo o actuar cuando se produce. Dede el punto de vista del usuario, una aplicación web para el iPhone ejecutada desde la pantalla de inicio es como cualquier otra aplicación. Pero técnicamente es como una metaaplicación — es una aplicación JavaScript que se ejecuta dentro de una aplicación nativa para el iPhone que lo único que hace es mostrar una vista de WebKit a pantalla completa y cargar la aplicación web.

Pero bien mirado, esta aplicación del manual de usuario del iPhone y la plataforma PastryKit son realmente sorprendentes. La pregunta de los 64.000 dólares, no obstante, es si PastryKit es algo que Apple pretende (o que un equipo dentro de Apple desea) poner a disposición del público. Se diría que son demasiados esfuerzos para crear una plataforma tan completa sólo para usarla en esta guía de usuario, así que tengo esperanzas de que la respuesta sea sí. ¿Quizás sea algo que forme parte de la próxima actualización importante de Dashcode? ¿Y a lo mejor tendrá herramientas integradas para la creación de interfaces, al estilo del Interface Builder de Cocoa Touch?

Por mi parte espero que tengamos más noticias de PastryKit, y que Apple siga trabajando para que Mobile WebKit sea una alternativa abierta al App Store.

Demostraciones de PastryKit / Manual de Usuario del iPhone

Para la posteridad y para aquellos de vosotros que no tengáis acceso a un iPhone o Safari, he creado dos screencasts que muestran en funcionamiento la aplicación web citada.