Archivos mensuales: Octubre 2011

Zepto vs jQuery

Estoy inmerso en el desarrollo de una aplicación web para iPad, como el tema de los recursos que se consumen es muy importante en este dispositivo, estoy intentando optimizar al máximo y por tanto decidí utilizar una framework de javascript ligero: Zepto.

Al principio todo iba de maravilla, el framework apenas pesa 5K y te ofrece la mayor parte de la funcionalidad de jQuery, framework al que estoy acostumbrado a usar.

Al terminar la primera iteración del desarrollo me pongo a hacer pruebas de rendimiento y compruebo que tarda muchísimo en hacer una llamada AJAX para obtener un JSON con datos para pintar la interfaz.

Al principio pienso que es mi código y que necesita más optimizaciones, reduzco al máximo el código y aún así veo un retraso de unos 7 u 8 segundos en el proceso de la petición.

Tengo que decir que antes de decantarme por Zepto hice una primera versión usando jQuery y el problema lo tenía en el renderizado de la interfaz y no en la llamada AJAX. Así que vuelvo a poner jQuery como framework de la aplicación y como la sintaxis entre ambos frameworks es compatible, veo que sí es cierto que realiza más acciones, que probablemente podré optimizar más adelante, lo que es la llamada AJAX se hace de manera fluida y sin el retardo de 7 segundos.

Analizado el código de ambos frameworks veo que en Zepto se hace un eval cuando el resultado es de una llamada AJAX es un JSON y por tanto es ahí donde se pierde el tiempo y hace que la aplicación se quede momentaneamente congelada.

La moraleja de esta historia es que aunque un framework pese poco y esté especificamente diseñado para un tipo de navegadores, en este caso Webkit, no tiene por qué ser más eficiente a la hora de realizar ciertas acciones y por tanto a la hora de elegirlo habrá que ver que tipo de llamadas hay que hacer y si nos merece la pena usarlo o no.

En defensa de Zepto puedo decir que está en fase beta y que me imagino que irán mejorando con el tiempo, pero por ahora, para una aplicación como la mía que requiere de procesado de JSON en las llamadas AJAX no es válida y tendré que seguir usando jQuery aunque sea más pesada y no sea especifica para Webkit.

Admob y SL4A

Durante un tiempo he estado desarrollando una app para Android usando SL4A y Python. Una vez desarrollada quería probar el tema de meter publicidad a la misma usando Admob.

Con SL4A uso HTML como interfaz gráfica de la aplicación y por tanto tengo que usar javascript para meter la publicidad, como si de una aplicación web se tratase.

El banner se muestra correctamente y lo puedo colocar donde quiera, el problema viene a la hora de pinchar en la publicidad, ya que al ser un webview me abre la publicidad en la propia ventana de la aplicación perdiendo toda la interfaz de la misma y quedandome sin acceso a ella.

Después de varías pruebas y un poco de ingeniería inversa sobre el javascript de Admob he descubierto la solución para que la publicidad se abra en una ventana del navegador y no en la interfaz de mi aplicación.

Primero configuramos Admob para lanzarlo nosotros de manera manual:

var admob_vars = {
 pubid: '2121324214214', // publisher id
 bgcolor: '000000', // background color (hex)
 text: 'FFFFFF', // font-color (hex)
 manual_mode: true,
 test: false// test mode, set to false to receive live ads
};

Después pedimos la publicidad:

var ad = _admob.fetchAd(document.getElementById('admob_ad'));

Y por último redefinimos la función gotourl:

_admob.gotourl = function() {
    var droid = new Android();
    droid.view(arguments[0]);
};

Con el código anterior conseguimos que la acción por defecto a la hora de pinchar en el banner sea la de abrir la URL con el navegador y no la de cargar la URL en la página actual, que en nuestro caso es la interfaz gráfica.