E4X, Javascript y XML

noviembre 13, 2010

Hace un tiempo, acceder a documentos XML era perfectamnete posible, pero había que pasar por APIs que quizás no eran todo lo sencillas que deberían ser.

Las dos principales APIs que nos servían para procesar un documento XML eran DOM y SAX. Los nombres describían la forma de acceder al documento, mientras que en DOM se cargaba todo el documento en memoria, y podiamos acceder de una forma más sencilla, en SAX registrabamos una serie de “callbacks” a los que se nos iba llamando segun se procesaba el documento.

Sin duda DOM era mas sencilla desde el punto de vista del uso, pero menos eficiente, si nuestro documento era muy grande, necesitabamos tenerlo completamente en memoria. Por su lado SAX era más eficiente, pero la forma de desarrollar con él era bastante incomoda, ya que teniamos que separar nuestro código en multiples funciones de callback y nosotros teniamos que ser responsables de mantener el estado entre las diferentes llamadas.

Sin duda, hoy en día XML es el lenguaje de intercambio de datos más extendido (ya veremos en unos pocos años si esto sigue siendo así). Y sobre todo teniendo en cuenta que en el entorno del navegador, usar XML suele (o solía) ser común para intercambiar datos usando AJAX.

Debido a todo esto, poco a poco los lenguajes han ido incorporando mecanismos cada vez más comodos para procesar los documentos XML, como por ejemplo en Java JAXP . En este caso vamos a hablar sobre E4X, o la extensión de ECMAScript para el procesado de documentos XML.

Tratar un documento XML con esta extensión es sumamente sencillo, de hecho, el propio código habla por si mismo.

var library = <library postalcode="28000">
<books>
<book id="1">
  <title>Book Title 1</title>
  <author>Author of Book 1</author>
</book>
<book id="2">
  <title>Book Title 2</title>
  <author>Other Author of Book 2</author>
</book>
</books>
<magazines>
<magazine id="1">
<title>Magazine title 1</title>
</magazine>
</magazines>
</library>

alert(library.books.book[0].title); // Book Title 1
alert(library.books.book.(@id == "2").author); // Other Author of Book 2

Como veis, el procesado de un documento XML se simplifica de una manera dramática. Al mapear un documento XML a un objeto, su forma de acceso es practicamente similar a como lo haríamos con dicha estructura de datos.

La sintaxis de acceso al documento nos recuerda en cierta manera a XPath, pudiendo hacer cosas como:

alert(library.books..*.length()) 
	// El operador .. accede a todos los hijos.
alert(library.magazines.magazine[0].@id) 
	// Usando el operador @ accedemos a los atributos
alert(library.books.book.(@id == "2").author); 
	// Podemos filtrar por el valor de los atributos

Además de ayudar a procesar un documento, tambien tenemos facilidad para generar XML, si “encerramos” una expresion entre {}, se sustituirá por su valor, o incluso usando el operador +, añadiremos nuevos elementos al documento.

var b = "book"
var xmlDoc = <{b}><title>The Title</title></{b}>
alert(xmlDoc.toXMLString())

library.books.book += <book id="3"><title>....</book>

Después de ver todo lo que E4X puede hacer por nosotros, ahora contaremos la parte mala :).

Actúalmente, solo esta soportado en productos de Mozilla, esto es, Firefox, Thunderbird o Rhino, además de ActionScript, pero no se puede utilizar en Chrome, Safari o Internet Explorer. Y, ¿Por qué sucede esto?, pues básicamente por que los desarrolladores de los navegadores no consideran que sea necesaria esta implementación, ya que consideran que el acceso estandar usando DOM en Javascript es lo suficientemente versatil como para no necesitar nada más. Además, librerías como JQuery tienen extensiones para manejar documentos XML.

En cualquier caso, al ser un estandar nos garantizamos que si algun día deciden incorporar E4X en los navegadores actúalmente no soportados, funcionará de forma identica a la que lo hace ahora mismo en Firefox o incluso en ActionScript.


Juego de la Vida en un canvas de HTML5

septiembre 13, 2010

Poco a poco HTML5 va tomando forma, lo que hace un tiempo era poco mas que un proyecto de estandar, hoy en día ya es una realidad en la mayoría de los navegadores.

