ShortCuts Flash Builder 4

Usar un buen IDE siempre es bueno, pero usarlo bien es todavía mejor. La comodidad y la fluidez para trabajar son indispensables para aumentar la productividad y, sobre todo, sentirse menos frustrado haciendo cosas molestas.

Les voy a dejar una serie de shortcuts y tips para FlashBuilder 4, sin duda muy cómodos.

Si sos usuario de MacOs solo reemplazá la tecla Control por Command, como seguro ya sabés.

Asistente (Control + Space): Un viejo conocido de muchos desarrolladores, más si vienen de cualquier Eclipse o derivado. Nos muestra el asistente según donde estemos posicionados y nos da una guía de como seguir (completando variables, métodos, etc).

Comentario en bloque (Control + Shift + C):  Sumamente útil, cuando lo descubrí fui muy feliz. Básicamente comenta (/* */) el sector de código que tengas seleccionado.  Si ya está comentado, lo descomenta.

Organizar Imports(Control + Shift + O): Se encarga de organizar los statement de los import, eliminando los no usados y acomodando por package si hace falta. No es un comando que vivas usando pero es realmente util.

Rapido acceso al Outline (Control + O): Amo este tipo de Shortcuts. Nos permite visualizar y dirigirnos rápidamente las variables y métodos del archivo que tengamos abierto. He visto algunos (incluyendome a mí tiempo atrás), hacés Control + f (find-search) buscando el método o variable en cuestión y navegando entre comments y demás. Este shortcut es indudablemente más práctico y veloz.

Abrir recurso (Control + Shift + R): Como el anterior, un shortcut para amar. Nos permite buscar rápidamente por nombre cualquier clase o recurso de nuestro proyecto. Se puede incluir caracteres ? y * en la búsqueda (la ventanita explica para que sirven). Un tip interesante es que podemos buscar escribiendo solo las mayúsculas. Por ejemplo, si tenemos una clase ResourceLoader, podemos escribir RL y la encontrará.

Encontrar la llave Perdida (Control + Shift + P): Suena a una aventura de Indiana Jones, y, a veces, es medio parecido encontrar donde cierra una llave ({ y }). Con este shortcut se soluciona facilmante 🙂

Encontrar Declaraciones (Control + G): autoexplicativo

Encontrar Referencias (Control + Shift +G):  idem

Ir a la declaración (F3): sumamente práctico. Si tenemos una variable que estamos usando, o un metodo al que estamos incvocando, un objeto creando, etc, con colocarnos encima y tocar f3 accedemos a la declaración del mismo.

Volver a la última posición de edición (Control + Q): A veces nos emocionamos tocando f3 o buscando cosas o abriendo recursos y nos olvidamos dondes estabamos o hay que ir buscando entre archivos cuál era el punto del que partimos. Con este shortcut podemos retroceder en dicha cadena de movimiento y búsqueda.

 

Hay varios shortcuts más, pero estos son los que más uso y realmente agilizan mucho el trabajo. Si me doy cuenta alguno más lo sumo!

 

 

 

Object Pooling

Hace un tiempito estaba haciendo un juego en Flash, en el cual iban apareciendo enemigos cada vez en mayor cantidad y llegaba un momento en que la perdida de rendimiento era muy fuerte.

Una solución (o al menos un enfoque para mejorar la situación) a este tipo de situaciones es lo que se conoce como Object Pooling.

El término pool significa literalmente pileta, pero para conceptos como este, no se me ocurre una traducción correcta, pero basicamente hace referencia a un conjunto de recursos a los que se puede acceder para ser usados en algo (se usa no solo en la informática).

Object Pooling es un Design Pattern en concepto muy simple. Se trata de mantener un pool de objectos constantemente instanciados e ir accediendo a ellos según los necesitemos en vez de ir instanciandolos y disposiandolos de memoria on demand. Cada vez que accedemos a un objeto, sin duda, necesitamos resetearlo, así que que también hay que «limpiar» los objetos una vez liberados.

