Archivo de la categoría: Programación

Precargar CSS con la aplicación Flex

A la hora de crear una aplicación Flex con temas (skins) intercambiables o personalizables, uno de los problemas principales con el que nos encontramos es la precarga del mismo. En general tendríamos por un lado nuestro swf de la aplicación y por el otro el del css que estamos cargando. Asumiendo que cargásemos el tema en el evento creationComplete con

 StyleManager.loadStyleDeclarations("micss.swf", true )

tendríamos un problema de sincronización. Los usuarios no verían el look&feel de nuestra aplicación hasta que se hubiese cargado el swf del tema, mientras tanto se vería el tema por defecto, lo que ofrece una imagen bastante pésima de la aplicación.

Para solucionarlo recurrimos a precargar el tema junto a la aplicación, de manera que cuando lancemos el evento creationComplete, el swf está ya en la caché del navegador y casi instantáneamente se aplica sin que el usuario note apenas retardo.

Para hacer la precarga personalizada de la aplicación deberemos extender el componente DownloadProgressBar. Además de para nuestro propósito de cargar el css, podemos también aprovechar para traducir los textos de la percarga, de manera que aparezcan en castellano, un detalle para los usuarios.

Os dejo el código de ejemplo.

Lo primero será decirle a nuestra aplicación que utilice nuestra precarga personalizada y cargar nuestro swf de estilos. Recuerda que cuando se ejecute el evento creationComplete, este swf estará ya en caché del navegador, no se cargará de nuevo desde el servidor.

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
layout="vertical"
creationComplete="StyleManager.loadStyleDeclarations("micss.swf", true )"
preloader="com.xplota.mainloader.AppProgressBar">

Ahora veremos rápidamente como personalizamos el componente.

package com.xplota.mainloader{
	import mx.preloaders.*;
	import flash.events.ProgressEvent;
	import flash.text.TextFormat;
	import mx.controls.Image;
	import flash.display.Sprite;
	import flash.events.Event;
	import mx.events.FlexEvent;
	import mx.events.RSLEvent;
	import flash.display.Loader;
	import flash.net.URLRequest;
	public class AppProgressBar extends DownloadProgressBar{
	 	private var loader:Loader;
	 	private var _preloader:Sprite;
		public function AppProgressBar() {
	 		super();
	 		//Configuramos las etiquetas
	 		downloadingLabel="Cargando..."
	 		initializingLabel="Iniciando..."
	 		// Set the minimum display time to 2 seconds
	 		MINIMUM_DISPLAY_TIME=2000;
	 	}

		// Override to return true so progress bar appears during initialization.
	 	override protected function showDisplayForInit(elapsedTime:int, count:int):Boolean {
	 		return true;
	 	}

		// Override to return true so progress bar appears during download.
	 	override protected function showDisplayForDownloading(elapsedTime:int, event:ProgressEvent):Boolean {
	 		return true;
	 	}

	 	//cambiamos el color de fuente de la precarga
		 override protected function get labelFormat():TextFormat{
	 		var tf:TextFormat=new TextFormat();
	 		tf.color=0xFFFFFF;
	 		tf.font = "Verdana";
	 		tf.size = 10;
	 		return tf;
	 	}

		override protected function createChildren(): void {
	 		super.createChildren();
	 	}

		 //una vez ha cargado la aplicacion cargamos el tema usando la misma precarga
	 	override protected function completeHandler(event:Event):void{
	 		this.label="Cargando tema...";
	 		loader=new Loader();
	 		loader.load(new URLRequest("css/obsidian.swf"));
			loader.contentLoaderInfo.addEventListener(ProgressEvent.PROGRESS, progressHandler);
	 		loader.contentLoaderInfo.addEventListener(Event.COMPLETE, loaderCompleteHandler);
	 	}

		private function loaderCompleteHandler(event:Event):void{
	 		_preloader.addEventListener(FlexEvent.INIT_PROGRESS, initProgressHandler);
	 		dispatchEvent( new Event( Event.COMPLETE ) );
	 	}

		override public function set preloader( preloader:Sprite ):void{
	 		_preloader=preloader;
	 		preloader.addEventListener(ProgressEvent.PROGRESS, progressHandler);
	 		preloader.addEventListener(Event.COMPLETE, completeHandler);
	 		preloader.addEventListener(RSLEvent.RSL_PROGRESS, rslProgressHandler);
	 		preloader.addEventListener(RSLEvent.RSL_COMPLETE, rslCompleteHandler);
	 		preloader.addEventListener(RSLEvent.RSL_ERROR, rslErrorHandler);
	 	}
	}
}

