• Escuchar entrevista (rtve.es)
• Visitar la web del programa de la UNED “Apps, web y marketing”

Primero veremos cómo personalizar objetos de Titanium para posteriormente crear múltiples instancias del mismo. Crearemos nuestro propio módulo commonJS que devuelve un TableViewRow ya personalizado con los datos de cada fila.

En segundo lugar, veremos cómo llamar a un servicio web remoto, cuya respuesta es asíncrona (esto es, no ocurre en el orden normal del hilo de ejecución, si no cuando llega la respuesta del servidor). Para gestionar esta respuesta asíncrona haremos uso de las funciones callback y haré una breve discusión sobre cuándo usar funciones callback y cuando usar eventos a nivel de aplicación, por si a Miguel Ángel no le quedó del todo claro.

Si no has seguido los anteriores posts, te recomiendo echar un vistazo al blog con la introducción de JavaScript y commonJS para Titanium.

Como siempre, empezamos con app.js y los módulos de la aplicación declarados en ModulePaths.js. La discusión de estos ficheros es la misma que hice en esta entrada, así que no la repito.

App.js

gist id=3554525 file=app.js]

ModulePaths.js

gist id=3554525 file=ModulePaths.js]

Styles.js

gist id=3554525 file=Styles.js]

AppWindow.js

Esta es la ventana que se crea desde app.js, simplemente añade la tabla de fotos a la ventana y la devuelve para que app.js cree una instancia y la abra.

gist id=3554525 file=AppWindow.js]

PhotosTableView.js

Este módulo devuelve un tableView de Titanium, que llama a Feed.getData (que veremos a continuación) y  le pasa como argumento callbackTableView, que es el nombre de una función definida previamente. Feed se conecta con los servicios de Flickr y recibe un listado de fotografías. Si la información que devuelve Feed.getData fuera local (de un fichero o una base de datos), podríamos hacer algo como tableview.data = Feed.getData() (suponiendo que la info viniera ya formateada). Pero como Feed va a conectar con un servidor remoto y no sabemos cuándo va a responder, lo que hacemos es pasarle como argumento la función que queremos que ejecute cuando ya tenga la respuesta del servidor.

De momento, basta saber que cuando Feed.getData termine de hacer lo que tenga que hacer, llamará a callbackTableView

gist id=3554525 file=PhotosTableView.js]

Cuando Feed tiene respuesta del servidor, llama a callbackTableView y le pasa como argumento dicha respuesta. Dentro de callbackTableView, si la respuesta es válida, se crean las instancias de PhotoRow, que son cada una de las filas de la tabla. Finalmente se añaden a la tabla.

Después de la función de callback, digo a la tabla que escuche los eventos click que pueda recibir y, si la fila es válida, creará una instancia de PhotoViewer para visualizar la foto en grande. Siempre es mejor añadir el eventListener al tableView y no a las tableViewRow, es más eficiente gestionar un sólo eventListener (uno por la tabla) que decenas o cientos de eventListeners (tantos como filas tenga la tabla). Por tanto, evita la tentación de usar eventListeners a nivel de fila.

e.row es el objeto fila que ha sido clickado y Titanium se encarga de devolvérnoslo siempre que se hace click en la tabla. e.row.data es una propiedad creada por nosotros mismos en el módulo PhotoRow. Lo que hago es crear esta propiedad con toda la información del elemento devuelta por el servidor para poderla recuperar más adelante (en el siguiente apartado se termina de entender esto).

PhotosTableViewRow.js

Es cada una de las filas de la tabla. Este componente se va a reutilizar varias veces (al contrario que el resto, que sólo se usan una vez en la aplicación). Para hacerlo reutilizable, el componente recibe como argumento el item con la información que tiene que rellenar (en nuestro ejemplo, título y una foto) y usamos esta información para completar la creación de los componentes que forman la fila. En la fila 9, creo una propiedad data en el TableViewRow que me permitirá recuperar toda la información del elemento más tarde. Este es el mismo “data” que recupero en el eventListener de la tabla.

gist id=3554525 file=PhotosTableViewRow.js]

PhotoViewer.js

Este fichero no tiene mucha complejidad. Se tiene en cuenta si la plataforma es iOS o Android, para colocar o no un botón de cerrar (android no lo necesita, ya que dispones de el botón “volver”).

