Pero que es Dart entonces?,  es una nueva apuesta para destronar a Javascript sí, pero por qué es tan especial? porque la apoya Google y eso quiere decir mucho en estos tiempos, por un lado quiere decir que en poco tiempo estará soportado en Chrome (que por estos días a destronado a Firefox y va a la caza de IE a una velocidad impresionante), y por el otro y muy importante que imagino posible que empiecen a publicar parte de sus aplicaciones con versiones hechas en Dart para los navegadores compatibles.

1. Ante todo está orientado a objetos: tiene clases, y tiene valores estáticos (entre otras cosas claro).
2. Está pensado con foco en la escalabilidad de las aplicaciones: Una aplicación Javascript de un tamaño considerable rápidamente se vuelve compleja de mantener, la idea de Dart es ofrecer alternativas para que una aplicación compleja sea mucho más sencilla de mantener de lo que es con Javascript.
3. Otro punto clave es la performance: Google sostiene que por más que los parsers sigan mejorando, el problema de fondo está en el lenguaje en sí mismo, de ahi que es necesario un cambio.
4. Finalmente la seguridad claro, poner tanto foco en la seguridad como sea posible.

El futuro por ahora es incierto, pero bien vale mantenernos al tanto, por ahora, como buenos desarrolladores digamosle "Hola Mundo" al señor Dart...

main() {
  print('Hola Mundo Dart!');
}

Sigan sintonizando, en cualquier momento un poco más sobre Dart...

1. La posibilidad de determinar nuestra posición en un momento dado.
2. Poder realizar un seguimiento de nuestra posición en tiempo real.

Lo primero ya lo vimos en nuestro artículo anterior, para hacer lo segundo tenemos un nuevo método a conocer:

var watchId = navigator.geolocation.watchPosition(fnPosicion, fnError, objOpciones);

El método watchPosition recibe tres parámetros, una función a ejecutar cuando la lectura de posicionamiento se produjo en forma exitosa, una a ejecutar cuando las cosas no salieron de la forma en que lo esperábamos y por último un objeto Javascript con algunas opciones que se pueden configurar (las opciones ya las describimos en el artículo previo). Al igual que con getCurrentPosition,  sólo el primero de los parámetros es obligatorio y recibe un objeto Position (el que también describimos).

La diferencia entre este método y getCurrentPosition es que la función fnPosicion se ejecutará cada vez que la posición cambie, cómo funciona entonces?

1. Una vez ejecutada la función esta retorna un ID (la variable watchID en nuestro ejemplo) que identifica al "watch" que ejecutará nuestra función callback en forma continua. El método intenta retornar un objeto Position y si lo hace ejecuta la función fnPosicion. En caso contrario, y si fue definida, se ejecuta la función fnError.
2. Cada vez que la posición cambia (lo cual depende de la implementación) se ejecuta la función callback con el nuevo objeto Position como parámetro.

Un ejemplo vale más que mil palabras...

navigator.geolocation.watchPosition(function(posicion) {
  document.getElementById('Latitud').innerHTML = posicion.coords.latitude;
  document.getElementById('Longitud').innerHTML = posicion.coords.longitude;
});

Y ya tenemos nuestro monitor de posición en tiempo real...

Lo único que nos resta conocer es como "apagar" nuestro monitor de posición y para eso es que tenemos el ID que el método watchPosition nos devolvió:

navigator.geolocation.clearWatch(watchId);

Este último método nos permite detener la ejecución de nuestra función callback y la recolección de posiciones.

Es importante destacar que, en general, las lecturas sucesivas de una posición van mejorando su exactitud, sobre todo si la lectura del posicionamiento se basa en triangulación GSM en lugar de posiciones GPS (de nuevo, el método a utilizar depende de la implementación). En una implementación típica de triangulación GSM la primer lectura de posición es muy probable que sea la posición de la antena a la que estamos conectados lo cual es prácticamente inútil para nuestros objetivos por lo que es buena idea al menos darle "un tiempito" para que se estabilice la lectura mediante un watch.

