Prácticas recomendadas - Directrices de edición de aplicaciones SWF

La mejor forma de crear aplicaciones de Animate depende de la aplicación que se pretenda crear y de la tecnología empleada durante la creación de la aplicación.

Una aplicación en línea permite la influencia de un usuario en el sitio web al interactuar con él. Por ejemplo, la aplicación puede recopilar información del usuario (por ejemplo, un nombre de usuario y una contraseña para el registro), se puede añadir información al sitio (por ejemplo, en un foro) o el usuario puede interactuar en tiempo real con otros visitantes del sitio (por ejemplo, una sala de chat o un foro de discusión interactivo). Los resultados del servidor suelen mostrarse en el archivo SWF, según la interacción. Estos ejemplos son aplicaciones en las que se ven implicados los usuarios y los distintos tipos de interacción con el servidor. Un sitio web que no utilice información ni datos de los visitantes no se considera una aplicación (por ejemplo, un sitio de muestras, de animaciones de dibujos o con información estática). Las aplicaciones de Animate implican un proceso interactivo entre el usuario, una aplicación web y un servidor. El proceso básico se lleva a cabo del siguiente modo:

Al crear una aplicación, es preciso seleccionar un protocolo para la transferencia de datos. El protocolo advierte a la aplicación sobre el momento en que se envían o reciben datos, en qué formato se transfieren y cómo se gestionar la respuesta del servidor. Una vez recibidos los datos en el archivo SWF, se deben manipular y aplicarles formato. Si utiliza un protocolo, no deberá preocuparse por el posible formato inesperado de los datos. Cuando se transfieren datos con pares nombre/valor, es posible comprobar qué formato se aplica a los datos. Verifique que los datos tengan el formato correcto para no recibir datos con formato XML y que el archivo SWF sepa qué datos esperar para trabajar con ellos.

Recopilación de datos y aplicación de formato

Las aplicaciones dependen de la interacción del usuario con el archivo SWF. Con frecuencia, la introducción de datos en formularios depende del usuario. Animate permite introducir datos y aplicarles formato de muchas maneras en las aplicaciones de Animate. Esta flexibilidad existe, entre otros motivos, gracias a dos factores: la capacidad del usuario para controlar la animación y la creatividad en la interfaz, y la posibilidad de comprobar errores y llevar a cabo la validación con ActionScript.

Entre las ventajas que supone utilizar Animate para crear formularios que recopilen datos, se incluyen las siguientes:

• Mayor control del diseño.

• Menor necesidad (o ausencia de necesidad) de actualizar las páginas.

• Reutilización de los activos comunes.

   Para guardar la información recopilada del usuario, guárdela en un objeto compartido del equipo del usuario. Los objetos compartidos permiten almacenar datos en el equipo del usuario (método similar al uso de cookies). Para obtener más información sobre los objetos compartidos, consulte la clase sharedObject en la Referencia del lenguaje de ActionScript 2.0 y Referencia de componentes y lenguaje de ActionScript 3.0.

Envío y procesamiento de datos

Normalmente, se debe procesar la información antes de enviarla al servidor para que tenga un formato que el servidor pueda comprender. Cuando el servidor recibe los datos, se pueden manipular de diversas formas y se envían de vuelta al archivo SWF en un formato que pueda aceptar (desde pares nombre/valor hasta objetos complejos).

 El servidor de aplicaciones debe tener el tipo MIME de su salida definido como application/x-www-urlform-encoded. Si falta dicho tipo MIME, normalmente el resultado no se podrá utilizar cuando llegue a Animate.

En la tabla siguiente se muestran distintas opciones de envío de datos a un servidor y de recepción de datos utilizando Animate:

Cómo añadir carga de datos y validación

Se puede validar cualquier información recuperada antes de enviar dichos datos a un servidor. De este modo, se reduce la carga en el servidor remoto, ya que no controla tantas peticiones cuando los usuarios no rellenan los campos necesarios. No se debe basar exclusivamente en la validación de la aplicación en el lado del cliente: también debe llevarse a cabo la validación en el lado del servidor.

