CODIGO.actionscript » Aportes

Curso de Adobe AIR, online y gratuito, en Video2brain

admin — Tue, 28 Jul 2009 14:35:00 +0000

Para quienes no lo conozcan aun, Video2brain es Centro de formación autorizado de Adobe que ofrece cursos online en vídeo de calidad de numerosas aplicaciones de Adobe.

Actualmente tienen disponible un curso de Adobe AIR totalmente gratuito a cargo de Jorge Glez. Villanueva, responsable de, entre otros, los cursos Adobe Flash CS3 y Adobe Dreamweaver CS3. Este vídeo-training es una introducción en el uso de AIR, para aprender a programar aplicaciones
de escritorio usando los programas de Adobe, Flex y Flash.

Índice del curso:

Descripción del runtime AIR. Instalación de la aplicación
Creación de un ejemplo de xml cargado a través de PHP en un DataGrid que corra como aplicación de escritorio
Creación de un ejemplo simple de drag and drop sobre el escritorio
Creación de una aplicación AIR basada en ActionScript 3. Control de la ventana de la aplicación
Uso de la API de control de ficheros de ActionScript/AIR: crear, copiar, borrar y seleccionar archivos
Uso del drag and drop de AIR. Aplicación que permite arrastrar imágenes al escritorio
Creación de aplicaciones AIR: personalización del icono de las aplicaciones. Uso de certificados

Enlace del curso:

http://www.video2brain.com/es/products-14.htm

Comparte:

ADM, aplicación AIR para editar archivos de configuración

admin — Wed, 01 Jul 2009 03:46:11 +0000

En mi tip anterior escribí una descripción del archivo de configuración de las aplicaciones AIR. Este archivo de configuración lo deberemos editar para definir las características de nuestra aplicación.

Navegando por internet encontré una aplicación creada por David Deraedt que me pareció muy útil. Se trata de ADM (AIR Application Descriptor Manager), una aplicación AIR que nos permite abrir y editar todos los parámetros de un archivo de configuración.

Es una aplicación gratuita que la podemos descargar desde la página del autor:

Descargar ADM

Una vez instalada la aplicación podremos abrir cualquier archivo .XML de configuración de nuestros proyectos AIR, y podremos introducir los parámetros de una manera más cómoda:

Una característica que especialmente me gustó es que te permite generar de forma automática todos los tamaños necesarios para los iconos de la aplicación desde un mismo archivo de imagen:

La página web del autor también tenemos disponible un vídeo para ver una demostración de la aplicación:

En definitiva, una aplicación muy práctica y recomendable para los que generan habitualmente aplicaciones AIR.

Comparte:

Tray Icon animado en AIR

admin — Wed, 20 May 2009 23:36:01 +0000

Autor de post: David Villegas - Dvgmex

Estuve buscando como usar los Tray Ballons en Windows desde AIR, pero al no encontrar hice una alternativa, con mismos mensajes cortos pero en el icono directamente! Algo así como un Tray Icon con Mensaje tipo Ticker. Que además funciona tanto en Windows como en Mac.

Aquí se ve el ejemplo:

Este es el código que utilizo en mi película principal:

import flash.desktop.DockIcon;
import flash.desktop.SystemTrayIcon;
import flash.desktop.NotificationType;
import flash.desktop.NativeApplication;

if (NativeApplication.supportsDockIcon)
{
var dockIcon:DockIcon = NativeApplication.nativeApplication.icon as DockIcon;
}
else if (NativeApplication.supportsSystemTrayIcon)
{
var sysTrayIcon:SystemTrayIcon = NativeApplication.nativeApplication.icon as SystemTrayIcon;
sysTrayIcon.tooltip = "Mi ToolTip \n" + "Flash Version: " + Capabilities.version;
}
var icon16bitmapData:BitmapData = new i16(0,0);
var icon32bitmapData:BitmapData = new i32(0,0);
var icon48bitmapData:BitmapData = new i48(0,0);
var icon128bitmapData:BitmapData = new i128(0,0);
var iconDefaultSet = new Array(icon16bitmapData,icon32bitmapData,icon48bitmapData,icon128bitmapData);

//Carga TrayIconTicker
var MyTrayIconTicker = new TrayIconTicker();
MyTrayIconTicker.Show("MENSAJE INFORMATIVO");

Y este código lo coloco dentro de un MovieClip llamado "TrayIconTicker" que es el que utilizo para animar y crear el icono:

import flash.desktop.DockIcon;
import flash.desktop.SystemTrayIcon;
import flash.desktop.NotificationType;
import flash.desktop.NativeApplication;

var tickerWidth = 128;
var tickerStep = 8;

function Show(sMsg)
{
txtTicker.text = sMsg;
txtTicker.autoSize = TextFieldAutoSize.LEFT;
addEventListener(Event.ENTER_FRAME,myEnterFrame);
}
function Hide()
{
txtTicker.text = ".";
txtTicker.autoSize = TextFieldAutoSize.LEFT;
removeEventListener(Event.ENTER_FRAME,myEnterFrame);
}

function myEnterFrame(event:Event)
{
txtTicker.x = txtTicker.x - tickerStep;
if ((txtTicker.x + txtTicker.width)<0)
{
txtTicker.x = tickerWidth;
}
var icon128bitmapData:BitmapData = new BitmapData(tickerWidth,tickerWidth,true,0x00ffffff);
icon128bitmapData.draw(this);
var iconSet = new Array(icon128bitmapData);
NativeApplication.nativeApplication.icon.bitmaps = iconSet;

}

Puedes descargar el archivo .FLA del ejemplo para verlo implementado.

Comparte:

No related posts.

Sorteo de libros “Adobe AIR Cookbook” y “Youtube: an insider’s guide”

admin — Wed, 13 May 2009 01:44:28 +0000

Justo esta mañana me acaba de llegar un paquete de O'Reilly con un par de libros de promoción. El Cookbook de AIR y otro libro sobre Youtube. Dado que los libros vienen de regalo por ser un Adobe User Group los sortearé entre los miembros del grupo que realicen algún tipo de colaboración. Ya sea escribir un ejemplo de AIR, mostrar alguna aplicación o hacer algún review de un libro o aplicación que pueda ser de interés para el grupo.

Cómo ya he dicho unos de los libros es el Adobe AIR 1.5 Cookbook. Para los que no conozcan la serie de libros "Cookbook" les diré que son libros imprescindibles para el aprendizaje de una aplicación. Cómo su nombre indica, el libro está lleno de "recetas", osea de pequeños trucos y códigos de ejemplo que cubren prácticamente todas las posibilidades que ofrece AIR. Desde el nivel más básico a otro más avanzado.

El segundo libro es el YouTube: An Insider's Guide to Climbing the Charts. Es una interesante guía de editores de vídeos en Youtube. Muestra todo lo que debes saber si quieres crear y tener éxito con tu canal. Interesante el capítulo sobre como ganar dinero con tu canal de Youtube.

Cómo ya he dicho, los libros serán sorteados entre lo que hagan algún aporte al grupo. Para aportar únicamente tienes que registrarte en el grupo y dejar tu aporte en este post. También si quieres puedes hacerlo desde el grupo de Facebook, o comunicándote conmigo por email.

Comparte:

AdobeTV: Videotutorial de creacion de componentes en Flex