Lo primero que debemos comprender es que la "Geolocation API" es un estándar impulsado por el W3C y como tal, toda aplicación que hagamos que cumpla con este estándar va a funcionar en todo dispositivo que lo respete, así, hoy en día la mayoría de los browsers soportan la interfaz en cuestión (excepto IE) y nos permite su uso.

Para comenzar, el objeto en cuestión que vamos a conocer se encuentra debajo de navigator, se llama geolocation y tiene un método principal llamado getCurrentPosition

navigator.geolocation.getCurrentPosition(fnOK, fnError, objOpciones);

El método getCurrentPosition recibe además tres parámetros, una función a ejecutar en caso que todo haya salido bien, una a ejecutar cuando las cosas no salieron de la forma en que lo esperábamos y por último un objeto Javascript con algunas opciones que se pueden configurar (más en breve). Es importante destacar que sólo el primero de los parámetros es obligatorio.

Este método obtiene la posición geográfica del usuario y ejecuta la función que aquí hemos decidido llamar fnOK con un parámetro, un objeto del tipo Position que recibe las coordenadas obtenidas.

function fnOK(Posicion) {
    document.getElementById('Latitud').innerHTML = Posicion.coords.latitude;
    document.getElementById('Longitud').innerHTML = Posicion.coords.longitude;
}

Tan sencillo como eso y con esta simple función ya logramos tener en un SPAN, DIV o lo que querramos dibujadas nuestras coordenadas geográficas.

El objeto Posicion tiene otros atributos que completan la información de posicionamiento y que dependiendo de la implementación pueden ser de mayor o menor utilidad:

Avanzando un poco más en nuestra implementación debemos pensar que sucede si algo falla y en este caso es bastante posible que lo haga ya que la disponibilización de la información geográfica es una decisión del usuario, cuando entramos a un sitio que hace uso de los métodos que aquí describimos el usuario verá un mensaje de alerta al respecto y el browser le preguntará si desea compartir su información.

function fnError(error) {
    alert('Error occurred. Error code: ' + error.code);
}

La función fnError recibe un objeto que contiene el código de error correspondiente:

Finalmente, el último de nuestros parámetros originales es el objeto que nos permite definir configuraciones a la forma en que trabaja nuestra API:

Traduciendo esto entonces a nuestro ejemplo original:

var objOpciones = {enableHighAccuracy:true, maximumAge:30000, timeout:27000};

Suficiente por hoy, en próximas entregas voy a seguir mostrando las alternativas que ofrece esta API. Por lo pronto los dejo con un ejemplo de cómo podría ser una integración con Google Maps, espero que lo disfruten:

function fnOK(posicion) {
	var latlng = new google.maps.LatLng(posicion.coords.latitude, posicion.coords.longitude);
	var myOpciones = {
		zoom: 15,
		center: latlng,
		mapTypeControl: false,
		navigationControlOptions: {style: google.maps.NavigationControlStyle.SMALL},
		mapTypeId: google.maps.MapTypeId.ROADMAP
	};
	var mapa = new google.maps.Map(document.getElementById("myMapa"), myOpciones);

	var marker = new google.maps.Marker({
		position: latlng,
		map: mapa,
		title:"Aca estas!"
	});
}

if (navigator.geolocation) {
	navigator.geolocation.getCurrentPosition(fnOK);
} else {
	alert('No se puede utilizar GeoLocation en este navegador');
}

Vamos ya por la versión 7 de sus Previews y la cosa parece que se encamina de a poquito, antes ya decíamos que bien podríamos estar frente a la versión que "revolucione" la historia de IE y parece con el correr del tiempo se va confirmando esta sensación, cada nueva "Developer Preview" que se libera parece mejorar en algo sobre la anterior y sobre todo en el cumplimiento de los estándares, tanto que estamos presenciando algo histórico, IE está superando a sus rivales más cercanos según las pruebas de la mismísima W3C:

Estos resultados no son poca cosa definitivamente han hecho una mejora importante, aunque, si le buscamos la vuelta podríamos decir que el suite de pruebas que está utilizando la W3C no es TAN completo como el de otros servicios similares pero de nuevo, es mejor de lo que esperábamos...

El otro gran punto de discusión en estos tiempos que corren es la performance del motor de Javascript y aquí nuevamente el IE9 parece coronarse como el campeón absoluto...

