Javi Sanromán

A ver por donde empiezo, que son muchas las novedades/experiencias acumuladas los últimos días sobre gwt, buenas y no tan buenas:

SmartClient

1- El rendimiento de smartclient, sobre todo en ie y equipos poco potentes, deja bastante que desear. Especialmente utilizando grids con muchas columnas. Varios fueron los intentos por solucionarlo: precargar imágenes antes de mostrar componente, activar caché, hacer rollover sobre color de fondo y no sobre imagen, setShowAllRecords(false), personalizar estilo filas setBaseStyle(”estilo_filas_grid”). En fin, que no soy el único quejica, aqui un hilo significativo en los foros, el problema parece que está en la raíz.

2- Soporte: 2 caras 1 cruz

Dos problemas de maquetación, y dos envíos a los foros de smartclient.

Cara, una duda sobre la existencia de un flowlayout perfectamente resuelta por uno de los usuarios.

Cruz, un problema al intentar posicionar un DisclosurePanel de gwt dentro de un window de smartclient con posición absoluta, ni una sola respuesta. Finalmente lo solucioné con un SectionStack de smartclient, pero nada de posiciones absolutas.

Otra cara, contacto directo vía mail con gente de smartclient, siempre responden .

3- Integración gwt-smartclient: Al hilo de estos problemas, comentar que la integración de componentes gwt con smartclient no es buena. Así que si elegimos smartclient tendremos que usar muchos componentes smartclient para evitar problemas de maqueta.

De cualquier forma no puede haber queja del soporte.

Gracias a smartclient por ofrecer una librería gratuita sobre gwt como esta. Pero queremos mas y sobre todo mejor, estaremos atentos.

gwt-exporter

Desde javahispano me entero de la existencia de gwt-exporter. Aun existiendo librerías javascript libres (jquery&otras) tan buenas, prácticas, con gran comunidad, etc, es muy interesante la posibilidad de desarrollar una propia librería bajo gwt para que después terceras personas/equipos la usen desde javascript al estilo jquery&otras.

Google Plugin for Eclipse

Desde que hace tiempo probé sin éxito cypal, no habia buscado alternativas y me valía la simple estructura generada por los scripts de gwt. Ahora google publica Google Plugin for Eclipse, tanto para gwt como para App Engine, un nuevo pasito.

Gwt 1.6

Nueva versión de gwt. Aqui lo nuevo, a modo de resumen:

Nueva estructura de proyecto: Bien! se eliminan los (.launch, .compile, .shell) y se añade fichero de tareas ant.

Se sustituyen Listeners por Handlers.

Nuevos widgets, DatePicker, DateBox y LazyPanel, no llegan no ¡queremos mas!.

Creación y activación de eventos nativos.

Mejoras en el Modo Hosted.

Slider

Que gwt todavía no tenga un slider pasa (está en la incubadora). Pero que ext gwt no tenga slider en su versión stable ya es demasiado, si, lo incluyen en su próxima versión 2.0.

Google!, que sepas que echamos de menos nuevos y mejores widgets, ya se que no me escucha pero hay que intentarlo.

Ext GWT nativo

Me gusta que la implementación de extgwt sea de forma nativa sobre gwt y no se utilicen librerías externas. En general (aun con los problemas que comenté en el post anterior) la integración con gwt está mas conseguida y el rendimiento es mucho mejor que en smartclient, aunque me pese es así.

Sobre el semestre en la uoc, lo mas destacable: TALF2 me mata.

Sobre El quinto día, mantengo lo dicho quitando el último capítulo (que pesado).

Me he enganchado desde el principio a El Ocho, imprescindible para los jugones del ajedrez

Al final les envie una notificación de lo que me había pasado con la codificación de lineas (en un penoso inglés, tengo q ponerme con el ): http://code.google.com/p/gmaps-api-issues/issues/detail?id=1081, que está aceptada.

Efectivamente parece que el paso 2 está mal documentado, no se redondea a la baja, en inglés ya solo tienen:

Take the decimal value and multiply it by 1e5, rounding the result

en lugar de:

Take the decimal value and multiply it by 1e5, rounding down the result

También dicen:

The visual results should look pretty much the same for the viewer, however.

Pero claro un pequeño error sobre otro pequeño error… al final es un gran error. Recordemos que cuando codificamos una polilinea el único punto original codificado es el primero, para los siguientes simplemente se codifica la distancia desde el punto anterior, con lo que cualquier tipo de error se multiplica y al final las diferencias pueden ser enormes.

Debido a esto y que me encontrado con otras pequeñas diferencias entre la herramienta de codificación y mi algoritmo, finalmente he decidido no gastar ni 1seg mas de mi escaso tiempo. Representaré las lineas con los puntos originales sin codificación, y codificaré toda la lógica de carga y presentación de las diferentes líneas en base a posicion del mapa y zoom básicamente.

Llevo ya un buen tiempo jugando con google maps, es divertido, y si a eso le sumamos RoR, mas divertido todavía :-).

Para dibujar líneas sobre un mapa se utiliza el objeto GPolyline. Para construir esta línea lo que hacemos es unir puntos, representados mediante la clase GPoint, puntos que se construyen con 2 parametros (latitud, longitud). Bastante básico todo.

Imaginemos que tenemos una Polilínea con muchisisimos puntos, llegará un momento en el que nuestro navegador será inoperativo, demasiada carga javascript, demasiado lento. Además, seguro que con un zoom muy lejano no necesitaremos dibujar tantos puntos, mmm interesante, dependiendo del zoom dibujamos unos puntos u otros, a mas detalle mas puntos. Y además, solo necesitamos dibujar los puntos que se representen sobre la zona del mapa que visualizamos, aunque la polilinea recorra todo el planeta, si solo veo Galicia no quiero cargar la parte de la polilinea que pasa por Francia.

