¿Cuál es la ventaja real de cargar código AS 3.0 externo?

Hola:

Mi metodología es la que metí entre parentesis. Intento separar, más por ordenarme mentalmente que por otra cosa, la programación de la parte gráfica. Flash lo utilizo para la parte gráfica/diseño, como queráis llamarlo, exporto la biblioteca y me paso a Flex para escribir el código. Antes con AS2 utilizaba SEPY. Es la forma en la que más a gusto me siento.

Un saludo.

Entonces es que te he entedido mal. De los siguientes parrafos:

tpmmds

Pero bueno, si hay alguien que realmente está empezando con Flash (AS2 o AS3) sí le recomendaría que se acostumbre desde un principio a escribir código sólo en el Frame 1 (lo ideal sería hacerlo en un archivo "as" de la clase del documento, pero bueno, para el que empieza sí puede ser duro Sad ).

Aparte de la ventaja indiscutible de tener TODO el código en el mismo sitio y no andar buscando si hay un trocito en el frame 37 del movieClip "ocultarBotonPrincipal", hay otra relacionada con el RENDIMIENTO de la aplicación. Haz el siguiente ejemplo con Flash CS3:

...entendía que tu metodología se basa en meter todo o la mayor parte del código en el 1er frame de la aplicación. Ya sean funciones o sea una clase. Yo he visto aplicaciones desarrolladas así, de hecho me acuerdo que la clase principal se llamaba "Orquestator" y controlaba movieclips con una profundidad de anidación alta. Ello implicaba una clase "kilométrica" con referencias en plan "this.mc_1.mc_hijo1_mc_nieto2.otro_mc.miMetodo()"
La ventaja principal que se esgrimía era que se tenía todo el código centralizado. Yo la veía como la principal desventaja. Yo a un Orquestator de esos le quitaba el 95% de código y lo dejaba en una entidad que tan solo emitiera una serie de eventos para determinadas ciscuntancias.

Lo mismo lo que realmente comentabas y no te he malentendido es que la buena praxis dicta que en cada movieclip/elemento de librería que tenga código, éste deba estar en el primer frame, con lo que estoy totalmente de acuerdo y añadiría que todo el código esté distribuido en funciones y con una única función de arranque (un init() por ejemplo que hace mas o menos de constructora). Todo esto al margen de hacerlo realmente bien y extender movieclip (en AS3 que en AS2 casi mejor que trabajar por composición) y vincular el elemento de librería a esa clase.

En fin, siempre es un placer hablar de estas cosas.

un saludo.

Hola:

El ejemplo llevaba la intención de mostrar lo que alguien que está empezando puede hacer sin darse cuenta, no lo que haría un avezado programador :-) .

Lo que sí que no entiendo es el comentario sobre las clases kilométricas, que para tocar la funcionalidad de algo tengas que conocer la estructura del resto. A mí me parece que es todo lo contrario. La gran ventaja de la POO es que sólo tienes que centrarte en el punto que estás desarrollando de tu aplicación en cada momento. Y esto es lo que permite, por ejemplo, utilizar Papervision3D, Tweener, SwfAddress, SIN CONOCER nada de cómo están hechos. Sólo necesitas conocer la API del paquete que estás utilizando; ahora bien, que eres un valiente... pues te buscas la clase que te interesa y la modificas a tu gusto, que para eso son open source :-) .

Un saludo.

Yo creo que aquí se está hablando de 2 conceptos distintos.

1) Externalización del código fuera del .fla
2) Unificación de TODO el código de la aplicación en 1 frame.

Puede ser que externalices todo el código pero lo externalices en mil archivos que estén vinculados a diferentes movieclips o instancias las cuales tengan diferentes profundidades de anidación. Por lo tanto la opción de externalización no va vinculada a la opción un unificación del código.

Mi opinión, basada en 10 años programando partiendo de un perfil inicial de diseñador que ha ido adquiriendo nivel de programación, es que la externalización es una opción de desarrollo, aveces importante y recomendable bajo determinados entornos de desarrollo (producciones grandes con varios programadores desarrollando a la vez por ejemeplo) y que te permite utilizar herramientas muy interesantes como FlashDevelop que aumentan tu productividad y que te permiten exprimir mas aun las ventajas de un gestro de versiones por lo que se ha comentado de que los .as no son binarios, etc pero es una opción de desarrollo.

Mas importante en mi opinión es la arquitectura. En ese punto creo que discrepo de "tpmmds". Por lo que he leido la arquitectura de "tpmmds" se basa en tener un organizador, orquestador central que aglutine todo el código y desde ahí controlar todas las entidades. Si lo he entendido mal sorry. Este tipo de arquitectura suele llevar a clases o pedazos de código kilométricos donde para tocar la funcionalidad o comportamiento "local" de una instancia debes conocer la estrutura del resto de la aplicación.

