Dando la chapa

Bueno, no tanto como loving it, pero ya se sabe que la verdad no puede arruinar un buen titular. Ni siquiera un titular.

El caso, ando usando Flex para la interface de HippoHX que espero salga en la próxima versión. Me he decidido por Flex en lugar de GTK más que nada por un tema de mi productividad (Flex es “sólo” un framework para Flash, una plataforma que ya conozco) y de mis perspectivas laborales.

Las primeras impresiones son bastante positivas en el sentido de que hace lo que espero que haga. Acostumbrado a picar mis propios componentes, mis lógicas de reescalado, posicionamiento, etc. de repente construir en una hora una interface con CheckBoxes, TextAreas, Tabs, que se adapta sin problemas a distintos tamaños… es gratificante porque me permite dedicarme a lo importante que es la funcionalidad.

Pero claro, la fama cuesta y Flex no es una excepción. El nivel de detalle gráfico baja bastante. Si tienes una interface que necesitas diseñar al milímetro, olvídate. El peso también es considerablemente más elevado. Normal, estás compilando un framework MUY grande del que seguro no estás usando el 100% (aunque nunca lo haces con los frameworks). El ciclo de vida de los componentes de Flex te obliga a hacer las cosas en un orden muy determinado que, todo sea dicho, aun no tengo muy controlado*. Y como no hagas las cosas en el orden Flex, vas apañao.

Si alguien quiere echarle un ojo a mis andanzas, puede bajarse o ver el código en Google Code, dentro de tools > gui.

Y para Flasheros que quieren bichear con Flex, el mejor tuto que he encontrado que explica la relación entre AS3 y MXML es este de Xavi Beumala que ya tiene un tiempito: MXML vs AS3.

Salud!

* Si alguien conoce un tutorial (inglés o castellano) claro y conciso sobre el ciclo de los componentes en Flex, soy todo oidos. Todo lo que encuentro lo veo poco claro.

Y es que se toman decisiones sobre nuestro futuro como desarrolladores sin que nosotros tengamos mucho que decir al respecto. Los datos:

- Ecma estaba y está preparando el borrador de lo que se considera EcmaScript 4. JavaScript y ActionScript están basados en ese estandar. JS y AS son los motores de la internet cliente, los navegadores. Así que lo que le pase a la especificación EcmaScript es, digamos, importantillo.

- Adobe y Mozilla quieren darle un buen empujón a EcmaScript 4 (ES4 para los amigos) porque JS es fundamental para Mozilla (no sólo por Firefox, también por XUL) y para Adobe porque AS3 estaba muy, muy cerca del borrador de ES4. Además, ayuda a vender ActionScript como un lenguaje estandar y no propietario. Eso sin contar que Adobe liberó en su día Tamarin, una máquina virtual para lenguajes ES4 que es la que Mozilla pretende integrar en FF.

¿Quién falta en la escena? Microsoft, claro. ¿Que qué dicen? Que a ellos no les parece bien darle un empujón muy fuerte a ES4, que mejor lo dejan en ES3.1. ¿Y por qué no quiere MS darle caña y convertir a JS en superguerrero? Ellos dicen que porque los cambios tienen que ser “suaves”. Los mal pensados dicen que porque ya tiene .Net y Silverlight. La verdad es que no hay ni buenas ni malas intenciones, sólo compañías utilizando buscando su propio beneficio. Otra cosa es las tácticas que utilicen para conseguir ese beneficio propio.

Pero un comentario de Grant Skinner sí que me ha dado que pensar: Ya me jodería a mi si yo fuera desarrollador JS. Contando conque van a ir a por ES3.1, más el tiempo que tarden en integrarlo los navegadores, más el tiempo hasta que saquen ES4, más el tiempo que tarden en integrarlo…. Estamos hablando fácilmente de… ¿8 años? JavaScript va a estar prácticamente como está ahora los próximos 8 años.

Allá por 1999, JS y AS estaban a la par. 9 años después AS3 es muy diferente de AS1 (mucho mejor diría yo, pero eso es casi cuestión de gustos). En otros 8 años, vaya usted a saber. Parece que el software propietario le ha ganado la partida al software que es un estándar y que su evolución depende de que empresas con intereses muy dispares se pongan de acuerdo. Parece que Adobe/Macromedia le ha venido muy bien poder tomar decisiones sobre cómo evolucionar el lenguaje y la máquina virtual sin tener que esperar a los demás.

Lo bueno de todo esto es que a lo mejor volvemos a tener constructores privados en AS4 :)

Posts unos cuantos sobre el tema: Cristalab, Hank Williams, Nicolas Cannasse 1 y 2, Slashdot, Mozilla, Grant Skinner…