En el constructor de la clase configuramos las etiquetas en nuestro idioma. Aprovechamos para sobreescirbir el método labelFormat de manera que podamos modificar la fuente de las etiquetas para acomodar la precarga a nuestro diseño.

Lo importante llega al sobreescribir el método set preloader. Lo principal es capturar el evento Event.COMPLETE, que se disparará cuando termine la precarga y antes de que se inicie la aplicación. Cuando se dispare este evento lanzaremos la carga de nuestro CSS pasando al mismo preloader el progreso de carga de los estilos, de manera que reaprovechamos la misma precarga. Cuando termine de cargar el CSS será cuando lancemos manualmente el evento Event.COMPLETE del componente, lo cual iniciará la aplicación teniendo ya nuestros estilos en caché.

Este método no sirve sólo para cargar los estilos, podemos precargar cualquier archivo que necesitemos. Nosotros lo hemos utilizado para cargar, además de los estilos, un archivo de configuración XML. Puedes, además, ir cambiando la etiqueta de carga: cargando configuración, cargando tema, etc.

Recuerda que para jugar a extender componentes lo más sencillo siempre es ver como está construído el original. Haciendo ctrl+click en el código sobre un tipo se nos abrirá automáticamente el código fuente del mismo, pudiendo explorar los métodos que tienes disponibles, los que puedes sobreescribir y el funcionamiento completo.

Redimensionando GIF’s desde PHP I

Como desarrollador de tecnologías para móviles, uno de los servicios que hacemos habitualmente es la venta de imágenes, fondos, wallpapers o como queráis llamarlo. Este servicio requiere el escalado de los archivos para adaptarlo al tamaño de pantalla del teléfono del cliente. Además de para la descarga de contenidos, el redimensionamiento de imágenes es necesario también para adaptar el look&feel de los sites al dispositivo del cliente. En un primer momento lo hacíamos con Imagemagick, pero, por alguna extaña razón, a medida que aumentaban las visitas se saturaba el Apache de las máquinas (Windows) puesto que, parece ser, el convert no finalizaba los procesos, y había que reiniciar los servidores web. La solución fue reemplazar el sistema basado en Imagemagick por otro basado en GD, utilizando las funciones nativas de PHP, de manera que todo quedaba integrado en la propia aplicación.

Os estaréis preguntando cual es el problema en el escalado de imágenes con GD. Ninguno, el resultado era perfecto hasta que nos encontramos con gif’s transparentes. Al hacer el escalado se perdía la transparencia sin remedio. Dimos muchas vueltas y probamos distintos métodos que fuimos leyendo por cientos y cientos de foros y blogs, puesto que en la documentación de PHP no quedaba nada claro cómo hacerlo hasta que dimos con la solución.

He decidido separar este artículo en dos partes. En el segundo trataremos el escalado de gif’s animados, un proceso bastante más complejo que los estáticos.

En un GIF, la transparencia viene definida por un color, un solo color, que se define como transparente, de manera que cada pixel que tenga exactamente ese color será transparente, de ahí que, tradicionalmente, se comience por una imagen de fondo blanco o negro y sobre ella se dibuje, guardando ese color de fondo inicial como el de transparencia. La transparencia es una característica de la imagen, no del color en sí. No tiene por qué ser blanco o negro, cualquier color puede ser el transparente, pero una vez definido, cualquier pixel que tenga ese color será transparente. Por otro lado, en un GIF se guarda la paleta de colores que utiliza, de manera que se optimiza el tamaño de la imagen manteniendo la información únicamente de los colores disponibles y referenciándolos por un índice dentro de esa paleta. Esto que puede parecer un dato sin importancia es fundamental a la hora de tener claro el proceso a seguir desde PHP.