Incluso si crea un formulario sencillo de registro o de inicio de sesión, compruebe que el usuario ha introducido su nombre y su contraseña. Esta validación se debe llevar a cabo antes de enviar la petición al script de servidor remoto y esperar el resultado. No se base exclusivamente en la validación del lado del servidor. Si un usuario solo escribe un nombre de usuario, el script de servidor debe recibir la petición, validar los datos que se envíen y devolver un mensaje de error a la aplicación de Animate indicando que es necesario introducir tanto el nombre de usuario como la contraseña. Del mismo modo, si la validación sólo se realiza en el lado del cliente (en el archivo SWF), un usuario podría modificar ilícitamente el archivo SWF, sortear la validación y enviar los datos al servidor para intentar publicar datos erróneos.

La validación del lado del cliente puede ser algo tan sencillo como verificar que el contenido de los campos de formulario sea como mínimo de un carácter de longitud o que el usuario introduzca valores numéricos, no cadenas. Para validar una dirección de correo electrónico, por ejemplo, compruebe que el campo de texto de Animate no esté vacío y que contenga al menos los caracteres de arroba (@) y punto (.). Para la validación del lado del servidor, añada procesos de validación más complejos y verifique que la dirección de correo electrónico pertenece a un dominio válido.

Debe escribir código ActionScript para gestionar los datos que se cargan en el archivo SWF desde el servidor. Tras finalizar la carga de datos en un archivo SWF, puede acceder a los datos desde dicha ubicación. Utilice código ActionScript para comprobar si los datos se han cargado por completo. Puede utilizar funciones callback o detectores para enviar una señal que indique que los datos se han cargado en el documento.

Al cargar los datos, se les puede aplicar formato de varias maneras:

• Puede cargar datos XML; se utilizarán los métodos y clases XML para analizar los datos y utilizarlos. Si utiliza pares nombre/valor, los pares se convierten en variables y es posible manipularlos como tales.

• Puede recibir datos desde un servicio web o desde Animate Remoting.

En ambos casos, podría recibir estructuras complejas de datos, como conjuntos, objetos o conjuntos de registros, que se deben analizar y vincular adecuadamente.

Utilización de gestión de errores y depuración

Es preciso que la aplicación sea lo suficientemente robusta para anticiparse a ciertos errores y gestionarlos del modo correcto.

Uno de los mejores métodos para llevar a cabo la gestión de errores en ActionScript 2.0 consiste en utilizar los bloques try-catch-finally que permiten emitir y capturar errores personalizados. Mediante la creación de clases de errores personalizados, es posible reutilizar el código en la aplicación sin necesidad de reescribir código de gestión de errores. Para obtener más información sobre la emisión de errores personalizados consulte la clase Error en la Referencia del lenguaje ActionScript 2.0. Para obtener más información sobre los bloques try-catch-finally, consulte try..catch.. finallycatch..finally en Referencia del lenguaje ActionScript 2.0.

En ActionScript 3.0, utilice la clase flash.errors para capturar errores.

Para obtener más información, consulte la sección “Gestión de errores sincrónicos en una aplicación” en Programación con ActionScript 3.0.

Organización de archivos y almacenamiento de código

Tenga en cuenta las siguientes directrices antes de comenzar a organizar archivos y almacenar código:

• ¿Ha dividido el archivo SWF en varios archivos SWF? Si es así, ¿cómo deben interactuar?

• ¿Qué activos puede compartir entre los archivos SWF?

• ¿Qué archivos se cargan dinámicamente?

• ¿Cómo y dónde se almacena el código ActionScript?

  Al desarrollar una aplicación, almacene el código de servidor y los archivos en una estructura de directorios lógica, similar a la del paquete ActionScript. Ordene el código de esta forma para tenerlo bien organizado y reducir el riesgo de sobrescritura.

  Para aplicaciones más grandes, encapsule la comunicación entre el cliente y el servidor y los servicios en clases. Si utiliza clases, se beneficiará del modo siguiente:

• Podrá reutilizar el código en más de un archivo SWF.

• Podrá editar el código en un lugar centralizado y actualizar todos los archivos SWF mediante su republicación.

• Podrá crear una sola API que manipule distintos elementos de la interfaz de usuario y otros activos que lleven a cabo funciones parecidas.

Uso del patrón de diseño MVC

El patrón de diseño MVC se utiliza para separar la información, la salida y el procesamiento de los datos de la aplicación. La aplicación se divide en tres elementos: el modelo, la vista y el controlador; cada elemento gestiona una parte distinta del proceso.

Incorpora los datos y las reglas de la aplicación. Gran parte del procesamiento de la aplicación tiene lugar en esta parte del patrón de diseño. El modelo también contiene todos los componentes (por ejemplo, CFC, EJB y servicios web) y la base de datos. No se aplica ningún formato a los datos devueltos para la interfaz (o procesador principal) de la aplicación en esta parte del proceso. Los datos devueltos se pueden utilizar para distintas interfaces (o vistas).

