Por fin leo una exposición que viene de alguien de Adobe y que explota el problema desde el lado puramente empresarial que es el verdadero nicho de las aplicaciones Flex.

Michael da justo en el clavo y nos hace ver lo que yo y otros muchos hemos intentado comunicar a Adobe una y otra vez sin éxito debido sencillamente a los objetivos claramente distintos de Adobe (la venta de herramientas para el tratamiento de contenidos) y de las empresas que adoptan Flex para sus soluciones empresariales (sistemas empresariales cuya construcción está subyugada a entornos de integración continua donde se deben integrar con otras muchas soluciones open source, donde la orientación a objetos es crucial, donde nunca ha sido crucial tener un “Design View”, pero si un plugin de maven-flashbuilder y donde la naturaleza de la propia empresa es muy distinta a la del usuario *de la calle* donde HTML5 está teniendo tanto éxito en móviles y tablets).

Está claro que el caso que yo me esfuerzo en defender, el de las aplicaciones empresariales, afecta a un colectivo muy concreto, al cual no puedes ofrecerle una visión irreal o utópica. El mundo de la empresa se mueve en otros tiempos (quizá tiempo bala, como en Matrix ) y con objetivos claros de fiabilidad, seguridad y alta disponibilidad. Suele tener además implicaciones muy distintas a las pequeñas soluciones que se manejan en internet (cualquier servicio en internet suele ser ordenes de magnitud más pequeño, manejable y mantenible a nivel de desarrollo).

En definitiva, muchos de los casos de uso a los que me refiero yo y donde Flex se utiliza de forma brutalmente extensiva, son aplicaciones privadas, que viven dentro del entorno de la empresa, en redes privadas o intranets, cuyo acceso es privado y ciclo de vida y necesidades son muy distintos a los que podemos encontrar en el mundo al que Google, Apple y ahora Adobe se quieren dirigir de forma exclusiva.

Lo nuestro siempre ha sido un escenario donde Apache, Java, Spring, y otras muchas organizaciones han sido las que han marcado las aplicaciones. Adobe Flex siempre ha sido una tecnología con un aporte claro y necesario pero con una naturaleza extraña por estar dentro del ala de Adobe, y que ahora por fin puede ocupar su lugar natural junto con el resto de soluciones del sector en Apache.

Creo que esta es una lectura obligada y que a todos los que estáis en un entorno empresarial similar a mí os va a gustar y vais a ver que por fin alguien de Adobe “habla vuestro mismo idioma”.

Enhorabuena Michael!

Flash en el móvil

Con respecto a la primera decisión, no me extenderé mucho. Me parece una buena decisión teniendo en cuenta como está evolucionando el mundo y como se consume contenido en los dispositivos móviles, donde el público prefiere aplicaciones nativas y el navegador tiene el uso para el que fue creado (búsquedas, consumo de información textual, blogs…).

Salvo por la mala comunicación de Adobe PR (Public Relations), Hasta aquí todo correcto. De hecho no creo que esta decisión afectase a nadie ya que con la negativa de Apple de incorporar Flash Player en iOS, la única opción real en los navegadores moviles era HTML5. Esto dejaba las webs informativas tradicionales, blogs y demás sucedáneos, en un formato diseñado con el objetivo de servir información textual. Quizá solo podamos tener un cierto sentimiento de “estar siendo manejados” al quitarnos la libertad de elegir si queremos usar una u otra tecnología o la combinación de ambas.

Para la aplicaciones nativas siempre podemos recurrir a Adobe AIR (que incluye el Flash Player) donde podemos, con un solo desarrollo, desplegar en iOS, Android y BlackBerry. En este sentido los desarrollos Flash y Flex cobran todo su sentido.

El futuro de Flex

Por el contrario el cambio de estrategia con Flex y su malísima comunicación por parte del departamento de relaciones públicas de Adobe (que parece un grupo de aficionados por sus repetidas meteduras de pata), unido al cambio radical de la dirección empresarial de Adobe han provocado que la comunidad Adobe se sienta engañada y enfadada. Engañada por que esto significa un cambio de 180º en la visión marcada por Adobe (Visión que ha sido soportado por millones de profesionales del sector y refrendada por los clientes de dichos profesionales que han confiado en las soluciones tecnológicas soportadas por el fabricante) y enfadados por que la imagen y el daño generado suponen un perjuicio, quedando en el campo de los profesionales el dar explicaciones a los clientes y convencer sobre el uso correcto de Flash/Flex.