Todo esto lo podemos hacer manualmente registrando eventos de zoom y movimiento sobre el mapa, y cargando por llamadas callback ajax las partes de las lineas que necesitemos.

Pero hay otra forma, con la que además disminuimos la carga de javascript de nuestro navegador, que consiste en codificar, mediante este algoritmo propuesto por google, todos los puntos con los que dibujaremos nuestra polilínea. En esta codificación también incluiremos la definición de sobre que niveles del zoom quiero dibujar cada uno de los puntos.

Hasta aqui todo bien, nos ponemos a traducir el algoritmo (que por cierto podía estar mejor documentado), llegamos al punto 2:

2. Multiplica el valor decimal por 1e5, redondeando el resultado a la baja:
Fácil, -179.9832104*10^5=-17998321.04, redondeamos a la baja y nos queda -17998321.
Seguimos todos los pasos y al final nos queda ese punto codificado como: `~oia@

Aqui los pasos:

Los creo, pero debo asegurarme de que mi algoritmo está perfectamente traducido.

Así que ahora que mi algoritmo funciona con el punto anterior, probemos con otros, estemos seguros de que funciona bien. Tenemos una utilidad del mismisimo google para que codifiques tus puntos de forma manual, codificamos el mismo punto -179.9832104 en la longitud claro, y… uy, volvemos a hacerlo, vaya, resulta que el punto devuelto no es el mismo: b~oia@

Veis en verde el punto en la longitud, y abajo en verde también ya traducido, no es el mismo que el anterior:

Le damos una y otra vuelta, probamos una y otra vez, y finalmente encontramos el motivo, parece el rendondeo, resulta que en la explicación del algoritmo nos dicen que debemos redondear a la baja, y sin embargo aqui estan redondeando al alta, no tiene otra explicación, debe ser eso. Vamos a preguntarles, ya os contaré.

Google lanza su propio navegador web, ya no son rumores, es noticia confirmada. Por un lado en este gracioso e ilustrativo comic y por otro en el blog oficial de google, en breve también estará disponible para su descarga.

En estos momentos estoy confuso. No se si alegrarme por la noticia de un nuevo navegador que continúe haciendo crecer la web y sus diferentes aplicaciones, o por el contrario mantener todos mis temores ante la aparición de ¡un nuevo navegador donde testear webs!.

Una buena y otra mala noticia, y a las dos nos tiene acostumbrados google. La buena: será 100% open source, ¡bien!. Y la mala: los usuarios de linux tendremos que continuar esperando, ¿hasta cuando?.

Os animo a leer este artículo de Enrique Dans, en el que expone la idea de un navegador diferente, una nueva plataforma web para soportar aplicaciones, el primer paso para restar la dependencia de algunos pesados sistemas operativos actuales. Para ello google chrome incluirá google gears y contará con una maquina virtual de javascript al que llaman “V8″, que si cabe viene a reforzar todavía mas ajax, que google utiliza en todos sus productos, y GWT como kit de desarrollo, del que espero contaros mis experiencias dentro de poco. También contará con un sistema multihilo para que la vida del navegador no dependa de la web a visualizar.

Esperemos a tener siquiera una beta para tener las cosas mas claras, por cierto, no me gusta nada el nombre.

A nadie se le escapaba ya que google se estaba preparando para entrar en el mundo móvil, algunos mas fantasiosos y a pesar de los desmentidos de la compañía seguían creyendo en que presentaría un teléfono similar al iphone de apple, otros de forma mas acertada creían a google e insistían en que su negocio era software no hardware que su modelo de negocio se basaba únicamente en la publicidad.
Pues bien el pasado día 11, un grupo de mas de 30 empresas liderados por google, la openhandsetalliance (alianza de terminal abierto), presentaban android, una plataforma abierta para terminales móviles en la que se incluye un sistema operativo basado en el kernel de linux 2.6, un conjunto de aplicaciones (contactos, sms, email, calendario, navegador(basado en webkit), etc…) y un framework escrito en java para desarrollar aplicaciones.

Android esta llamado a marcar época por muchos motivos; poner de acuerdo tantas y tan importantes empresas en este negocio es un hecho sin precedentes; el apoyo de google que hasta la fecha ha convertido en oro todo lo que ha tocado, con la segura portabilidad de todos sus servicios web de los que se intuye que google maps formará una parte estratégica; la decisión de liberar la plataforma bajo licencia apache(ASL) hace posible su uso de formas y bajo modelos de negocio muy diferentes.

Desde google ya han comenzado a soltar la pasta para comenzar a formar comunidad y desde su blog bajo el título de Calling all developers: $10M Android challeng anuncian un concurso para desarrolladores, premian con 10 millones de dólares al mejor proyecto software para la plataforma, nada mal.

Fuera de la openhandsetalliance se quedan por el momento compañías importantes como Nokia, Sony Ericsson, Blackberry o Microsoft, con posturas muy diferentes, mientras que Nokia ya ha anunciado su disposición a desarrollar terminales compatibles con android, Microsoft sigue apostando por su windows mobile y saca a relucir su ventaja (40 millones de telefonos, acuerdos con 166 operadoras, 55 fabricantes de dispositivos, 18.000 aplicaciones, etc). Solo el tiempo nos dirá en que posición quedará cada uno, desde luego se avecina una dura batalla, iphone;windows mobile;openmoko;simbian;Palm OS;Blackberry…

Unas capturas de pantalla:

Y un par de enlaces a la presentación de android, y a un primer vistazo sobre como contruir una aplicación para android:
http://www.youtube.com/watch?v=1FJHYqE0RDg
http://www.youtube.com/watch?v=I6ObTqIiYfE