De nuevo, estos resultados no son poca cosa, claro, estamos hablando de diferencias ínfimas entre los navegadores, pero pongamos en perspectiva la mejora..., se ve en el gráfico lo que tarda IE8 pero recordemos que la Preview 2 de IE9 utilizaba unos 500 ms para terminar el mismo test !

Cómo lograron esto?, para hacerlo sencillo entre las mejoras más notables del nuevo motor JavaScript del IE9 ("Chakra") tenemos que elimina el código que "inútil", aquel que nunca será ejecutado por ejemplo por una condición que no hay forma que se cumpla, para poner un ejemplo sencillo:

var x = 8;
if (x == 4) {
    // Código que nunca será ejecutado
    // ...
}

Lo que tenemos dentro de ese "if" no hay forma que se ejecute entonces el equipo de IE decidió que no tiene sentido gastar tiempo en compilar siquiera ese código por lo que directamente lo "elimina" por así decirlo.
Este tipo de soluciones no son nada revolucionario, existen hace mucho pero la implementación de las mismas tiene sus desafíos y así, salieron ya las primeras voces a demostrar que el test que hizo el equipo de MS no está bien y que en realidad el IE9 no es tan rápido como claman, básicamente lo que sostienen es que MS hizo trampa, configurando su motor de Javascript para que funcione bien para este set de pruebas en particular pero que en la vida real no hay forma que funcione bien este eliminación de código tan agresiva sin dar lugar a posibles errores.
Para aquellos que nos gusta la programación la explicación es realmente muy interesante y recomiendo leerla si tienen ganas de pensar un rato, pero por favor dejemos de lado las suspicacias, que sea uno de los principales ingenieros de Javascript de Mozilla quien presente la teoría nada tiene que ver...

Dejando esto último de lado, a mi gusto es impresionante hasta aquí lo que han conseguido, poco que decir, IE9 bien podría ser el navegador que IE debió ser mucho tiempo atrás, le tomo tiempo que parece que lo está consiguiguiendo definitivamente.

Esta nueva versión es por supuesto evolutiva sobre la anterior, y lo primero que queremos ver es si estamos mejorando en el cumplimiento de los estándares en esta nueva versión...

Resultado ACID3 de la Preview 2 de IE9

Repito lo que dije antes, estamos muy lejos del 100/100 de Chrome pero un 68/100 es una mejora sobre el 55/100 que teníamos en la anterior preview (y ni hablar del 12/100 de IE8), si seguimos así todo hace suponer que llegar al 100/100 no es una utopía para el equipo de Internet Explorer 9.

El otro punto que están atacando fuertemente es el motor Javascript...

Performance de JavaScript en la Preview 2 de IE9

De nuevo una mejora sobre la versión anterior, una mejora de un 20% respecto a la preview anterior no está nada mal realmente, pero está lejos todavía de lo que la versión estable de Chrome (la 4) puede ofrecer y ni hablar de la versión 5 que se presenta como imbatible, aunque hay que destacar que ganarle a Firefox es un mensaje importante.

Por otro lado, no sólo de velocidad se trata el mundo y así, IE9 suma algunos cambios importantes a su motor JS, entre los más importantes aparecen el evento "DOM ready" (DOMContentLoaded), rangos DOM, y métodos como getElementByClassName, y createDocument.

Por último, bien valen las palabras del equipo de desarrollo de IE9 ante le pregunta de si se acabó la guerra de los navegadores..

El soporte de los estándares por parte de IE9, lo acerca mucho más a Gecko, Presto y las diferentes versiones de Webkit, que IE7.

Es decir, el markup que escribamos se debería ver igual en todos los navegadores, les creemos?

Para la próxima versión preview se espera por fin el soporte para el tag VIDEO de HTML5, vamos a ver cómo se porta, sobre todo con el ya famoso problema de los codecs.

Hoy en día estas diferencias radican ya no tanto sobre el navegador que soporte tal o cual tag sino en los codecs que implementan a fin de soportar la reproducción nativa de audio y video de HTML5.

