Flash invisible

Mejore las aplicaciones web al utilizar secretamente Flash Player

¿Alguna vez ha deseado que las Cookies fueran mucho más grandes, de forma que pudiera almacenar más datos en el cliente o que pudiera hacer llamadas entre dominios de Asynchronous JavaScript and XML (Ajax)? Si es así, está de suerte. Estas dos técnicas pueden ser conseguidas utilizando Flash invisible. Entonces, ¿qué es el Flash invisible? Sin embargo, no es realmente invisible; es 1 píxel por 1 píxel, lo cual lo hace muy difícil de ver. Además, puede ser utilizado como una forma de aprovechar las posibilidades de Flash Player. En este artículo, aprenderá cómo desarrollar archivos de Flash invisible que le permiten almacenar hasta 100 KB de datos del lado del cliente y hacer llamadas de Ajax entre dominios—todo sin que sus usuarios se enteren de que se está utilizando Flash.

Michael Galpin, Arquitecto de software, eBay

Michael GalpinMichael Galpin es un arquitecto en eBay. Es un contribuidor frecuente de developerWorks. Ha hablado en diversas conferencias técnicas, incluyendo JavaOne, EclipseCon y AjaxWorld. Para obtener una vista previa del trabajo que realizará a continuación, siga a @michaelg en Twitter.



26-11-2012

Vamos a comenzar

Como se mencionó, en este artículo aprenderá cómo utilizar Flash para añadir posibilidades extras a sus aplicaciones web. Estar familiarizado con JavaScript es la habilidad más necesaria, pero la experiencia con ActionScript también será útil. Existen varias formas de compilar ActionScript, algunas de las cuales dependen de herramientas comerciales de Adobe. Sin embargo, es posible utilizar el SDK de Flex de código abierto de Adobe. Para este artículo, se utilizó Flex SDK 4.0.0.10485 (Beta 2). Para ejecutar los ejemplos, necesitará Flash Player versión 10 o superior. Yo utilizo la versión 10.0.42.34 durante este artículo. Vea Resources para obtener enlaces para adquirir estas descargas.


Almacenamiento local de Flash

Muchas aplicaciones web necesitan salvar el estado en el cliente. Algunas veces esto puede ser sólo un ID de sesión o de algún tipo que pueda ser utilizado para recuperar el estado del lado del servidor a partir de la memoria o de una base de datos. Sin embargo, muchas aplicaciones web deliberadamente evitan el estado del lado del servidor por el bien de la escalabilidad. Así que cualquier estado debe ser almacenado en el cliente. Además, es frecuentemente deseable que este estado persista más allá de la sesión actual del usuario.

Las cookies de HTTP han sido la forma predeterminada para manejar esto durante años. Sin embargo, las cookies de HTTP tienen sus desventajas. Pueden ser difíciles de utilizar desde la perspectiva de un desarrollador, ya que son físicamente sólo una cabecera de HTTP. Más importante aún, son una responsabilidad de seguridad potencial. Las cookies de HTTP son enviadas de ida y vuelta entre el cliente y el servidor en cada solicitud, así que cualquier dato en ellas puede ser interceptado. Además, los scripts/falsificación entre sitios frecuentemente se aprovechan de este hecho para "robar cookies". Si sus cookies son robadas, su cuenta correspondiente puede ser fácilmente comprometida o incluso se la pueden quitar.

Pero, la desventaja más común de las cookies HTTP es el límite de tamaño. Distintos navegadores colocan distintos límites para el tamaño máximo de las cookies de HTTP asignadas por dominio. La especificación de HTTP coloca el límite en 4 KB, y esto es con todo lo que puede contar. ¿Qué hacer entonces si es necesario almacenar más de 4 KB en el cliente? Si alguna vez pensó que sería divertido escribir un algoritmo de compresión de estilo gzip en Java™Script, entonces esta es su oportunidad. Es también posible utilizar una alternativa, como Flash.


Objetos compartidos locales

Flash Player da espacio de almacenamiento local de aplicaciones de Flash. De forma predeterminada, este tiene un límite de 100 KB por dominio. Es correcto: obtiene veinticinco veces el espacio que obtendría con cookies de HTTP. También existen otras diferencias clave. Una, los datos del lado del cliente en Flash nunca son enviados al servidor, ya que no tiene relación alguna con HTTP. Por supuesto, es posible tomar estos datos y enviarlos a su servidor si lo desea. Obviamente nada lo detendrá para hacer esto. Sin embargo, tiene que elegir qué datos enviar y cómo son enviados. Si realmente necesita estos datos en el cliente y el servidor, esto en realidad puede volverse un poco tedioso. Sin embargo, esto es en general mucho más seguro, ya que debe "exponer" explícitamente estos datos en el cable.