Tal es el daño generado por Adobe que desde hace varios días se pide la dimisión de su CEO (537 firmas recogidas en el momento de escribir esta entrada), cuya falta de liderazgo ha llevado a Adobe a ser un actor pasivo en esta guerra tecnológica. Desde que Steve Jobs inició su batalla contra Flash, debido a sus rencillas con Adobe y a su interés de mantener el control del canal de venta dentro de sus dispositivos iOS, Adobe no ha sido capaz de responder a las difamaciones sobre su tecnología, ni de hacer notar las maravillas de la misma al público, lo que finalmente ha llevado a esta situación.

Durante estos años tanto las empresas cliente como los profesionales de la industria han invertido mucho en Flex ofreciendo resultados espectaculares. Esta decisión repentina de Adobe tendría sentido en el caso de que tuviésemos un reemplazo actual para Flex a día de hoy y no solo una promesa de futuro. El segmento de las *aplicaciones* empresariales no es el mismo que el de las *webs* donde HTML5 cobra todo el sentido. HTML5 *no* está todavía preparado para solventar los problemas que surgen en el mundo de las aplicaciones empresariales y lo peor es que no sabemos cuando ni como estará.

Realmente HTML no ha cambiado significativamente durante los últimos años. El motivo por el que todos nos pasamos a Flex fue debido a la fragmentación de los navegadores y a la inconsistencia de la experiencia de usuario que existía entre ellos. Esto sigue siendo así y continuará así a no ser que todos los fabricantes se asocien para crear un motor único que permita asegurar esa experiencia única de visualización.

La innovación generada en el Flash Player a través de los años así como su alta penetración (mayor al 98%) en la base de ordenadores en todo el mundo y su consistencia a través de plataformas convierten a Flash en un entorno de ejecución perfecto y clave en el desarrollo de aplicaciones empresariales.

Además, la naturaleza de la tecnología es lo esperado por un desarrollador de aplicaciones : Lenguaje OOP, debugger, compilación sobre interpretación, IoC, Metadatos, AOP, protocolos de comunicación avanzados como AMF y RTMP, Profiling, Acceso a bajo nivel (Bitearray, pixel level handling), etc…

Estas características son el principal motivo por el que HTML5 no podrá sustituir a Flash (y sobre todo a Flex) en el desarrollo de aplicaciones corporativas. HTML siempre ha sido una tecnología orientada al *documento* y flash orientada las *aplicaciones*. Los desarrollos empresariales (ERPs, sistemas de información corporativos, …) son soluciones de miles/millones de lineas de código que no pueden estar basados en una amalgama desordenada de scripts. El desarrollo y posterior mantenimiento de esas aplicaciones sería muy costoso y en muchos casos imposible de llevar a cabo. La orientación a objetos es crucial en este campo.

¿Que podemos esperar en un futuro de HTML5 y de Flex?

Está claro que si Google, Apple, Adobe y otras muchas están apostando por HTML5 en un futuro será la tecnología predominante. Pero ese futuro no será real hasta dentro de al menos 4 o 5 años. En mi opinión muchos de los problemas que existían en Flash debido a malos programadores los veremos nuevamente en HTML5 ya que no es un problema de la tecnología y si de hacer un buen uso de las mismas.

Por el contrario Flex es la opción real hoy en día para aplicaciones empresariales de cierta envergadura. Como Adobe dice en su última entrada: Nada ha cambiado de un día a otro en el estado de HTML5 y la realidad es que entrar hoy en día en HTML5 supone un alto coste, una alta incertidumbre y estar dispuesto a sufrir los problemas de una tecnología que, lejos de estar madura no soporta la mayoría de las necesidades que actualmente ya están resueltas en Flex.