Para facilitar la escritura, en el fichero estilos he creado una propiedad iOS que será true si el dispositivo es iPhone o iPad, así resulta más fácil de escribir (y de leer), tan simple como ver el valor de $$.iOS.

Otro punto interesante, podemos agregar nuestros propios métodos a objetos Titanium. A win le añado el método showImage, que es una función que abrirá la ventana en forma modal. (Ojo! No es la mejor manera de hacer esto, pero para el ejemplo queda bien y es suficiente). Así, podemos extender el funcionamiento nativo de los componentes Titanium agregando métodos y propiedades.

Importante saber que cuando añadamos métodos a objetos Titanium estos no deben nunca empezar con get o set. Es una limitación de la plataforma, fallará en silencio y podemos tirarnos un buen raton sin saber qué pasa o porqué no funciona.

gist id=3554525 file=PhotoViewer.js]

flickrFeed.js

Vistos todos los ficheros relativos a la interfaz de usuario, pasamos a ver cómo se gestiona la conexión con el servidor.

El cliente http establece una conexión con un puerto web y hace una petición GET o POST a la url que le indiquemos. HTTPclient permite definir varias funciones callback para gestionar la respuesta del servidor. En este ejemplo uso onload y onerror, pero tambien podemos capturar ondatastream y onsendstream para saber la cantidad de información enviada y recibida.

gist id=3554525 file=flickrFeed.js]

He definido la función exports.getData para que reciba un argumento llamado callback. Titanium llamará la función definida en onload cuando tenga respuesta del servidor. Tras procesar la respuesta, se ejecuta callback, pasándole como argumento la respuesta – ya procesada – del servidor. getData no necesita saber qué es o a quién pertenece callback, simplemente la intentará ejecutar suponiendo que se trata de una función y que sabrá como ejecutarse. En el ejemplo, lo que ocurrirá es que se llamará a callbackTableview, que es la función que pasamos como argumento a Feed.getData y si todo va bien, rellenará la tabla con las fotos.

He observardo que algunas tags en flickr generan una respuesta json que titanium no puede procesar, si haces pruebas cambiando las palabras en la URL, puede que falle por esto.

Eventos vs. callbacks

Espero dedicar en algún momento una entrada sólo a la creación y gestión de eventos, pero quiero hacer una pequeña aclaración de porqué es preferible usar callbacks a eventos a nivel de app. Primero, hay que diferenciar entre lo que son eventos de componentes gráficos (como click, load, etc.) y eventos de aplicación. Los eventos de aplicación son los que se gestionan desde Ti.App.addEventListener() y Ti.App.fireEvent(). Lo que explico a continuación afecta a ambos, pero especialmente a los segundos.

Por explicarlo de forma gráfica, una función callback es una conexión directa entre dos objetos. Un objeto llama a un método de otro objeto. No hay intermediarios. Fin de la historia.

Un evento de aplicación es más complejo. Se dispara un evento desde un punto de la aplicación, la aplicación recoge el evento y lo “reparte” entre los otros módulos que previamente estarán escuchando. El simple hecho de estar escuchando eventos ya tiene un coste. Como además, el evento es a nivel de app, salta de un módulo al objeto Ti.App y de éste a los que estén escuchando.

En casos en los que sólo queremos comunicar dos objetos es preferible usar callbacks.

Si estamos creando componentes reutilizables, normalmente componentes UI, podemos disparar nuestros propios eventos de componentes (por ejemplo, si nos inventamos un botón que implementa un evento tripleclick)

Y sólo en los casos en que necesitemos llamar la atención de varios objetos no conectados entre sí desde un único punto de la aplicación nos plantearemos usar eventos de aplicación.

Tienes los ficheros de este proyecto disponibles para descargar aquí.

La aplicación por defecto de Titanium Studio crea un tabGroup con dos ventanas. Yo voy a crear la misma aplicación, pero usando módulos commonJS. Además, ya dejamos preparada la estructura de directorios para que nuestra app pueda crecer correctamente desde un principio.

Antes de continuar, puede que te interesen estos artículos si no los has leído aún.JavaScript para Titanium (I), JavaScript para Titanium (II), CommonJS para Titanium

Resumen

Crearemos una app con un TabGroup con 3 tabs (secciones). Cada tab abre una ventana diferente. El mismo código nos permitirá distribuir una aplicación nativa android, iPhone y mobile web.