Entre la batalla de los codecs entonces tenemos dos grandes grupos: por un lado tenemos aquellos que opinan seguir con la línea basada en H.264 (los videos de flash utilizan este codec), donde tenemos a Microsoft, Apple y Google. Y por el otro lado tenemos a Mozilla que lo rechaza porque está basado en un estándar cerrado (aunque es de licencia gratuita para el implementador). Mozilla entonces no soporta H.264 y propone la utilización de Ogg Theora, que a diferencia del primero es un estándar sí libre en el amplio sentido de la palabra pero no es muy aceptado entre otras cosas porque es técnicamente inferior a H.264.

Claramente esta situación a los únicos que perjudica es a los programadores que una vez más debemos decidirnos para un lado u otro de la balanza, aunque todo indica al momento que Mozilla lleva las de perder.

Pero hay un tercero en discordia, el propio Google con una compra que hizo el año pasado:  On2 Technologies, y con la compra de ésta empresa, se hizo dueño del codec VP8. De primera impresión esta compra parece un poco difícil de entender si unas líneas antes dije que Google soporta H.264, pero primero veamos quién es On2:

1. Empecemos por atrás: la versión VP3 de su codec es ni más ni menos que la base de Ogg Theora.
2. VP6 fue adoptado por Adobe para Flash desde el 2005 y actualmente lo sigue utilizando.
3. VP7 es el códec que utliza Skype.

Casi nada no?, qué propone la versión VP8 entonces?, bueno, esta nueva versión dice superar en calidad, compresión y uso de procesador a H.264, y todo parece indicar que lo consigue, aunque no es el mejor ejemplo, hay una buena captura en el sitio sitio oficial de VP8 mostrando de lo que es capaz:

H264 vs VP8

Nada mal en los papeles..., y la noticia de la semana es que aparentemente Google estaría a punto de anunciar que liberará el código de VP8, de ser así, creo que se encamina a ser el estándar definitivo, sobre todo si como es de esperarse, YouTube lo adopta rápidamente.

Un golpe más para el pobre Flash sin lugar a dudas...

Siendo que HTML5 está cada vez más cerca me parece oportuno presentarles una breve reseña de cómo cada navegador está cumpliendo con el nuevo estándar.

Seguramente a todos son familiares los tests ACID, el punto de referencia indiscutido a la hora de discernir si un navegador cumple o no con los estándares de la W3C. De la misma forma ha surgido el referente para las pruebas de compatibilidad con HTML5, esta vez no de la mano de la misma gente (extraño para mi) sino desde un programador solitario que puso manos a la obra y armó un set que verifica la compatibilidad con HTML5:

1. Soporte a los tags AUDIO y VIDEO.
2. Soporte a codecs específicos que deben ser soportados.
3. Soporte al CANVAS.
4. Web workers.
5. Almacenamiento local.
6. Aplicaciones Offline.
7. Un grupo importante de los nuevos tags de HTML5.

Una buena prueba y el resultado se da en forma de un índice numérico que va de 1 a 160, siendo esta última la nota más alta. Veamos entonces cómo se comportaron los navegadores más populares:

Compatibilidad de Internet Explorer con HTML5

Arranquemos nuestra prueba por la última versión estable de Internet Explorer, la 8:

Test de HTML5 para IE8

El navegador más usado en su última versión estable logra un pálido 19. No es de extrañar si pensamos en que este mismo navegador aún tiene problemas para culminar el set ACID, lo que sí es extraño es que la versión preliminar del IE9 logra el mismo resultado. Dada la forma en que vienen anunciando su compatibilidad con HTML5 yo esperaba algo más.

Compatibilidad de Firefox con HTML5

De la gente de Mozilla esperamos mucho más y no defrauda...

Test de HTML5 para Firefox

Con la última versión estable de Firefox (la 3.6.3) la cosa toma otro color, un muy respetable 101 es otra cosa y si entramos en detalle vamos a ver que cumple con todo lo que debería cumplir a esta altura de las cosas, fallando en algunos codecs que faltan más que nada.

Compatibilidad de Chrome con HTML5

Google sigue un paso adelante...

Test de HTML5 para Chrome

