Hola a todos!
DISCLAIMER:
Este artículo solo representa mi opinión.
Dicho esto, si sigues leyendo es porque te interesa saber porqué llego a esta conclusión. Hasta ahora me había alejado todo lo posible de javascript y html, los lenguajes del futuro que salvarán al mundo de la crisis y harán que el sol luzca más y la lluvia moje menos. Pero esta semana he tenido que trabajar en un proyecto en PhoneGap, la verdad es que me apetecía probar como funcionaba y como era la experiencia tanto del lado del desarrollador como del lado del usuario. Y tras unos días realmente sorprendentes, aquí van mis conclusiones y algo de código y ejemplos para probarlas.
PhoneGap, javascript, html…
La verdad es que todo aquel que me conozca sabrá que no me caracterizo por mi amor a javascript o html, pero debo reconocer que el trabajar con ellos esta semana ha sido menos doloroso de lo que me esperaba. En gran parte gracias a la ayuda de mi compañero Gerard López, un auténtico crack de PhoneGap, javascript y demás hierbas. En parte por el stack que el mismo ha escogido, formado por knockout.js, jquery mobile y PhoneGap, que realmente facilita mucho la vida del desarrollador. Lo reconozco, me lo he pasado muy bien con javascript… es algo que no me esperaba jejejeje
Pero aunque el lado del desarrollador me ha sorprendido gratamente, me ha decepcionado mucho el lado de usuario. Me explico, por lo que he visto, el rendimiento de las aplicaciones, al menos en Windows Phone, no es ni de lejos el mismo y después de verlo por mis propios ojos no creo que se pueda llegar a ofrecer una buena experiencia de usuario con PhoneGap en Windows Phone. Pero las palabras se las lleva el viento, vamos a ver varios ejemplos de ello.
Mapas y más mapas
Para empezar veamos un ejemplo de uso de mapas, el objetivo del ejercicio es tener un mapa en pantalla centrado en unas coordenadas específicas (el centro del mundo) y con un zoom de nivel 8.
En PhoneGap, añadimos una referencia al api javascript de google:
- <script type=»text/javascript» src=»https://maps.google.com/maps/api/js?sensor=true»></script>
En nuestro <BODY> incluimos un <DIV> llamado “map”:
- <body onload=»load()»>
- <div id=»map» style=»Height:100%; width:100%;»></div>
- </body>
Y en el evento onload del <BODY> cargamos el mapa de google en nuestro <DIV>:
- function load() {
- var latlng = new google.maps.LatLng(43.409038, -3.159943);
- var myOptions = { zoom: 8, center: latlng, mapTypeId: google.maps.MapTypeId.ROADMAP };
- var map = new google.maps.Map(document.getElementById(«map»), myOptions);
- }
Nadie en su sano juicio puede pensar que este código es complicado, de hecho está copiado de la página de google sobre como usar el api de google maps.
¿El resultado?
Voilá! Con solo tres líneas de javascript tenemos un mapa de google totalmente funcional.
¿Y Silverlight? Bueno, empezaremos por añadir a nuestro proyecto una referencia al ensamblado Microsoft.Phone.Controls.Map y a continuación añadiremos una referencia en nuestra página:
- xmlns:map=»clr-namespace:Microsoft.Phone.Controls.Maps;assembly=Microsoft.Phone.Controls.Maps»
A continuación, solo tenemos que insertar el control en nuestra página y establecer sus propiedades ZoomLevel y Center:
- <Grid x:Name=»ContentPanel» Grid.Row=»1″ Margin=»12,0,12,0″>
- <map:Map ZoomLevel=»8″ Center=»43.409038, -3.159943″></map:Map>
- </Grid>
Y listo, ejecutamos y obtenemos el siguiente resultado:
Así a primera vista, salvo que en PhoneGap usamos Google maps y en Silverlight usamos Bing maps, no podemos decir que haya existido una complejidad mucho mayor en uno u otro caso, y las diferencias visuales son anecdóticas… ¿Cual es el problema entonces? Mejor lo vemos en un vídeo:
Como podemos observar en el vídeo hay una gran diferencia de rendimiento en la aplicación de PhoneGap con respecto a la aplicación de Windows Phone escrita en Silverlight. También el arranque de la aplicación se ve más lento en PhoneGap, aunque esto es más debido a que se trata el primer inicio y está pasando nuestro código html y todas las dependencias al isolated storage de la aplicación para poder acceder a ellas.
Conclusión
Creo que el modo de desarrollo con javascript y html ha mejorado muchísimo, cosas como knockout.js o jquery hacen que sea mucho más sencillo trabajar, pero también creo que el rendimiento que ofrece javascript y html, al menos en Windows Phone, es horrible y justifica de sobra desarrollar en nativo. ¿Tendremos una sorpresa en cuanto a rendimiento en Windows Phone 8? Quizás, pero si no es así, no creo que puedas crear una aplicación de calidad para Windows Phone con PhoneGap. Aquí os dejo como siempre el proyecto de ejemplo, que contiene las dos aplicaciones con el mapa para que se vea que no hay trampa. Para poder usar PhoneGap os podéis descargar la última versión y encontrar instrucciones sobre como instalarlo aquí.
Un saludo y Happy Coding!
Mis impresiones 😉
1. PhoneGap a medio plazo está muerto. PhoneGap no es nada más que un «acelerador», para «acelerar» la adopción de una plataforma. Pero la plataforma es la web. Cuando los navegadores incorporen de forma nativa la mayoría de cosas que actualmente proporciona PhoneGap, este dejará de tener sentido. Así que, realmente, la comparativa no es PhoneGap vs Silverlight, sino webapp vs Silverlight (digamos «nativo»).
2. El rendimiento de PhoneGap varía mucho de una plataforma a otra. En iOS p.ej. va realmente bien. En Android ya flojea un poco más y en WP7 no lo he probado. Supongo que se debe a la calidad del control web browser de cada plataforma.
3. Nativo siempre ofrecerá el máximo rendimiento. Es evidente, si no, no tendría razón de ser. Así que al final de lo que se trata no es webapp vs nativo (que siempre ganará nativo). Se trata de si la diferencia es lo suficientemente pequeña para poder usar webapp en una aplicación determinada.
4. Actualmente, en mi opinión, la mejor opción para multiplataforma pasa por aproximaciones como Titanium. De todos modos PhoneGap está mucho más extendido que Titanium. De hecho Titanium existe solo para iOS y Android, aunque leí que hay planes de portarlo a WP. Eso sí, Titanium requiere aprender una API nueva, así que bueno… es como todo 🙂
Pero la integración que tiene Titanium con código nativo de cada plataforma es algo que, evidentemente, con PhoneGap no puedes ni soñar.
Buen post! 😉
Saludos!
PD: Si solo vas a desarrollar para UNA plataforma no tiene sentido usar PhoneGap (ni Titanium, ni nada parecido)
PD2: En un proyecto en el que participo, salimos (saldremos) para iOS, Android y WP7… todas ellas en nativo.
Ya que habláis de alternativas para el desarrollo multiplataforma, creo que puede ser de interés mencionar lo que están haciendo la gente de Xamarin (http://xamarin.com/). La empresa de Miguel de Icaza está creando diversos productos para el desarrollo nativo de aplicaciones móviles multiplataforma (iOS, Android y WP7) con .NET y C#. A diferencia de Mono, el proyecto original que creó el equipo, las nuevas herramientas sí son de pago.