Gestiona el procesador principal de la aplicación (la interfaz con la que interactúa el usuario) y representa el contenido del modelo. La interfaz especifica la forma en que se presentan los datos del modelo, produce la vista que utilizará el usuario y permite al usuario acceder a los datos de la aplicación o manipularlos. Si cambia el modelo, la vista se actualiza para reflejar los cambios introduciendo o extrayendo datos (enviando o solicitando datos). Si crea una aplicación web híbrida (por ejemplo, una en la que Animate interactúe con otras aplicaciones de la página), tenga en cuenta las distintas interfaces como parte de la vista del patrón de diseño. El patrón de diseño MVC admite la gestión de diversas vistas.

Gestiona los requisitos del modelo y de la vista para procesar y mostrar datos. Suele contener mucho código. Realiza llamadas a cualquier parte del modelo, según las peticiones realizadas por el usuario desde la interfaz (o vista), y contiene código específico de la aplicación. Puesto que este código es específico de la aplicación, no suele ser reutilizable. Sin embargo, el resto de componentes del patrón de diseño sí se pueden reutilizar. El controlador no procesa ni produce ningún dato: recibe la petición del usuario y decide a qué parte del modelo o componentes de la vista necesita llamar, determina dónde se envían los datos y qué formato se aplica a los datos devueltos. El controlador garantiza que las vistas tengan acceso a las partes de los datos del modelo que deben mostrar. Normalmente, el controlador transmite y responde ante cambios que afectan al modelo y a la vista.

Cada parte del modelo se crea como un componente de contenido propio en todo el proceso. Si se modifica una parte del modelo (por ejemplo, al rediseñar la interfaz), el resto de partes del proceso no suele requerir ninguna modificación, lo que reduce el número de problemas. Si el patrón de diseño se crea correctamente, puede cambiar la vista sin tener que rediseñar el modelo o el controlador. Si la aplicación no utiliza MVC, los cambios realizados en cualquier lugar pueden generar un efecto ondulado en todo el código. Esto requiere muchos más cambios que si se utilizase un patrón de diseño específico.

Uno de los motivos de peso para utilizar el patrón MVC es la necesidad de separar los datos y la lógica de la interfaz de usuario. Al separar estas partes del proceso, es posible disponer de varias interfaces gráficas distintas que utilicen el mismo modelo y datos sin formato. Esto significa que se podrá utilizar la aplicación con distintas interfaces de Animate, como una interfaz para la web, una para un PC de bolsillo, una versión para teléfonos móviles y, tal vez, una versión HTML que no utilice Animate en absoluto. Al separar los datos del resto de la aplicación se reduce significativamente el tiempo de desarrollo, de prueba e incluso de actualización de más de una interfaz del cliente. De forma similar, añadir nuevos procesadores principales para la misma aplicación es más sencillo si se dispone de un modelo existente.

Utilice MVC únicamente si va a crear una aplicación grande y compleja, como un sitio web de comercio electrónico o una aplicación de aprendizaje por Internet. Para utilizar esta arquitectura, es necesario planificar y comprender el funcionamiento de Animate y de este patrón de diseño. Piense detenidamente cómo interactúan entre sí las distintas partes; para ello se suele recurrir a las pruebas y a la depuración. Si utiliza MVC, las pruebas y la depuración están más relacionados y suponen una mayor dificultad que en aplicaciones Animate habituales. Si crea una aplicación en la que será necesaria complejidad adicional, considere la posibilidad de utilizar MVC para organizar el trabajo.

Creación de aplicaciones seguras

Tanto si crea un pequeño portal en el que los usuarios inicien sesión para leer artículos como si desarrolla una tienda de comercio electrónico de gran envergadura, habrá usuarios deshonestos que intenten piratear la aplicación. Por ello, debe tener en cuenta lo siguiente para que la aplicación sea segura.

• Publique los datos como HTTPS en los casos en que necesiten ser seguros. Cifre los valores en Animate antes de enviarlos a un servidor remoto para su procesamiento.

   no almacene nunca información ni código en un archivo SWF que no quiera que el resto de usuarios puedan ver. No es complicado desensamblar archivos SWF y ver su contenido con aplicaciones de terceros.

• Añada una política entre dominios para evitar que los dominios no autorizados puedan acceder a los activos.