Si usamos Safari, Firefox o Chrome ya somos capaces de disfrutar de la mayoría de las ventajas que el nuevo estandar nos propone.

Una de las grandes mejoras es la habilidad para ponder “pintar” en una zona especialmente diseñada para ello. Dicha zona se conoce como “canvas” y vamos a poder utilizarla como si de cualquier otro contexto gráfico se tratara.

Seguramente pensareis que esto no es tan gran novedad, esto ya se podia hacer antes con cosas como Flash o Applets de Java, pero el canvas de HTML5 va un paso mas adelante.

Sin duda la principal novedad de dicho canvas no es tanto el que nos permita dibujar en el navegador sino que es que es propio navegador quien decide como tratar esa zona. A diferencia de la aproximación de flash o java donde era necesario un plugin en comunicación con el navegador.

Este cambio supone un salto drástico en el rendimiento de este tipo de aplicaciones. Seguro que si habéis usado flash o applets java os habréis dado cuenta lo exigente que era para las cosas que mostraban por pantalla. Sin embargo, con el canvas y una buena implementación por parte del navegador, no solo este rendimiento será mejor, sino que además podremos usar cosas como la acceleración nativa 3D.

Además, la ausencia de la necesidad de plugins facilita enormemente la labor de porting a otras plataformas, si el navegador soporta HTML5, no se necesitará nada mas.

Y para terminar con las ventajas, estamos hablando de un estándar, libre de patentes, no controlado por ninguna empresa y con los requerimientos totalmente abiertos. Cualquiera puede implementar un navegador HTML5 sin tener que pagar nada a nadie.

Se me nota entusiasmado, ¿no? :). Creo que es para estarlo, pues la web es uno de los medios de comunicacion mas importante hoy en día, y el hecho de estandarizar algo tan común en la web como son estas aplicaciones es para estar de enhorabuena.

Pues bien, investigando un poco en como se usa el canvas de HTML5, me vino a la mente lo fácil que sería hacer un simulador del famoso “juego” “Juego de la Vida” de Conway.

El juego de la vida, es como se define en la wikipedia, un juego de 0 jugadores. ¿Un Juego sin jugadores? :), básicamente diseñamos una situación inicial y lo único que hacemos es ver como evoluciona la población de células que forman el juego.

El juego está formado por un conjunto de células, representadas por un punto, si la célula esta viva, se pintará de color verde, y si la célula esta muerta, no se pintará. Según ciertas condiciones dependientes del numero de vecinos, cada célula vivirá, morirá o nacerá en la siguiente generación. La implementación es muy sencilla y al igual que con la entrada anterior sobre Mandelbrot, los resultados son bastante interesantes y sin duda algunos patrones de evolución son bastante vistosos.

Aconsejo echar un vistazo a la entrada de la wikipedia para saber un poco más en que consiste el juego.

Hablando de la implementación, pintar en el canvas de HTML5 es bastante sencillo, básicamente, se reduce a 3 lineas

// ...
var context = canvas.getContext("2d");
context.fillStyle = "rgb(100,0,100)";
context.fillRect(10,10, 100, 100);
// ...

Con esas 3 líneas dibujamos un cuadrado en la posicion 10, 10 del canvas. De hecho una vez que obtenemos el contexto, podemos hacer las típicas operaciones, como dibujar cuadrados, arcos, rutas o imagenes.

Para mas detalles, os aconsejo que visiteis el sitio de desarrolladores de mozilla, donde tienen un fantastico tutorial de lo que se puede hacer con el canvas: https://developer.mozilla.org/en/Canvas_tutorial

Finalmente, os dejo con el código fuente de una implementación sencilla del juego de la vida y que como no puedo incrustar en este post de wordpress, podeis ver aquí