La API de Flash para almacenar y recuperar datos locales es conocida como un SharedObject. Flash de hecho tiene una noción de SharedObjects que puede ser también remota, por lo que la variedad de sólo cliente es frecuentemente conocida como un local SharedObject. La API es muy simple y permite el almacenamiento y recuperación de objetos arbitrariamente complejos utilizando un paradigma de valor clave. El Listado 1 muestra código simple para almacenar y recuperar SharedObjects.

Listado 1. Almacenar y recuperar SharedObjects
package{
    
    import flash.display.Sprite;
    import flash.net.SharedObject;
    
    public class JsHelper extends Sprite{
        private const SO_NAME:String = "helperSo";
        
        private function saveLocal(name:String, value:Object):void{
            var so:SharedObject = SharedObject.getLocal(SO_NAME);
            so.data[name] = value;
            so.flush();
        }
        
        private function readLocal(name:String):Object{
            var so:SharedObject = SharedObject.getLocal(SO_NAME);
            return so.data[name];
        }
    }
}

Si no está familiarizado con ActionScript, el código en el Listado 1 puede verse algo extraño para usted. ActionScript es muy similar a JavaScript; de hecho, es derivado del estándar de ECMAScript. Sin embargo, tiene muchos dispositivos normalmente vistos en lenguajes como C++ y Java. Las variables son fuertemente digitadas y hay herencia basada en la clase. El código en el Listado 1 es una clase que extiende la clase Sprite . Dicha clase se compilará en un archivo de Shockwave Flash (SWF) que puede ser intercalado en una página web. Esta clase tiene dos métodos. Uno es llamado saveLocal. Uno toma un nombre (el cual es sólo una cadena de caracteres) y un valor (el cual puede ser cualquier tipo de objeto). Después obtiene un SharedObject particular utilizando el método de fábrica getLocal .

Cada definición de la instancia SharedObject tiene una propiedad de datos que puede ser pensada como una tabla hash para almacenar datos. Eso es lo que la segunda línea de la función saveLocal hace. La última línea "desecha" el SharedObject o la persiste en el disco. Eso es todo lo que requiere hacer para salvar localmente. Si hace un uso pesado de SharedObjects y comienza a acercarse al límite de los 100 KB, entonces tal vez quiera adjuntar receptores de eventos en ellos. Esto le permitirá responder a eventos como "flush completed" o "flush failed".

Leer a partir del almacén local es tan sencillo como hacerlo en la función readLocal en el Listado 1. En este caso, el SharedObject es buscado y el parámetro name es utilizado para buscar el objeto salvado desde la tabla hash de datos. Si el nombre no corresponde a una clave en la tabla hash, entonces simplemente se retornará un valor nulo. Ahora que ha visto cómo acceder a SharedObjects, sólo necesita obtener este Flash (invisiblemente) en una página web -- y accederlo desde JavaScript.


Hacerlo invisible

De forma predeterminada, ninguna de las funciones mostradas en el Listado 1 serán accesibles fuera de la clase JsHelper . Sin embargo, Flash hace que sea bastante fácil exponer funciones en JavaScript. Todo lo que tiene que hacer es utilizar la API ExternalInterface de Flash, como se muestra en el Listado 2.

Listado 2. Exponiendo funciones de JsHelper para JavaScript
package{
    
    import flash.external.ExternalInterface;
    import flash.net.SharedObject;
    
    public class JsHelper extends Sprite{
        private const SO_NAME:String = "helperSo";
        private const SAVE_LOCAL:String = "saveLocal";
        private const READ_LOCAL:String = "readLocal";
        
        public function JsHelper(){
            ExternalInterface.addCallback(SAVE_LOCAL, saveLocal);
            ExternalInterface.addCallback(READ_LOCAL, readLocal);
        }
        // functions omitted for brevity
    }
}

