martes, junio 19, 2012

AIR Android iOS App con Blue Marble y FlashDevelop

Antes de proceder con este artículo, le recomiendo que lea mi artículo anterior "Desarrollando Apps para iOS y Android con FlashDevelop" que le será de utilidad si quiere iniciar a desarrollar aplicaciones para dispositivos móviles con FlashDevelop.

Sobre este artículo Mi objetivo es ayudarles a crear su primera aplicación AIR Android/iOS completamente funcional gracias a un par de herramientas que he desarrollado y que considero que pueden ser de utilidad para muchos por su sencillez.

Herramientas
  • En esta ocasión usaremos el ya hablado en el artículo anterior FlashDevelop con Flex y AIR.
  • ArbolNegro: Usaremos mi proyecto OpenSource que he movido recientemente a Github; es una serie de paquetes de clases que he desarrollado desde hace varios años, que eliminan ciertas tareas repetitivas al momento de crear programas y aplicaciones con actionscript, como lo son cargar un XML (complicado para principiantes en as3), un tipo muy singular de LiquidLayout, carga de clases externas almacenadas en otros swfs entre otras, que si se presenta la oportunidad las demostraré, pero no es el punto principal de este artículo.
  • BlueMarble: Blue Marble inició como un apéndice de Arbol Negro, pero sus funciones cambiaron drásticamente durante el desarrollo y actualmente lo he separado como proyecto de Arbol Negro y funciona como un Framework, pero sigue siendo dependiente de él. La función principal de Blue Marble es crear un GUI sin preocuparse por ello, semejante a Flex en el hecho de que juntas unos cuantos componentes y ya tienes tu aplicación, pero con las diferencias que es mucho más liviano (mi principal queja de Flex es su peso), está completamente basado en código, no en un markup tipo HTML como Flex, por lo que posiblemente sea todo muy abstracto para quien solo haya hecho de este tipo de aplicaciones, pero lo hice de esta forma para evitar que en el desarrollo se mezcle el código con el markup, una mala práctica (o no dependiendo del desarrollador) a raíz de arreglar cosas de última hora. Será Blue Marble de lo que hablaré principalmente.
Inicializando

Descargamos ArbolNegro y BlueMarble y lo ponemos en nuestro directorio de elección; por costumbre tengo separadas todas las class del proyecto en sí, pero también es recomendable tener la copia con el proyecto por los posibles cambios a futuro de los paquetes que incluyamos. Procedemos a abrir FlashDevelop, y creamos un nuevo proyecto "AIR Mobile AS3 APP"; una vez cargado procedemos a agregar las referencias a nuestras class de ArbolNegro y BlueMarble y cualquiera que usted ya tenga con anterioridad. Para ello nos dirigimos al menú, Tools > Global ClassPaths (Ctrl - F9)



Seleccionan as3 en el combobox, presionan Add Classpath y van al directorio donde se encuentra ArbolNegro y BlueMarble; si están por separado hay que agregar ambos directorios. Ambos paquetes empiezan con la carpeta "net/", la carpeta que debe ser incluida debe ser la que contenga a esa misma carpeta net/ para poder hacer la llamada a las classes desde la raíz, por ejemplo import net.absulit.bluemarble.controls.Button. Una vez agregadas las classes podemos proceder a crear lo básico de la aplicación.

Creando la aplicación

 Antes de iniciar, hay unas cuantas cosas que quiero que tengan presentes, una de ellas es que el Framework funciona en su estado actual; puede que se encuentren un bug, pero hasta el momento no me ha impedido publicar 2 aplicaciones en Play Store; otra es que estoy consciente que se puede mejorar, hay  un par de cosas que quiero cambiar y se las mencionaré en el camino; en el momento que las desarrollé me pareció el enfoque más sencillo, y me gusta no complicarme,y por el momento se van a quedar así hasta que planifique una re estructuración; pero nada de lo anterior les va a evitar desarrollar un app super facil y rápido. 

Profundizando un poco más sobre BlueMarble y su estructura, este tiene una interfaz mínima, transparencias y lineas monocromáticas; también su estructura funcional se basa en tomar ideas de proyectos ya existentes, como lo es Flex y su concepto de ventanas que me parece muy atinado, al igual que su navegación; y por otro lado el concepto de States de Flixl (que también usa Starling) en el que un "mundo" es una class aparte, y para entrar en ese nuevo mundo, llamamos a la Class de forma dinámica sin almacenar todo en memoria. Así cada ventana de BlueMarble es un "Mundo Nuevo" donde programamos aparte del resto del sistema y con una comunicación sencilla entre ventanas enviando un objeto de parámetro que veremos más adelante. 