<html>
<head>
	<script type="text/javascript">
		var cellSize=10;
		var hcells = 70;
		var vcells = 40;
		var board;
		var canvas;
		var context; 
		var timerId = undefined;
		
		function drawShapeInBoard()
		{
			// Draw Some shapes in the board
			
			board[10][10] = board[12][10] = board[12][9] = board[14][8] = board[14][7] = board[14][6] = board[16][7] = board[16][6] = board[16][5] = board[16][6] = 1;
			
			board[25][30] = board[26][30] = board[27][30]  = board[28][30] = board[29][30] = board[29][30] = board[30][30] = board[31][30] = board[33][30] = board[34][30] = board[35][30] = board[29][30] = 1;
		}
		
		function initGame() {
			canvas = document.getElementById("gameoflife");
			context = canvas.getContext("2d");		
			canvas.addEventListener("click", onCanvasClick, false);	
			initBoard();
			drawShapeInBoard();
			drawBoard();
		}
		
		function onMouseMove(evt) {
			context.fillStyle = "rgb(200,200,200)"			
			context.fillRect(evt.clientX - canvas.offsetLeft, evt.clientY - canvas.offsetTop, cellSize, cellSize);
		}
		
		function onCanvasClick(evt) {
			var x = evt.clientX - canvas.offsetLeft;
			var y = evt.clientY - canvas.offsetTop;
			var boardX = parseInt(x / cellSize);
			var boardY = parseInt(y / cellSize);
			if ( isAlive(boardX, boardY) ) board[boardX][boardY] = 0
			else board[boardX][boardY] = 1;
			
			drawBoard();
		}
		
		function initBoard() {
			board = [];
			for ( i = 0; i < hcells; i++) {
				board[i] = [];
				for ( j = 0; j < vcells; j++ ) {
					board[i][j] = 0;
				}
			}
		}
		
		function drawBoard() {
			for ( i = 0; i < hcells; i++) {
				for ( j = 0; j < vcells; j++ ) {
					if ( board[i][j] == 0){
						context.fillStyle = "rgb(180,180,180)";
					} else {
						context.fillStyle = "rgb(0,170,0)";
					}					
					context.fillRect(i*cellSize, j*cellSize, cellSize, cellSize);					
				}
			}
		}
		
		function isAlive(x,y) {
			if ( board[x] ) 
				if ( board[x][y] == 1) return true;
			return false;
		}
		
		function numberOfNeighbours(x, y) {
			var count = 0;
			if ( isAlive(x-1, y   ) ) count++;
			if ( isAlive(x-1, y-1 ) ) count++;
			if ( isAlive(x-1, y+1 ) ) count++;
			if ( isAlive(x  , y-1 ) ) count++;
			if ( isAlive(x  , y+1 ) ) count++;
			if ( isAlive(x+1, y-1 ) ) count++;
			if ( isAlive(x+1, y+1 ) ) count++;
			if ( isAlive(x+1, y ) ) count++;
			
			return count;
		}
		
		function nextStep() {
			var newBoard = [];
			for ( i = 0; i < hcells; i++) {
				newBoard[i] = [];
				for ( j = 0; j < vcells; j++ ) {
					var neighbours = numberOfNeighbours(i, j);
					if ( isAlive(i,j) && neighbours < 2) newBoard[i][j] = 0;
					else if ( isAlive(i,j) && neighbours > 3 ) newBoard[i][j] = 0;
					else if ( isAlive(i,j) && (neighbours == 2 || neighbours == 3) ) newBoard[i][j] = 1;
					else if ( !isAlive(i,j) && (neighbours == 3) ) newBoard[i][j] = 1;
					else newBoard[i][j] = 0;
				}
			}
			board = newBoard;
		}
		
		function computeNS() {
			nextStep();
			drawBoard();
		}
		
		function startNS() {
			if ( ! timerId) {
				timerId = setInterval("computeNS()", 150);
				var status = document.getElementById("status");
				status.innerHTML = "<b>Running</b>";
			}
		}
		
		function stopNS() {
			clearInterval(timerId);
			timerId = undefined;
			var status = document.getElementById("status");
			status.innerHTML = "<b>Stopped</b>";
		}
		
		function clearBoard() {
			initBoard();
			drawBoard();
		}
		
	</script>
</head>
<body onload="initGame()">
	<p align="center">
		The Game of Life
	</p>
	<p align="center">
		<canvas id="gameoflife" width="700" height="400" border="1"></canvas>
		<br/>
		<button onclick="computeNS()">Next Step</button>
		<button onclick="startNS()">Start</button>
		<button onclick="stopNS()">Stop</button>
		<button onclick="clearBoard()">Clear</button>
		<br/>
		<span id="status"><b>Stopped</b></span>
	</p>