El Listado 2 simplemente muestra lo que fue añadido a la clase JsHelper desde el Listado 1. Lo primero que hay que notar es que ha añadido un constructor explícito. Este será llamado siempre que una instancia de esta clase sea creada, justo como lo esperaría. En él, usted utiliza la API ExternalInterface para exponer las dos funciones, saveLocal y readLocal, en cualquier JavaScript en cualquier página web donde este SWF será intercalado. La función addCallback toma una cadena de caracteres como su primer parámetro. Este será el nombre utilizado por clientes de JavaScript para identificar la función. Puede ser distinto del nombre de función en la clase, pero en este caso son el mismo. El segundo parámetro es un cierre de función. Como JavaScript, ActionScript es un lenguaje funcional, así que las funciones son de primera clase y pueden ser pasadas. Esto es todo lo que se necesita para exponer las dos funciones. Ahora echemos un vistazo al JavaScript para intercalar y acceder al SWF. Esto es mostrado en el Listado 3.

Listado 3. Intercalando Flash invisible
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Flash Helper for JavaScript</title>
<script type="text/javascript" src="swfobject.js"></script>
<script type="text/javascript">
    function writeFlash(){
        var attrs = {id : "JsHelper"};
        swfobject.embedSWF("JsHelper.swf", "flashContainer", "1", "1", "10.0.0", 
            "playerProductInstall.swf", null, null, attrs);
    }
    function save(name, value){
        var helper = document.getElementById("JsHelper");
        helper.saveLocal(name, value);
    }
    function load(name){
        var helper = document.getElementById("JsHelper");
        return helper.readLocal(name);        
    }
</script>
</head>
<body onload="writeFlash()">
    <div id="flashContainer"></div>
</body>
</html>

Lo primero que hay que notar sobre este código es que utiliza una biblioteca de JavaScript de terceros llamada swfobject. Esta es la biblioteca estándar de facto para intercalar SWFs. Es de código abierto y, aunque no fue diseñada originalmente por Adobe, es distribuida por ellos ahora. Su función embedSWF es utilizada para intercalar el SWF compilado desde el Listado 2. El primer parámetro es el URL para el SWF. En este caso, el SWF está siendo atendido desde el mismo servidor y ruta que el archivo HTML, así que un URL relativo funciona bien. El segundo parámetro es el ID del elemento de HTML en la página donde el SWF será intercalado. En este caso, es "flashContainer"—y notará que en el cuerpo del documento de HTML hay un div de HTML con este ID.

Los siguientes dos parámetros para embedSWF son el alto y el ancho del SWF. En este caso, ambos son de 1. Eso significa que su SWF será de un píxel de alto y un píxel de ancho. ¡Esta es la invisibilidad de SWF! El siguiente parámetro es la versión mínima de Flash que su JavaScript verificará. Si Flash está instalado en el navegador, pero es una versión anterior a la versión mínima que pasó a embedSWF, entonces embedSWF utilizará el siguiente parámetro "playerProductInstall.swf". Este es el URL para otro SWF utilizado para solicitar al usuario que instale la versión más reciente de Flash. Para el Flash invisible, esto realmente no tiene importancia—el SWF que dice que "es necesario instalar la versión más reciente de Flash" también será invisible (bueno, de 1x1 píxeles). El último parámetro pasado a embedSWF es importante. Este es un objeto de atributo que puede contener diversos parámetros opcionales. Uno de esos parámetros opcionales es un ID para su SWF. Para un caso de uso como el de este artículo, este parámetro no es opcional—¡es crítico! Esto le dará a su SWF un ID de HTML, el cual necesitará acceder programáticamente utilizando JavaScript.

Ahora eche un vistazo a las dos funciones de JavaScript en el Listado 3. Son bastante similares. Ambas utilizan la conocida función getElementById para llevar una referencia al SWF. Note que utilizan el ID especificado en el objeto attrs en la función writeFlash . Después de que lleva una referencia al SWF, es posible llamar directamente las funciones de ActionScript expuestas en el Listado 2.. La clave aquí es que el nombre de función utilizado en JavaScript debe coincidir con el nombre expuesto a través de la función ExternalInterface.addCallback o del primer parámetro pasado a addCallback.

Para el método de salvado, está pasando un objeto de JavaScript como el parámetro de valor. Esto puede ser cualquier objeto, incluso uno con una profunda estructura anidada. Sin embargo, sólo sus datos serán pasados. Si el objeto tiene cualquier función, ésta no será pasada. Tome en cuenta que el método de carga retorna cualquier cosa que venga del SWF. ¿Esto qué será? La respuesta es simple: lo que sea que usted envíe. Si almacenó un valor escalar como un número o cadena de caracteres, entonces eso es lo que regresará. Si almacenó un objeto complejo entonces ese objeto de JavaScript es lo que regresará—no hay necesidad de analizar ni de nada más. Una excepción es que si su objeto tiene funciones, éstas obviamente pueden no ser serializadas y salvadas. Así que sólo son los datos de su objeto, ni más ni menos. Eso concluye todo lo que es necesario saber sobre utilizar Flash para almacenamiento local. Antes de avanzar y ver el Ajax entre dominios con Flash, examine algunas de las alternativas para almacenamiento local que pueden estar disponibles para usted.