¿Cuándo usar Object Pooling?

La idea de object pooling es ahorrar memoria y tiempo de cpu en la instanciación y liberación de objetos, además de prevenir memory leaks y la fluctuante situación del garbage collector (supiendo que usemos un lenguaje que lo tenga). Por lo tanto, esta técnica es ideal para cuando instanciamos mucho una clase  y/o el costo de instanciación es muy alto.

Tomemos el ejemplo de un survival mini game. Si, de esos que empiezan a venir chobis y chobis y chobis. Digamos, zombies (todos amamos los zombies). Con el paso del tiempo, la cantidad de zombies es cada vez más grande.

Bien, acá tenemos  un buen caso para usar (casi seguro) Object Pooling.

Vamos a usar ActionScript3 para los ejemplos. Y el objecto  que vamos a poolear es,claramente, un Zombie.

Zombie.as

public class Zombie extends Sprite{
        public static const OUT_SCREEN_X   : Number  = -2000;
        public static const OUT_SCREEN_Y   : Number  = -2000;
        // -- Class Constructor
        public function Zombie(){
        }
        public function reset():void{
             this.x=OUT_SCREEN_X;
             this.y=OUT_SCREEN_Y;
        }
}

Como vemos,es una clase muy básica. Simplemente estamos hablando de herencia de Sprite. Ahora nos ocuparemos del pool:

ZombiePool.as

public class ZombiePool {
        public static const MIN_ZOMBIE_QTY    : int  = 50;
        private m_pool : Vector.<Zombie>;
        public function ZombiePool(){
            m_pool = new Vector.<Zombie>();
            var i:int =MIN_ZOMBIE_QTY   ;
            while (i-->0){
                m_pool.push(new Zombie());
            }
        }
        public function getAZombie():Zombie{
              if(m_pool.length==0)
                   m_pool.push(new Zombie());
              return (m_pool.pop()).reset();
        }
        public function freeZombie(_zombie:Zombie):void{
                m_pool.push(_zombie);
       }
}

Revisemos rapidamente el código. Como podemos ver,  la pool propiamente dicha es un Vector de Zombies. Esta pileta es inicializada con cierta cantidad de zombies definida en la constante MIN_ZOMBIE_QTY. Por supuesto que podria haber sido inicializada por inyección en el constructor o
seteada en algun init del ZombiePool, es indistinto.
Entonces, el uso es sumamente simple. Cuando un cliente (por ejemplo.. una clase Level, o GameManager
o Map,etc) necesite crear un zombie, en lugar del clásico

var zombie:Zombie = new Zombie();

deberá utilizar:

var zombie:Zombie = ZombiePool.getAZombie();

Tras eso, lo inicializa como desee, siempre que el zombie tenga un metodo para inicializar
e inyectar valores o bien estos sean públicos.
De esta manera evitamos crear y eliminar de memoria constantemente (y esto, en un juego como este,
puede ser muy constantemente) Zombies, evitamos el mal uso del garbage collector, memory leaks
y el costo de una instanciación.
En este ejemplo simple usamos un pool incremental, es decir, si la pool se encuentra vacía,
automaticamente crece. Existen otros enfoques (pool limitada, pool que empieza vacía, etc),
pero son básicamente lo mismo.

Cuando no Usarlo , el Anti-Pattern
Aunque no me pasó, existen casos donde aparentemente es copado usar Object Pooling pero,
la realidad, termina siendo muy distinta (lo que se conoce como Anti-Pattern, es decir,
usar un patrón creyendo que es la mejor solución pero que termine teniendo un efecto contraproducente.)
Se trata de casos en los que limpiar el objecto (resetearlo) es más costoso que instanciarlo
o casos donde las referencias al objecto del pool pueden ser conflictivas y al liberarlo
al pool puede generarse problemas con los punteros y demás. Pero no creo que sea para
alarmarse, la mayoría de los mortales no tenemos ese problema.

Así que, a llenarse de zombies!