admin — Fri, 16 Jan 2009 03:24:00 +0000

Videotutorial "Creating New Components in Flex 3" por Deepa Subramaniam

Comparte:

onReleaseOutside, onDragOut, onDragOver en ActionScript 3

admin — Fri, 01 Jun 2007 10:59:45 +0000

Un problema de AS3 es que no trae los eventos de Mouse onReleaseOutside, onDragOut, onDragOver. Visitando la web de André Michelle he visto que ha creado una clase para controlar estos eventos

Estos serían los códigos:

/* code by: André Michelle - http://blog.andre-michelle.com */

package de.popforge.events
{
import flash.events.Event;

public class SimpleMouseEvent extends Event
{
static public const PRESS:String='onPress';
static public const RELEASE:String='onRelease';
static public const RELEASE_OUTSIDE:String='onReleaseOutside';
static public const ROLL_OVER:String='onRollOver';
static public const ROLL_OUT:String='onRollOut';
static public const DRAG_OVER:String='onDragOver';
static public const DRAG_OUT:String='onDragOut';

public function SimpleMouseEvent(type:String,bubbles:Boolean=true,cancelable:Boolean=false)
{
super(type,bubbles,cancelable);
}
}
}

/* code by: André Michelle - http://blog.andre-michelle.com */

package de.popforge.events
{
import flash.display.InteractiveObject;
import flash.display.MovieClip;
import flash.display.Sprite;
import flash.display.Stage;
import flash.events.MouseEvent;
import flash.utils.Dictionary;

public class SimpleMouseEventHandler
{
static public function register( target: InteractiveObject, trackAsMenu: Boolean = false ): void
{
new SimpleMouseEventHandler( target, trackAsMenu );
}

static public function unregister( target: InteractiveObject ): void
{
SimpleMouseEventHandler( table[ target ] ).dispose();

delete table[ target ];
}

static private const table: Dictionary = new Dictionary( true );

//-- target must have set buttonMode = true
private var target: InteractiveObject;

private var trackAsMenu: Boolean;

public function SimpleMouseEventHandler( target: InteractiveObject, trackAsMenu: Boolean )
{
this.target = target;
this.trackAsMenu = trackAsMenu;

init();
}

private function init(): void
{
if( target is Sprite )
Sprite( target ).buttonMode = true;

else if( target is MovieClip )
MovieClip( target ).buttonMode = true;

target.addEventListener( MouseEvent.MOUSE_OVER, onTargetMouseOver );
target.addEventListener( MouseEvent.MOUSE_OUT, onTargetMouseOut );
target.addEventListener( MouseEvent.MOUSE_DOWN, onTargetMouseDown );
target.addEventListener( MouseEvent.MOUSE_UP, onTargetMouseUp );

table[ target ] = this;
}

private function dispose(): void
{
target.removeEventListener( MouseEvent.MOUSE_OVER, onTargetMouseOver );
target.removeEventListener( MouseEvent.MOUSE_OUT, onTargetMouseOut );
target.removeEventListener( MouseEvent.MOUSE_DOWN, onTargetMouseDown );
target.removeEventListener( MouseEvent.MOUSE_UP, onTargetMouseUp );
}

private function onTargetMouseOver( event: MouseEvent ): void
{
if( event.buttonDown )
{
if( target.stage.focus == target || trackAsMenu )
dispatch( SimpleMouseEvent.DRAG_OVER );
}
else
{
dispatch( SimpleMouseEvent.ROLL_OVER );
}
}

private function onTargetMouseOut( event: MouseEvent ): void
{
if( event.buttonDown )
{
if( target.stage != null )
{
if( target.stage.focus == target || trackAsMenu )
dispatch( SimpleMouseEvent.DRAG_OUT );
}
}
else
{
dispatch( SimpleMouseEvent.ROLL_OUT );
}
}

private function onTargetMouseDown( event: MouseEvent ): void
{
dispatch( SimpleMouseEvent.PRESS );

target.stage.addEventListener( MouseEvent.MOUSE_UP, onStageMouseUp );
}

private function onTargetMouseUp( event: MouseEvent ): void
{
if( target.stage.focus == target )
dispatch( SimpleMouseEvent.RELEASE );

target.stage.removeEventListener( MouseEvent.MOUSE_UP, onStageMouseUp );
}

private function onStageMouseUp( event: MouseEvent ): void
{
dispatch( SimpleMouseEvent.RELEASE_OUTSIDE );

Stage( event.currentTarget ).removeEventListener( MouseEvent.MOUSE_UP, onStageMouseUp );
}

private function dispatch( type: String ): void
{
target.dispatchEvent( new SimpleMouseEvent( type ) );
}
}
}

Podéis ver el post original en el blog de André Michelle, y descargaros los archivos del ejemplo aqui.

Comparte:

Apollo: Preguntas Frecuentes del Desarrollador (Developer FAQ) en Castellano.

admin — Tue, 17 Apr 2007 22:59:50 +0000

Nota: traducción hecha del original en ingles al español por Oscar Cortes - Hola Flex!

1 General

