Tres puntos a recordar al crear una libreria

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 <mx:Button /> 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 <package1:Componente1 /> o <package2Componente2 />.

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:

[ftf w=”550″ h=”130″]



[/ftf]

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:

[ftf w=”550″ h=”80″]
[/ftf]

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.

[ftf w=”550″ h=”300″]










[/ftf]

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.

Xavi es un Technical Arquitect de Aplicaciones RIA basadas en la Plataforma Flash trabajando para Adobe en Londres. Especializado en aplicaciones colaborativas en tiempo real, e-learning y CMS (Content Management Systems) utiliza Flex, LCDS, BlazeDS, FMS y Java principalmente.

Sitio Web:http://www.code4net.com

4 Comentarios

  1. oscar

    Hola, una gran pagina.

    Una duda?
    Si lo que tengo son solo clases de codigo que uso en flash, deberia crear un Actionscript Project en lugar de un Flex Library project?
    Lo unico que me interesa es tener las clases metidas en un swc.

    Saludos.

  2. Yerson Crespo

    Hola, trate de hacerlo con Flash Builder 4.5, pero no funciona el procedimiento, parece que hay problemas con los archivos XML, sabrías por casualidad cuales son las diferencias ?

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Acerca de Made In Flex

Made In Flex es una comunidad de desarrolladores de Apache Flex creada en 2006.

Apache Flex, anteriormente conocido como Adobe Flex, es un SDK (kit de desarrollo de software) para crear aplicaciones enriquecidas - multiplataforma basadas en Adobe Flash donado por Adobe a la fundación Apache in 2011 y promocionado a proyecto de primer nivel en Diciembre de 2012.

Actualmente estamos cambiando muchos aspectos del sitio web para ofrecer un sitio útil para toda la comunidad que tenga en cuenta las necesidades actuales.

Últimas Fotos

Instalador de Apache Flex

Entrar o Registrase