Otras opciones de almacenamiento local

Mencioné que Flash puede ser una opción atractiva para cookies de HTTP para almacenamiento del lado del cliente. Sin embargo, hay otras tecnologías web que han adoptado el mismo paradigma que SharedObjects. De hecho, durante años los diversos navegadores han proporcionado APIs muy similares. Sin embargo, estas APIs eran normalmente distintas de un navegador a otro. Así que podía hacer algo de exploración del navegador y después utilizar la API específica del navegador. Flash proporcionó una alternativa consistente. El código desarrollado en este artículo funcionará en virtualmente cualquier navegador: desde Internet Explorer 6 y Firefox 2, hasta las versiones más recientes de esos navegadores. Las versiones más recientes proporcionan una alternativa consistente. La especificación de HTML 5 incluye una API localStorage . Esta está implementada en la versión más reciente de los principales navegadores, incluyendo IE 8 y Firefox 3.5. Así que si sólo tiene que preocuparse por esos navegadores, entonces localStorage es una opción viable. Si tiene que preocuparse por navegadores anteriores (IE 6, IE 7, etc.), entonces puede ser más sencillo quedarse con Flash. Ahora echemos un vistazo a otro lugar donde Flash puede abrir nuevas posibilidades, el Ajax entre dominios.


Ajax Entre Dominios

Ajax se ha vuelto ubicuo para aplicaciones web; es una parte asumida de cualquier aplicación web. Una de las principales restricciones de Ajax es la política notablemente del mismo origen. Si su página web fuera atendida a partir de un .com, entonces sería posible sólo hacer llamadas de Ajax (o, más precisamente, XMLHttpRequest) a a.com. No podría llamar a b.com, por ejemplo. No importa si su compañía es dueña de a.com y b.com; al navegador eso no le importa. Sin embargo, este no es el caso para aplicaciones de Flash.

Se puede otorgar permiso a las aplicaciones de Flash para hacer llamadas a dominios distintos a aquel donde fueron atendidas. Esto se hace utilizando un archivo de política entre dominios. De forma predeterminada, el tiempo de ejecución de Flash buscará este archivo de política en la raíz del documento de su servidor: http://<your domain>/crossdomain.xml. Por ejemplo, el Listado 4 es el archivo de política para el dominio de búsqueda de Twitter, http://search.twitter.com/crossdomain.xml.

Listado 4. Archivo de política para el dominio de búsqueda de Twitter
<!DOCTYPE cross-domain-policy 
SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">

<cross-domain-policy>
    <allow-access-from domain="*" />
</cross-domain-policy>

Este es un archivo de política especialmente agradable. Está otorgando acceso a SWFs desde cualquier dominio (como es indicado por el comodín "*"). Así que cualquier aplicación de Flash puede llamar las APIs de búsqueda de Twitter. Los archivos de política como este son comunes en sitios web importantes con APIs públicas. Sin embargo, algunos sitios también utilizan políticas más restrictivas que sólo permiten acceso de otros dominios que les pertenecen o con los que están asociados. Con los archivos de política, obtiene un control de grano fino sobre exactamente quién puede llamar a sus servidores y quién no. Eche un vistazo a cómo es posible extender estas mismas habilidades hacia aplicaciones de Ajax.


Ir entre dominios

Si su aplicación sólo necesitó llamar un dominio específico, puede escribir código de ActionScript que llamó a ese dominio y después exponerlo utilizando ExternalInterface para JavaScript en su aplicación. Sin embargo, tomaré una ruta un poco más ambiciosa e intentaré expone esto genéricamente. Así, en el Listado 5 verá una clase de utilidad para llamar cualquier dominio desde ActionScript.