Hay varias funciones de PHP que hacen referencia a la transparencia y a los colores. En unas se utilizan los colores como tal en formato RGB, en otras se utiliza el índice de color en la paleta y en otras se necesita la representación del color. Aquí está uno de los problemas, ¿cómo se debe utilizar el resultado de cada una de las funciones disponibles?.

Lo primero que debemos calcular es el porcentaje de escalado que vamos a aplicar. Esto dependerá de nuestra aplicación y del destino de la misma. Si queremos fijar un determinado ancho habrá que calcular el porcentaje sobre el que debemos escalar el alto y viceversa. No entraremos en detalles sobre este aspecto puesto que se sale fuera del objeto de este artículo.

Una vez tenemos claro el nuevo tamaño, debemos, antes de nada, saber cual es el color transparente de la imagen original. Para ello usamos la función imagecolortransparent, si hay transparencia nos devolverá el identificador de ese color. A partir del índice del color transparente, obtenemos la representación RGB en la imagen original con imagecolorsforindex y ya podemos localizar ese color en la nueva imagen con imagecolorallocatealpha. Ya tenemos todo lo necesario. Ahora simplemente rellenamos la nueva imagen con ese color, le decimos que ese color será el transparente y copiamos la imagen original en la nueva escalando según necesitamos.

A la hora de copiar la imagen y escalarla no utilizamos imagecopyresampled ya que, a diferencia de imagecopyresized, hace una interpolazión para suavizar el resultado final. Esto, que en general es correcto, en el gif transparente provoca la deformación de pixeles propios de la interpolación, haciendo que se pierda parte de la trasparencia ya que estos pixeles no son del color exacto.

Este sería el código final.

$srcImage=imagecreatefromgif("demo.gif");
$new_w=160;
$new_h=114;
$dst_img=imagecreatetruecolor($new_w,$new_h);
$transcolor=imagecolortransparent($srcImage);
if($transcolor!=-1){
 $trnprt_color = imagecolorsforindex($srcImage, $transcolor);
 $trnprt_indx = imagecolorallocatealpha($dst_img, $trnprt_color['red'], $trnprt_color['green'], $trnprt_color['blue'], $trnprt_color['alpha']);
 imagefill($dst_img, 0, 0, $trnprt_indx);
 imagecolortransparent($dst_img, $trnprt_indx);
}
imagecopyresized($dst_img,$srcImage,0,0,0,0,$new_w,$new_h,ImageSX($srcImage),ImageSY($srcImage));

Para muestra, un color. Con esta imagen de fondo transparente (sí, vale que no es un Picasso, pero para el ejemplo sirve :P):

Demo Transparente

Conseguimos esto:

Demo Transparente Redimensionada

Ajax vs. Flex

O Flex vs. Ajax. O Silverlight. O JavaFX. Menudo debate. A muchos no les gustará y sé que generará mucha controversia. Yo hablaré de Flex pues es el que conozco, pero podríais hacer la misma comparación con los otros dos.

Para el que a estas alturas no lo sepa, FLEX es la tecnología Flash orientada a programadores. Tradicionalmente Flash ha sido una herramienta de animación y diseño, la que conoces de toda la vida. Después de un primer intento más o menos fallido con Flex1 y 1.5, Adobe, tras adquirir Macromedia, decidió reorientar el rumbo, construyendo algo auténticamente revolucionario con Flex2. Las secuelas, además de Flex3, han sido AIR (para aplicaciones de escritorio) y próximamente Thermo (diseño de R.I.A.). Con Flex2 han conseguido crear una herramienta para la construcción de interfaces de usuario en Flash.

No cabe duda que las R.I.A. están de moda. Da igual la tecnología utilizada, cada día aumentan las aplicaciones online. Desde sistemas operativos online hasta aplicaciones de edición de fotografías o vídeos pasando por aplicaciones corporativas de gestión de cualquier tipo.