Estoy viendo algo bastante raro. Según la documentación el objeto NetStream necesita un objecto SoundTransform para modificar el sonido. Benne.

Pero resulta que para que cambie el volumen (supongo que para las otras propiedades también) hay que “reasignar” el objeto SoundTransform de nuevo… Algo así:

—————————————————————————
var st:SoundTransform = new SoundTransform(1,0);

var ns:NetStream = new NetStream();
ns.soundTransform = ts;

(en otra función)

st.volume = 0.5;
ns.soundTransform = ts; // sin esta linea el volumen no se actualiza
—————————————————————————

Lo podéis ver funcionando en ZVideo (un wrapper en AS3 para simplificar el uso de vídeo) y también lo he encontrado en un player libre de vídeo de SourceForge: AS3 FLV Player.

¿Estoy empanao o esto funciona realmente así y simplemente llego tarde? No entiendo por qué si el objeto NetStream tiene una referencia al SoundStream hay que volver a asignársela para que surtan efectos los cambios.

Hace unos días preguntaba en ASNativos si en AS3 se podía cambiar el tipo de una variable heredada. En concreto cambiar el tipo a una clase que hereda de la original. Pues parece que no es posible.

Es decir, tengo clase B que hereda de A. Clase A tiene una propiedad tipo X y yo quiero que la clase B modifique el tipo de X a un hijo de X (sí, este párrafo se entiende peor que el anterior).

¿Y para qué? Pues para ZCode. En mi MVC base tanto el modelo como la vista tienen una instancia del otro. Ahora, la aplicación Pepito tienen las clases PepitoModel y PepitoView por lo que la instancia de la vista de PepitoModel debe ser tipo PepitoView, no View. Es precisamente por eso que NO me vale una interface ya que no sé a priori qué métodos va a necesitar PepitoView. Me vale lo que hacía en AS2, modificar el tipo de una variable al heredar, como aquí:

Modelo/vista general:

http://code.google.com/p/zcode/source/browse/trunk/as2/tv/zarate/application/Model.as
http://code.google.com/p/zcode/source/browse/trunk/as2/tv/zarate/application/View.as

Modelo/vista específico:

http://code.google.com/p/zcode/source/browse/trunk/as2/tv/zarate/projects/webv3/WebModel.as
http://code.google.com/p/zcode/source/browse/trunk/as2/tv/zarate/projects/webv3/WebView.as

Pues parece que no es posible en AS3. Lo mejor que me he encontrado es hacer algo como esto:

private function get view():PepitoView{
return _view as PepitoView;
}

Pero claro, entonces PepitoView tiene 2 variables _view y view, lo cual es una mala ñapa. Como dice Cay la otra sería utilizar view:*, no sé qué es menos malo.

¿Otra ideas felices? ¿Algún superpatrón al rescate?

O mejor piénsatelo antes de declarar en AS3 un método privado. Cuando lo haces nada ni nadie puede sobreescribirlo, ni siquiera las clases que extiendan la tuya. Si crees (aunque sea remotamente) que vas a necesitar sobreescribir esos métodos o propiedades, mejor cúbrete las espaldas declarándolos “protected”. Un rápido resumen de cómo se comportan los modificadores de acceso en AS3 se puede ver aquí.

De hecho, en una de las últimas charlas del LFPUG Tink comentaba que uno de los problemas con los que se encontraban con los componentes oficiales (creo que los de Flex) era que muchas veces intentaban heredar de ellos para hacer algunas modificaciones hasta que se encontraban con un método privado y entonces estaban en un callejón sin salida.

Pero bueno, por fin estoy metiendo el cuezo con AS3 y la verdad es que mola bastante. Entiendo que a alguna gente le parezca un poco coñazo (temas como tener que importar muchas más clases explícitamente) pero da la sensación de mucho más robusto y deja bastante claro que AS2 no fue más que una mala manera de parchear la AVM1 para darle un poco de consistencia al lenguaje.

El sistema de eventos tiene buena pinta, E4X es un lujo porque tienes XPath de serie y mucho más conciso, utilizar URLLoader y URLRequest parece mucho más largo pero unifica el método de carga de todos los elementos externos (XML, imágenes, sonidos, etc)… No sé, estoy en el medio de portar ZCode a AS3 y por ahora va bien, ya iré contando como va todo y lo que me gusta y lo que no.

¡AS3 se está poniendo muy serio!

Acaba de ser anunciado en OSFlash FZip, una librería escrita en AS3 que permite cargar un zip y descomprimirlo dentro de Flash para obtener su contenido.

Es una primera versión que no está completa, pero promete.

¡Yeah!