app.js

Empezamos por el punto de arranque de la app. Recuerda que todas las apps titanium arrancan desde app.js.

Hay varias cosas que comentar. Primero, habrás observado que todo el fichero está envuelto en una función anónima que se autoejecuta (el hecho de que la función esté envuelta en unos paréntesis con otros paréntesis a continuación hace que la función se ejecute tras ser declarada). Como recordarás de la introducción a JavaScript, las funciones limitan el ámbito de las variables. Con esta función anónima, lo que hacemos es evitar que las variables Mods, TabGroup y tabGroup salten al ámbito global y por tanto puedan ser accesibles desde otras partes de la aplicación. Esta técnica sólo es necesaria (en principio) en el fichero app.js, ya que el resto de nuestros ficheros van a ser todos módulos commonJS, que  limitan de por sí el ámbito de sus variables.

Lo primero que hace app.js es cargar un módulo llamado ModulePaths. Aunque esto no es obligatorio y no lo verás en todas las apps, es una costumbre que he puesto en práctica y que me ha demostrado tener varias ventajas. De momento, basta saber que ModulePaths contiene todas las sendas y nombres de ficheros del proyecto para no tener que recordarlos.

A continuación, cargo el módulo TabGroup (explicado más adelante). La línea 9 crea una instancia del módulo y finalmente se da la orden de abrir el tabGroup. Mucho ojo a las mayúsculas y minúsculas. Es una buena costumbre cargar los módulos en variables con mayúsculas (TabGroup) y las instancias de módulos con minúsculas (tabGroup).

app/ui/TabGroup.js

Este módulo devuelve una instancia de Titanium.UI.TabGroup, ya adaptada a nuestras necesidades. El hecho de poder cargar un componente de Titanium, modificarlo y ampliarlo a nuestro gusto y devolverlo como un componente nuevo, es tremendamente útil y lo desarrollaré a fondo en próximas entregas.

En todos mis módulos siempre lo primero que hago es cargar ModulePaths, a continuación defino los módulos que voy a usar en este módulo y finalmente se implementa el módulo desde module.exports.

En este caso, declaro las tres ventanas que voy a necesitar en el proyecto (líneas 3-5) y defino el módulo en sí mismo con module.exports. Cada ventana Window1, Window2 y Window3 tiene un fichero .js donde se implementa su código. Más abajo muestro su contenido.

Línea 10, creo el tabGroup de titanium. Líneas 12-16 creo una instancia de cada una de las ventanas, líneas 19-40, creo los tabs del tabGroup, asigno las ventanas, títulos e iconos y finalmente devuelvo el tabGroup con todo listo para ser abierto.

app/ui/Window1.js

Las tres ventanas son prácticamente iguales, así que sólo explico la primera.

Es una ventana muy sencilla con una etiqueta. Como este módulo no tiene dependencias externas, no necesito llamar a ModulePaths ni ningún otro módulo. Simplemente crea una ventana de Titanium, le añade una etiqueta y devuelve la ventana.

Una de las ventajas de programar de esta manera, es que este módulo no se preocupa de cómo va a ser usado o por quién. En este caso, Window1 es instanciado por TabGroup en su línea 12, pero perfectamente nos la podríamos llevar a otro proyecto y reutilizarla sin a penas cambios.

ModulePaths.js

Como decía antes, el uso de un fichero índice de todos los ficheros del proyecto no es obligatorio. Perfectamente podríamos haber llamado cada ventana por su senda en TabGroup de este modo

Sin embargo el uso de ModulePaths tiene varias ventajas.

Primero, que a medida que nuestro proyecto crezca, no necesitaremos recordar todas las sendas y nombres de archivo, sólo un identificador que asignaremos a cada módulo.

Segundo, que en proyectos complejos, podremos cambiar una versión de un fichero por otra, simplemente cambiando el nombre en ModulePaths. Por ejemplo, si tenemos un componente llamado VideoPlayer y queremos hacer pruebas con un fichero distinto sin modificar todo el proyecto, cambiaremos la senda en ModulePaths a un fichero nuevo (por ejemplo, VideoPlayerTest.js) y todo el proyecto cogerá esta referencia.

Tercero, más de una vez ocurre que hay que cambiar la estructura de carpetas de un proyecto. Si esto ocurriera, podemos mover los ficheros tranquilamente y después tan sólo tenemos que actualizar este fichero, y no cada módulo del proyecto.

Una última ventaja, si piensas desarrollar para mobile web, es que las sendas en esta plataforma no pueden empezar con la barra /, cosa que sí ocurre en el resto de plataformas. Trabajando con ModulePaths, podemos gestionar fácilmente estas diferencias.

Como ves, el fichero únicamente asigna una senda a una clave que después es la que llamamos desde los módulos (por ejemplo Mods.WINDOW1 o Mods.TABGROUP).

Y para terminar…

Te recomiendo que vuelvas al código de app.js y vuelvas a leerlo desde el principio, ahora que ya sabes lo que contiene cada módulo te resultará más fácil entenderlo. El objetivo es dividir el código en partes funcionales lo más pequeñas posibles, lo que te permitirá crear código que reutilizarás con más facilidad en tus proyectos y mejorarán cuanto más los uses.

Y esto es todo! Puedes descargar el proyecto completo desde mi github en https://github.com/jaraen/TabGroupTemplate

App funcionando en el simulador de android

App funcionando en el simulador de iPhone

App funcionando en el navegador

Con encapsular me refiero a la habilidad de crear una “burbuja” con código que tiene su propio ámbito de variables, de manera que ninguna de las que definamos en su interior contamina el ámbito global. En otro artículo hago una breve explicación de porqué es malo contaminar el ámbito global y como evitarlo. commonJS supone un nivel más de control sobre el ámbito de las variables.

El programador define el interfaz del módulo (las funciones y variables “públicas” a las que se podrá acceder desde fuera), de modo que para usarlo sólo tendremos que preocuparnos por conocer este interfaz y no lo que ocurre en su interior.

El buen uso de los módulos CommonJS facilita la reutilización de componentes entre proyectos, hace la trazabilidad más sencilla y obliga a estudiar mejor la interdependencia entre partes del proyecto.

Antes de continuar, si no sabes cómo se crean los objetos en JavaScript o quieres dar un repaso a las principales peculiaridades del lenguaje, echa un vistazo a los dos tutoriales de introducción a JavaScript para Titanium. Están aquí: 1 y 2

¿Que pinta tiene un modulo commonJS?

Se trata de un fichero JavaScript (.js) en el que encontraremos una serie de funciones y variables y un objeto especial llamado  exports (no hay que definirlo, ya existe per sé).

Dentro del módulo pondremos todo nuestro código, pero sólo el que sea añadido a exports será accesible desde fuera.

TestModule.js:

Ciclo de ejecución

Un aspecto importante a tener en cuenta es que un módulo commonJS sólo se interpreta la primera vez que es invocado. Esto implica varias cosas:

- Primero, que la carga de los distintos módulos se retrasa hasta que son necesarios, lo que hace que el arranque inicial suela ser más rápido

- Segundo y más importante: las variables que se declaren fuera de cualquier función del módulo tendrán un comportamiento estático (en el ejemplo, anterior, las declaradas en la línea 2). Solo se inicializan la primera vez y el resto de veces que invocamos al módulo no se inicializan de nuevo, conservando su último valor asignado. Aunque esto puede ser confuso al principio, es tremendamente útil a la hora de compartir información entre distintas partes del proyecto sin necesidad de usar variables globales.

Llamada desde Titanium

Para cargar un módulo commonJS desde Titanium utilizamos la orden require()

Dado un fichero  TestModule.js que se encuentre en el raíz de nuestro proyecto (en la carpeta resources), lo cargaremos así (ojo, al hacer require no se pone la extensión del fichero)

Esta orden carga el módulo en una variable cuyo nombre, en este caso ‘myTestModule’, lo asignamos a nuestra conveniencia. Una vez cargado, myTestModule contiene el objeto exports que hemos ido implementando en la definición del módulo.

Patrones de uso

Existen varios patrones de uso de los módulos commonJS que se repiten confrecuencia en Titanium y conviene conocer desde un principio. Comentaré dos de ellos que usaré a menudo en próximos artículos.

Un Componente instanciable (o sea, reusable)