Pero ¿qué es mejor para construirlas? La respuesta es sencilla: depende de para qué. No me sirven argumentos sobre plugins (¿Javascript funciona en Lynx?) o software libre vs. privativo (¿acaso al usuario habitual le importa o sabe lo que es?) o SEO (¿Javascript es search engine friendly?). Hablemos mejor de utilidad y de conveniencia para el desarrollador y el usuario.

Lo primero que deberíamos preguntarnos es

¿Qué voy a hacer?

No es lo mismo hacer una web o una aplicación que va a utilizar mucha gente que hacer una aplicación de gestión para una empresa de seguros o un banco. ¿Alguien se imagina a una aseguradora haciendo su software de gestión en Javascript? Pero sí en Flex como de hecho están haciendo ya. Por otro lado a nadie se le ocurriría hacer una web en Flex, no tiene sentido, no es su cometido. Pero sí que harías una aplicación como la de Flickr para editar fotografías online o la de Youtube para hacer montajes de vídeo. O pequeños módulos concretos que no podrías hacer de otro modo o que te costaría demasiado, o widgets varios como está haciendo mucha gente utilizando feeds, mapas, etc. Este creo que sería el punto clave diferenciador. Con Ajax hacemos complementos para aplicaciones web o pequeñas aplicaciones, con Flex hacemos aplicaciones completas. Lógicamente estoy generalizando y cada uno puede pensar y hacer lo que quiera, hay aplicaciones completas realizadas 100% en Javascript, no hay ningun inconveniente, para ejemplo EyeOS. ¿Por qué opino esto entonces? Sencillo, por una simple cuestión de ingeniería del software y productividad. Flex es un lenguaje orientado a objetos 100% y con todas las ventajas que aporta. Crear interfaces de usuario con Flex es impresionantemente sencillo. ¿Alguien puede decir lo mismo de Javascript? Que se puede hacer es indudable, pero a costa de convertir la aplicación en una auténtica telaraña de Javascript‘s. ¿Qué ocurrirá cuando otro programador deba tomar esa aplicación y modificarla? Cualquiera que haya hecho lo más mínimo en Ajax sabe que es una locura. No hay un patrón MVC y la interacción con la interfaz de usuario (html) es harto difícil, innerHTML está muy bien y es muy rápido, pero siendo puristas deberíamos utilizar DOM, a medio plazo lo agradeceremos, y sino intenta modificar atributos de código insertado con innerHTML :P.

Mejor aún, encontremos un responsable de proyectos, director técnico o el cargo que se os ocurra que se comprometa a realizar un proyecto medianamente importante en Ajax. Si conoce Flex verá las similitudes con Java, de hecho se hizo con Java en mente. Si no lo conoce pensará directamente en Java, difícilmente se le ocurriría pensar en Ajax, su cuello es el que está en juego en definitiva.

¿Para qué hemos utilizado nosotros Flex?

Hemos hecho widgets de distintos tipos, paneles de control y gestión, aplicaciones de audio/vídeo multiusuario (chat, audio-chat y vídeo-chat). Ahora mismo trabajamos en un cliente IRC en colaboración con una de las principales redes de IRC.

En backoffices y otros paneles administrativos hemos comprobado que para el usuario la comprensión y utilización de la aplicación es muy superior a interfaces html puesto que son más parecidas a una aplicación de escritorio tradicional y tienen más interactividad, algo que el usuario agradece.

En artículos posteriores os expondré algunos ejemplos de cosas que hemos ido haciendo a lo largo de los dos últimos años, aunque también veremos cosas en Ajax, no son tecnologías excluyentes.

Añadir que Flex ya es de código abierto, el SDK es libre y hay un excelente plugin para Eclipse. Lo único que es de pago es el Flex Builder de Adobe, la aplicación oficial, pero puedes hacer tus aplicaciones con el plugin de Eclipse del mismo modo.

Por cierto, Adobe no me paga nada por este post :P.

¿Por qué nos siguen enseñando gestión de proyectos en cascada?