Además, y según noticias de última hora, Adobe donará Flex a la fundación Apache, donde residen la mayoría de proyectos open source más importantes de los últimos tiempos (Apache Tomcat, Apache Maven, Apache Web Server,…). Esta noticia es muy positiva, ya que el nuevo empuje de la tecnología será llevado por personas con un entendimiento de los problemas mucho más acertado, en mi opinión, que la propia Adobe, cuya filosofía era por naturaleza distinta y más centrada en la venta de “cajas” y herramientas para la edición de contenido.

Además Adobe asegura que el Flash Player continuará soportando las aplicaciones Flex y que Flash Builder esté actualizado con los cambios en el SDK bajo el gobierno de la fundación.

Asi mismo un equipo de ingenieros de Adobe estará asignado a tiempo completo a seguir mejorando Flex que continuará con la evolución marcada para la siguiente release.

En resumen

Realmente nada cambia por el momento. Yo diría que incluso hay mejoras gracias a que Apache formará parte fundamental de la evolución de Flex. Todos los que estamos ahora en Flex tendremos la oportunidad de ver como evoluciona la tecnología (tanto Flex como HTML5) y podremos ir girando progresivamente con las mismas según nuestros intereses. Es de esperar que en el futuro todas las empresas que están empujando el carro de HTML5 lo hagan viable, no solo para moviles o para webs, si no que también consigamos herramientas y mejoras del lenguaje (alguna plataforma OOP sobre la que desarrollar), de forma que HTML5 sea viable para aplicaciones empresariales.

Por el momento HTML5 NO es una opción si tú segmento es el de las aplicaciones empresariales. No lo es hoy y no lo será por los próximos 3 o 4 años. Mientras tanto y durante ese tiempo la mejor opción que tienes es Flex.

Ya tendremos tiempo de ver si HTML5 realmente funciona y consigue evolucionar hacia algo realmente interesante…y si por descontado, los coches eléctricos terminan siendo una realidad

Esta nueva versión 4.5 de Flex y de su entorno de desarrollo Flash Builder es sin duda alguna la mejor hasta la fecha con notables novedades a destacar. La mayor de ellas es la nueva orientación hacia dispositivos móviles que adopta Flex, añadiendo las plataformas Android, iOS y BlackBerry, a la gama de “pantallas” sobre las que podemos desplegar nuestras aplicaciones y contenidos SWF.

Sin duda Adobe ha trabajado muy duro en conseguir que Adobe Flash Player rinda a la perfección en dispositivos moviles y tablets con Flash Player 10.2 y continua mejorando la tecnología sabiendo la importancia que tendrán dichos dispositivos en los próximos años. La filosofía “Write Once and Run Everywhere” alcanza con esta versión una importancia relevante a tener muy en cuenta a la hora de enfocar un desarrollo RIA.

Por último aprovechar este post para dar públicamente las gracias a Adobe por incluirme en los creditos de esta versión de Flash Builder 4.5!

No lo dudéis! bajad los nuevos bits y probar las novedades y el entorno pues vereis grandes mejoras de productividad y rendimiento que no os podeis perder.

Go Flex Go!

La aplicación hace uso intensivo de las nuevas capacidades de AIR 2.0 para comunicarse de forma nativa con procesos del sistema operativo (NativeProcess API). Además ha sido diseñada pensando en la sencillez máxima: Simplemente basta con arrastrar los documentos que queremos firmar a la aplicación y hacer “click” en el botón firmar para tener todos los documentos firmados en pocos segundos.

Puedes descargar una versión de evaluación de 30 días del producto para Windows o Mac desde aquí.

A su vez es de esperar que Made In Flex y CEV aprovechen los conocimientos del equipo de MIF en estas tecnologías y las estupendas instalaciones del CEV para ofrecer nuevos eventos para beneficio de toda la comunidad.

Os dejo la nota de prensa:

CEV Y CODEOSCOPIC: ACUERDO DE COLABORACIÓN

GeoStratum es un sistema de información basado en un visor cartográfico sobre el que podemos desarrollar diferentes aplicaciones basadas en visualización georeferenciada.

La usabilidad de una aplicación de estas características alcanza niveles excelentes gracias a la sencillez de navegación, basada principalmente en clicks y movimientos del ratón, en contraposición a los típicos formularios de las aplicaciones de gestión tradicionales y la exposición de la información de forma espacial sobre localizaciones geográficas en vez de las tablas de datos normales en estos casos.