1.1 Que es Apollo?
1.2 Esta Apollo disponible para descarga?
1.3 A que tipo de aplicaciones esta orientado Apollo?
1.4 A que tipo de desarrolladores esta dirigido Apollo?
1.5 Es Apollo gratis ( como en â€˜cerveza gratis')?
1.6 Cuando será liberado Apollo?
1.7 A que plataformas esta dirigido Apollo?
1.8 Suporta Apollo Linux?
1.9 Cuales son los sistemas operativos suportados para el alpha de Apollo?
1.10 Cuales son algunas de las características incluidas en el alpha de Apollo?
1.11 Cuales son algunas de las características no incluidas en el alpha de Apollo?
1.12 Es Apollo un navegador Web?
1.13 Cual es el tamaño previsible para el runtime de Apollo?
1.14 Como esta relacionado Apollo con Macromedia Central?

2 Desarrollo

3 Problemas conocidos y soluciones

3.1 Puedo instalar una aplicación Apollo en un sistemas operativo que no este en ingles?

4 Sugerencias y Comentarios

4.1 Donde puede reportar dificultades / problemas con Apollo?
4.2 Donde puedo enviar requerimientos de funcionalidad de Apollo?

5 Noticias e información

5.1 Donde puedo encontrar las últimas noticias con respecto a noticias e información acerca de Apollo?
5.2 Se hablara de Apollo en las próximas conferencias?

6 Información FAQ

6.1 Es este el sitio oficial de la FAQ?
6.2 Donde puede enviar sugerencias y comentarios acerca de la FAQ?

General

Que es Apollo?

Apollo es el nombre código de un runtime para múltiples sistemas operativos siendo desarrollado por Adobe, que permite a desarrolladores el utilizar sus conocimientos en desarrollo Web (Flash,Flex,HTML,JavaScript,Ajax) para desarrollar y distribuir Aplicaciones Ricas para el Internet (RIA) para escritorio.

Esta Apollo disponible para descarga?

Si. Se puede descargar la versión Alpha pre-liberada de la página Apollo Download

A que tipo de aplicaciones esta orientado Apollo?

Apollo esta orientado a permitirles a los desarrolladores Web construir y distribuir aplicaciones para el escritorio.

A que tipo de desarrolladores esta dirigido Apollo?

Apollo esta dirigido a desarrolladores que están actualmente haciendo uso de tecnologías Web tales como Flash, Flex, HTML, JavaScript y técnicas Ajax para construir y distribuir Aplicaciones Ricas para el Internet.

Es Apollo gratis ( como en â€˜cerveza gratis')?

Si. El runtime de Apollo será gratis (similar al Flash Player y Adobe Reader).

Cuando será liberado Apollo?

Se puede bajar una versión Alpha de pre-liberación al DIA de hoy de Apollo Download Page

Por el momento estamos buscando liberar Apollo 1.0 en la segunda mitad del 2007

A que plataformas esta dirigido Apollo?

Apollo 1.0 será soportado en Windows y OS X.

Suporta Apollo Linux?

Apollo 1.0 no estará disponible para Linux. Planeamos liberar soporte para Linux poco después de la liberación de la versión 1.0

Aunque originalmente habíamos planeado suportar Linux en el mismo periodo que la versión 1.0, tuvimos que esperar a que las partes esenciales del Flash Player para Linux estuvieran terminadas.

Cuales son los sistemas operativos suportados para el alpha de Apollo?

Windows XP con Service Pack 2 (SP2) o Vista Home premium edition

Macintosh Mac OSX 10.4 en PPC o Intel

Cuales son algunas de las características incluidas en el alpha de Apollo?

Algunas de las características incluidas en el alpha de Apollo, pero limitadas a son:

Suporte completo de HTML dentro de contenido basado en Flex- y Flash.
API de escritura y lectura de archivos. I/O API
múltiples modos de window chrome (incluyendo el native y custom/transparent)
Nativa windowing API (parcialmente implementada)
Comunicación entre ActionScript/JavaScript script
Componentes Flex
APIs para actualización de bajo nivel. (Low-level update APIs)
Suporte para uso de iconos

Cuales son algunas de las características no incluidas en el alpha de Apollo?

De bajo esta una lista parcial de las características planeadas para Apollo 1.0, las cuales no están aun implementadas en el alpha de Apollo:

Suporte de archivos PDF
Online/offline APIs
Suporte completo para el top-level de aplicaciones HTML
APIs para persistencia de datos y su configuración
Soporte de Arrastrar y Soltar (Drag and drop)
Soporte de Copiar y Pegar
Cajas de dialogo nativas para seleccionar archivos
Soporte nativo completo de ventanas
Registro de extensiones de archivo
Iniciar una aplicación para manejar un tipo de archivo.
Control completo del menú de boton derecho ( right-click)
Transparencia in HTML

Es Apollo un navegador Web?

No. Apollo es un multi-sistema operativo runtime que corre afuera del navegador.

En teoría se podría desarrollar un navegador Web encima de Apollo.

Cual es el tamaño previsible para el runtime de Apollo?

El tamaño esperado actualmente para el runtime de Apollo es entre 5 y 9 megas.

Es importante aclarar que el runtime solo necesita ser instalado una vez.

Como esta relacionado Apollo con Macromedia Central?

Aunque hay un numero de miembros del equipo de Apollo que trabajo previamente en Macromedia Central, Apollo no esta directamente relacionado con Macromedia Central.

El código base de Apollo es completamente separado del de Macromedia Central.

Desarrollo

Que tecnologías puedo explotar dentro de una aplicación Apollo?

Apollo permitirá desarrollar aplicaciones usando Flash / Flex y HTML / JavaScript o una combinación de ambos.

Aplicaciones basadas en Flash serán capaces de incluir contenido creado en HTML , y aplicaciones basadas en HTML serán capaces de usar contenido creado con Flash.

Además, las aplicaciones Apollo podrán integrarse cercanamente con documentos en formato PDF, aunque esta funcionalidad no es disponible para el alpha de Apollo.

Puedo usar solo HTML y JavaScript para construir aplicaciones?

Si.

Cual IDE debo usar para desarrollar aplicaciones Apollo?

Se puede hacer uso de cualquiera de los IDE ya existentes para el desarrollo de Flash/Flex o HTML/JavaScript. (Tales como Flex Builder, Eclipse, vim, etc...). Apollo no requiere de un IDE específico.

Liberaremos una serie de herramientas de comandos en línea para Apollo que harán fácil para los desarrolladores hacer el empacamiento y desarrollo de aplicaciones Apollo usando su IDE o editor favorito. Se puede descargar una versión alpha de estas herramientas en el Apollo SDK.

Básicamente, se puede usar cualquier cosa que cree archivos SWF's o HTML

Podré crear aplicaciones Apollo con el Flash Authoring?

Si.

Publicaremos más información en como crear contenido Flash con Flash Authoring, una vez que la siguiente versión del Flash Authoring sea liberada.

Como será distribuido el runtime de Apollo?

Apollo será distribuido en varias formas, incluyendo pero no limitado a:

Descarga del sitio Web de Adobe
Distribuido con aplicaciones Apollo (en el caso que el usuario no tenga Apollo instalado).

Estamos también explorando una variedad de métodos de distribución, y tenemos confianza de que podremos tener significa distribución del runtime de Apollo rápidamente.

Nota, este tópico fue discutido en más detalle en este podcast.

Podrán los desarrolladores distribuir el instalador del runtime de Apollo con sus aplicaciones?

Si, además de crear y distribuir archivos de instalación para aplicaciones Apollo multi-plataforma, los desarrolladores podrán crear instaladores nativos que primero revisaran si el usuario tiene el runtime de Apollo instalado. Si no esta instalado, se instalara, y entonces se instalara la aplicación.

Nota, este tópico fue discutido en más detalle en este podcast.

Como se instalan las aplicaciones Apollo?

Las aplicaciones Apollo son instaladas como cualquier otra en la computadora del usuario. El usuario descarga un archivo de instalación multi-plataforma, hace doble clic, lo cual empieza el proceso de instalación.

La experiencia para el usuario final dependerá de que sistema operativo esté usando, ya que Apollo proveerá de un mecanismo de instalación consistente con dicho sistema operativo.

También estamos explorando otros mecanismos para la instalación de aplicaciones Apollo.

Que motor de HTML y JavaScript es usado dentro de Apollo?

HTML y JavaScript dentro de Apollo son manejados por el motor WebKit HTML / JavaScript

Es este el mismo proyecto WebKit en que están basados el navegador Safari en Mac OS y el navegador KHTML en KDE?

Si.

Por que escogió Adobe WebKit?

Pusimos una cantidad considerable de tiempo investigando un número de motores de HTML para usar en Apollo. Teníamos cuatro principales requerimientos, los cuales WebKit cumplió:

Proyecto abierto al cual pudiéramos contribuir
Tecnología comprobada, con la cual ya estuvieran familiarizados los desarrolladores de Web y usuarios finales
Mínimo impacto en el tamaño del runtime de Apollo
Habilidad comprobada para correr en dispositivos móviles

Aunque la decisión final fue difícil, sentimos que el WebKit es la opción más cercana para Apollo por el momento.

Resultara el uso de Webkit en Apollo en un nuevo motor para HTML del cual los desarrolladores serán responsables?

No. Nuestra meta es mantener compatibilidad completa con las implementaciones existentes de WebKit. Esto ayudara a asegurar que el contenido que corre en los navegadores basados en WebKit, tales como Safari de Apple , también corran dentro de las aplicaciones Apollo.

Planea Adobe presentar cambios al proyecto WebKit?

Si. Nuestra meta es convertirnos en activo miembro de la comunidad WebKit y activamente presentar cambios y correcciones al proyecto WebKit para consideración.

Es este el mismo WebKit framework que el de Mac OS X?

No exactamente. El proyecto WebKit de código abierto, y el Apple WebKit Framework para Mac OS X son dos cosas diferentes.

Apollo usa el código base directamente del proyecto WebKit, y no del de Apple WebKit framework.

Donde puedo encontrar mas información sobre WebKit

Se puede encontrar más información sobre el WebKit en:

Podrán comunicarse las aplicaciones Apollo unas con otras?

Si. Serán capaces de comunicarse unas con otras haciendo uso de LocalConnection una API de ActionScript.

Podrán comunicarse las aplicaciones Apollo directamente con bases de datos?

Apollo 1.0 no tendrá soporte incluido para comunicación directa con bases de datos. Sin embargo, será posible escribir manejadores de base de datos con ActionScript( usando soques binarios o de XML), los cuales le permitirán a las aplicaciones de Apolo comunicarse directamente con una base de datos ( local y remotamente)

Incluirá Apollo una base de datos integrada que las aplicaciones puedan acceder?

Esta es una característica que todavía estamos considerando para la versión 1.0.

Que tanto control tendrán los desarrolladores / diseñadores sobre la apariencia de sus aplicaciones?

Desarrolladores y diseñadores tendrán 100% control sobre la apariencia de sus aplicaciones.

Puedo usar código de Flex 2 en una aplicación Apollo?

Si. De hecho, no se necesitara re-escribir nada del código para tener una aplicación Flex corriendo dentro de Apollo, aunque tal vez se necesite escribir código adicional para tomar ventaja de especificas APIs de Apollo.

Cuales son algunas de las APIs de Apollo que estarán disponibles para los desarrolladores?

Algunas de las APIs que han sido discutidas son:

Escritura y lectura de archivos (File I/O)
Online / Offline
Windowing
Portapapeles (Clipboard)
Sistema de arrastrar y soltar (System Drag and Drop)
API de manejo completo de red. Full Network API support
Almacenamiento Local y su configuración
más...

Podrán funcionar las aplicaciones Apollo fuera de línea(offline)?

Si. Apollo proveerá de un conjunto de APIs que hacen fácil desarrollar aplicaciones que trabajen offline.

Esta funcionalidad no esta implementada en el alpha de Apollo.

Podrán los desarrolladores extender Apollo con código nativo?

No. Esta funcionalidad no estará disponible en Apollo 1.0

Podrán las aplicaciones Apollo abrir las aplicaciones por defecto según el tipo de archivo?

Si. Aplicaciones Apollo podrán abrir las aplicaciones por defecto para abrir un archive especifico dependiendo de su tipo.

Por ejemplo, se le podrá decir al sistema operativo que abra la aplicación por defecto para un documento específico.

Podrán las aplicaciones Apollo iniciar directamente aplicaciones nativas?

Esta es una característica que todavía estamos considerando para Apollo 1.0.

Ofrece Apollo un mecanismo de actualización de aplicaciones?

Si, Apollo ofrecerá un mecanismo para actualizar aplicaciones fácilmente. Esto esta parcialmente implementado en el alpha de Apollo.

Puede Apollo crear ejecutables o proyectores (exe / projector)?

No. Apollo es un runtime que corre en varios sistemas operativos y que corre en el sistema del usuario.

Una de las ventajas de esto es que los archivos de instalación de Apollo pueden ser mucho mas pequeños, ya que no requieren del motor del runtime en su totalidad para ser distribuidos con cada una de la copias de la aplicación.

Esto también permite integrar tecnologías juntas (Flash,HTML,PDF) en un mucho mas bajo nivel de lo que de otra manera no seria posible.

Finalmente, esto nos permite ofrecer un modelo de seguridad más estandarizado y consistente para las aplicaciones Apollo y usuarios.

Que modelo de seguridad ofrece Apollo?

Nuestra meta es ofrecer la funcionalidad que desarrolladores quieren y necesitan, y al mismo tiempo permitirles crear aplicaciones seguras.

Aunque todavía estamos terminando la política de seguridad, en la base de cualquier política esta el hecho de que las aplicaciones Apollo son descargadas, instaladas y ejecutadas en el escritorio del usuario. Es por ello que estas corren en un contexto de seguridad diferente a las aplicaciones que se ejecutan en un servidor Web, y tendrán un modelo de seguridad mas cercano al de una aplicación de escritorio.

Podré crear aplicaciones en un CD-ROM o aplicaciones de tipo Quiosco que hagan uso de Apollo?

Si se podrá distribuir e instalar aplicaciones Apollo desde un CD-ROM, aunque por el momento, no tenemos planes de permitir que las aplicaciones Apollo corran desde un CD-ROM sin que hallan sido instaladas primero en el sistema del usuario.

También será posible crear aplicaciones Quisco que usen el runtime de Apollo, de nuevo, este no es un caso de uso que este motivando las características de Apollo 1.0

Podrán correr dentro de Apollo las aplicaciones Macromedia Central?

No. Aplicaciones Central fueron construidas con ActionScript 2 y están dirigidas a una versión anterior de la maquina virtual (AVM1) del Flash Player, y descansa en una arquitectura muy especifica para central. Es por esto que las aplicaciones Central no correrán en Apollo.

Podrán las versiones 8 de Flash y menores correr en Apollo?

Si. Sin embargo las API de Apollo están solo expuestas a contenido Flash a través de ActionScript 3 / AVM2, y por eso Flash 8 /AVM1 SWFs serán capaces de correr, pero no tendrán acceso directo a las API de Apollo.

Problemas conocidos y soluciones

Puedo instalar una aplicación Apollo en un sistema operativo que no este en ingles?

Si, aunque esto no es suportado en Alpha 1. En sistemas operativos basados en Windows que no estén en ingles, puede que se necesite hacer lo siguiente para poder instalar aplicaciones Apollo:

Cambiar la variable TEMP para el usuario en My Computer ( Mi Computadora) para que apunte a una ruta que contenga solo caracteres en ingles ( a algo como C:\TMP)

de los labs forum

Sugerencias y Comentarios

Donde puede reportar dificultades / problemas con Apollo?

Favor de reportar cualquier defecto o dificultades que se encuentren con el alpha de Apollo en el Apollo Labs forum.

Donde puedo enviar requerimientos de funcionalidad de Apollo?

Pueden ser enviadas a wish-apollo@adobe.com.

Noticias e información

Donde puedo encontrar las últimas noticias con respecto a noticias e información acerca de Apollo?

Adobe Labs Apollo Page
Apollo Smart Category at MXNA (RSS Feed)
Apollo Search at Bloglines (RSS Feed)
Mike Chambers' Weblog Developer Relations para Apollo

Se hablara de Apollo en las próximas conferencias?

Si. Se puede encontrar una lista actualizada de las pláticas públicas acerca de Apollo aquí.

Información FAQ

Es este el sitio oficial de la FAQ?

Nota del traductor: Esta es una traducción de la FAQ oficial en ingles la cual es mantenida por Mike Chambers, que esta a cargo del Developer Relations para Apollo en Adobe.

Donde puede enviar sugerencias y comentarios acerca de la FAQ

Puede enviarlos a Mike Chambers.

Traducido de "http://labs.adobe.com/wiki/index.php/Apollo:DeveloperFAQ"

De la copia de las 17:15,19 Mar 2007

Comparte:

Lo que yo sé de AS2 #Enlaces, enlaces, millones de enlaces

admin — Wed, 21 Mar 2007 21:51:04 +0000

Lo que yo sé de AS2 (condensado y pasteurizado)

*AUTOR: Juan Delgado Zárate
zarate.tv | dandolachapa.com | loqueyosede.com
FlashLa.com | After-Hours.org

Enlaces, enlaces, millones de enlaces

>Indice de contenidos

Software

Tutoriales

EventDispatcher

GDispatcher. La versión que va en el zip con el código está modificada para meterla dentro de un classpath normal y para que compile con strict en MTASC
Jorge Maestre, Comunicación basada en eventos para AS2
Cómo crear instancias de clase dinámicamente
http://www.zarate.tv/articulos/cargarclasesdinamicamente/
Using _exclude.xml, the Good, the Bad, and the Wishlist
Cómo usar _exclude con MTASC
Why does my initializer get shared across all instances like it's static?

Patrones y OOP tips

Recursos

Foros y listas de correo

Revisores

[ anterior ]

Comparte:

Lo que yo sé de AS2 #Unos apuntes

admin — Mon, 19 Mar 2007 23:09:16 +0000

Lo que yo sé de AS2 (condensado y pasteurizado)

*AUTOR: Juan Delgado Zárate
zarate.tv | dandolachapa.com | loqueyosede.com
FlashLa.com | After-Hours.org

Unos apuntes

>Indice de contenidos

Aquí van unos comentarios que no sé dónde encajar pero que me parecen útiles a la hora de pensar aplicaciones AS2.

Â¿Extender o interface?

Para tomar esta decisión hay varias cosas a tener en cuenta. Por ejemplo, en Flash no hay herencia múltiple (sólo se puede extender de una clase), pero se pueden implementar varias interfaces.

Sin embargo, para mi la clave viene dada por cuántas cosas en común van a hacer las distintas implementaciones. Por ejemplo es normal que un grupo de vistas tengan un montón de código común:

Tener un método setSize
Tener una instancia del modelo
Tener una variable base_mc, con una referencia al MovieClip base sobre el que trabajar.
Un método config() con parámetros comunes
...

Parece que hay bastante código común, así que se podría guardar todo ese código común en una clase CommonView y luego hacer que las vistas específicas la extiendan y sobrescriban sólo los métodos necesarios.

Sin embargo, el ejemplo puesto en el apartado del patrón Factory en el que bajo la misma interface se implementaban 2 contenedores distintos que proporcionan acceso al sistema de archivos para la misma aplicación, el código común entre la clase de Screenweaver y la clase para lenguaje de servidor es mínimo, por lo que la interface es mejor.

Â¿Extender de MovieClip? No, gracias

Ã‰ste es un tema sobre el que hay bastante "polémica" en cualquier lista de correo de Flash. Así que volveré a dejar por escrito que ésta es _mi_ forma preferida de hacerlo. Sin embargo, no es un capricho, éstas son mis razones:

En Flash no hay herencia múltiple, así que si extiendes de MovieClip no puedes extender de nada más.
Las clases que extienden de MovieClip no se instancian mediante new, sino mediante attachMovie, lo que es bastante raro desde el punto de vista de un programador.

Cuando creo clases que tienen un componente gráfico (un menú, un TextArea, un player de vídeo) mi forma de trabajar es pasar a las clases un MovieClip base sobre el que "trabajan" (utilizar composición en lugar de herencia). Algo como:

classvideoplayer{
privatevarbase_mc:MovieClip;
publicfunctionvideoplayer(_base_mc:MovieClip){
base_mc=_base_mc;
}
}

A la hora de instanciar la clase:

varvp_mc:MovieClip=timeLine_mc.createEmptyMovieClip("vp_mc",100);
varvp:videoplayer=newvideoplayer(vp_mc);

Normalmente dejo a la clase que instancia el objeto videoplayer que decida cosas como la posición x,y del MovieClip. Esto lo hago así ya que considero que la única responsabilidad del videoplayer es poner un vídeo "donde le manden", no decidir cual es la posición dentro de la pantalla, por ejemplo. Aún así, esto es una regla general que muchas veces depende de la organización de clases y objetos que tenga una aplicación en concreto.

Hasta hace poco estaba en un error que Joseba Alonso (sidedev.net) me aclaró amablemente. Las clases que heredan de MovieClip NO heredan su dinamicidad. MovieClip es una clase dinámica (se le pueden crear propiedades y métodos en tiempo de ejecución), pero las clases que extienden de ella no tienen por qué serlo.

El problema (ventaja al mismo tiempo en algunas ocasiones) de las clases dinámicas es que se le pueden crear propiedades y métodos en tiempo de ejecución. El problema de eso es que si te equivocas escribiendo el nombre de una propiedad, el compilador no lanza error ya que sobreentiende que estás creando una propiedad nueva. Ejemplo:

dynamicclassmiClaseDinamica{
publicvarvariable:String="Helloworld";
publicfunctionmiClaseDinamica(){}
}

A la hora de usarla:

varinstancia:miClaseDinamica=newmiClaseDinamica();
varvalor:String=instancia.avriable;//elcompiladorNOdaerror

A pesar del error (usar "avriable" en lugar de "variable"), el compilador asume que se está accediendo a una variable que se ha creado en tiempo de ejecución, cuando lo más normal es que queramos acceder a la propiedad "variable".

Pero esto al mismo tiempo es una ventaja. Â¿Cuántas veces habremos creado propiedades a un MovieClip en tiempo de ejecución? Algo como:

for(varx:Number=0;x<10;x++){
varboton:MovieClip=timeLine_mc.createEmptyMovieClip("boton_"+x,100+x);
boton.opcion=x;
}

Aunque útil, muchas veces es mejor crear una pequeña clase para el manejo del botón. Esa clase podría tener una propiedad pública "opcion" sobre la que estableceríamos el valor.

Objetos responsables

Uno de los principios OOP es que cada objeto haga única y exclusivamente lo que tiene que hacer. Cuando una clase sabe demasiado o hace demasiado, se le conoce como la clase Dios o God Object (ver enlace al final).

Sin llegar a límites absurdos, casi siempre es mejor trabajar con muchas clases pequeñas, cortas y concisas que con clases de 1.000 líneas. Que cada una haga su pequeño trabajito y poco más. Esto claramente favorece la reutilización y la depuración de errores (el código a revisar por clase es menor).

Supongamos que tenemos una clase para pintar un player de vídeo. Aquí van 2 ejemplos de implementación:

importVideoPlayer;
classA{
publicfunctionA(){
varvp:VideoPlayer=newVideoPlayer(timeLine_mc);
}
}

classVideoPlayer{
privatevarbase_mc:MovieClip;
publicfunctionVideoPlayer(timeLine_mc:MovieClip){
base_mc=timeLine_mc.createEmptyMovieClip("base_mc",100);
base_mc._x=10;
base_mc._y=10;
//ahoraempezaríamosapintarelpropioplayer
}
}

En el código anterior, la clase VideoPlayer se está encargando de crearse su propio clip sobre el que trabajar y de colocarlo en la posición deseada. Sin embargo la siguiente implementación es más flexible:

importVideoPlayer;
classA{
publicfunctionA(){
video_mc=timeLine_mc.createEmptyMovieClip("video_mc",100);
video_mc._x=10;
video_mc._y=10;
varvp:VideoPlayer=newVideoPlayer(video_mc);
}
}

classVideoPlayer{
privatevarbase_mc:MovieClip;
publicfunctionVideoPlayer(_base_mc:MovieClip){
base_mc=_base_mc;
//ahoraempezaríamosapintarelplayer
}
}

En la segunda versión la clase VideoPlayer no tiene la responsabilidad de crear su MovieClip de trabajo ni de colocarlo en la pantalla. Â¿Por qué debería hacerlo si no lo necesita? Que sea la clase que lo instancia quien tenga esa responsabilidad. Así cuando haya que reutilizar la clase de VideoPlayer, no hay que hacerle ninguna modificación.

Dicho esto, el astuto lector estará pensando que la clase VideoPlayer podría recibir como parámetros la posición x,y donde se tiene que pintar, el nombre del MovieClip y la profundidad a la que va.... sí, técnicamente es posible, pero para qué pasar un montón de parámetros cuando se puede no pasar ninguno : )

Mejor que no te acoples

Una de las normas consideradas como correctas dentro de la programación orientada a objetos es que las clases entre sí deben estar poco "acopladas". Eso significa que cuanto menos sepa una clase de otra, mejor. Siempre que sea posible es más flexible que las clases trabajen sobre parámetros en lugar de hacerlo sobre otros objetos. Ejemplo:

importB;
classA{
publicvarvariable:String="Helloworld",
publicfunctionA()
{
vara:A=newA(this);
}
}

importA;
classB{
public function B(a:A){
trace(a.variable)
}
}

Según la estructura de código de arriba, la clase B necesita importar la clase A para acceder a su propiedad pública cuando realmente no es necesario. Modificando el código como sigue, las clases no están acopladas:

importB;
classA{
privatevarvariable:String="Helloworld",
publicfunctionA(){
vara:A=newA(variable);
}
}

classB{
publicfunctionB(toTrace:String){
trace(toTrace);
}
}

El resultado es el mismo, pero en el segundo caso la clase B no necesita a la clase A para nada. Si por necesidades del proyecto necesitamos que sea la clase C en lugar de la A la que inicie el proceso, a la clase B le va a dar igual porque lo único que necesita es una cadena en el constructor.

Como toda regla general, depende mucho del proyecto decidir si pasar una instancia de una clase o un montón de parámetros.

Protos Nunca Mais

Una de las preguntas más habituales para la gente que está dando el paso de AS1 a AS2 es cómo reaprovechar protos hechos en AS1 en AS2. Para mi la salida más natural a los protos son clases con un método estático para cada proto.

Ejemplo de proto sacado de Layer51

String.prototype.PALINDROME=function(){
returnthis+this.split("").reverse().join("");
};

classtv.zarate.Utils.StringUtils{
publicstaticmethodpalindrome(s:String):String{
returns+s.split("").reverse().join("");
}
}

A partir de ese momento, las llamadas serían así:

importtv.zarate.Utils.StringUtils;
trace(StringUtils.palindrome("wadus"));

Es importante fijarse en que para utilizar el método estático no hace falta crear una instancia de la clase StringUtils;

Como en los métodos estáticos no se puede hacer la referencia a "this" que se hacía en el proto, se pasa como parámetro el objeto (en este caso una cadena) con el que el método tiene que "trabajar". Por supuesto si hubiera que trabajar con más parámetros, se pasarían a continuación.

Â¿Cuándo se compila una clase?

Algo que no está meridianamente claro es cuándo el compilador incluye una clase en un swf. La respuesta es cuando esa clase está referenciada *en el código*. Y resalto lo de "en el código" porque si la clase está importada pero no usada, no se compila. Ejemplo:

importclassB;
classA{
publicfunctionA(){}
//laclaseBnosecompila
}

importclassB;
class A{
public function A(){
var b:B = new B();
}
//laclaseBsecompila
}

importclassB;
classA{
privatevarb:B;//AQUITAMBIENSECOMPILA!
publicfunctionA(){
}
}

Otra de las ventajas de utilizar MTASC es que por defecto avisa con un warning cuando se están importando clases que luego no son utilizadas dentro del código.

Â¿Y se puede evitar que una clase se compile incluso cuando se ha referenciado en el código? Claro que sí, aunque la forma de hacerlo no sea muy "amigable". Se trata de utilizar archivos *_exclude.xml, pero como el tema es un poco largo, en la sección de Enlaces dejo recursos sobre el tema.

Importando packages

Algo muy habitual es importar un package completo utilizando "*":

importcom.xfactorstudio.xml.xpath.*;

Â¡OJO! El compilador NO incluye todas las clases del package, ya que hace su trabajo de optimización y sólo compila las que están referenciadas en el código.

Â¿Entonces por qué no se importa siempre todo el package? Yo diría que es una cuestión didáctica. Prefiero importar explícitamente sólo las clases que voy a utilizar y así poder ver rápidamente de un vistazo las relaciones entre clases.

Getters y setters implícitos y explícitos

Se conocen por getters/setters a los métodos que permiten establecer y recuperar el valor de una variable. La idea es que la variable en si sea privada, y que para que acceder a ella haya que llamar a estos métodos. Â¿Y por qué querría nadie obligar a usar un método para saber el valor de una variable? Pues porque hay veces que al cambiar el valor de una variable, otras variables
relacionadas también cambian su valor. Por ejemplo:

classA{
privatevarprice:Number;
publicfunctionA(){
}
publicfunctiongetPrice():Number{
returnprice;
}
publicfunctionsetPrice(p:Number):Void{
price=p;
updateBasketPrice();//acciónrelacionada
}
}

Estos son los getters/setters explícitos. Y son explícitos porque para saber el valor de la variable desde fuera de la clase, hay que llamar a un método.

Pero Flash permite hacerlos de forma implícita. Lo siguiente es perfectamente válido:

classA{
privatevar_price:Number;
publicfunctionA(){}
publicfunctiongetprice():Number{
return_price;
}
publicfunctionsetprice(p:Number):Void{
_price=p;
updateBasketPrice();//accionrelacionada
}
}

Â¿Ventajas de un método sobre otro? Técnicamente yo diría que no hay, pero hay programadores que prefieren hacer saber que se accede a un método. Otros dicen que no tiene por qué dar explicaciones. A gusto del consumidor.

Claro, que también hay gente que piensa directamente que los getters y setters deberían desaparecer de la faz de la tierra. En la sección de Enlaces hay más sobre ello para quien le interese.

Strong data typing

Strong data typing es de esos términos que casi mejor no traducir. Pero vamos, significa que le asignes un tipo a todas las propiedades, parámetros y tipos devueltos por los métodos. Aunque no es obligatorio, yo creo que es muy recomendable hacerlo.

varmyString:String="";
varmyNumber:Number=0;
publicfunctionwadus():Void{
}
//utiliza Void si tu método no devuelve nada

Hay una no muy buena costumbre a la hora de definir el tipo de las propiedades de las clases. Por ejemplo:

classA{
public var myNumber:Number = 5; // bien
public var myArray:Array = new Array(); // MAL!
public var mySecondArray:Array;
public function A(){
// aquí o en cualquier otro método, bien
mySecondArray = new Array();
}
}

Cuando se definen las variables de una clase sólo se puede definir el valor por defecto para las variables de tipos primitivos: String, Boolean y Number. Nada que tenga que ver con un new. El player de Flash no maneja muy esas definiciones (buscar en la sección de Enlaces "Why does my initializer get shared across all instances like it's static?").

[ anterior ] [ siguiente ]

Comparte:

Lo que yo sé de AS2 #Tus amigos los patrones

admin — Sun, 18 Mar 2007 23:37:55 +0000

Lo que yo sé de AS2 (condensado y pasteurizado)

*AUTOR: Juan Delgado Zárate
zarate.tv | dandolachapa.com | loqueyosede.com
FlashLa.com | After-Hours.org

Tus amigos los patrones

>Indice de contenidos

A mi me gusta pensar en los patrones como soluciones que gente muy friki y muy gafotas sabe para el problema que tienes entre las manos. Sólo son formas de organizar el código que te solucionan elegantemente un problema.

Ahora, como dijo un día Xavi Beumala (code4net.com): â€œsi no sientes que necesitas un patrón, es que no lo necesitasâ€. Es decir, no se trata de que busques problemas para aplicar un patrón, sino de que apliques patrones a situaciones y problemas reales. Lo más difícil de los patrones es saber reconocer cuándo son necesarios.

NOTA IMPORTANTE: Las implementaciones de los patrones que voy a comentar a continuación son â€œlibresâ€. Es decir, no me importa tanto que desde un punto de vista formal cumplan el patrón al 100% sino que guarden su â€œesenciaâ€ de la forma más simple posible. Si realmente estás interesado en conocer a fondo los patrones te recomiendo el libro Head First Design Patterns o si eres un tío muy gafotas, la biblia que todo talibán de los patrones lee los domingos por la mañana para desayunar: Design Patterns (by the Gang of four). Enlaces al final.

Singleton

Â¿Cuándo? Cuando necesitas que en una aplicación haya una y sólo una instancia de una clase.

Â¿Ejemplo? Un controlador de Combos. Supongamos que estamos desarrollando nuestro propio componente ComboBox, normalmente no queremos que haya 2 abiertos al mismo tiempo. Podríamos controlarlo mediante variables globales, pero ya hemos visto que eso no es muy buena idea. Singleton al rescate. La idea es tener una clase Singleton que tenga una referencia a todos los combos creados y que se encargue de coordinarlos.

Aquí va la clase que coordina, el Singleton

import Combo;
class ComboManager{
private static var _instance:ComboManager;
private var combos:Array;
private function ComboManager(){
combos = new Array();
}
public static function getInstance():ComboManager{
if(_instance == null){
_instance = new ComboManager();
}
return _instance;
}
public function addCombo(combo:Combo):Void{
combos.push(combo);
}
}

Y aquí la clase combo que lo utilizaría;

import ComboManager;
class Combo{
public function Combo(){
var cm:ComboManager = ComboManager.getInstance();
cm.addCombo(this);
}
}

Comentarios

Es muy importante darse cuenta de que el constructor del Singleton es privado, por lo que nadie puede crear una instancia a la forma tradicional (con new). La única forma de obtener una instancia del Singleton es utilizar el método público estático getInstance. Y es dentro de getInstance donde se controla que la instancia sólo se cree una vez, el resto de veces se devuelve la ya creada.

Problemas

Como con todos los patrones, no se debe abusar del Singleton. Especialmente NO tienen que ser un un sustituto de la variables globales. En la sección de Enlaces, al final del artículo de la Wikipedia hay enlaces sobre este problema.

Factory Pattern e interfaces

Antes de comentar el Factory, vamos a explicar qué es una interface. Una clase tiene que tener todos los métodos de la interface (o interfaces) que implemente. Ejemplo:

interface Application{
public function config(appXML:XML):Void;
public function start():Void;
}

class VideoPlayer implements Application{
public function config(appXML:XML):Void{
}
public function start():Void{
}
}

Si la clase VideoPlayer no tuviera los 2 métodos de la interface, el compilador protestaría. Así que las interfaces son una forma de â€œobligarâ€ a que las clases que la implementen tenga unos métodos públicos conocidos.

Lasintefaces sólo definen métodos públicos, no pueden definir ni propiedades, ni métodos privados o estáticos.

Ahora el Factory pattern.

Â¿Cuándo? Cuando necesitas resolver el mismo problema de distintas formas, y además hay que decidir en tiempo de ejecución cuál utilizar.

Â¿Ejemplo? Una aplicación para hacer un reloj que necesita 2 vistas distintas, una digital y otra analógica. Además necesitamos decidir en tiempo de ejecución cual utilizar.

Primero definimos una sencilla interface que ambas vistas van a implementar.

interface iView{
public function config():Void;
public function draw():Void;
}

Luego creamos las 2 vistas distintas y hacemos que implementen la interface.

import iView;
class AnalogView implements iView{
public function AnalogView(){}
public function config():Void{}
public function draw():Void{
// la clase analógica pinta las manillas
}
}

import iView;
class DigitalView implements iView{
public function DigitalView(){}
public function config():Void{}
public function draw():Void{
// la clase digital pinta números
}
}

Ahora creamos el modelo. Es importante fijarse en que el modelo no sabe con qué implementación de iView va a trabajar, ni siquiera importa las vistas. Es decir, no sabe si será analógico o digital. Lo único que sabe es que va a trabajar con una instancia de iView. Es ahí donde está la flexibilidad, es lo que se llama trabajar para la interface y no para implementaciones.

import iView;
import ViewFactory;
class ClockModel{
private var view:iView;
public function ClockModel(){
// supongamos que viene de un xml, FlashVars o algo dinámico
var viewType:String = â€œdigitalâ€;
// pedimos a la factoría una vista
view = ViewFactory.getView(viewType);
view.config();
view.draw();
}
}

Y finalmente la factoría:

import iView;
import AnalogView;
import DigitalView;
class ViewFactory{
public static function getView(viewType:String):iView{
var v:iView;
if(viewType == â€œanalogâ€){
v = new AnalogView();
} else {
v = new DigitalView();
}
return v;
}
}

Vista la estructura de la factoría (un if o switch gigante), es fácil darse cuenta de que si en el futuro queremos añadir más tipos de vistas, simplemente hay que aumentar el número de casos en el if. Lo bueno es que el modelo seguirá trabajando sin problemas mientras que las nuevas vistas implementen iView.

Esto mismo se podría conseguir en lugar de con una interface haciendo que ambas vistas extiendan de una clase común. Entonces el modelo trabajaría con esa vista común en lugar de con la interface, pero el resultado y objetivo es el mismo. Â¿Cuándo utilizar una interface y cuándo extender? Ver explicación en la sección de apuntes.

Comentarios

Situaciones en las que un factory es aplicable hay muchas. Todas ellas tienen es común distintas formas (implementaciones) de solucionar un mismo problema. Por ejemplo supongamos que tenemos una aplicación que necesita leer y escribir el sistema de archivos del usuario. Además queremos que la aplicación funcione on line y off line. Para conseguirlo on-line nos tendremos que basar en algún lenguaje de servidor, y para hacerlo on-line necesitaremos, Screenweaver, SWFStudio o algún otro wrapper o contenedor de swfs.

Veamos una posible interface:

interface iWrapper{
// los callbacks son porque la mayoría de estas llamadas
// serán asíncronas
public function getDir(path:String,callback:Function):Void;
public function writeFile(path:String,callback:Function):Void
public function readFile(path:String,callback:Function):Void;
}

La interface está definiendo qué queremos que el wrapper haga. Cómo lo haga es tarea de cada una de las implementaciones. En el caso de la implementación de servidor, seguramente sea con llamadas sendAndLoad del objeto XML, en el caso de la implementación local con Screenweaver será a través de las clases AS2 que vienen con la instalación. La parte buena es que si la aplicación trabaja con una instancia de iWrapper, cambiar la de on-line a off-line no sería problema.

Problemas

Uno de los efectos secundarios de la factoría es que TODAS las implementaciones se compilan en el swf final, aunque sólo vayamos a utilizar una. Â¿Y no hay forma de evitarlo? La hay. Como el tema es un poco más avanzado, quien quiera más información sobre el tema puede seguir 2 tutoriales de la sección de Enlaces que se titulan â€œCrear instancias dinámicamenteâ€ y â€œCargar clases dinámicamenteâ€.

Modelo-VistaControlador

Â¿Cuándo? Siempre. Bueno, casi siempre. Por poco grande que sea una aplicación siempre es útil separar lógica de presentación. Y eso es la parte fundamental del MVC, separar lógica de presentación.

A pesar de que ya lo he dicho un par de veces, la implementación que pongo a continuación NO es pura, es una adaptación libre y pragmática. Prefiero repetirlo para que:

Nadie me salte al cuello con la implementación buena en la mano.
Tú, querido lector, te molestes en ir a buscar esa implementación buena y compares. En la sección de Enlaces podrás encontrar más información.

Dicho esto, comentarios sobre problemas que pueda tener mi implementación son MUY bienvenidos. Mi implementación por ejemplo, asume que sólo hay una vista. eso permite al modelo hacer llamadas directas a la vista sin necesidar de que la vista sea listener del modelo. Además tambien junto en una misma clase la vista y el controlador. Veamos el ejemplo:

Empezamos con una clase que se encarga de crear la instancia del modelo:

import tv.zarate.Projects.loqueyosede.Model;
class tv.zarate.Projects.loqueyosede.MVCApplication{
public static function main(m:MovieClip):Void{
var model:Model = new Model();
model.config(m);
model.start();
}
}

Luego, el modelo:

import tv.zarate.Projects.loqueyosede.View;
class tv.zarate.Projects.loqueyosede.Model{
private var view:View;
private var timeLine_mc:MovieClip;
private var view_mc:MovieClip;
private var numberOfClicks:Number = 0;
public function Model(){}
public function config(m:MovieClip):Void{
// el modelo se guarda una referencia a la linea de tiempo principal
// basicamente para poder acceder a las FlashVars
// cuando sea necesario
timeLine_mc = m;
// creamos un mc solo para la vista
view_mc = timeLine_mc.createEmptyMovieClip("view_mc",100);
}
public function start():Void{
// creamos la instancia de la vista
view = new View();
// le pasamos la referencia al modelo y el
// clip sobre el que va a trabajar
view.config(this,view_mc);
// en este caso directamente llamamos al metodo
// start de la vista
// en aplicaciones mas complejas, el modelo
// podria primero ir a buscar datos a un servidor
// o leer un xml de configuracion
view.displayValue(numberOfClicks);
}
public function updateClick():Void{
// la vista llama a este metodo cada vez que el usuario hace click
numberOfClicks++;
// despues de actualizar
// llamamos al metodo que nos interesa de la vista
view.displayValue(numberOfClicks);
}
}

Y por último la VistaControlador (abreviado, ver código adjunto para la versión completa):

import tv.zarate.Projects.loqueyosede.Model;
class tv.zarate.Projects.loqueyosede.View{
private var model:Model;
private var base_mc:MovieClip;
private var background_mc:MovieClip;
private var title_mc:MovieClip;
private var titleField:TextField;
private var width:Number = 0;
private var height:Number = 0;
private var OVER:String = "over";
private var OUT:String = "out";
private var PRESS:String = "press";
public function View(){}
public function config(_model:Model,_base_mc:MovieClip):Void{
// nos llega por composicion una instancia del modelo
// eso nos permitira acceder a sus metodos y propiedades publicas
model = _model;
// guardamos una referencia al clip con el que trabajara la vista
base_mc = _base_mc;
// creamos los elementos basicos
doInitialLayout();
onResize();
}
public function displayValue(value:Number):Void{
titleField.text = "Clicks> " + value;
}
private function doInitialLayout():Void{
var button_mc:MovieClip = base_mc.createEmptyMovieClip("button_mc",300);
// definimos los eventos y los delegamos al metodo manageButton
button.onPress = Delegate.create(this,manageButton,button,PRESS);
}
private function layout():Void{}
private function onResize():Void{}
private function manageButton(mc:MovieClip,action:String):Void{
switch(action){
case(PRESS):
// llamamos a un metodo publico del modelo
// que actualiza el contador de clicks
model.updateClick();
}
}
}

Comentarios

Utilizo la clase MVCApplication como â€œpunto de partidaâ€ (aunque también se podría integrar en la clase Model). Primero crea la instancia del modelo, luego lo configura mediante config, y luego llama al método start. Tanto â€œconfigâ€ como â€œstartâ€ son nombres completamente arbitrarios.

Ya en el modelo, en el método start se crea la instancia de la vista, se la configura pasando una referencia al modelo y un MovieClip de trabajo.

En este momento, tanto la vista como el modelo tienen una referencia mútua, con lo que pueden fácilmente acceder a sus propiedades y métodos públicos. Es importante darse cuenta de que en esta implementación sólo puede haber una vista. Â¿Y es eso importante? Pues seguro que depende de a quien le preguntes. Desde luego es menos flexible (no puede haber 2 vistas al mismo tiempo), pero yo creo que es más sencillo a la hora de ser usado.

Después de configurar la vista, es el modelo quien decide qué hacer. En este caso tan simple tampoco tiene muchas opciones, por eso llama directamente al método displayValue al que le pasa el total de clicks hechos. En aplicaciones más complejas, lo más normal es que primero tenga que hacer algo de tarea sucia como leer un xml de configuración, extraer algún parámetro de las FlashVars, instanciar otras clases relativas al modelo, etc. etc.

En la vista mostramos el número de clicks y creamos un botón para aumentarlo. Es en este momento donde se supone que debería entrar en juego el controlador. Si tuvieramos un controlador como tal, la función manageButton seguramente debería encontrarse allí. Es decir, el controlador es el encargado de decidir qué hacer con las acciones del usuario.

Aún sin el controlador hemos conseguido separar la lógica (el contado de los clicks), de la presentación (cómo la vista muestra la información). Al modelo le da exactamente igual cómo se muestre el número de clicks (si centrado en la pantalla, si en verde, rojo, grande, pequeño) y la vista tampoco le importa mucho cómo se consigue esa información. Símplemente quiere que le digan qué tiene que pintar.

[ anterior ] [ siguiente ]

Comparte: