MadeInFlex » Tips

#flex101 SWF más ligeros, bin-release

Edgar Parada — Fri, 05 Feb 2010 08:05:11 +0000

Con este post comenzamos una serie de recomendaciones, tips y tutoriales enfocados a cubrir aquellos temas básicos de la tecnología Flex que esperamos sean de utilidad para los entusiastas de la plataforma.

Uno de los primeros tips que es importante conocer cuando hacemos aplicaciones con Flex utilizando Flex/Flash Builder es el manejo de los archivos de salida. De forma automática cuando generamos un proyecto nuevo con la herramienta se crean varias carpetas: bin-debug, html-template, src y libs.

Es común encontrar por la red aplicaciones Flex de desarrolladores que al compilar sus proyectos por descuido o desconocimiento suben las aplicaciones SWF generadas en la carpeta bin-debug, esta versión contiene información adicional que es utilizada cuando utilizamos el comando debug de la herramienta.

La forma correcta de subir nuestras aplicaciones al servidor sería aprovechando las versiones generadas a partir del comando “Export Release Build”, ya que al no incluir esa información adicional su peso es considerablemente menor que la versión de depuración.

Tomemos como ejemplo una aplicación sencilla que contiene 3 componentes: Button, TextInput y DataGrid. Al compilar estar aplicación el SWF generado en la carpeta bin-debug tiene un peso de 449 kb.

Ahora ejecutemos el comando Project > Export Release Build, el tamaño de la aplicación generada es de tan solo 276 kb, siendo el ancho de banda uno de los recursos más preciados en las aplicaciones de Internet es importante tener cuidado con estos pequeños detalles.

Hace tiempo en algún taller de Flex recuerdo que utilicé el hashtag #flex101 para hablar de los fundamentos de la tecnología, por lo que los invito a compartir sus mejores tips en Twitter a la cuenta de @madeinflex no duden que en una entrada posterior merecerá que hagamos una compilación de los mejores.

TurboBinding metadata tag

Sergi Dote Teixidor — Thu, 17 Sep 2009 18:29:54 +0000

Es bien sabido que el proceso de data binding es uno de los más usados en flex. Aporta facilidad y rapidez en el desarrollo de aplicaciones Flex. La grandeza del Binding seguramente es nos permite pasar datos entre diferentes componentes y distintas capas de una manera sencilla.
Aunque nos aporta grandes ventajas, también hace falta recordar que puede aportar grandes desventajas si se usa incorrectamente: memory leaks, disminución del rendimiento de la aplicación, etc. Estas desventajas vienen dadas sobretodo por el código que se genera al usar el binding.

Gracias a mi amigo Álex Albericio he dado con este post de Elad Elrom, que nos habla de su nueva implementación, el tag TurboBinding y que se incluye en su librería, eladlib.

El metatag TurboBinding, además de ser una implementación “lightweight” del concepto de Binding (según el autor), aporta más opciones en cuanto a binding. Las opciones que nos describe el autor son:

Remove binding: El binding se destruye automáticamente. Setteando la propiedad unwatchCounter con un entero, el binding se destruirá al ejecutarse n veces, tantas como hayamos determinado con este entero.
Two-way data binding: nos permite hacer bindings bidireccionales.
Call back method: nos permite determinar una función de callback para que se llame cuando se ejecute el binding relacionado.

El autor, en este post, nos adjunta un ejemplo para ver una comparación de rendimiento entre BindingUtils, MXML Binding y TurboBinding.

Espero que os sea de ayuda, aún no he tenido tiempo de testearlo, pero pinta bastante bien. A ver que os parece.

[PercentProxy] Metadata tag

Joan Garnet — Mon, 14 Sep 2009 15:00:30 +0000

La metadata, conocida en otros lenguajes como anotaciones, es una potente herramienta para comunicarse con Flex Builder que permite realizar un abanico de tareas que van desde la generación de código hasta chequeos especiales en tiempo de compilación pasando por integración con el sistema de autocompletado del IDE.
En esta entrada veremos el funcionamiento de la anotación PercentProxy, con la cual podemos definir parámetros en unidades numéricas o porcentuales.

Sintaxis

[PercentProxy("propiedadPorcentual")]
Argumentos:

propiedadPorcentual (obligatorio) es la versión de cálculo porcentual del getter/setter al que afecta.

Posicionamiento

Esta anotación debe situarse antes de la declaración de un getter/setter de tipo numérico.

Descripción

Este tag de metadata (indocumentado) es la solución a la falta de sobrecarga de métodos en el lenguaje ActionScript 3. Cuando el compilador se encuentra una declaración porcentual en MXML para un valor que debería ser numérico y la propiedad está marcada con la anotación [PercentProxy] internamente se crea la lógica necesaria para que la asignación apunte al setter que le toca.

Ejemplo

TestPercentProxy.mxml

PLAIN TEXT

MXML:

"1.0" encoding="utf-8"?>
xmlns:mx="http://www.adobe.com/2006/mxml"
xmlns:local="*">
>
>
headerText="Col 1"
width="15%"/>
headerText="Col 2"
width="15%"/>
headerText="Col 3"
width="70%"/>
>
>
>

DataGridColumnPorcentualSize.as

PLAIN TEXT

Actionscript 3:

package
{
import flash.utils.setTimeout;
import mx.controls.DataGrid;
import mx.controls.dataGridClasses.DataGridColumn;
import mx.core.mx_internal;
use namespace mx_internal;
public class DataGridColumnPorcentualSize extends DataGridColumn
{
public function DataGridColumnPorcentualSize( columnName:String = null )
{
super( columnName );
}
[PercentProxy( "widthPercent" )]
override public function get width():Number
{
return super.width;
}
override public function set width( value:Number ):void
{
super.width = value;
}
public function get widthPercent():Number
{
var dg:DataGrid = owner as DataGrid;
return 100 * ( dg.columnCount / dg.width );
}
public function set widthPercent( value:Number ):void
{
setWidth( value );
}
private function setWidth(value:Number):void
{
if(owner){
var dg:DataGrid = owner as DataGrid;
width = dg.width * ( value / 100 );
}else{
// Esto está lejos de ser lo más correcto
// pero esto SOLO es un ejemplo...
setTimeout( setWidth, 100, value );
}
}
}
}

La clase DatGridColumn que viene en el SDK de Flex no permite asignar los anchos de las columnas porcentualmente (por buenas razones). Para ilustrar el uso de la anotación en cuestión se puede ver en la clase DataGridColumnPorcentualSize la lógica añadida para que se soporte este tipo de asignación.

[ArrayElementType] Metadata tag

Joan Garnet — Fri, 07 Aug 2009 07:00:07 +0000

La metadata, conocida en otros lenguajes como anotaciones, es una potente herramienta para comunicarse con Flex Builder que permite realizar un abanico de tareas que van desde la generación de código hasta chequeos especiales en tiempo de compilación pasando por integración con el sistema de autocompletado del IDE.
En esta entrada veremos el funcionamiento de la anotación ArrayElementType, con la cual podemos definir Arrays tipados en MXML.

Sintaxis

[ArrayElementType("elementType")]
Argumentos:

elementType (obligatorio) es un nombre de clase completo. ej: com.madeinflex.Usuario

Posicionamiento

Esta anotación debe situarse antes de la declaración de una variable de tipo Array.

Descripción

La anotación en cuestión permite definir el tipo de dato de los elementos que son aceptados en un Array.
Esta funcionalidad solo está disponible en Flex Builder en tiempo de compilación y cuando declaramos dicho Array mediante MXML.

Ejemplo

Ejemplo.mxml

PLAIN TEXT

MXML:

"1.0" encoding = "utf-8"?>
xmlns:mx = "http://www.adobe.com/2006/mxml"
xmlns:local = "*"
xmlns:madeinflex = "com.madeinflex.*">
>
>
uid = "5" nombre = "Carlos Rovira" />
uid = "6" nombre = "Xavi Beumala" />
uid = "6" nombre = "Albero Albericio" />
>
>
>

com/madeinflex/Usuario.as

PLAIN TEXT

Actionscript 3:

package com.madeinflex{
public class Usuario{
public var nombre:String;
public var uid:int;
}
}

ListaUsuarios.mxml

PLAIN TEXT

MXML:

"1.0" encoding = "utf-8"?>
xmlns:mx = "http://www.adobe.com/2006/mxml"
width = "400" height = "300">
[Bindable]
[ArrayElementType( "com.madeinflex.Usuario" )]
public var usuarios:Array;
]]>
text = "Hay { usuarios.length } usuarios" width = "100%" />
labelField = "nombre" dataProvider = "{ usuarios }" width = "100%" />
>

Si modificamos Ejemplo.mxml y añadimos un elemento de cualquier tipo que no sea Usuario, por ejemplo un String, obtendremos un error diciendo algo como: "In initializer for usuarios': type String not assignable to target Array element type":

Conclusión

Es un buen ejemplo de integración con Flex Builder a través de metadata pero la funcionalidad en si realmente no es demasiado útil ya que solo funciona para código MXML y en tiempo de compilación.
Nota: Si se requiere tener Arrays tipados en tiempo de ejecución ver la clase __AS3__.vec.Vector disponible a partir de Flash Player 10.

Breakpoints condicionales

Joan Garnet — Thu, 05 Mar 2009 00:35:13 +0000

Existe una función flash.debugger.enterDebugger() (no documentada de momento) que permite, durante una sesión de debug, parar la ejecución de la aplicación para ser inspeccionada de la misma forma que lo haría un breakpoint.
Esta función nos puede ser útil, por ejemplo, en situaciones en las que queremos validar un comportamiento del que no logramos aislar la causa. Añadiendo la llamada a la función dentro de un bloque condicional nos podemos ahorrar teclear F5, F6 y F8 un montón de veces, dejando que sea la misma aplicación la que decida cuando debe parar.

Un ejemplo de uso:

PLAIN TEXT

MXML:

"1.0" encoding="utf-8"?>
xmlns:mx="http://www.adobe.com/2006/mxml" creationComplete="test()">
import flash.debugger.enterDebugger;
private var cont:uint = 0;
private function test():void {
cont++;
if( cont> 5 ) {
enterDebugger();
trace("Ejecutado test() "+ cont +" veces");
return;
}
callLater( test );
}
]]>
>

En el caso de que no estemos en sesión de debug la función simplemente no hace nada, lo cuál resulta muy cómodo.

Ordenar Datagrid por fecha

ripoblet — Fri, 13 Jun 2008 08:51:44 +0000

Comienzo mi posteo en este gran sitio con una respuesta que realicé en la lista de correos de madeinflex.
Consideremos que tengo un un datagrid que recibe un ArayCollection como Dataprovider, el campo de fecha se llama FECHA y se encuentra en el formato "dd/mm/yyyy hh24:mi" por ejemplo ahora cuando escribo este correo es: "11/06/2008 09:24" , ahora si la fecha que tienes es sin horas, más simple aún.

La solución será utilizar una función llamada "sortFechas" sea capaz de comparar las fechas.

En la columna del datagrid coloca la funcion que realizará la comparación entre tipos de datos de fecha correctos, es decir "date". Sin embargo como mi dataprovider tiene la fecha como "String", debo transformarla en formato "Date" para así poder utilizar una función de comparación de la clase ObjectUtil llamada "dateCompare".

Primero creamos la funcion que transformará la fecha en formato string a la fecha en formato date, la llamaremos "String2Date". (No explicaré la función, pero no es nada difícil de entender, lo básico en cortar con split el string).

Primero creamos la funcion que transformará la fecha en formato string a la fecha en formato date, la llamaremos "String2Date".
Segundo creamos la funcion que hará la comparación de fechas en formato date, llamada "sortFechas"
Indicamos a la columna del datagrid cómo ordenar la columna conla propiedad "sortCompareFunction"

En un ejemplo completo :

El código fuente está aquí ordenarfechasendatagrid.zip

Si tiene una fecha más simple como por ejemplo DD/MM/YYYY entonces es más fácil y sólo modifiquen la funcion "String2Date"

Espero que les sirva, saludos a todos.

ripoblet

Protocolos de comunicación

Aritz Oruesagasti — Thu, 12 Jun 2008 09:17:43 +0000

Es conocido que Flex ofrece diversas formas para la comunicación con el servidor: HttpService, WebServices, RemoteObject, Image, FileReference, Mensajería... pero cuáles son los protocolos que se emplean por detrás? Cuántos protocolos se pueden utilizar en Flex? Cuál es la diferencia entre AMF, HTTP y RTMP? Este post pretende aclarar estas y otras cuestiones sobre los protocolos de comunicación utilizados por Flex.

Protocolos soportados por Flex

Flex soporta sólo dos protocolos de comunicaciÃƒâ€ºn: HTTP y RTMP. Realmente, utilizando Sockets puede llegar a soportar cualquier protocolo, pero fuera de HTTP y RTMP (con sus sucedáneos:HTTPS, etc.), toda la implementación del protocolo la tiene que hacer el usuario.

HTTP (Hypertext Transfer Protocol)

Es el protocolo de Internet por excelencia. Su puerto por defecto es el 80. Los datos que se transmiten van en formato plano. La gran ventaja sobre RTMP, es que ofrece la seguridad de que ningún firewall de ninguna empresa va a ser obstáculo.

La desventaja que tiene es que es un protocolo unidireccional. No permite el data-push por parte del servidor al cliente. Se puede intentar emular esta capacidad con la técnica conocidad como polling, que no es más que hacer que el cliente le pregunte cada cierto tiempo al servidor si hay alguna novedad o no. Esta técnica puede incrementar de forma considerable el tráfico en la red.

Estos son los componentes que utilizan el protocolo HTTP: HTTPService (métodos GET, POST, HEAD, OPTIONS, PUT, TRACE, y DELETE), WebService (SOAP encapsulado en HTTP), FileReference (método POST para subir y bajar ficheros, tambiÃƒË†n GET para el paso de parámetros) e Image.

También se utiliza HTTP en los distintos servicios del Adobe LifeCycle Data Services (LCDS en adelante), dependiendo del canal escogido (ver apartado AMF).

HTTPS (Hypertext Transfer Protocol over Secure Socket Layer, la versión segura de HTTP), es otra de las opciones a la hora de intercambiar datos con el servidor. Su puerto por defecto es el 443.

RTMP (Real Time Messaging Protocol)

Protocolo propietario de Adobe. Puerto por defecto: 1935

Ofrece dos grandes ventajas:

Permite data-push desde el servidor al cliente.
Permite el streaming de audio, video y datos en Internet (con LifeCycle Data Services sólo datos, con Flash Media Server audio, video y datos, con WebORB.NET también audio y video.

Su gran desventaja radica en que los firewalls de algunas empresas, por cuestiones de seguridad, pueden tener capado el puerto 1935 o directamente el protocolo.

Para solventar este problema sin perder la funcionalidad se desarrolló RTMPT (Real Time Messaging Protocol Tunneled). Este protocolo encapsula los datos RTMP en peticiones válidas HTTP, y por lo tanto, la comunicación se hace a través del puerto 80, superando el bloqueo de los firewalls. Lógicamente, requiere algo más de ancho de banda que el RTMP, por las cabeceras HTTP y puede ser algo más lento, sobretodo en el establecimiento de la conexión. Tanto LCDS como WebORB.NET soportan RTMPT. FluorineFx lo hará en la siguiente versión.

También existe la versión segura de RTMP (RTMP sobre Tranport Layer Security), llamada RTMPS, que tiene al mismo problema con los firewalls que su versión no segura. Por ello, se pueden encapsular los datos RTMP en HTTPS. A esto se le llama RTMPS tunneled.

El protocolo RTMP lo emplea el bus de mensajería de LCDS, si el usuario escoge un canal RTMP.

AMF (Action Message Format)

Protocolo binario de Adobe que va por la versión AMF3 (han publicado recientemente su especificación). Aunque por el nombre de la versión pueda parecer que existan 3 cabe destacar que sólo existen dos: AMF0 y AMF3. Una de las mayores diferencias o mejoras que aporta AMF3 es que soporta datos binarios (ByteArray) y int, datos no soportados por AMF0 debido a que en la época que apareció el formato, Flash Player no soportaba estos tipos de datos.

AMF3 no es un protocolo para transferir información (como sÃƒÅ’ lo son HTTP y RTMP), sino que representa el formato en el que se transmite la información, en este caso un formato binario. El AMFGateway que se encuentra en LCDS (y sucedáneos) serializan y deserializan automáticamente los objetos debidamente serializados desde FlashPlayer.

Utilizando LCDS (o similares), todos los mensajes/llamadas, con RemoteObject, FlexMessaging y DataManagementeServices van en formato AMF. Puede ser AMF sobre HTTP o AMF sobre RTMP. Es decir, en los ficheros XML de configuración de estos servicios (remoting-config.xml, mesagging-config.xml, etc.), cuando se definen canales, el usuario escoge entre HTTP y RTMP, aunque el nombre de los canales disponibles sea:

mx.messaging.channels.AMFChannel : AMF3 sobre HTTP
mx.messaging.channels.RTMPChannel : AMF3 sobre RTMP
mx.messaging.channels.SecureAMFChannel : AMF3 sobre HTTPS.
mx.messaging.channels.SecureRTMPChannel : AMF3 sobre RTMPs
mx.messaging.channels.SecureHTTPChannel : Datos en formato texto sobre HTTPS.

Sockets

Los socket permiten al usuario crear cualquier conexión con cualquier protocolo (que el servidor pueda atender, claro). Eso sí, implementándolo de forma manual. Se puede crear una aplicación Flex que sea un cliente FTP, o que se conecte a servicios como POP3, IMAP y SMTP. Pero lo dicho, es el usuario quién tiene que gestionar todo y cumplir lo que establezca el protocolo.

Bueno, pues hasta aquí con los protocolos en Flex. Espero haber aclarado un poco este tema. Y seguro que podemos ir completando la información con los comentarios.

Tres puntos a recordar al crear una libreria

Xavi Beumala — Tue, 10 Jun 2008 22:56:37 +0000

Utilizando compc o bien, desde FlexBuilder, podemos crear librerías de código en ActionScript y/o mxml que luego podemos distribuir en formato .swc a terceros ya sea por comodidad, porque nos dedicamos a vender librerías de código, porque es una forma de paquetizar conocimiento, fomentar la reutilización o por cualquier otro motivo.

La cuestión es que para que la librería se vea lo mejor acabada y profesional posible deberíamos considerar siempre los siguientes puntos:

Desvincular la SDK de Flex

Es muy probable que en tu librería exista alguna referencia a cualquier clase de la SDK de Flex, ya sea debido a que alguno de tus componentes hereda de alguno de los base, porque utilizas alguno de sus managers o clases de utilidad o bien porque has paquetizado algun mxml en ella. En cualquier da estos casos, el linkador, detectará las dependencias directas de tus clases con las de la SDK. Este proceso será un proceso en cascada que detectará todas las interrelaciones incluso dentro de la misma SDK. Por ejemplo, si estas paquetizando una clase que no tiene nada, que simplemente herede de mx.controls.Button tu librería pesará entorno a los 200K debido a las dependencias que tiene Button con todo el resto del framework. Todas estas clases se añadirán pues a tu librería.

NOTA: Esto no es una forma de reducir el tamaño final de los swf's

El concepto es correcto, pero el 99% de los usuarios que utilicen tus librerias no van a necesitar esas clases ya que cuando compilen sus proyectos con tu librería igualmente tendrán las clases de la SDK (resultando con el mismo tamaño final).

Por lo tanto podemos hacer que no se incluyan las dependencias de la SDK en la librería. A priori no notaremos una gran mejora en los tiempos de compilacion (aunque un poquito sí). Si estamos distribuyendo la libreria entonces sí que podemos ahorrar un poco de ancho de banda y mejorar los tiempos de descarga.

Para no añadir la SDK a la librería, en FlexBuilder, tenemos que ir a las propiedades del proyecto > "Flex Library Build Path" > "Library Path". Ahi cambiamos la opcion "Link Type" de framework.swc para que sea "External".

Crear un manifest.xml

Tomando como ejemplo los componentes paquetizados en la SDK de Flex, siempre que añadimos uno a un .mxml el componente se instancia con una sintaxis parecida a siendo el único namespace que se usa siempre mx. En cambio cuando hacemos nuestras propias librerias siempre se utiliza como namespace la última parte del package donde se encuentra el componente que estamos instanciando. De esta forma si tenemos componentes en paquetes distintos i.e: com.madeinflex.package1 y com.madeinflex.package2 se nos instanciaran los componentes de la forma o .

La verdad es que luego, el uso de la librería, es bastante molesto ya que se terminan declarando un sinfín de namespaces en el xml que ensucia bastante el código. Por otro lado no se puede saber con un simple vistazo a qué librería pertenece un componente concreto. Se tiene que ir a la definición del namespace, mirar cuál es su package y luego ponerle un poco de imaginación.

Para solventar esto FlexBuilder y compc ponen a nuestra disposicion los manifest, asociados a un namespace. Un manifest no es mas que un fichero xml en el que se declaran, en la forma clave / valor, los componentes contenidos en una librería. Por ejemplo:

En FlexBuilder, para asociar un fichero de manifest a un namespace lo tenemos que hacer a través del panel de propiedades del proyecto. En el subapartado "Flex Library Compiler" definiremos el namespace y le vincularemos el fichero. Si declaramos que el nombre de espacios sea http://www.madeinflex.com/mif entonces podremos instanciar los componentes de la siguiente forma:

Destacar aquí que podemos definir el id de un componente con un nomre distinto al de su clase.

Otra cosa a considerar cuando paquetizamos una libreria es que muy probablemente no queramos que el programador que la utilice tenga acceso o pueda visualizar todas las clases que hemos paquetizdo. Puede haber clases de utilidades, superclases, clases de soporte, etc. que deberían ser transparentes y no mostrarse al integrador. Si declaramos un manifest para la librería y no declaramos en él estas clases el code autocomplete no se las mostrara aunque si que estarán en la librería y por lo tanto todo compilará correctamente.

Crear un design.xml

Puede que esta funcionalidad haya pasado desapercibida para muchos pero creo que es imprescindible para terminar de paquetizar bién una libreria y darle el toque final.

Al definir el namespace http://www.madeinflex.com/mif, por defecto FlexBuilder al instanciar un componente suyo lo hace de la forma , es decir utilizando madeinflex como prefijo para el namespace en vez de mif o cualquier otro. Al hacer esto parece que no podamos asignar a un mismo dominio distintos namespaces. Pero la SDK de flex si que lo hace no? xmlns:mx="http://www.adobe.com/2006/mxml".

Este es uno de los objetivos que tiene el fichero design.xml, poder definir el prefijo que FlexBuilder utilizará por defecto al instanciar un componente de la librería.

Otro aspecto que podemos pulir un poco más tiene que ver con la perspectiva de diseóo dentro de Flex Builder. Para los que la habéis utilizado habréis visto que en la vista "Components" aparece un árbol jerárquico con los distintos componentes que se pueden arrastrar al mxml. Por defecto todos los componentes o clases que se puedan instanciar visualmente dentro del proyecto aparecerán en la categoría Custom. Pues bién, a través del fichero design.xml podemos hacer que los distintos componentes paquetizados en una librería aparezcan jerarquizados como creamos más conveniente.

En este ejemplo estamos definendo que el prefijo para el namespace http://www.madeinflex.com/mif sea mif y tal como se ve en la figura, definimos dos categorias de componentes: MadeInFlex_1 y MadeInFlex_2 a las que asociamos respectivamente los componentes Component1 y Component2. Donde Component1 y Component2 son el atributo id del componente declarado en el manifest.xml.

Para que estos cambios surjan efecto tenemos que forzar al compilador a añadir el fichero desing.xml a la librería. Para ello abrimos el panel de propiedades del proyecto >> Flex Library Build Path >> Assets y ahi marcamos tanto el manifest.xml como el design.xml. Esto hará que, aunque no sean ficheros referenciados desde el código y a los que por lo tanto el linker jamás llegaría, los añada al swc final.

Para rizar el rizo, podemos terminar de paquetizar nuestros componentes personalizando el icono que se utiliza en el árbol jerárquico. Para ello lo único que tenemos que hacer es utilizar el siguiente tag de metadatos en la clase que define el componente [IconFile("icono.png")]. Donde icono.png hace referencia al fichero que queremos utilizar como icono. El fichero referenciado se toma con una ruta relativa respecto a la clase que lo incluye. Destacar tambien que para que el icono se cargue éste se tiene que haber añadido a la compilacion (igual que hemos hecho con design.xml). Si se cambia el icono de una librería se tiene que reiniciar eclipse para que los cambios se vean reflejados.

Te puedes descargar aqui los proyectos utilizados en los ejemplos.

Guía práctica de ActionScript 3.0

Xavi Beumala — Thu, 24 Apr 2008 12:25:35 +0000

Este es el nombre del libro en el que hemos estado trabajando los últimos meses con Joseba y con Dani.

La verdad es que ha sido una experiencia genial, aunque hemos tenido bastante trabajo, invertido bastantes horas y bastantes reescrituras, me quedo sobretodo con la mucha ilusión y muchas ganas que hemos puesto en ello. Espero que lo disfruteis tanto como hemos hecho nosotros mientras lo escribíamos.

Aún y tratarse de un libro de nivel medio y no muy extenso (algo más de 300 páginas) hemos tratado de cubrir todos los aspectos relevantes que presenta ActionScript 3.0 de una forma amena y práctica.

El libro está enfocado tanto aquellos que quieran empezar como a aquellos que ya conocían AS.2 y quieran dar el salto a AS.3. Aunque estoy seguro que aquellos que ya trabajáis en AS3 encontraréis alguna cosa útil en él.

Los ejemplos están enfocados desde una vertiente Flash, pero la compatibilidad es 100% con Flex. Sin que se llegue a tratar específicamente nada concreto de Flex, lo podéis tomar igualmente como referencia de lenguaje.

Este es el índice del libro:

Introducción a Actionscript
Variables y tipos de datos
Operadores
Estructuras de control
Programación Orientada a Objetos y Flash
Eventos
Estructuras de datos
Paquetes en el Flash API
Usando la Display List
Filtros en Flash CS3
Trabajo con campos de texto
XML
Efectos matemáticos
Transiciones en Flash CS3
Vídeo en Flash
Manejo de sonido en AS3
Papervision: 3D en Flash
Recursos y enlaces

El libro aún no está a la venta, seguramente estará en las librerías en Junio, pero para que empeceis a hacer boca Anaya, gracias Eugenio!, nos ha dado permiso para distribuir gratis el capítulo de XML y e4x. Así que aquí lo teneis!.

Si todo va bien, este será sólo el comienzo

Shortcuts, shortcuts, shortcuts…

Xavi Beumala — Thu, 10 Apr 2008 15:19:41 +0000

No sé qué haría sin ellos! Creo que su utilidad está justificada antes de explicarlos pero por lo que voy viendo en las sesiones que hago y cursos hay aún shortcuts desconocidos en lo que refiere a Flex Builder.

Así que aquí va un pequeño resumen de los shortcuts sin los que no podría vivir:

ctrl + shift + R: Abre una ventana en la que, usando search as you type, podemos localizar cualquier clase de los proyectos que tengamos abiertos. La gracia es que no tenemos que acordarnos del package, ni de la carpeta donde está. Además podemos usar wildcards por si ni tan siquiera recordamos el nombre exactamente.

ctrl + shitf + T: En la misma linea que el anterior, pero perimite buscar clases de la SDK o de cualquier librería que tengamos referenciada en el proyecto. Este es muy útil para navegar por las clases de la SDK.

F3: Tiene varias funciones dependiendo del contexto en el que nos encontremos. Si estamos editando una clase y tenemos el cursor encima del nombre de una clase, al pulsar F3, iremos al fichero de esa clase. Si el cursor está encima de una variable, el cursor se desplazará a la definición de esa variable. Si el cursor está encima de la invocación a un método se abrirá la clase y posicionará el cursor en la definición de ese método.

ctrl + click: Si pulsamos la tecla control y movemos el ratón por encima de los elementos estos se mostrarán subrayados. Haciendo click navegaremos a la definición de ese elemento.

ctrl + shift + c: Si tenemos un bloque de código seleccionado y pulsamos esta combinación , el código se comentará.

ctrl + shift + /: Ídem pero con comentarios a nivel de linea. Ambos los podemos utilizar tanto para comentar como para descomentar.

ctrl + espacio: Si estamos escribiendo el nombre de una variable, de un método o de un clase y pulsamos esta combinación, aparecerán las posibles opciones para autocompletar. Si sólo hay una opción directamente se autocompletará. En el caso de tratarse de una clase, si es necesario, se añadirá el import de forma automática. Si pulsamos esta combinación mientras editamos el package automáticamente se añadirá el package que toque correspondiente a la anidación de carpetas.

ctrl + shift + espacio: Con el cursor, y en el contexto de una invocación a un método, nos aparecerá la firma del método que estamos invocando. De esta forma podemos ver qué es cada parámetro así como los nombres de los atributos.

shift + F2: Si tenemos una propiedad, un método o una clase seleccionada se abrirá la documentación contextual de ese elemento.

ctrl + alt + g: teniendo el cursor en un método, nos mostrará las referencias a ese método desde otras clases.

ctrl + o: Editando una clase nos aparecerá un Outline de los métodos y atributos de esta. Es una ventana con funcionalidad search as you type, de tal forma que podremos escoger el punto del código al que queremos ir de forma muy fácil.

ctrl + shift + D: Añade un bloque CDATA (sólo mientras editamos un mxml).

ctrl + f: Abre la ventana de buscar y reemplazar texto. Yo normalmente y para mayor comodidad tengo las opciones de wrap search e incremental marcadas.

ctrl + j: Lo mismo que antes pero sin abrir ninguna ventana. Tal cual empezamos a escribir el cursor irá cambiando de sitio.

ctrl + k: Después de hacer una búsqueda (tanto con ctrl+f como con ctrl+j) nos posiciona en el siguiente resultado. Un uso que utilizo mucho es, seleccionar una palabra, y pulsar ctrl+K. Lo que hace es ir a la siguiente ocurrencia.

ctrl + shift + k: Igual que el anterior pero en vez de buscar hacia adelante busca hacia atrás.

Mark ocurrences: Ãƒâ€°ste no es un shortcut, pero ayuda muchísimo. Si tenemos activada la opción (ver imagen) tendremos siempre señalado en el código las ocurrencias del elemento que tengamos debajo del caret.

ctrl + d: Elimina la linea donde esté posicionado el caret. Si tenemos varias selecionadas las borra todas.

ctrl + alt + {UP_ARROW | DOWN_ARROW}: Duplica arriba o abajo las lineas que tengamos seleccionadas. Si no tenemos ninguna seleccionada duplica la linea donde esté el caret.

alt + {UP_ARROW | DOWN_ARROW}: Mueve las lineas seleccionadas hacia arriba o hacia abajo. Muy bueno para reorganizar el código sin tener que andar copiando y pegando.

ctrl + F11: Lanza en modo debug la última compilación que hayamos hecho.

ctrl + shift + F11: Lanza en modo run la última compilación que hayamos hecho.

ctrl + b: Si no tenemos la compilación automática activada (recomendable no tenerla) compila el código.

ctrl + alt + r: Teniendo el caret encima del nombre de una variable, clase o método lanza un proceso de refactor a través del que podemos cambiar su nombre en todo el código (no sólo en la clase que esté abierta).

ctrl + alt + [LEFT_ARROW | RIGHT_ARROW]: Cuando estamos editando código en varias clases, estas flechas permiten ir al punto anterior en el que se ha estado editando. Es como un deshacer de la posición del cursor entre clases.

ctrl + w: Cierra la clase que estemos editando.

ctrl + shift + w: Cierra todas las clases que tengamos abiertas.

ctrl + g: Busca todas las declaraciones del tipo que tengamos debajo del caret.

ctrl + shift + g: Busca todas las referencias del elemento que tengamos debajo del caret.

ctrl + m:Maximiza el editor que tenga el foco en ese momento.

ctrl + L: Ir a la linea que indiquemos.

ctrl + tab: Nos permite movernos por las distintas clases que tengamos abiertas.

ctrl + shift + b: Añade un break point en la línea donde esté el caret.

shit + enter: Añadir una linea por debajo de la del caret y empezar a escribir (respetando el indentado).

ctrl + shift + enter: Ídem que el anterior pero añadiendo la línea por encima.

Dejo para otro post los que tienen a ver con el Debug.

Si alguno de los shortcuts no os funciona o directamente no os convence la combinación de teclas recordad que las podéis modificar desde el panel de preferencias de Flex Builder en la sección "keys".

Para los que nos esteis acostumbrados a usarlos quizás os parezcan muchos, incluso demasiados, pero la verdad es que cuando uno se acostumbra la vida le es más fácil, e incluso los puede escribir de una atacada

¿ Cuáles usais vosotros ?