</body>	
</html>

Más vale tarde que nunca. Extensiones en Safari.

junio 14, 2010

Pese a que toda la atención del WWDC se la ha llevado el nuevo iPhone, entre el barullo del nuevo teléfono de Apple se ha lanzado una nueva versión del navegador por defecto del OSX, estamos hablando de Safari 5.

Una de las grandes novedades del Safari 5 es que incorpora la posibilidad de ejecutar extensiones, de la misma manera que hace Firefox desde hace mucho tiempo, o mas recientemente Chrome, de hecho, el concepto utilizado es muy similar al usado en el navegador de Google.

Además de para OSX, Safari 5 también esta disponible para Windows, y a diferencia de las versiones anteriores y, basado en mis escasas pruebas, parece que es cuanto menos usable. La buena noticia es que las extensiones son totalmente funcionales también en el sistema operativo de Microsoft.

Hablando ya de las extensiones de Safari, existen varios tipos. Si hablamos de modificar o añadir elementos a la interfaz gráfica de Safari, podemos tener nuevos botones, nuevas barras o nuevos elementos que se añadirán al menú contextual. Aparte de estos elementos, podremos tener extensiones que modifiquen la propia web que estamos visitando, como el típico bloqueador de anuncios o de contenidos Flash

Desde el punto de vista técnico, las extensiones estan programadas usando las típicas técnologias web; HTML5, CSS3 y Javascript

Entrando un poco mas en detalle, típicamente las extensiones estarán formadas por una página HTML que se cargará al incio de la extensión. Esta página la usaremos para colocar las inicializaciones del resto de componentes, así como los eventos que responderán a los elementos gráficos de la propia extension.

Además de esta pagina web, tendremos según los requisitos de esta extension, un conjunto de HTML y CSS que controlarán el aspecto gráfico de nuestra extensión. Por ejemplo, si queremos hacer una barra que muestre algun tipo de información, dicha información estará descrita por un fichero HTML con su correspondiente hoja de estilo, imágenes e iconos.

Si, por otro lado, queremos que nuestra extensión modifique el contenido de la web, necesitaremos tener un conjunto de scripts programados usando Javascript, con el que grácias a la API que nos proporciona el navegador (ofrecida en Javascript tambíen), podremos acceder e incluso modificar el propio contenido de la web que se esta mostrando en el navegador.

Si queremos ponernos manos a la obra, el propio Safari tiene un editor para crear las extensiones. No esperar encontraros un editor de HTML ni nada parecido, en lo que nos ayudará sera en crear la estructura o el “paquete” en el que podremos meter los contenidos de las propias extensiones. Con el Extension builder podremos crear los botones, barras o scripts de las que hemos hablado anteriormente.

Para activarlo, necesitamos ir al menú de preferencias de Safari, y activar el menu de Desarrollador, que por defecto esta desactivado. Una vez activado dicho menú, podremos acceder al Extension builder

El último elemento que necesitamos para crear la extensión es un certificado de desarrollador. Sin este cerficado no podremos ni siquiera instalar una extensión en nuestro navegador. Como vemos, el concepto es muy similar al seguido con el iPhone.

La principal diferencia, es que formar parte del programa de desarrolladores de extensiones de Safari es totalmente gratis. Lo único que tenemos hacer es ir a la web de desarrolladores de apple, http://developer.apple.com y darnos de alta.

Después de rellenar los datos oportunos sólo tendremos que instalar el certificado en el llavero de Mac, o en el almacen de certificados de Windows, para que el Extension Builder lo detecte y nos deje instalar y empaquetar nuestra extensión


Dashcode, como hacer widgets para OSX

diciembre 20, 2009

Cuando hablamos sobre desarrollo en OSX, raudo y veloz aparece en nuestra mente el nombre de XCode. Si bien es cierto que es la herramienta de referencia ( Sin olvidarnos de Interface Builder, claro), hay otra alternativa para desarrollar software en OSX.

Esta otra manera es mas o menos reciente, y la aplicación que nos va ayudar a crearla se llama Dashcode. La primera versión del sistema operativo de apple en el que podemos usar esta herramienta es en Leopard 10.5, y forma parte del grupo de herramientas para desarrolladores. Actualmente se puede usar Dashcode tanto para crear widgets para el Dashboard como para crear webs personalizadas para el iPhone. Este último dato es lo que lo convierte en una alternativa para desarrollar aplicaciones para el smartphone de apple.

Esta aproximación al desarrollo de aplicaciones para el iPhone tiene como gran punto negativo las limitaciones que impone el que realmente estas desarrollando una aplicacion web, pero pero como puntos positivos tiene el hecho de que no hace falta comprar ninguna licencia para desarrollar, y que la dificultad de desarrollo con respecto a la programación de aplicaciones nativas es bastante mas asequible.

Uno de los aspectos que hacen el desarrollo más sencillo es el lenguaje escogido para desarrollar dichas aplicaciones. HTML + Javascript hacen las veces de Objective-C en Dashcode, nuestros widgets realmente se pueden asemejar a porciones de páginas web. Aún así esta eleccion no nos debe hacer pensar que estamos limitando las posibilidades, pues en el caso de los widgets para el dashboard podremos usar mucha de la funcionalidad que tambien podemos acceder desde una aplicación Cocoa, ya que desde javascript podemos acceder a estos modulos mas cercanos al Sistema Operativo.

Para muestra, un boton, en el siguiente enlace podreis ver algunos de los widgets actuales para dashcode.

Junto con Dashcode se incorpora un montón de componentes “prefabricados” como listas, botones, paneles, que podemos usar en el desarrollo de nuestros widgets.

El propio IDE también nos facilita mucho el trabajo, sin tener mucha idea de como funciona todo podemos realizar ejemplo sencillo en cuestion de minutos. Estas ayudas se traducen en autocompleting de Javascript y HTML, edición gráfica de los widgets, y debugger incluido.

Aunque tampoco debemos dejarnos engañar, como con casi todo, manejar a fondo los componentes ( llamados “parts” ) que se pueden insertar en los widgets lleva su tiempo de aprendizaje.

En general podemos concluir que siendo consciente de sus limitaciones, es una gran alternativa al desarrollo tradicional de aplicaciones.


Incorporar Modelos ManyToMany al Backend en Django

diciembre 10, 2009

Uno de los beneficios de usar django para crear nuestra aplicación web es que como por arte de mágia, todo el backoffice de nuestra aplicación se generará ante nuestros ojos sin tirar ni una linea de código.

Parafraseando a Uderzo y Goscinny, ¿Ni una sola linea?, No, alguna, cual aldea Gala indestructible, habrá que tirar, pero ni mucho menos comparable a lo que sería hacerlo desde cero.

Hasta hace poco, si en nuestro modelo exitía una relación Muchos a Muchos, la edición desde la interfaz de administración no era todo lo intuitiva que esperaríamos, pero en la última versión de django este aspecto esta solucionado, proporcionandonos una flexibilidad absoluta.

Supongamos un modelo de un sencillo bloc de notas, inicialmente tendremos dos entidades, una que será las notas y otra que serán los tags que asociamos a dichas notas. La relación entre los tags y las notas es de Muchos a Muchos, el código de dichos modelos sería algo como:

class Note(models.Model):
  title = models.CharField(max_length=200)
  pub_date = models.DateTimeField('date created')
  body = models.TextField()
  tags = models.ManyToManyField('Tag', related_name='notes')

  def __unicode__(self):
    return self.title</div>

class Tag(models.Model):
  name = models.CharField(max_length=100)

  def __unicode__(self):
    return self.name

Por defecto, django nos genera una interfaz de administración que podemos ver si entramos a la aplicación “admin” una vez lanzado el servidor. Si usamos el servidor de desarrollo, la URL habitual es http://localhost:8000/admin/

Como deciamos anteriormente, en las versiones anteriores de django, solo podíamos editar (y personalizar usando Inlines por ejemplo) los elementos de la clase asociada donde se definía la relacion ManyToMany. En nuestro caso, solo podriamos asociar y añadir tags desde la gestión de notas, pero no viceversa. Al ser una relación bidireccional, como vemos esto no es muy útil.