Este es sin duda un buen ejemplo de aplicación RIA, desarrollada sobre Flex y JEE, por uno de los equipos de producción de Codeoscopic. El concepto principal detrás del producto es el poder extender la base GIS para añadir información propia de un negocio concreto. En ese aspecto, GeoStratrum 2.0 es la herramienta apropiada para gestionar infraestructuras de suministro (agua, electricidad, etc), planes urbanísticos, líneas de transporte (metro, autobus,…), servicios de logística, polígonos industriales, parques naturales, etc…

Esta lista es un experimento con las nuevas capacidades que ofrecen las listas en Flex 4. Ya sabéis que ahora el layout y los Item Renderers son mucho más versatiles en Spark y podemos mantener el reciclaje de renderers (useVirtualLayout = true) a la vez que hacemos que estos se comporten de forma más expresiva como en este caso. Os recomiendo que juguéis un poco con las nuevas listas de spark

Por otra parte he añadido dos nuevos experimentos en formato “modular”. Uno es un fork del experimento con Picasa y fisicas reales, salvo que en este caso lo que llueven son controles Flex!.

El otro es un experimento-mashup con los servicios de YouTube.com. En el uso una lista de reproducción que tengo en mi usuario de YouTube para visualizar algunos videos sobre mis gustos personales a modo de “televisión a la carta”. De esta forma puedo ir añadiendo o quitando vídeos a dicha lista desde el interface de youtube para que automáticamente se visualicen en la cabecera de este blog con el formato aplicado.

El único proposito detrás de todo esto es la diversión. Como suelen decir “code is fun”!

En este caso he aplicado físicas reales al visor de fotos de Picasa. El API usada para añadir las físicas reales es Box2D. Podéis arrastar las imagenes y lanzarlas por el escenario .

También he cambiado la estructura por un cargador de módulos que selecciona uno de ellos al azar. De momento solo hay dos módulos, pero espero ir introduciendo algunos más con el tiempo. Todo es cuestión de entretenerse, experimentar y disfrutar de las cosas que se pueden hacer con Flash .

Como paso con el anterior experimento, espero destriparlo en próximos posts!

El planteamiento principal a la hora de pensar técnicamente este visor simple de fotos era como hacerlo de forma que la memoria se mantuviera estable y no tuviéramos problemas si manteníamos la ejecución durante largo tiempo, teniendo en cuenta que estamos todo el rato cargando imágenes que se quedan en el fondo del visor y que van a ir siendo tapadas en parte por las nuevas fotos.

La forma óptima es usar solo dos objetos. Un control Image de Flex que es el que irá cargando cada foto, y un Bitmap que será sobre el que iremos copiando los pixeles de cada imagen una vez terminen el recorrido de su animación (este componente puede ser un UIComponent). Una vez desarrollado este concepto, vemos que el profiler se mantiene constante como era de esperar en cuanto a la memoria consumida.

En cuanto a la programación llevada a cabo. Los dos objetos que intervienen son el control Imagen y un UIComponent que servirá de “lienzo” para ir copiando las fotos e ir manteniendo el uso de memoria:

<mx :UIComponent id="canvas"/>
<mx :Image id="img" smoothBitmapContent="true" complete="photoEffect.play();"/>

A continuación un poco de código de inicialización para entender que variables hay implicadas:

// --- Definición de variables y código de inicialización
// --- Bitmap sobre el que copiaremos las imagenes
private var collage:Bitmap;
// --- Array de datos descargado de PIcasa (ver post anterior)
private var fotos_arr:Array;

// --- Inicialización del canvas (UIComponent) sobre el que pintaremos las imagenes
canvas.width = width;
canvas.height = height;
collage = new Bitmap(new BitmapData(width, height, true, 0x000000));
canvas.addChild(collage);

Luego tenemos un método que se encarga de “lanzar una foto” como podemos ver a continuación:

public function throwOnePhoto():void {
        //-- Sacamos la imagen que lanzaremos del array de fotos de picasa al azar
	var tmp:Object = fotos_arr.splice(Math.random()*fotos_arr.length,1).pop();

	// --- hacemos los calculos iniciales (rotacion,escala,...) para dicha imagen
	angle = range*Math.random()-range/2;
	finalAngle = -angle+Math.random()*20;
	rot.angleTo = finalAngle;
	img.scaleX = img.scaleY = 2;
	img.alpha = 0;
        // --- sacamos la url de los datos de picasa y añadimos el parametro imgmax. Esto último es *crucial* para evitar errores de carga en algunos navegadores (como siempre IE da sus problemillas). Otro pequeño truco indispensable para que funcione este servicio de Picasa correctamente.
	img.source = tmp.media.content.url + "?imgmax=800";
	img.width = tmp.media.content.width;
	img.height = tmp.media.content.height;
	img.x = Math.random()*(width - img.width);
	img.y = Math.random()*(height - img.height);
	img.rotation = angle;

        // --- dibujamos en la imagen un fondo blanco y proyectamos una sombra para darle aspecto de foto a la imagen
	img.graphics.clear();
	img.graphics.beginFill(0xffffff);
	img.graphics.drawRect(-5, -5, img.width+10, img.height+10);
	img.graphics.endFill();
	img.filters = [new DropShadowFilter(1, 90, 0, .75, blur, blur, 2, 2)];
}

Cada vez que queramos lanzar una foto, llamaremos al método anterior.

En cuanto al efecto utilizado cuando “lanzamos la foto”, se trata de una combinación de efectos ejecutados en paralelo:

<fx : Declarations>
	<s : Parallel id="photoEffect" duration="4000" effectEnd="copyImage(event)" >
		<s : Fade alphaTo="1" duration="3000"/>
		<s : Rotate id="rot" startDelay="500" duration="3500" autoCenterTransform="true"/>
		<s : Scale scaleXFrom="2" scaleYFrom="2" duration="3000" scaleXTo="1" scaleYTo="1" startDelay="1000" autoCenterTransform="true"/>
	</s>
</fx>