No esperaba menos de Google y su Chrome, siendo que son ellos quiénes más empujan la aceptación de HTML5 es lógico un resultado de estas características donde la última versión estable de Chrome cumple con todo y sólo flaquea en la compatibilidad de geolocalización la cual tanto en Chrome como en Firefox es habilitable mediante una configuración pero a los efectos de este test me pareció interesante dejarlos tal cual vienen.

En resumen

Se dice por ahí que el estándard HTML5 no va a estar plenamente aceptado antes del 2020 pero la verdad es que a la luz de estos resultados yo lo empiezo a dudar, estamos complicados con Internet Explorer (como siempre) pero para el resto tenemos por delante grandes cosas.

Como dije antes, este problema afecta a todos por igual, pero en el caso Google se puede resolver mediante las Webmaster Tools, indicando al buscador a que región está orientado nuestro sitio en las opciones de Configuración por lo que muchos webmasters pasan por alto lo que aquí vamos a discutir.

Configuración Regional en las Google Webmaster Tools

Por el momento lamentablemente, las herramientas para Webmasters de Bing no son tan poderosas como las de Google, cómo hacen entonces los motores de búsqueda para determinar a qué región está orientado nuestro sitio?, sencillamente se toman dos variables en cuenta:

1. El idioma de nuestra página.
2. La IP de nuestro sitio (la cual depende de nuestro proveedor de hosting).

Sabiendo esto ya podemos empezar a entender por dónde viene el problema, veamos entonces qué necesitamos hacer para resolverlo...

1. Definir correctamente el juego de caracteres

Primero que nada tenemos que indicar claramente a nuestro buscador qué juego de caracteres utilizamos, para esto primero debemos establecer el tipo MIME del contenido que estamos enviando para al mismo tiempo definir dicho juego de caracteres, todo eso lo hacemos con una línea:

<meta content="text/html; charset=iso-8859-1" http-equiv="Content-Type" />

Este tag es fundamental no sólo para el buscador sino para nuestros clientes, indica a los navegadores (y por supuesto los crawlers) cómo identificar los caracteres especiales, por ejemplo los acentos, para evitar sorpresas desagradables o recurrir a las entidades HTML.

La selección del juego de caracteres correcto depende directamente del idioma que utilicemos, así, existen muchas posibilidades, pero el ISO-8859 y el UTF-8 son dos de los más utilizados.

2. Definir correctamente el idioma de nuestras páginas

Definido el juego de caracteres vamos a definir el idioma, para eso recurrimos una vez más a los tags META:

<meta http-equiv="content-language" content="es"/>

Sencillo y sin lugar a dudas, esta línea indica que estamos escribiendo en Español. De nuevo, el listado de idiomas disponible es muy amplio y responden al estándar ISO 639 el cual define el listado completo.

La elección del idioma y el juego de caracteres deben estar en armonía, de nada sirve definir un juego de caracteres que no puede representar los caracteres del idioma.

Con estos dos pasos ya logramos que nuestro buscador encuentre sin dudas y sin errores el idioma de nuestra página, nos falta localizar los resultados.

3. Definir correctamente la regionalización

Para hacer esto vamos a recurrir a tres opciones diferentes, es un poco redundante pero nos va a asegurar el resultado en todos los casos y sin necesidad de recurrir a ninguna herramienta de webmaster.

El primero paso es reescribir nuestra definición de idioma agregando la regionalización al mismo, no es el mismo el inglés americano que el inglés británico, lo mismo pasa con el español y la mayoría de los idiomas, entonces podemos definir la región específica del idioma:

<meta http-equiv="content-language" content="es-AR"/>

Aquí hemos agregado a nuestra definición el país según el código de países y agregamos al idioma información de regionalización según el código de país de acuerdo al estándar ISO, en nuestro caso elegimos AR para identificar a Argentina.

Ahora que tenemos esto vamos a ser redundantes haciendo uso de todas las herramientas que el HTML nos ofrece:

<html dir="ltr" xmlns="http://www.w3.org/1999/xhtml" xml:lang="es-AR" lang="es-AR">

Nótese que agregamos a nuestro tag html los atributos lang, tanto para HTML como para XHTML, los cuales responden a la misma codificación el tag que usamos antes, sólo que están en otro lugar.

Si bien este último paso puede parecer innecesario, y como dije antes, redundante, no podemos asegurar a cuál de las alternativas da predilección cada navegador o crawler, y estamos hablando de unos pocos caracteres como para preocuparnos.

4. GeoReferencia para nuestros sitios

Con lo que venimos haciendo hasta ahora debería alcanzar para resolver nuestro problema, aún así,  el toque final lo vamos a dar utilizando GeoReferenciación para lograr que nuestros sitios sean tan locales como querramos:

<meta name="geo.region" content="AR"/>

Esta familia de tags no es muy utilizada ya que no está muy difundida, sin embargo los buscadores ya las están reconociendo, en particular Bing. La familia en cuestión permite definir tres niveles, desde el más general (País) hasta la latitud y longitud exacta, recomiendo echarles una mirada, para nuestro ejemplo basta saber que se codifican, una vez más según lo códigos de país del estándar ISO correspondiente.

5. En resumen

Orientar nuestro sitio al público correcto es una de las principales definiciones que debemos tener en cuenta cuando pensamos en SEO, con estos sencillos pasos nos vamos a asegurar que los buscadores, en particular Bing, listen nuestro sitio donde nosotros querramos.

Recordemos que el problema surgió luego que Steve Jobs decidiera darle un golpe a Adobe al cambiar el acuerdo de licencia para desarrolladores y prohibir el uso de todo aquello que no estuviese desarrollado con tecnologías de Apple, específicamente esto le impacta al conversor de Flash a Iphone que Adobe incluyó y anunció con bombos y platillos en la versión CS5 de Flash, que dice dicho acuerdo?

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

Hace unos días les contaba las palabras oficiales de Adobe sobre el futuro del conversor Flash-Iphone y en ese momento decía que iban a seguir con él y estaban estudiando el tema, bueno, tiempo después la situación es otra, entonces según nuevas palabras oficiales...

We will still be shipping the ability to target the iPhone and iPad in Flash CS5. However, we are not currently planning any additional investments in that feature.

En castelllano ahora sí...

Vamos a continuar soportando la conversión de Flash a iPhone y iPad en Flash CS5. Sin embargo, no estamos planeando seguir invirtiendo en el desarrollo de dicha característica.

O sea, ganó Apple y en cambio Adobe retruca con una serie de improperios contra Apple y le devuelve el favor a Google impulsando a su comunidad de desarrolladores a migrar sus aplicaciones a Android.

En lo personal estoy de acuerdo con Mike en que no es bueno que un sistema sea cerrado, sin embargo Apple funcionó así desde siempre y siempre le dió resultados, el desafío ahora es para Apple quien debe lograr mantener su liderazgo con el advenimiento de las nuevas generaciones de sistemas operativos y dispositivos móviles que vienen sumándole presión. En su momento el iPhone fue revolucionario y sacó cuerpos de ventaja sobre la competencia pero hoy tiene teléfonos a la par y superiores también, el iPad recién salido no es una opción tan clara para aquellos "no fanáticos" de Apple, si bien genial como lo es, hay una lista de dispositivos en marcha que no le van a hacer la vida tan fácil y no sé si a largo plazo esta movida le va a redituar, habrá que esperar...

Aunque la noticia ya es importante por sí mismo, no sólo esta novedad es relevante sino que además entre los sponsors del proyecto  apareció el gigante de Redmond: Microsoft, lo cual aporta un peso muy importante a este movimiento, después de todo Microsoft, con su Internet Explorer sigue siendo el dominante en el mercado de navegadores.

Además refuerza también la idea que Microsoft está encaminándose hacia la aceptación de los estándares abiertos, cosa que esperamos finalmente confirmar con la llegada de Internet Explorer 9.

WOFF viene a unificar esfuerzos previos: ZOT de Mozilla, EOT de Microsoft y .webfont creado por tipógrafos independientes. Al momento Mozilla y Safari soportan el uso de fuentes OpenType en sus implementaciones y sabemos que SVG nos permitirá también crear tipografías (suena HTML5 ?).

Con la aceptación del W3C se creó el WebFonts Working Group, conformado al momento por Mozilla, Microsoft y Opera, el cual trabajará en refinar la especificación para convertirlo en una recomendación oficial que pueda luego ser convertida en estándar por la W3C.