Para empezar ya a codear, nos vamos a la carpeta /src y abrimos el archivo Main.as que es la raíz de nuestro programa; aquí vamos a establecer las variables de BlueMarble y las llamadas de clases, pero antes, vamos a comentar una línea que luego nos puede ser algo incómoda al momento de hacer debug, y es en el método deactivate(), que es un listener que se dispara al ponerse Idle el aparato, pero también al darle click fuera de la ventana de AIR, por lo que se nos puede cerrar sin querer al estar revisando el output de FlashDevelop:

  private function deactivate(e:Event):void { // auto-close         //NativeApplication.nativeApplication.exit(); 
}

Sugiero cambiar la siguiente linea de código de point a gesture, ya que si en algún momento queremos proceder a usarlos es muy probable que se nos olvide y caigamos en frustración porque los eventos no se dispararán; no es obligado y tampoco afecta el uso de BlueMarble (hasta donde mis pruebas actuales indican), pero es una recomendación.

 // touch or gesture? Multitouch.inputMode = MultitouchInputMode.GESTURE;

Procedemos a continuación a crear una variable para nuestro administrador de ventanas llamando a la class WindowManager de Blue Marble

WindowManager

 private var _windowManager:WindowManager;

al digitar los dos puntos (":") se llamará al generador de código automático y nos incluirá WindowManager en cuanto presionemos enter al aparecer un menú contextual; en caso que no se importe solo por presionar mal alguna tecla, procedemos a colocar el cursor sobre el nombre de la class e inmediatamente presionamos Ctl-Shift-1; esta secuencia importará WindowManager automáticamente y con cualquier otra class en nuestro código; una entre varias ventajas que tiene FlashDevelop con respecto al manejo de código actionscript que está ausente en otros lenguajes que dan soporte de colores como PHP, Javascript; aunque PHP tiene autocompletar para classes nativas, pero no así importadas por nosotros; esto obviamente por que su enfoque principal es HaXe/as3. WindowManager es la class que administrará nuestras ventanas y la navegación entre ellas, cargándolas y descargándolas de memoria, conforme las llamamos; es una class gráfica dependiente de la variable Stage, por lo que recomiendo este siguiente código para asegurarse de que Stage ya se ha cargado correctamente, ya que podrían presentarse problemas si esto no se realiza, ya que la necesita para tomar medidas de pantalla y colocar los elementos antes de que se presenten en pantalla:

 // entry point init(); if (stage != null){ 
addedToStage(); 
}else{ 
addEventListener(Event.ADDED_TO_STAGE, addedToStage); 
}

Este código se coloca en el constructor Main(); tiene una función init() para inicializar variables, esto porque el constructor en Actionscript al compilarse no se comprime, lo que aumenta el tamaño final del archivo, así que hay que mantener al mínimo el uso de variables e inicializadores en el constructor, por eso es mejor tener una referencia a una función sin comprimir, que todas las variables; luego preguntamos si el stage existe; si ya se cargó para ese momento, entonces procedemos a llamar a la función donde iniciará el programa, en caso contrario ponemos un listener y este esperará a que el contenido se cargue para iniciar. Este método también es muy útil al crear swf para web, ya que el archivo al ser descargado no estará funcional hasta que esté completo, y si stage se llama antes pues habrán problemas. En nuestra funcion addedToStage agregamos al parametro default de Event un null para poder hacer la llamada en solitario de la función en el constructor, y también para evitar ponerle el null a mano en el constructor

 private function addedToStage(e:Event = null):void

 También movemos las siguientes lineas de código que estaban en el constructor aquí:

stage.scaleMode = StageScaleMode.NO_SCALE; 
stage.align = StageAlign.TOP_LEFT; 
stage.addEventListener(Event.DEACTIVATE, deactivate);