Una instancia es una copia de un objeto que tiene su propio ciclo de vida. Esto permite que varias instancias puedan sobrevivir simultáneamente con ciclos de vida diferentes e incluso con comportamientos diferentes sin depender necesariamente una de otra. Ejemplos de instancias son la mayoría de componentes UI de Titanium: un botón, un label, una ventana… En este caso, querremos que cada instancia del objeto no colisiones con el resto.

Supongamos que queremos crear un componente propio que extienda de uno existente. Lo “envolveremos” en un módulo commonJS, añadiéndole las nuevas funcionalidades. Como ejemplo, vamos a crear un botón especial con dos estados, de manera que su color cambie cada vez que se pulsa el botón:

SwitchButton.js:

Para utilizar nuestro componente en Titanium, deberemos crearlo con el operador new

app.js:

Con esta técnica, podríamos añadir tantos botones como fueran necesarios, cada uno con sus características de tamaño y color y cada uno con sus propios addEventListeners.

Tienes un ejemplo más avanzado de SwitchButton usando imágenes de fondo y disparando un evento propio en mi proyecto TitanTricks

Patrón de configuración

A menudo ocurre que distintas partes de la aplicación deben compartir una serie de datos “estáticos” sobre la aplicación. Cosas como el nombre de la app, la url de un servicio web al que debe acceder o distintas configuraciones de estilo.

Config.js

Como puedes ver, en vez de extender exports con una propiedad config, en este caso directamente asignamos config al módulo. Esta técnica es igual de válida que la de extender exports. Lo único que no debes hacer nunca dentro de un mismo módulo es mezclar ambas técnicas: o extiendes exports o igualas module.exports a un objeto tuyo. La experiencia te dirá cuando usar una u otra, te he mostrado un ejemplo de cada caso para que te suene a la hora de diseñar tu propio módulo.

Ahora, en nuestra aplicación, podremos invocar al módulo Config sin necesidad de instanciarlo:

App.js

Este tipo de patrón también es muy útil para separar los estilos de la programación pura. Podemos tener un fichero de estilos fácilmente reutilizables y modificables al que invocar desde cualquiera de nuestros módulos. Podríamos, por ejemplo, cambiar los colores de todas las ventanas sólo con cambiar el color en este fichero.

Styles.js

Y ahora en App.js…

Me gusta usar $$ siempre como nombre del módulo de estilos. Es fácil de recordar, rápido de escribir y recordar (manía que adquirí del estilo de programación de tweetanium, una app que hizo escuela en los principios de Titanium). El hecho de que sean dos símbolos $$ no tiene ninguna otra implicación como nombre de variable.

Esto es to, esto es todo amigos

Estos dos patrones  son suficientes para empezar a montar la arquitectura de la aplicación.  Por supuesto que hay más e intentaré mostrarlos en sucesivos tutoriales.

Mi objetivo, una vez superados los conceptos básicos de JavaScript y sabiendo qué son y cómo funcionan los módulos commonJS, es mostraros como crear una arquitectura sólida, escalable y segura para una aplicación móvil con Titanium. En la próxima entrega crearemos una plantilla para comenzar todas nuestras aplicaciones desde una base e iremos viendo como superar los distintos obstáculos que nos encontraremos en la comunicación entre componentes. Siempre, por supuesto, intentando seguir el manual de buenas prácticas.

En entregas posteriores, desarrollaré algunos problemas típicos de programación, como la llamada a métodos asíncronos, componentes UI avanzados, optimización de código y lo que se me vaya ocurriendo (se aceptan retos, ruegos y sugerencias).

Hasta entonces, os recomiendo probar y desmenuzar la app TitanTricks, un proyecto iOS+Android de demostración/experimentación con Titanium. También existe TitanTricksMobileWeb, para su versión web.

¿Te interesa Titanium y JavaScript? Sígueme en @jrayon

Lo mejor y lo peor de JavaScript es que lo aguanta todo. Puedes olvidarte de declarar las variables, no usar punto y coma al final de línea y ser un desastre organizando el código. Es posible que, incluso así, el código funcione. Pero pobre del que tenga que revisar tu código, incluso si eres tú mismo, cuando algo deje de funcionar.

No me gusta convencer a la gente de que haga cosas sólo por miedo a que algo terrible ocurra (en este caso, el miedo a que algún día nuestro código sea un desastre). Y, aunque es un argumento de peso, JavaScript tiene bastantes alicientes como para motivar su aprendizaje a fondo sin otro objetivo que crear grandes aplicaciones y aprovechar al 100% las características del lenguaje.