Yo prefiero delegar y delegar responsabilidades a entidades o subentidades y que cada una sea muy especialista en lo suyo y desconozca lo maximo posible que hay por arriba o por debajo. Intento considerar una aplicación como la suma muchas mini-aplicaciones. Eso si en cada mini-aplicación el código en el primer frame en clases o en su defecto todo en funciones. Pero esta forma de estructurar huye de unificar en un sito el código y aboga por recortar el problema en mini problemas y atacar cada uno por separado.

Ello implica recortar el código en muchos mini-codigos. Puede implicar cierta complejidad a la hora de buscar el fragmento de código que controla una entidad (el cual puede estar externalizado o metido en el mc) pero se puede subsanar con orden y metodología.

Tambien pienso que en ocasiones trabajar con el timeline te puede ahorrar muchas lineas de código. Estoy de acuerdo con "tpmmds" cuando dice "Lo importante en la programación es tener varias estrategias para aplicarlas según sea el caso." Bueno pues el timeline te abre una opción mas. Programar ese timeline con código presente en ese timeline puede ser mas sencillo que programarlo desde una superclase o desde el primer frame del Stage (o _level0 en AS2).

Por ultimo no entiendo el ejemplo de meter:

import fl.controls.Button;
addChild(new Button());
trace(numChildren);

...en el 1er frame de un timeline con 2 frames y sin stop(). Creo que si haces eso es que lo estas haciendo algo mal pero no lo veo relacionado a externalizar o unificar código.

En resumen, toma este comentario como que otras opciones son posibles, que hay gente que prima el tener el asunto unificado y otros que lo prefieren delegado. Prueba ambas, ambas tienen sus pros y sus contras, al final se sentiras mas cómodo con una opción.

Hola,gracias por contestar.
A mi que soy un novato,muchas veces me ha pasado encontrar dos tutoriales de un mismo tema con distintos códigos.A veces hay tanta diferencia entre los códigos que me pregunto¿cómo es posible que uno emplee dos veces más código que otro para cumplir la misma cosa.
Ademas en muchos de los tutoriales,borro comandos,porque me parecen inutiles y el resultado no cambia.
Otras veces desharchivo dos archivos de tutoriales,les ejecuto en flash y lo curioso es que un simple efecto de lluvia hace que se cuelge el Flash media player y otra aplicación 3d interactiva con muchos elementos va como un demonio.
Lo que se puede codificar en la frame,lo codificaré en la frame,porque asi me he acostumbrado desde flash 8.
Hasta otra!

Por empezar un proyecto con el código incrustado en vez de en un fichero externo, se petó el flash al publicar y se corrompió el .fla perdiendo dos semanas de trabajo.

Es una buena técnica, reescribir todo desde cero, para mejorar el código. Pero es duro hacerlo sin querer :)

Si usas un control de versiones puedes ver los cambios en un fichero de texto. En un binario como el .fla, es imposible.

Puedes editar el .as en un editor como Dios manda y no en la basura del IDE de Flash. Yo estoy probando SEPY ahora.

Hola, creo que tengo 8 años programando en Flash y entiendo lo que dices, pese a que apenas comienzas creo que te servirá mi respuesta.

El mal programador escribe mucho código (malo). El buen programador escribe mucho código (eficiente). Pero el programador excelente escribe solo lo necesario (dependiendo el caso).

Lo importante en la programación es tener varias estrategias para aplicarlas según sea el caso.

Una buena arquitectura de programación puede ser costosa en tiempo y enormemente compleja y por lo tanto solo vale la pena implementarla en determinados tipos de proyectos.

Una arquitectura simple de código copy pasate en varios fotogramas es sucia pero resuelve mejor los problemas "suigeneris" de proyectos simples y al vapor.

Si eres diseñador multimedia y la programación no es lo tuyo, mejor quédate en la el código por frames, y si quieres ser un poquito avanzado aprende a importar clases que te resuelvan problemas concretos.

Te recomiendo este tópico que habla sobre el costo beneficio de "productividad vs eficiencia"

http://www.alesys.net/foro/viewtopic.php?f=3&p=500

Saludos!!