Listado 5. SWF de utilidad entre dominios
package{
    
    import flash.display.Sprite;
    import flash.events.Event;
    import flash.external.ExternalInterface;
    import flash.net.URLLoader;
    import flash.net.URLRequest;
    
    public class JsHelper extends Sprite{
        private const SEND_REQUEST:String = "sendRequest";
        
        public function JsHelper(){
            ExternalInterface.addCallback(SEND_REQUEST, sendRequest);
        }

        public function sendRequest(url:String, handlerName:String, 
                method:String="GET", content:Object=null, 
                headers:Object=null):void{
            var loader:URLLoader = new URLLoader();
            var request:URLRequest = new URLRequest(url);
            if (method){
                request.method = method;
            }
            if (headers){
                for each (var name:String in headers){
                    request.requestHeaders[name] = headers[name];
                }
            }
            if (content){
                request.data = content;
            }
            loader.addEventListener(Event.COMPLETE, 
                function(e:Event):void{
                    ExternalInterface.call(handlerName, loader.data);
            });
            loader.load(request);
        }
    }
}

Esta clase expone su función sendRequest para JavaScript utilizando ExternalInterface. Esto se hace en el constructor del objeto, tal como lo hizo en el ejemplo anterior en el Listado 2.. La función sendRequest es un poco más complicada: tiene dos parámetros requeridos. El primer parámetro es el URL al que desea llamar. Esta es la cadena de caracteres completa de URL, incluyendo cualquier parámetro de solicitud. El siguiente es el nombre de la función de JavaScript que desea que Flash llame cuando reciba una respuesta del servidor. Igual que con el Ajax típico, Flash hace llamadas asíncronas a servidores remotos, de forma que la hebra de IU principal no es congelada mientras se espera una respuesta del servidor remoto. Por lo tanto, igual que con Ajax, es necesario escribir una función class que será invocada después de que una respuesta es recibida del servidor. Usted pasa esto a Flash como una cadena de caracteres, pero debe ser el nombre exacto de la función.

La función sendRequest también tiene tres parámetros opcionales. ActionScript le permite tener parámetros opcionales, pero deben tener valores predeterminados para utilizar. El primero de estos es el método HTTP que será utilizado, el cual es normalmente GET o POST. En este artículo, yo uso GET de forma predeterminada, pero es posible alterarlo temporalmente con facilidad a POST si eso es requerido por el servidor remoto. El siguiente parámetro opcional es llamado content. Este es un objeto de datos genéricos que contiene cualquier par de valores de nombre que desee enviar al servidor remoto. Necesitaría utilizar esto si está enviando datos hacia el servidor remoto. Finalmente, el último parámetro opcional es otro objeto de datos genéricos para cabeceras. Este es para configurar cabeceras HTTP personalizadas para enviarlas como parte de la llamada al servidor remoto.

El código entonces toma todos estos parámetros y construye una solicitud de HTTP utilizando el objeto URLRequest de Flash y envía la solicitud utilizando la claseURLLoader de Flash. Un receptor de eventos está conectado a URLLoader de forma que sea posible procesar la respuesta después de que es retornada. Aquí usted crea un cierre, igual que como lo haría en JavaScript, para crear una función incorporada anónima que será invocada cuando el evento COMPLETE sea iniciado por el cargador. Este cierre simplemente utilizará ExternalInterface para llamar a la función cuyo nombre fue pasado a sendRequest. Pasará todos los datos desde el servidor remoto hacia esa función. Este es definitivamente un caso de uso más complejo que el de almacenamiento local. Eche un vistazo al Listado 6 para obtener un ejemplo que llame la búsqueda de Twitter.

Listado 6. Llamando la búsqueda de Twitter
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Calling Twitter from the client</title>
<script type="text/javascript" src="swfobject.js"></script>
<script type="text/javascript">
    function writeFlash(){
        var attrs = {id : "JsHelper"};
        swfobject.embedSWF("JsHelper.swf", "flashContainer", "1", "1", "10.0.0",
            "playerProductInstall.swf", null, null, attrs);
    }
    function search(){
        var keyword = document.getElementById("keyword").value;
        var helper = document.getElementById("JsHelper");
        helper.sendRequest("http://search.twitter.com/search.json?q=" + keyword, 
"showResults");
    }
    function showResults(responseStr){
        var response = eval("(" + responseStr +")");
        var results = response.results;
        alert("#Results = " + results.length);
    }
</script>
</head>
<body onload="writeFlash()">
    <div id="flashContainer"></div>
    <div id="inputDiv">
        <label for="id">Search Twitter</label>
        <input type="text" id="keyword" name="keyword"/>
        <input type="button" value="Search Twitter" onclick="search()"/>
    </div>
</body>
</html>