En este caso, el truco está en el uso de los parámetros startDelay y duration para hacer la combinación de timelines que buscamos. Otro parámetro clave en la nueva arquitectura de efectos de Flex 4 es autoCenterTransform, cuyo cometido es hacer que los efectos Move, Scale y Rotate actúen al unisono mediante un proxy que hace que el valor solo cambie una vez como resultado de todos los cambios de efectos sobre el objeto (de esta forma se evitan los parpadeos o “brincos” inesperados de los objetos animados.

Finalmente y una vez que el efecto a terminado, tenemos que ejecutar la parte más delicada del proceso. La copia del estado visual de la imagen en nuestro lienzo para poder reutilizar el componente Image nuevamente y evitar el uso innecesario de memoria, como comentamos anteriormente. Para ello llamamos al método copyImage cuando el efecto a terminado su ejecución:

//cuando termina el effecto
private function copyImage(event:EffectEvent):void {
	drawOntoBitmapData(img,collage.bitmapData);

	if(fotos_arr.length > 0)
		throwOnePhoto();
}

El método drawOntoBitmapData se encarga de dibujar el objeto Image sobre el Bitmap. En el conseguimos los limites de la imagen mediante getBounds (teniendo en cuenta que hemos aplicado un filtro de sombra). Y tenemos que tener igualmente en cuenta la rotación y la traslación aplicada para hacer la copia final en nuestro lienzo. Aquí se trata de darle un poco de uso a nuestros conocimientos matemáticos .

private function drawOntoBitmapData(source : IBitmapDrawable, target : BitmapData) : void {
	var bounds : Rectangle = DisplayObject(source).getBounds(DisplayObject(source));
	var bitmapData : BitmapData = new BitmapData(bounds.width+blur*2, bounds.height+blur*2, true, 0x00000000);
	var mangle:Number = finalAngle*Math.PI/180;
	var sinVal:Number = Math.sin(mangle);
	var cosVal:Number = Math.cos(mangle);

	var m1:Matrix= new Matrix(1, 0, 0, 1, -bounds.x+blur, -bounds.y+blur);
	bitmapData.draw(source, m1, null, null, null, true);

	var m2:Matrix= new Matrix(1, 0, 0, 1, bounds.x - blur, bounds.y - blur);
	m2.translate(img.x*cosVal+img.y*sinVal, img.y*cosVal-img.x*sinVal);
	m2.rotate(mangle);
	target.draw(bitmapData, m2, null, null, null, true);
}

Y ya está. El efecto visual está terminado y listo para usar en nuestro blog .

Espero que os haya parecido interesante. El siguiente paso es empezar a jugar con lo conseguido y experimentar con las nuevas cosas que ofrece Flex 4…¿qué tal si aplicamos ahora un efecto Rotate3D?

El concepto inicial era crear una cabecera sencilla con Flex 4, donde fuesen apareciendo fotos al azar como si fuesen “lanzadas” a un escritorio. La idea no es nueva, ya que se puede ver en alguno de los salvapantallas de los Mac. El motivo de elegir Flex 4 era simplemente por posibilidades de experimentación en el futuro con el nuevo framework.

En el proceso de pensar dicha cabecera me planteé donde estarían alojadas las fotos a mostrar. Podría tener, como en mi antiguo visor de fotos, un álbum en mi propio servidor y acceder vía AMF a la estructura de directorios y fotos, de forma que simplemente subiendo una nueva foto por FTP, el servicio AMF ya supiese de su existencia y la devolviese al visor para ser visualizada. No obstante y teniendo en cuenta que hoy en día tenemos servicios de alojamiento de imágenes gratuitos como Flickr, Picasa o Facebook, me decidí por estos últimos ya que además tienen interfaces web y se hacen sencillos de gestionar. Otras ventajas de esta elección es que podemos subir las imágenes desde un browser vía http y eliminamos ancho de banda del servidor dado que las imágenes están en las máquinas de Google.

Inicialmente hice un poco de investigación entre los distintos servicios y sus APIs para Flex y finalmente me quedé con Picasa. Quizá simplemente por la sencillez que siempre imprime Google en todo lo que hace y sobre todo por el API Flex de acceso tan sencilla que encontré.

Si tenéis un álbum creado en Picasa es muy sencillo recoger la información de su contenido. Para que veáis la facilidad de uso del API de Flex podemos hacer lo siguiente:

private var gService:GDataService = new GDataService();
private var username:String = "usuario";
private var albumName:String = "album";	

gService.userName = username;
gService.proxied = false;
gService.projection = GDataService.GDATA_PROJECTION_API;

gService.addEventListener( GDataEvent.GET_PHOTOS_BY_ALBUM, handlePhotoOk );
gService.addEventListener( GDataEvent. GET_PHOTOS_BY_ALBUM_FAILED, handlePhotoFail );

gService.getPhotosByAlbum( albumName );

Como es habitual tenemos que definir un servicio con nuestro usuario y álbum a mostrar y los listeners para el manejo del resultado o del error. En mi caso opté por usar el método getPhotosByAlbum que me devuelve todas las fotos del álbum en cuestión. Luego en el método handlePhotoOk podemos recoger el array de fotos depositado en event.result.source y comenzar a usarlo en nuestro visor para mostrar las imágenes que necesitemos.

Eso sí, os dejo unas lineas de código fundamentales para que todo funcione correctamente:

Security.loadPolicyFile( "http://photos.googleapis.com/data/crossdomain.xml" );

Security.loadPolicyFile( "http://lh3.ggpht.com/crossdomain.xml" );
Security.loadPolicyFile( "http://lh4.ggpht.com/crossdomain.xml" );
Security.loadPolicyFile( "http://lh5.ggpht.com/crossdomain.xml" );
Security.loadPolicyFile( "http://lh6.ggpht.com/crossdomain.xml" );

Esto último lo descubrí a base de prueba y error ya que la seguridad del Flash Player, una vez más, tiende a complicarnos un poco la vida y sin estas lineas las imágenes no descargaran o algunos browsers simplemente no mostraran ninguna imagen haciendo que nuestro visor falle silenciosamente (o mal funcione en el mejor de los casos).

En el siguiente post veremos como mostrar las imágenes con el efecto deseado ahora que tenemos la fuente de datos a punto. Espero que os resulte interesante .