Cada día que pasa lo entiendo menos. Cualquiera que haya participado en algún proyecto de software, da igual el tamaño del mismo, se habrá dado cuenta que los patrones a seguir que nos enseñan a todos en las asignaturas de ingeniería del software y gestión de proyectos ya no tienen sentido. De hecho hace mucho tiempo que dejaron de tenerlo. Toma de requisitos, análisis, desarrollo, pruebas, implantación… Y cuando los usuarios finales comienzan a utilizarlo te das cuenta de que la usabilidad es nula (no es lo mismo como piensan los técnicos que los usuarios finales), faltan funcionalidades básicas, determinados procedimientos cotidianos se han complicado tanto que el trabajo diario se alarga… ¿Solución? O bien se aumenta el presupuesto para contemplar las modificaciones (suele ocurrir con las administraciones públicas) o bien el cliente no te paga hasta que el software funcione como él y sus empleados necesitan, con lo cual tu estimación de tiempo/recursos se ha quedado corta y empiezas a perder dinero sobre el plan inicial.

¿Por qué ocurre esto? Sencillo, por que es muy difícil contemplar todas las necesidades del cliente en la fase inicial del proyecto. Pensar que con las notas que se toman durante esas semanas va a ser suficiente lleva a ocultar las potenciales carencias. Sí, hablas con el personal de tu cliente, ves como trabajan, te lo apuntas todo. Pero tú no eres el que trabajará con la aplicación, son ellos, pero vas a plantear el proyecto desde tu punto de vista, no desde el del cliente. Cuando les enseñas el producto aparecen los problemas.

¿Y si, en vez de eso, implantas en tu equipo de desarrollo técnicas de desarrollo ágil? Podríamos decir que sería un método de desarrollo orientado a producto, periódicamente se liberan versiones funcionales del software, con más o menos funcionalidades, pero que funcionan y permiten al cliente toquetear y jugar con su compra.

El ejemplo más evidente lo tenemos en el desarrollo de webs. Cualquiera que haya trabajado en ese campo se habrá topado con el momento en que el cliente empieza a ver lo que hay hecho (es una web, puede verla en cualquier momento ¿no?) y comienza a pedir cambios y a decir cosas que no le gustan. Para nosotros, que tenemos nuestra idea clara del desarrollo lineal, que sabemos que teníamos tres meses para hacer el desarrollo y vamos a cumplir ese plazo, comienzan los problemas. Pierdes la línea de tus planes y comienzas a centrarte en lo que el cliente ha dicho al ver cosas, en cambios, en errores, olvidándote de todo lo planificado que te queda por hacer porque mañana volverá a ver la web y querrá ver los cambios solicitados, tu mente en cascada no es capaz de verlo de otro modo.

En vez de eso vamos planteando pequeños desarrollos cada tres o cuatro semanas. Cada periodo se presenta algo nuevo que funciona, es decir, comenzamos por una pequeña porción del sistema, siempre funcional, y la vamos aumentando poco a poco en periodos posteriores teniendo siempre en cuenta los errores detectados y las impresiones del cliente, sin olvidarse de las funcionalidades pendientes. Estaríamos, por tanto, ante un desarrollo adaptativo en función de las necesidades que se van viendo sobre la marcha. Por esta misma razón comenzamos a tirar líneas de código mucho antes que en los procesos tradicionales ya que apenas nos preocupamos por concretar todos los detalles al inicio, lo vamos haciendo sobre la marcha y con una idea inicial bastante general es suficiente. El objetivo es algo siempre complicado, que el cliente se implique en el proyecto y aporte continuamente su feedback.

Puedes comenzar con el Manifiesto ágil y buscar documentación y bibliografía sobre desarrollo ágil y SCRUM (una de las técnicas más utilizadas). Ya de paso no estaría de más echar un vistazo a Xtreme Programing (no, no es trabajar 15 horas diarias).

A los desarrolladores, en general, nos cuesta mucho asimilar los conceptos ágiles. Nos enseñaron a ser mecánicos en los procedimientos de desarrollo de software y este tipo de técnicas se basan más en ir sobre la marcha, y cuidado, esto no significa ni mucho menos que sin planificación, al contrario. La primera pregunta del director de proyectos la primera vez que oye hablar de desarrollo ágil será: bueno, pero así ¿cómo hago las estimación del tiempo necesario? Pues igual que lo hacías hasta ahora, estamos proponiendo nuevas técnicas de desarrollo, pero la estimación tienes que seguir haciéndola igual: piensa en las tareas que hay que hacer y estima el tiempo necesario para realizarlas, compáralo con la cantidad de recursos (personas) de tu equipo y obtén las estimación, o mejor aún, ya que hablamos de técnicas ágiles, deja que sea el propio equipo el que estime la duración de las tareas, a fin de cuentas son los que las van a hacer.