Para personalizar las interfaces de administración debemos editar el fichero admin.py que esta dentro de nuestro proyecto.

Si queremos que la lista de objetos de la clase asociada aparezca de forma linear, podemos crear un objeto derivado de algun sabor de Inline, como por ejemplo TabularInline. La novedad en la nueva versión de django es que a la clase que modela la relación ManyToMany posee un atributo que representa la asociación.

Este atributo se conoce como through, en versiones anteriores, ese parámetro nos servía para indicar un modelo extendido asociado a la relación muchos a muchos, a la hora de declarar la propia relación en el modelo.

Así si usamos las siguientes clases:

class TagNoteInline(admin.TabularInline):
  model = Note.tags.through

class TagAdmin(admin.ModelAdmin):
  inlines = [
    TagNoteInline,
  ]

class NoteAdmin(admin.ModelAdmin):
  inlines = [
    TagNoteInline,
  ]
  exlude = ('tags',)

admin.site.register(Note, NoteAdmin)
admin.site.register(Tag, TagAdmin)

Podremos editar en ambas interfaces la clase correspondiente asociada.

Para finalizar, si no has entendido nada 😉 quizás te interese el maravilloso tutorial que esta en la propia web del django y concretamente la relacionada con la parte de administración: http://docs.djangoproject.com/en/dev/intro/tutorial02/#intro-tutorial02

Navegadores y futuro de las aplicaciones web

diciembre 3, 2009

Poco a poco nos estamos dando cuenta que el futuro de las aplicaciones apuntan a “la nube”. Google ha apostado por ello con cosas como GMail, Wave o el reciente Chrome OS. Como elemento imprescindible en esta migración, estan los navegadores, los “vehiculos” hacia la nube. Pero, ¿están preparados los navegadores para esta migración?

Cuando la web empezo a ser web, nadie se podía plantear que de aquel lenguaje de marcado derivado del SGML como era el HTML se podría crear todo una plataforma de desarrollo de aplicaciones. Para que esto fuera posible se incorporó un lenguaje que dotara de dinamismo a las, por aquel entonces novedosas, paginas webs. Estamos hablando de ECMAScript, mas conocido con el “desafortunado” nombre Javascript. Desafortunado por su parecido con Java, del que no tiene nada que ver.

Indudablemente se podría hablar mucho de Javascript, como por ejemplo de las primeras implementaciones en los navegadores, de JScript, de su caprichosa sintaxis, etc., pero este, no es el objetivo de esta entrada 😉

Javascript ha sido uno de los grandes “culpables” de que hoy contemplemos como futuro las nuevas aplicaciones web, sin embargo, también ha sido el culpable de muchos quebraderos de cabeza para los desarrolladores de navegadores. Dichos navegadores llevan intentando optimizar el motor que se encarga de interpretar el Javascript desde hace mucho tiempo, sin embargo el desarrollo de dichas aplicaciones ha acelerado mas rápido que la esperada optimización.

Google juega uno de los papeles mas importantes en esta evolución y es muy consciente que a día de hoy, Javascript es un “problema” desde el punto de vista del rendimiento. Uno de los pilares de la presentacion de Chrome fué precisamente un nuevo motor opensource de javascript, el V8. Sin embargo, actúalmente parece que el problema sigue latente.

Además de la nueva implementación de google existen multitud de motores de Javascript, como Rhino de la fundación Mozilla, JavaScriptCore que implementa Safari o Carakan en Opera, pero a vista de los resultados actuales parece que mas de uno sigue sufriendo cuando debe ejecutar una aplicación compleja.

Para darse cuenta de todo esto, solo hace falta escoger un navegador y ponerse a dar vueltas por la aplicación web de moda, Google Wave. Si bien es cierto que la propia aplicación esta en una fase muy previa a considerarse estable, es cierto que el problema también se presenta en otros casos similares como por ejemplo Google Maps, aunque es cierto que de una manera mucho menos acusada. En el caso de Google Wave el problema es tan grave que deja el navegador totalmente inusable, en el caso de navegadores “monoproceso” como firefox, la unica solucion es “matar” al propio navegador.