Y ahora sí dentro de esta función podemos iniciar nuestro programa después de estas últimas líneas. Window Manager en sí misma la vamos a necesitar en otras partes, así que la convertí en un Singleton; que es una class que solo puedes instanciar una vez, y solo por el método ofrecido por la clase; esto también para mantener la integridad de la aplicación y no tener más de un WindowManager corriendo; pero si podremos tener más de una referencia y usar sus propiedades como una variable global.

 _windowManager = WindowManager.instance; addChild(_windowManager);

La raya baja en la propiedad ("_") es una costumbre de desarrolladores de actionscript; tiene dos utilidades, una es hacer notoria que la variable es privada en contexto de variables locales en un método, pero es puro concepto visual, hay muchos que no les gusta y no lo usan; pero la segunda utilidad tal vez los haga cambiar de parecer, y es que el autocompletar de FlashDevelop al presionar "_" y una letra, nos mostrará únicamente esas variables o propiedades privadas, y se tiene un acceso rápido a ellas. Pueden no usarlas, pero se los recomiendo, es casi que un standard entre desarrolladores de actionscript. WindowManager es un Sprite, lo que quiere decir que se verá en pantalla; pero no será visible hasta indicarselo directamente por actionscript, y para eso está addChild, que agrega variables de tipo DisplayObject al DisplayList que es el ambiente visual, lo que vemos en pantalla. Inmediatamente después de creada, la agregamos al DisplayList, para luego proceder a agregar nuestras pantallas o ventanas; esta es una de las cosas que quisiera mejorar, ya que por costumbre a veces, hago addChild después de tener a todos los objetos visuales y variables listas, pero WindowManager necesita de acceso a stage, y solo puede tenerlo al hacerse el addChild, ya que como tuve que elegir crear el Singleton, no puedo enviar stage de parámetro; si se hace addChild de WindowManager luego de agregar las ventanas, es muy probable que todo se desordene en pantalla, le recomiendo lo intente para ver las consecuencias de ello, pero luego de agregar unas ventanas para que sea visible el daño.

Window

Una ventana es una class que hereda de Window, así de simple, esto nos permitirá enviársela a WindowManager para que la coloque en nuestra pantalla. Para crear una nueva class, damos click derecho sobre nuestra carpeta src/ y seleccionamos Add > New Class y llenamos los datos de la siguiente ventana:




A simples rasgos una class heredada de Window luce así:    

 package { 
import net.absulit.bluemarble.controls.Window;
public class MainWindow extends Window { 
public function MainWindow(width:int=400, height:int=400, data:Object=null) { super(width, height, data);

}


Sin poner nada en esta ventana, podemos enviársela a WindowManager y tener la aplicación vacía, pero lista:

   _windowManager.push(MainWindow, "Home", [true|false], [iconpath:String]); _windowManager.sort();

 Para esto agregamos las dos lineas anteriores; el método push, inserta la referencia de la class dentro de WindowManager para futuro uso, incluso si llamamos directamente a la class luego, es necesaria para otros procesos; el segundo parámetro existe para otro componente visual: El TabBar; ese string pondrá un texto en el TabBar para ser visualizado inmediatamente y para navegación; el true o false sirve para esconder el boton del TabBar; el iconpath es un parámetro que exíste pero no está completamente funcional; provee un ícono para ser usado con o sin el texto, pero me pareció más apropiado en este primer release de BlueMarble dejar funcional al menos uno y luego retomar el desarrollo, aunque el campo está abierto desde ya. Luego llamamos a la función sort() que acomodará finalmente los elementos en pantalla y principalmente el TabBar, que tiene que hacer un conteo de las ventanas existentes y visibles; así como de las medidas de la pantalla actuales. Técnicamente con esto la aplicación está completa, pero falta incluir algo, un archivo del que el mismo ArbolNegro depende, y es flash.swc (incluido en la descarga del ejemplo). Si considera que está listo, puede probar la aplicación, presionando Ctrl-Enter y probarlo StandAlone en el computador:  



Me gusta cambiar las dimensiones en Run.bat y usar las dimensiones en proporción al iPhone, ya que a la vez sirve para visualizarlo en la computadora y acostumbrarnos al mínimo tamaño disponible:

  set SCREEN_SIZE=320x480:320x480

 Como pueden apreciar en la imagen anterior, la interfaz es mímina; TabBar con "Home" de label, y arriba, aunque vacío, está el ActionBar, que podrá contener por ahora, un botón de navegación a la izquierda, aunque usted puede darle el uso que requiera, y un botón de acción a la derecha, pensado para menús secundarios; en medio puede ir un título, que se ajustará y mostrará de acuerdo a su tamaño. Estos elementos son accesibles gracias a propiedades dentro de cada Window, aunque pienso cambiarlo a algo más sencillo y asignarlo al WindowManager en un futuro, o ambos, pero prefiero el WindowManager para un acceso más abierto que actualmente no tengo al poner el acceso dentro de Window. Veamos un ejemplo sobre como modificar estas propiedades; para esto nos vamos a nuestra recién creada ventana MainWindow.as, recordando mantener el proceso de preguntar si existe stage antes de usarlo, proseguimos con el código:

  private function init():void { 
_actionBar.title = "Blue Marble Demo 1"; 
_actionBar.navigation = new Button(); 
_actionBar.navigation.label = "Exit"; _actionBar.navigation.addEventListener(MouseEvent.CLICK, onClickActionBarNavigation);
_actionBar.action = new Button(); 
_actionBar.action.label = "Test"; 
}

 private function onClickActionBarNavigation(e:MouseEvent):void { NativeApplication.nativeApplication.exit(); 
}

ActionBar actualmente es una propiedad heredada de Window (pero estará en WindowManager) y de ahí podemos acceder a los botones navigation y action; crearles una nueva instancia (mi principal queja de esto es rehacerlas, cuando deberian estar constantes a mi gusto, aunque eliminarlas entre ventanas ahorra memoria, creo que es algo incomodo rehacerlas) y agregarles un listener y su método como por ejemplo el CLICK para hacer EXIT con el método nativo de AIR. Pueden probarlo y de hecho el exit funcionará. Para probarlo bien en Android y iOS pueden revisar el post anterior y comprobar que todo funcione bien. Conclusión Dentro de un Window, pueden meter LO QUE SEA que ustedes ya hayan hecho en actionscript con anterioridad, esa era mi meta, simplificar la forma de hacer aplicaciones y devolverle el poder al programador sin obstáculos de componentes pesados y poder hacer lo que sabemos hacer, que es crear nuestra propia interfaz dentro de la aplicación. Hay muchas cosas más por ver; hay un par de componentes que no he detallado aquí, pero que son fáciles de usar y pueden ver el código, que son Button, Text e InteractiveList, aunque el último necesita una explicación propia, pero eso será para otro artículo. Si quieren ver una aplicación completamente terminada en BlueMarble pueden ver Webcams Costa Rica la cual originalmente fue desarrollada en Flex con un peso de 6MB ahora con BlueMarble tiene un peso de 712KB.


Dentro del proyecto en Github pueden encontrar el proyecto terminado: BlueMarbleDemo1


Espero que esto sea de utilidad para quien aún no se haya animado a crear una aplicación y subirla al Play Store, y que empiecen a convertir esas ideas en algo real. Saludos y espero sus comentarios y dudas.   

martes, mayo 29, 2012

Desarrollando Apps para iOS y Android con FlashDevelop

Como desarrolladores tenemos una responsabilidad para aprender herramientas que muchas veces no pensamos usar, ya que los requerimientos así lo piden. Al menos en Costa Rica existe un tabú con respecto al uso de herramientas relacionadas con Flash, debido al mal rendimiento en memoria del plugin en los browsers; pero las empresas grandes que trabajan con clientes en el extranjero no piensan igual y ahí tienen una ventaja. La mejor forma de perderle el miedo y dejar de criticar una herramienta es empezar a usarla, y hoy voy a hacer una introducción a un grupo de herramientas, que no solamente expandirán sus habilidades como programador, si no que les permitirá desarrollar aplicaciones en iOS y Android. No voy a enseñarles a programar, espero que quien vea esto ya tenga sus años montado en la carrera o trabajando, pero creo que es claro que hay cosas sobre la sintaxis de AS3 en que necesitarán ayuda, e intentaré aclararlas durante el camino, y obviamente también en los comentarios. Nota: Como requerimientos mínimos vamos a usar un computador con Windows; generalmente los desarrolladores no podemos escapar de esta plataforma para desarrollar (.Net es buen ejemplo) y en este caso no podremos evitarlo, ya que Flash Develop está desarrollado en .NET; y un dispositivo Android con version 2.2 (FroYo) o superior(con capacidad gráfica 3D) y/o dispotivo iOS en su versión 5 como recomendación. Siempre he tenido un gusto primordial por el uso de herramientas gratuitas, y esta no es la excepción; usaremos Flash Develop  que pueden descargar directamente de este link, pero si ya ha pasado mucho tiempo de este post revisen la página principal, ya que se está actualizando constantemente. Otra parte gratis que usaremos es Flex SDK, que para quienes no lo conocen permite crear aplicaciones con componentes al mejor estilo de VB .NET, que para mi gusto resultan muy pesadas, pero lo importante es que tiene un compilador de SWF. Flex SDK viene junto con la instalación de Flash Develop, así que tienen que marcar el check que aparece en la instalación para permitir la descarga que toma un tiempo; junto con el Flex SDK, se descarga AIR SDK, que es lo que nos permitirá crear la aplicación Android o iOS, empaquetando en SWF junto con assets en un .apk o .ipa dependiendo del sistema y nuestras necesidades. Aparte de esto necesitamos el Android SDK, que si ya han estado experimentado desarrollo con Android en Java y otras herramientas seguro ya tendrán instalado. Una vez instalado FlashDevelop, lo ejecutamos y procedemos a abrir un nuevo proyecto (Project/New Project) y seleccionamos AIR Mobile AS3 App

Como pueden ver hay una amplia capacidad de FlashDevelop para crear aplicaciones, incluso legacy como as2, y para los interesados está HaXe, que con un mismo lenguaje compila para diferentes tipos, como C++ y AS3. Si ponen atención podrán ver que existe un tipo de proyecto llamado NME, que aunque uds no lo crean, permite compilar en muchas más plataformas que AIR; si tienen curiosidad, pueden investigarlo enhttp://www.haxenme.org/


Una vez creado el proyecto, deberán revisar obligatoriamente los siguientes archivos dependiendo de la plataforma que vayan a desarrollar: AIR_Android_readme.txt y AIR_iOS_readme.txt con instrucciones para configurar y ejecutar una serie de .bat que viene listos para ejecutar los comandos de compilación por nostros. Muy importante en Android y iOS, para poder compilar necesitamos un archivo .cert o de certificado, para eso nos dirigimos al archivo /bat/CreateCertificate.bat; si no quieren complicarse mucho la vida sobre qué hace, simplemente lo ejecutan (doble click sobre el .bat o en el navegador de archivos de FlashDevelop, click derecho al archivo, se despliega el menú contextual > Execute) y este les generará ese certificado en el directorio /cert dentro del proyecto. La consola nos previene de compilar hasta pasado un minuto de la ejecución del .bat; si mal no recuerdo, el compilar durante ese periodo da un error, pero no es nada grave. El archivo SetupSDK.bat debe ser editado para que los paths de los SDKs correspondan a los que ya tenemos en el sistema, si ud ya instaló Flex y no quiso utilizar el que viene junto con FlashDevelop (aunque lo recomiendo) podrá editar estas rutas default

:: Path to Flex SDK
set FLEX_SDK=C:\Program Files (x86)\FlashDevelop\Tools\flexsdk 

:: Path to Android SDK
set ANDROID_SDK=C:\Program Files (x86)\FlashDevelop\Tools\android 



En cualquier momento que intente compilar el proyecto, si le sale algún error, la consola le advertirá de las posibles faltas de configuración que no haya realizado. La explicación está bien detallada en los readme TXT de cada plataforma. Antes de compilar para ver si todo funciona, si está en Android deberá instalar el AIR Runtime para Android, que interpreta el APK creado en AIR; para esto ejecutamos el bat/InstallAirRuntime.bat mientras tenemos conectado nuestro dispositivo Android; en iOS el AIR va empacado junto con el IPA, por lo que no necesita de una preinstalación; también puede descargar el AIR Runtime en Play de Google. En los settings de las aplicaciones también existe la opción de compilar el APK junto con el AIR Runtime, pero la desventaja es que la aplicación pesará demasiado, hablamos de 8Megas por APK si decide compilarlo de esa manera, pero se estaría brincando que el usuario al descargar la aplicación se le incluya un cuadro de dialogo indicándole que debe descargar el AIR del Market; esta decisión debe tomarse desde el punto de vista de mercadeo, ya que es posible que un usuario no instale su app si no tiene AIR. Actualmente no poseo datos sobre el porcentaje de usuarios que tienen instalado AIR. Para iOS necesitará un archivo de extensión .mobileprovision, este es necesario para poder publicar en el AppStore de Apple; pero gracias a los magos de la internet, poseo uno para pruebas, y también para instalar en dispositivos Jailbreak, si desea publicarlo legalmente el archivo no le va a servir, necesita tener su licencia de desarrollador en Apple y generar sus propios .cert y .mobileprovision mobileprovision para iOS En los settings de iOS en los bat de FlashDevelop (bat/SetupApplication.bat) encontrará donde colocar el path al .mobileprovision y también al .cert, que puede ser exactamente el mismo que está usando con Android.




El codigo del .bat debe ser de la siguiente manera para iOS. “fd” fue creada automáticamente al usar CreateCertificate.bat, esta clave es recomendable cambiarla al momento de ser distribuida.

:: iOS packaging 
set IOS_DIST_CERT_FILE=cert\ProyectoAIRiOSANDROID.p12
set IOS_DEV_CERT_FILE=cert\ProyectoAIRiOSANDROID.p12
set IOS_DEV_CERT_PASS=fd
set IOS_PROVISION=cert\mobileprovision.mobileprovision
set IOS_ICONS=icons/ios 




Básicamente eso es todo lo que se necesita, puede presionar F8, Control-Enter, o el boton de compilar, justo debajo de Syntax en el menú; y para probar que todo está bien, puede poner algo de texto en src/Main.as; despues de // entry point digite lo siguiente

var text:TextField = new TextField();
text.text = "HelloWorld";
text.x = (stage.stageWidth - text.textWidth) / 2;
text.y = (stage.stageHeight - text.textHeight) / 2;
addChild(text); 
  


 Esto colocará una caja de texto en el DisplayList de Flash con la frase “Hello World” centrada en pantalla.




Tome en cuenta que al compilar, este se ejecutará en una ventana aparte, pero si quiere probarlo en su dispositivo, conectelo, y cambie en Run.bat el target

::target
::goto desktop
goto android-debug
::goto android-test
::goto ios-debug
::goto ios-test
  


 Retira los :: de  ’goto android-debug’ y se los pone frente a ‘goto desktop’ y ya puede probarlo en el dispositivo; le saldrá una ventanita pidiendole la IP de su máquina para hacer debug (a lo que me referiré en otro post), se la pone o le da cancelar, y podrá ver su primera aplicación en Android. El resultado de su labor se encontrará en el directorio /dist; encontratá sus APK e IPA bien identificados con el  nombre del proyecto, y también con el tipo de compilación que hizo (TEST o DEBUG) Incluyo a continuación un zip con el proyecto recién descrito completamente armado, así prácticamente solo tiene que instalar Android SDK y FlashDevelop y abrir el archivo del proyecto para visualizarlo. Dentro incluyo el IPA y APK; para instalar el APK sin hacer deploy desde el proyecto, tienen que activar en los settings de Android > Aplicaciones > Fuentes Desconocidas, para poder subirlo al dispositivo de forma manual, darle click e instalarlo. Para iOS no olviden que necesitan o tenerlo jailbreak para las pruebas, o tener su cuenta de desarrollador otorgada por Apple. Proyecto_AIR_iOS_ANDROID
¿Qué ventajas tengo de trabajar con AIR?
  • Para los que hemos trabajado con Flash y as3, sabemos la ventaja de un diseño hecho en Illustrator e importarlo directamente a Flash IDE; si su aplicación es sencilla y requiere verse bien, podrá usar vectores, pero a costa de sobrecargar la memoria.
  • Si ya sabe as3, no tiene que profundizar Java ni Obj-C, lo que le permite distribuir en 2 plataformas casi que inmediatamente; aunque siempre es recomendable conocer la arquitectura original con que se trabaja; por ejemplo, actualmente se desarrollan extensiones específicamente para cada plataforma, aprovechando sus características particulares, estas extensiones se desarrollan de forma nativa y se exportan a as3, lo que permite hacer un puente entre el APK y Android, o el IPA y iOS y por ejemplo enviar mensajes a la bandeja de Notificaciones, mostrar una alerta, tener un icono en el taskbar (Android) obtener información de la red, vibrar (iOS). Pueden ver una lista detallada de estas Extensiones Nativasaquí.
  • La mejor ventaja de todas es que puede crear una aplicación en una semana, no es broma, como experiencia personal, las 2 aplicaciones que tengo en el Market de Android, desde su inicio hasta fin de desarrollo para subirse finalmente a la tienda, fue una semana. Me llevó más tiempo ya que no conocía (y aún no conozco muy bien) los componentes de Flex, así que hice lo mejor que pude con lo que aprendí buscando por internet. Creo que con Flex se puede desarrollar muy rápido, pero se debe considerar el coste del peso; aunque siempre he preferido trabajar con raw code as3, que de paso hace más liviana la aplicación.
  • Hay frameworks especializadas para juegos, como Flixl, y el nuevo Starling que el mismo Adobe sacó, utilizando una nueva capacidad de Flash, que es la aceleración por hardware (Stage3D) que da un incremento INCREIBLE en la velocidad de las aplicaciones, incluso cuando se agregan cientos de sprites como por ejemplo para un juego.
  • El set de Gestures que trae Air for Android es muy sencillo de usar, se asigna un listener y puede escuchar el parámetro en la función llamada para obtener cambios de X y Y, presión, dimensión, etc.
¿Cuáles son las desventajas de trabajar con AIR?
  • El principal problema como antes mencioné, es la forma de empaquetarlo, el archivo puede pesar poco sin incluir el AIR Runtime incorporado, pero si lo incluimos tendremos mínimo 8Megas de peso.
  • El manejo de memoria puede llegar a ser un problema, esto referente a as3 en general,  si usted no está acostumbrado a programar con objetos pequeños, dígase Array e Int, puede olvidar liberar la memoria al crear sus propias Classes y el Garbage Collector nunca podrá eliminar su objeto. Específicamente hay que tener un control sobre las referencias de las instancias, y los listeners que se han puesto, ya que una vez que se dejan de usar, hay que eliminar estas; el Garbage Collector de la máquina virtual de Flash funciona un poco diferente a otros sistemas, este depende del DisplayList (cada que hacemos un addChild agregamos algo al DisplayList) y la única forma de que el GC pueda borrar la instancia es cortar todos los hilos que hacen referencia a ella.
  • Si usa los componentes de Flex su aplicación pesará y pesará más; actualmente Adobe trabaja en mejorar estos componentes, pero en estos momentos no son muy rentables para mobile si está cuidando el peso de su aplicación.
  • La falta de comunicación directa con el sistema operativo, que es “solucionado” en parte con las Extensiones Nativas.
  • En iOS no se puede cargar un SWF externo con código para usarlo luego, ya que el compilado de iOS se vuelve incompatible con un swf plano, y no puede leerlo. Puede cargar swfs con animaciones únicamente.

 Una mirada hacia atrás Apuesto que muchos en este punto están pensando “¿Para qué desarrollamos en iOS con Flash, si Apple no permite esto?”. Bueno, resulta que hay un poco de confusión con respecto al tema; actualmente Apple sí permite subir aplicaciones compiladas con Flash al AppStore, pero la gente no sabe que fue lo que pasó. En 2010 si no me equivoco, Adobe anunció que se podían compilar swfs a iPhone, y que de hecho ya tenían varias aplicaciones subidas; esto enfureció a Apple que de un tiempo para acá son enemigos por conveniencia (cosas fuera de este post) y prohibió de forma generalizada usar transcompiladores para generar aplicaciones para iOS, esto afectó no solo a Adobe, si no a grupos muy honestos como Appcelerator Titanium, se alzaron ciertas protestas y comentarios sobre Competencia Desleal por parte de Apple, lo que llevó a finales del 2010, casi terminando el año, y evitar estar en el ojo del gobierno, revocar esta restricción, noticia que pasó casi desapercibida, excepto para los desarrolladores más fanáticos (yo incluido), supongo que fue por ser la época navideña, y nadie estaba poniendo atención. Desde entonces Adobe retomó el desarrollo del transcompilador. Más o menos así es la historia, si hay algún detalle fuera o sobrante, me disculparán. Espero que esta introducción sea de utilidad para quienes tengan curiosidad en desarrollar aplicaciones con actionscript, luego mostraré más cosas, como manejo de memoria, y hasta crear sus propios componentes para evitar el uso de Flex y bajar el peso de su aplicación y hasta mostrar de mis propios experimentos. Saludos y espero sus comentarios.

Este artículo fue publicado originalmente en losdevs.com