No pasa nada.Jamas me pondría a hacer comentarios tipo destroyer.
Tan solo ando buscando la información que nececito para realizar lo que tengo en mente y aportar un poco para convertir el internet espacio en lo que hemos visto en las interfaces de las maquinas de las peliculas estilo cyber punk de manga y otras de fantasy.El hardware se desarolla y el software,el diseño también debería.
Y tal vez te parece raro que tengo idea de una cosa y de otra no,a pesar de que es más simple,pero es que como te he comentado antes,ando aprendiendo solo lo que voy a utilizar.Algo como aportar clases-aporto a mi conocimiento solo la informacion necesaria.
¿Al evento de que hablas,se le puede añadir un cargador basado en el porcentaje por ejemplo?Por ser así voy a buscar tutos.Supongo que debería funccionar igual para formatos .ase.
Gracias por la informacion.

Hola:

Lo primero, perdona por el comentario y bienvenido a esto de AS :-) .

Si cargas un archivo Ase, o DAE, exportado de 3DStudio con texturas, Papervision3D se encarga de todo: primero carga la geometría y después va cargando las texturas de los objetos. Si lo que quieres es mostrar el escenario una vez que se han cargado, existe el evento COLLADA_MATERIALS_DONE que se lanza cuando se han cargado todas las texturas. Tendrías que esperarte a que se produjera para mostrar el escenario 3D.

Un saludo.

Es que de verdad estoy empezando.
Gracias por responder.Lo del consejo de Adobe no lo sabia.Una ultima dudita:
¿Al cargar una paguina,se carga todo a la vez o algunos componentes se cargan primeros?
Lo pregunto,porque no he podido evitar fijar me que en un enlaze de papervision,al cargar la pagina,primero se cargó el modelo 3d con un color uniforme y después de poco se le aplicaron las texturas,o sea cobró color y sombras.Parece que primero cargó el modelo Ase y luego la mapa de bits.
Solo pregunto,como antes tuve solo un swf en el localhost y le podía poner una barra de precarga a todo,ahora en cambio voy a tener aparte los modelos 3d,los codigos,las clases...¿En qué orden se carga todo esto?

Hola:

Me he pensado varias veces si responder o no a esto porque me parece el típico post destroyer. Pero bueno, si hay alguien que realmente está empezando con Flash (AS2 o AS3) sí le recomendaría que se acostumbre desde un principio a escribir código sólo en el Frame 1 (lo ideal sería hacerlo en un archivo "as" de la clase del documento, pero bueno, para el que empieza sí puede ser duro :-( ).

Aparte de la ventaja indiscutible de tener TODO el código en el mismo sitio y no andar buscando si hay un trocito en el frame 37 del movieClip "ocultarBotonPrincipal", hay otra relacionada con el RENDIMIENTO de la aplicación. Haz el siguiente ejemplo con Flash CS3:

1. Crea un Archivo Flash AS3

2. Abre el panel Componentes y arrastra el componente Button a la biblioteca:

3. Selecciona en la línea de tiempo el Frame 1 y pulsa F9 para abrir el panel de acciones. Escribe:
<code>
import fl.controls.Button;
addChild(new Button());
trace(numChildren);
</code>
4. Prueba la película, Ctrl Intro

Verás que aparece un botón y en el panel Salida el valor 1. Esto indica que hemos creado sólo 1 botón, que era lo que pretendíamos.

Ahora selecciona el Frame 1 de la línea de tiempo y pulsa F5 para crear dos fotogramas. Si vuelves a pulsar Ctrl Intro verás que en el panel Salida se muestra una sucesión de números 1, 2, 3, .... Esto indica que si nuestra aplicación se reproduce a 24 fps estamos creando ¡¡¡¡12 botones cada segundo!!!!.

Si aún no te crees que esto ralentiza el sistema y estás en Windows abre el Administrador de tareas en la pestaña rendimiento y deja el swf funcionando un rato. Verás como en el primer caso el uso de CPU y la memoria no cambian; en el segundo, la memoria irá subiendo poco a poco, y el uso de CPU estará siempre activo (Flash player no para de crear botones).

Si en una aplicación tan SIMPLE como esta de crear un botón pasa esto... qué puede ocurrir en otra con 8 capas, movieclips anidados, en la que la interface gráfica la creamos en el Frame 78, capa "pantalla principal" del movieClip "pantallaPrincipal". La locura. Y lo que suele ocurrir: botones que no consigues localizar para cambiarles la etiqueta, o hacerlos invisibles momentaneamente, movieClips que no se detienen, aplicaciones que cada vez van más lentas y acaban bloqueando el equipo...

Es cierto también que hay muchos trucos para evitar estos problemas cuando se escribe código fragmentado. Pero, de verdad, si estás empezando, lo vuelvo a repetir: acostumbrate a escribir TODO EL CÓDIGO en el frame 1. Si lo recomienda Adobe/Macromedia, por algo será ;-) .

Un saludo.