Para probarlo en nuestras carnes, solo hace falta introducir una busqueda que incluya waves publicos, como por ejemplo introducciendo el texto “rpg with:public” y empezar a navegar por los waves. Rápidamente obtendremos resultados como los de las siguientes imágenes.

Firefox en linux ejecutando wave

Safari en OSX ejecutando wave

Chrome en Windows ejecutando wave

Por tanto a la pregunta del inicio del post, yo de momento tengo que decir, no, los navegadores aún no estan preparados para un salto total a la nube. Y si además introducimos en la ecuación los navegadores de dispositivos menos potentes como smartphones y versiones “light” de chrome o safari, aún la situacion se complica mas.


Aplicaciones Web como “verdaderas aplicaciones”. ¿Alguien dijo Chrome OS?

noviembre 13, 2009

wave header

Hoy en día todos usamos numerosas apliaciones web, en ciertos casos incluso han desplazado a las aplicaciones tradicionales.

Quizás la primera aplicación web que nos viene a la mente es GMail, en muchos ocasiones es el unico cliente de correo que utilizamos.

La forma de acceder a estas aplicaciones es mediante el navegador, sin duda una de sus grandes ventajas es el hecho de que pueden accederse desde cualquier lado sin embargo, el navegador es un “concepto” que no acaba de encajar con “aplicación”. Conceptualmente, el navegador no se asocia al hecho de alojar aplicaciones.

Cuando estamos manejando una aplicacion como Gmail o Google Wave, hay varias cosas de un navegador que no acaban de encajar, por ejemplo,

  • No necesitamos la barra de direcciones, no vamos a cambiar de página en el contexto de la aplicación
  • No necesitamos los controles del navegador, como por ejemplo para navegar por la historia, ya que dentro de una aplicación, no se vuelve hacia atras usando dichos controles.
  • No necesitamos las extensiones habituales del navegador, y de hecho prescindir de esto aligerará la memoria ocupada por la aplicación, que en el caso de ciertas aplicaciones ya es bastante.
  • En el caso de que la aplicación quiera enviar alguna notificación, como por ejemplo un mensaje nuevo recibido en GMail, será el navegador el encargado de enviar dicha notificación. Si tenemos en cuenta que una sesion actual en un navegador tiene muchas pestañas, la posibilidad de notificar directamente por parte de la aplicación web se complica.
  • La aplicación no aparece al mismo nivel que el resto de aplicaciones del sistema. Como ejemplo pongamos que queremos cambiar del Editor de Textos al gestor de correo, antes deberiamos pasar primero por el propio navegador. Cosa que es bastante incomodo.

Como vemos, las aplicaciones web piden a gritos salir del navegador y convertirse en aplicaciones “de ley” en nuestro escritorio.

Existen diversas alternativas para “extraer” estas aplicaciones del navegador y convertirlas en una mas de nuestro sistema operativo.

Una alternativa es Prism. Prism es un proyecto de mozilla, que como es evidente usa el motor de renderizado del firefox para crear mostrar la página web. El resultado que obtenemos de usar prism es un programa como otro cualquiera y que al ejecutarlo accederemos a la aplicación quitando todas las decoraciones del navegador.

Si usamos mac, tenemos Fluid, cuyo objetivo es similar.

Y como no, la estrella de toda esta iniciativa de aplicaciones web, google tiene su propia alternativa para crear aplicaciones reales a partir de sus similares en web.

Usando Chrome, podemos separar las webs como aplicaciones mediante la opción de menu llamada: “Crear accesos directos a aplicaciones…”. Usando esta opción las aplicaciones tendrán su propia entidad en el escritorio, apareciendo como cualquier otra en la barra de tareas, o como acceso directo junto al resto de aplicaciones del sistema. Además, cuando lancemos las aplicaciones desde este entorno, se eliminaran los elementos que antes mencionábamos como accesorios.

Wave en Chrome

Seguramente y como mencionaba en el titulo de la entrada, muy pronto estaremos hablando de este concepto mucho mas en serio, puesto que, sacando la bola de cristal del cajón, viendo las últimos movimientos de google, mucho me temo que la idea sobre la que se basa Chrome OS, puede ir por estos derroteros.