El código aquí es similar al HTML/JS que vio en el Listado 3. De nuevo, usted utiliza la biblioteca swfobject para intercalar el SWF en la página. Este código tiene un formulario simple que le solicita al usuario ingresar una palabra clave para buscar en Twitter. La función de búsqueda es invocada después de que se hace clic en el botón Search. Esto jala la palabra clave del campo de entrada y la utiliza para crear la cadena de caracteres de URL que desea llamar. Esto es pasado a JsHelper SWF, igual que como lo hizo en el Listado 3, al obtener una referencia para el SWF utilizando su ID y después directamente llamando la función expuesta utilizando ExternalInterface. Usted pasa el URL y una cadena de caracteres llamando la función de devolución de llamada. Después de que los datos son retornados de Twitter, son pasados a la función showResults . Esta será una cadena de caracteres de JSON, ya que es lo que regresa de Twitter, de forma que sea posible simplemente utilizar la función eval de JavaScript para convertirla en un objeto. En este caso, simplemente muestra el número de resultados retornados de Twitter. Sin embargo, puede fácilmente crear algo de HTML en la página que enumeró cada uno de estos resultados; es simplemente una cuestión de reutilizar código de DOM. Así de simple, ha hecho una llamad de Ajax entre dominios cortesía de Flash. Igual que utilizar Flash para almacenamiento local, existen algunas otras opciones que debe conocer.


Alternativas entre dominios

Durante años, Flash ha hecho posible hacer llamadas entre dominios así como ha hecho posible hacer almacenamiento local. En forma similar al caso de uso de almacenamiento local, algunos navegadores web han ideado su propia manera de hacer esto, y han habido intentos subsecuentes en la estandarización. No ha sido una historia tan agradable como lo fue con el almacenamiento local. Aunque actualmente hay un estándar para Ajax entre dominios, no es adoptado por IE 8. En su lugar, IE 8 tiene una forma propia de hacer Ajax entre dominios. Esta implementación propia es nueva en IE 8 y no está presente en versiones anteriores de IE. Así que, una vez más, Flash presenta un modelo que funciona en todos los navegadores.

Únase al grupo de desarrollo web en My developerWorks

Discuta sobre temas y comparta recursos con otros desarrolladores sobre el desarrollo web en el grupo de desarrollo web de My developerWorks.

¿No es un miembro de My developerWorks? ¡Únase ahora!

Finalmente, si hace algo de investigación en Ajax entre dominios, seguramente encontrará otras formas de hacerlo que no requieran Flash o alguno de los nuevos dispositivos en los navegadores. Esta técnica, normalmente llamada JSONP (JSON con Padding) o "etiqueta de script dinámico", aprovecha el hecho de que el navegador no obliga el uso de la misma política de origen en archivos de origen de JavaScript. Así que una etiqueta de script es creada en los puntos de origen para el URL que desea llamar y es insertada en el DOM. El URL normalmente incluye un parámetro "callback", el cual es el nombre de la función de devolución de llamada que desea invocar. El servidor entonces deriva los datos con el nombre de función, de forma que la función es invocada con los datos desde el servidor a donde fueron pasados. Esta técnica es ampliamente utilizada en Internet (por ejemplo, la API de búsqueda de Twitter mostrada anteriormente soporta esta técnica), pero tiene serios riesgos de seguridad asociados a ella—por eso el deseo de una forma estándar y segura de hacer esto, en forma similar a como lo hace Flash.


Resumen

Este artículo explicó cómo utilizar Flash para expandir las posibilidades de sus aplicaciones web. Es posible incrementar dramáticamente la cantidad de almacenamiento local disponible para su aplicación. Esto le permite guardar en caché grandes cantidades de datos en el cliente. También es posible hacer llamadas de Ajax entre dominios desde sus aplicaciones web utilizando Flash. Esta es sólo una muestra de algunas de las posibilidades de Flash. Si encuentra algo más que le ayude, es posible utilizar las mismas técnicas: hacer el Flash invisible y exponer sus funciones utilizando ExternalInterface.


Descargar

DescripciónNombretamaño
Article source codeJsHelper.zip12KB

Recursos

Aprender

Obtener los productos y tecnologías

  • Descargue el código de origen del SKD de Flex.
  • Innove en su próximo proyecto de desarrollo de fuente abierta con Software de prueba IBM, disponible para descarga o en DVD.

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=
ArticleID=847039
ArticleTitle=Flash invisible
publish-date=11262012