Subversion, ese gran desconocido

Equipos de varias personas, proyectos sin fecha de finalización, corrección de bugs, nuevas funcionalidades… ¿cómo gestionáis todos esos cambios?

Me resulta difícil de creer, por no decir incomprensible, que, en la época en que vivimos, la inmensa mayoría de empresas de desarrollo de software no utilicen un mínimo sistema de control de versiones (CVS, Subversion, Sourcesafe…). Y no hablamos sólo de pymes, hablamos también de grandes consultoras con grandes proyectos de las administraciones públicas. Y es que no hay mejor cara que aquella que se te queda cuando haces update y te contesta file merged. O mejor aún, cuando has metido la pata hasta el fondo y recurres al superhéroe de la película, a revert.

Algunos pensarán, cuando hablamos de desarrollo de software, que hablamos de grandes aplicaciones o proyectos, pero están equivocados, hablamos de cualquier cosa que se programe, incluida una web.

Subversion es lo que se conoce como un sistema de control de versiones (del inglés Control Version System). Control de versiones es la gestión de los cambios y modificaciones en el código fuente de un proyecto, es decir, cada cambio que se hace en el código queda registrado de manera que en cualquier momento se puede saber quién hizo qué. Pero eso no es todo. ¿Qué ocurre cuando dos o más programadores trabajan sobre la misma aplicación y sobre los mismos ficheros de código? En un escenario normal no podrían. Uno tendría que esperar a que terminase otro para obtener la última versión, hacer sus modificaciones y pasárselo al siguiente. Obviamente eso no es ni óptimo ni deseable, tendríamos programadores esperando para poder trabajar. Subversion soluciona esto permitiendo que varios programadores trabajen sobre el mismo proyecto simultáneamente. Llegado el momento de unir todas las piezas, él lo hace por ti, es lo que se conoce como merge.

¿Qué ocurre cuando el cliente solicita cambios en tu proyecto y, cuando lo tienes terminado, da marcha atrás y prefiere que todo vuelva a estar como antes? Como no has hecho copia de seguridad del código en el estado anterior tendrías que volver a rehacer tu código para quitar lo nuevo y ajustar lo anterior. Con Subversion es tan sencillo como recuperar la versión anterior.

Lo más sorprendente es buscar gente para tu equipo de desarrollo y encontrarte con que a ninguno les suena ni CVS, ni Subversion ni nada similar. ¿Tan poco profesionalizado está el sector? Dá igual los estudios, nadie sabe lo que es y siempre les cuesta adoptar el cambio de filosofía ftp/Subversion.

Lo mejor de todo es que hoy en día no tienes que saber ningún comando manual, está todo automatizado. Eclipse tiene integración plena con Subversion, de manera que hacer commit, update o cualquier otra cosa son unos simples clicks de ratón. Pero eso no es todo, con TortoiseSVN tendremos integración plena con el explorador de archivos de Windows. De un vistazo podrás ver qué archivos has modificado, cuales están sincronizados, etc…

¿Aún no ves las ventajas?

Calendario Multirango en Flex2

Hace algo más de un año trabajábamos en un proyecto que consistía en una aplicación de gestión de reservas para una cadena de hoteles. Una de las opciones necesarias era el mantenimiento de las temporadas de cada hotel, es decir, las tarifas. Aunque pueda parecer algo sencillo y sin importancia, en realidad dista bastante del clásico alta/media/baja. De hecho ni siquiera es algo que permanezca inalterado a lo largo del año, sino que, en función de la demanda y disponibilidad de habitaciones, el propio hotel va modificando las temporadas en función de sus necesidades. La gestión de temporadas se realiza manualmente día a día y para cada uno de los hoteles de la cadena y cambia cada año. Necesitábamos, por tanto, desarrollar un sistema que permitiese administrar las temporadas de manera rápida y sencilla.

La solución que se nos ocurrió fue crear un calendario anual completo, doce DateChooser, uno por cada mes del año, y permitir al administrador configurar en un solo paso el año entero de temporadas. Simplemente seleccionando la temporada que se va a configurar y haciendo click en los días de cada DateChooser se van marcando de un color distinto para cada temporada. Como podéis ver en el ejemplo, es muy sencillo cambiar de temporada los días, seleccionamos otra tarifa y hacemos click en el día que queremos modificar. Es casi tan sencillo cambiar un día como un mes completo.

El problema llegó con el DateChooser puesto que, por defecto, sólo permite seleccionar un día o rango de días, pero siempre marcándolos en el mismo color. Nosotros necesitábamos que de un vistazo el administrador supiese la configuración de las temporadas de su hotel, necesitábamos un código de colores para los fondos de los días, en los números sería poco visual. La solución parte de un componente desarrollado para Flex1.5 hace bastante y que su autor no llegó a portar a Flex2, algo que hicimos nosotros con algunas modificaciones.

Extendiendo el DateChooser

El efecto que queríamos conseguir era colorear el fondo cada día del calendario en función de la tarifa adjudicada, de manera que con un rápido vistazo se tenía claro qué es cada uno.

Lo primero que necesitábamos en nuestro caso particular era ocultar las flechas de navegación de meses, puesto que sólo íbamos a utilizar un mes de cada DateChooser dejando la navegación por años. Por defecto no hay forma de hacerlo ya que estos botones se han definido en mx_internal, así que hemos de recurrir a:

this.mx_internal::fwdMonthButton.visible=false;
this.mx_internal::backMonthButton.visible=false;

En nuestro componente está por defecto, vosotros tendríais que eliminar esas líneas o, mejor, crear un método publico que permita quitarlos.

A continuación definimos el método que haremos público para colorear los días. Como véis en el código, los parámetros son un array con los días a marcar y el color de fondo que le vamos a dar. Tuvimos que implementar un callLater ya que nuestra aplicación, al iniciarse, carga del servidor las temporadas del año en curso y configura los distintos DateChooser, pero nos dimos cuenta que esto se producía antes de que el componente estuviese disponible, con lo cual si intentábamos colorear los días saltaban excepciones de componente no disponible.

Finalmente la función highlight busca los días que se le pasan en el array y configura el color de fondo de cada uno. Dentro del DateChooser, los días son instancias de TextField, pero de nuevo no son accesibles, tenemos que acudir de nuevo a mx_internal. El código es muy explicativo.

public function highlightDays(dayArray:Array, highColor:Number=0xff9900):void{
	var o:CalendarioMultipleColor = this;
	callLater(highlight,[dayArray, highColor]);
}
private function highlight(dayArray:Array, highColor:Number):void {
	if (!dayArray is Array) return;
	if (isNaN(highColor)) highColor = 0xff9900;
	// row 0 of the dateGrid is used for the display of day names
	var startRow:Number = 1;
	// calculate the column where the first day of the month is placed
	var startCol:Number = getOffsetOfMonth(this.displayedYear, this.displayedMonth);
	// how many days do we have this month?
	var lastDay:Number = getNumberOfDaysInMonth(this.displayedYear, this.displayedMonth);
	for (var i:Number = 0; i < dayArray.length; i++) {
		var day:Number = dayArray[i];
		 // only numbers allowed
		if (isNaN(day)) continue;
		if (day < 1) continue;
		if (day > lastDay) continue;
		// calculate row and column of the day
		var row:Number = Math.floor((day-1 + startCol) / 7) + 1;
		var col:Number = (day-1 + startCol) % 7;
		//finally we set background color
		this.mx_internal::dateGrid.mx_internal::dayBlocksArray[col][row].background=true;
		this.mx_internal::dateGrid.mx_internal::dayBlocksArray[col][row].backgroundColor=highColor;
	}
}

Aquí os dejo el ejemplo y código fuente, ya sabéis, botón derecho y View Source.