JavaScript es un gran lenguaje de programación, a menudo incomprendido, porque ha sido el lenguaje que a movido la web durante años con tantos sabores como navegadores en el mercado. Quizá por eso mi primer consejo al empezar con Titanium es olvidarse del DOM, de JQuery y cualquier otro framework y forma de programar orientada a la web. Titanium no se ejecuta en una ventana de navegador, por tanto estamos hablando de JavaScript “puro”, ampliado y mejorado con la API de titanium, desarrollada en el código nativo de cada plataforma. Por eso Titanium es único, porque realmente ejecuta código nativo, que es llamado desde el intérprete JavaScript.

Este artículo pretende mostrar las “mínimas” cosas que uno debe saber de JavaScript, especialmente cuando viene de trabajar con otros lenguajes.

Lo mas basico

Tipos

Las variables no se declaran con un tipo específico y pueden cambiar de tipo durante su vida (pueden crearse siendo string y luego asignar un valor numérico sin hacer ningún tipo de cast).

Las cadenas se pueden delimitar con comillas simples y dobles indistintamente. Es exactamente lo mismo.

La mayoría de tipos (strings, arrays, objects…) son objetos. Así, al declarar una variable string como  var str = "hola", ya podemos hacer uso de sus métodos y propiedades. Por ejemplo str.length devolverá el valor 4.

Para declarar cualquier tipo de variable (sea array, string o cualquier otro tipo), utilizamos la palabra var. En aplicaciones como las que haremos con Titanium debemos obligarnos a declarar siempre las variables ya que, de no hacerlo, éstas se crean con alcance global (y como ya puedes intuir esto es malo, malo). Que estén en global significa que nunca se liberan de memoria y que pueden llegar a colisionar con otras variables, creando aplicaciones muy difíciles de trazar.

Los números en JavaScript siempre son tratados internamente en coma flotante. Las variables numéricas por defecto están “unboxed” lo que quiere decir que no podemos tratarlas como objetos. Para tratarlas como objeto crearemos con el operador new. Ocurre lo mismo con los booleanos.

Los arrays son muy flexibles, puedes crear arrays mezclando distintos tipos de variables, añadir índices en cualquier posición.

Comparaciones

Lo que en otros lenguajes se compara con == ó != (dos caracteres) en JavaScript se hace con tres (=== y !==). Este es uno de los errores de principiante más comunes al empezar con JavaScript. Así que siempre hay que utilizar el comparador ternario (el de tres caracteres), a menos que sepas lo que estás haciendo. Como ejemplo de los líos en los que nos podemos meter, en JavaScript todas las siguientes sentencias son TRUE (en la mayoría de lenguajes serían FALSE):

Usando la comparación === hubieran dado false como resultado, que es lo que esperaríamos en la mayoría de casos.

Ambito y declaracion de variables

En JavaScript el ámbito de una variable es el de la función en la que es declarada. Si la variable no se declara dentro de una función, entonces se trata de una variable global. Esto puede llegar a ser un serio problema, ya que JavaScript permite usar variables sin declarar, lo que hace que se vayan cargando siempre al ámbito global de ejecución y por tanto nunca se liberen de la memoria. ¿Cómo resolver esto?

(más adelante hablaremos de los objetos en JavaScript)
::

But none of them has given to us and our clients so many benefits as Titanium, from Appcelerator.

And we are so convinced of this, that we have spent the last months working only with Titanium mobile technologies, developing iPhone, iPad and Android projects, training developers, creating open source projects and contributing to the Titanium Community. Just myself have passed the Titanium Certificate App Developer test, which credits me as a professional and expert Titanium developer. And also, I’ve become a proud Appcelerator Titan user, which is a community leader and technology evangelist.

At this time, our commitment with Titanium is complete. We are training two new internal developers on Titanium to increase our development capacity. We are already planning the 2012 year, because we are pretty sure that it will be a great year, plenty of success and great projects that we have already in process. And we have the confidence and satisfaction of our clients, our most valuable treasure, because their success is the only aim we care.

The only constant is change, said Isaac Asimov, and survive in a so changing technological environment is only possible if you choose right your partners. For this reason, and many others, we are very proud to say that We are Titanium Developers.

Javier Rayon,
Consultant and Lead developer at Criteria Studio