• Ejemplos,
• Flash en Móviles,
• Interficies,
• Recursos útiles,
• Tablets

por Raúl Jiménez

Desde el primer momento en que salió BlackBerry Playbook y vi su interfaz totalmente desarrollada con Adobe AIR pensé: “ey, esos componentes se ven genial… ¿podré utilizarlos?”. En un par de charlas a las que asistí lo pregunté y nadie supo contestarme con claridad, quizá sea porque no lo probaron o porque no lo sabían, la cuestión es que hace unas semanas lo probé por mi cuenta y he de decir que funcionan de lujo.

Para poder utilizarlos lo único que hemos de hacer es instalar el SDK de Adobe AIR para BlackBerry Playbook y luego en Flash CS5.5 o Flash Builder 4.6 importar el SWC que contiene los componentes. En mi caso los pude encontrar en la siguiente dirección:

C:\Program Files\Research In Motion\blackberry-tablet-sdk-1.1.1\frameworks\libs\qnx-screen\qnx-screen.swc

Luego en Flash simplemente podemos hacer algo como esto:


import qnx.ui.buttons.LabelButton;

var button:LabelButton = new LabelButton();
button.label = "hello!";
button.setSize(120, 50);
addChild(button);


Y podremos ver algo como esto:

Los componentes de QNX están muy bien desarrollados, son ligeros, bonitos, extensibles, skinneables, están especialmente diseñados para pantallas táctiles y se pueden usar en Flash, así que desde mi punto de vista se presentan como la mejor alternativa a los proyectos con Flex Hero. Si queréis probar a hacer vuestros desarrollos os recomiendo que le peguéis un ojo a la excelente documentación que tenéis disponible del framework AIR para BlackBerry Playbook.

Una de las ventajas que veo en desarrollar con este framework es que puedes utilizarlo no solo para los proyectos de Playbook, si no también para iOS y Android. Aquí os dejo algunos de los componentes para que veáis como son y el FLA del ejemplo:

Descargar FLA de ejemplo de componentes de BlackBerry Playbook

Un saludo!

Etiquetas: air sdk, Android, componentes, Interficies, ios, playbook, Recursos útiles, tablets

Sin comentarios

• Android,
• Flex Mobile,
• Iniciativas,
• Interficies,
• iPhone,
• OpenSource,
• Recursos útiles

por Raúl Jiménez

Eskimo es una librería Open Source totalmente gratuita para Flex Hero para poder tener controles nativos para Android e iOS. Detrás de este proyecto está PIA, una consultora de París especializada en experiencia de usuario e innovación.

Hace poco han sacado la versión 1.0 que cuenta con varios componentes personalizados, además del skin nativo de Android y iPhone, podéis descargarlo desde la web de Eskimo o contribuir al código a través de GitHub.

Algunos de los componentes y skins de esta librería son:

• BackButton
• ConfirmButton
• ContextableList
• DeletableList
• ListWheel
• MobileContextMenu
• PageIndicator
• PopOver
• SlideDataGroup
• UniqueChoiceList
• SkinnableAlert
• MultipleChoiceList
• DateField
• ButtonBarSkin
• ButtonSkin
• FormSkin
• HSliderSkin
• MobileCheckBoxSkin
• AndroidComboBox

Como podéis ver hay mucho trabajo hecho y si descargáis la aplicación para Android Tour d’Eskimo veréis que el rendimiento es bastante bueno.

Además, parece ser que la gente de PIA escucha peticiones, así que si os animáis votad por el tema de Android 4.0, el cual será un requerimiento para las aplicaciones que quieran entrar en el Android Market en el futuro.

Saludos!!

Etiquetas: adobe air, Android, Flex Mobile, Iniciativas, Interficies, ios, OpenSource, Recursos útiles

Sin comentarios

• blackberry,
• Ejemplos,
• Recursos útiles,
• Tablets

por Raúl Jiménez

Creo que GestureSwipe es una de las mejores cosas que tiene la API de eventos gestuales de AIR, nos ahorra incontables líneas de código y con muy poco esfuerzo podemos crear efectos muy llamativos.

Desarrollando la plataforma Synctur, he podido trabajar bastante con esta API y me he dado cuenta de que no funciona igual en todas las plataformas en las que está disponible actualmente, iPad, Android y Playbook. El problema principal es que Playbook recibe muchos más eventos que  iPad y Android, con lo cual tuve que tirar de GesturePhase para filtrar este problema.

GesturePhase

GesturePhase es la fase de captura del evento Swipe y nos dice en qué momento de la interacción nos encontramos. Según la documentación de Adobe de GesturePhase, hay cuatro tipos:

• ALL: Un valor simple para todas las fases de los eventos simples como el two-finger-tap y el swipe.
• BEGIN: Cuando se inicia el gesto.
• UPDATE: Cuando se actualiza el gesto.
• END: Cuando se finaliza el gesto.

GesturePhase.BEGIN: Lo recibimos la primera vez que pulsamos sobre la pantalla para iniciar el gesto.

GesturePhase.UPDATE: Recibido cuando movemos el dedo hacia la dirección deseada. Se recibe varias veces y depende de la cantidad de espacio y velocidad del movimiento.

GesturePhase.END: Lo recibimos cuando levantamos el dedo y finalizamos el gesto.

Después de entender GesturePhase, corregir el problema fue muy simple y con un simple filtro para saber que el gesto ha finalizado nos basta:

addEventListener(TransformGestureEvent.GESTURE_SWIPE, onSwipeEvent);
protected function onSwipeEvent(evt:TransformGestureEvent):void
{
	if (evt.phase == GesturePhase.END)
	{
		//DO SOMETHING...
	}
}

Iconos por GestureWorks

Esta entrada no tiene ninguna etiqueta

Sin comentarios

• Adobe User Groups,
• Artículos,
• BlocketPc

por Raúl Jiménez

Como todos los años en BlocketPc os traemos el resumen del año 2011, doce meses en los que los tablets se han hecho fuertes en el mercado y en el que HTML5 ha irrumpido con fuerza en el mercado de los desarrolladores.

Para mi es un placer hacer este resumen todos los años, uno se da cuenta de lo que realmente ha hecho, este año ha sido más flojo que otros, pero igualmente ha sido intenso y lleno de noticias interesantes.

Enero
Después de un curro monumental teníamos que volver a una versión más simple de BlocketPc. Los hackers siempre han sido un problema en nuestro blog, pero hemos aprendido mucho de ellos.

Anunciábamos DeviceDays 2011 y hablábamos de como Android lograba los 9 millones de activaciones mensuales. Probablemente ahora sean muchos más.

Febrero

El Mobile World Congress y DeviceDays monopolizaba toda la información pero aún así hablábamos de otros eventos como Flash2Dev, MAUG eSeminar de HTML5 y Webinar Playbook.

Por si fuera poco Adobe anunciaba Adobe AIR 2.6 para Android.

Marzo

Participábamos en un divertidísimo podcast con el AUGV. ¡Qué bien lo pasamos! ¡Gracias chicos!

Flash Player 10.2 salía para Android, sería una de las últimas versiones, ya que meses después Adobe lo abandonaría.

Hablábamos de la importancia de las texturas en el diseño móvil y por fin sabíamos datos oficiales para Adobe en Vivo 2011.

Abril

Hacíamos un breve resumen de nuestros días en el Adobe en Vivo 2011 en Argentina. Como siempre fue una experiencia inolvidable que no se puede explicar con palabras.

Mayo

Seguíamos dando vueltas por eventos, esta vez fuimos a la primera edición del Genmob: The Smartphone day, que nos dejó una sensación buenísima.

Añadíamos HumansTXT al blog y hablábamos sobre la llegada de Flash Player 10.1 a WebOS, no se si finalmente llegaría, de todas formas ya es una plataforma muerta. Una pena, me encanta WebOS.

Junio

Colgábamos una interesante lista de videotutoriales de Video2Brain sobre movilidad y un largo tutorial paso a paso para compilar para iOS con Flash en Windows 7.

También anunciábamos el Barcelona Developers Conference 2011 al que luego pudimos asistir y disfrutar en primera persona.

Octubre

Después de unos meses complicados en verano volvíamos a la carga por la puerta grande asistiendo al Blackberry DevCon Americas, las Jornadas Adobe de Alicante y al eSeminar de creación de juegos para Android.

Tomábamos nota del proyecto de Community Translation que se había abierto para traducir contenido de la web de Adobe.

Noviembre

Adobe soltaba la bomba del final del Flash Player en dispositivos móviles y nosotros escribíamos una reflexión sobre el futuro de Flash.

Mientras tanto seguíamos poniendo algunos tips más como detectar un iPad en iOS con Adobe AIR.

Muchas gracias y feliz 2012

Etiquetas: 2011, adobe user group, BlocketPc, resumen

Sin comentarios

• Ejemplos,
• Flash en Móviles,
• iPhone,
• Recursos útiles,
• Tablets

por Raúl Jiménez

Hoy me ha surgido este problema y no he encontrado por ningún lado como hacerlo, así mismo la entrada sobre Capabilities de los LiveDocs de Adobe está desactualizada y la información que ponen no muestra lo que devuelven los últimos SDKs de Adobe AIR para iOS.

La cuestión es que para una aplicación que estamos desarrollando tenemos que detectar si un dispositivo con iOS es un iPad o un iPhone, para ello he utilizado Capabilities.os y con un simple indexOf podemos recoger si es un iPad. Esto es lo que devuelve AIR 2.7 en iOS 5.0.1 en un iPad 2:

• Capabilities.os: iPhone OS 5.0.1 iPad2,2
• Capabilities.version: IOS 10,3,180,82

Una forma rápida y sencilla de filtrar código según el dispositivo, no es lo ideal, pero en el mundo mobile tenemos estas herramientas para luchar contra la fragmentación.

Un saludo!

Etiquetas: adobe air, Ejemplos, Flash en Móviles, ios, ipad, Recursos útiles

Sin comentarios

• Android,
• Aplicaciones,
• Artículos,
• blackberry,
• Flash en Móviles,
• iPhone,
• Noticias

por Raúl Jiménez

Ya han pasado varios días desde que Adobe anunció que dejaría de desarrollar y evolucionar el Flash Player para navegadores de dispositivos móviles. Adobe, en un acto de irresponsabilidad sin precedentes, lo dijo sin dar muchas explicaciones al respecto, lo que causó que mucha gente descorchara botellas de cava y otros tantos empezaran a buscar trabajo en la construcción.

La realidad, como siempre, es bastante diferente a lo que la gente piensa y en este post me gustaría explicar un poco lo que pienso después de haber leído multitud de opiniones de diferentes evangelistas, profesionales, empleados y ex-empleados de Adobe.

Flash Player en dispositivos

Como decía antes, Adobe ha decidido dejar de desarrollar el Flash Player para móviles y tablets, una decisión que personalmente no me gusta, pero que por otra parte entiendo. El uso de Flash Player en los móviles y tablets a día de hoy se reduce básicamente a poder ver lo que ya se había hecho, muy poca gente ha desarrollado webs o juegos Flash para jugar a través del navegador y esto en parte se debe a que las tiendas de aplicaciones son las encargadas de hacer ese trabajo ahora.

Desde mi punto de vista esto es malo para el usuario, muy malo. ¿Qué pasa si yo estoy utilizando un servicio que solo es accesible a través de una aplicación y cambio de sistema operativo? ¿Y si esa plataforma no está soportada? ¿Y si ese sistema operativo es abandonado? ¿Y si he pagado dinero por esa aplicación?

Por otro lado, está claro que esto para los propietarios de las tiendas y los desarrolladores es bueno, pues podemos hacer que los usuarios accedan y compren nuestro contenido de una forma mucho más fácil. Esto es a lo que la gente le está llamando la Web 3.0, donde la internet que conocemos pasará a ser un lugar de información pura y dura, mientras que las tiendas de aplicaciones se encargarán de distribuir el contenido multimedia.

Dentro de este nuevo paradigma, en el que nos metió Apple, Flash Player para dispositivos no tiene cabida, básicamente porque la gente ya se ha acostumbrado a pagar y a acceder al contenido multimedia a través de tiendas de aplicaciones y el uso de Flash Player en los navegadores Android se ha reducido a la visualización de vídeo, terreno en el que HTML5 aún está muy, muy, muy, muy lejos.

Por si fuera poco, Mike Chambers explicó muy bien hace un par de días el porqué costaba tanto dinero y esfuerzo desarrollar para el navegador, mientras que AIR es mucho más fácil y barato, ya que al parecer las APIs que otorgan los navegadores son muy limitadas y Adobe tenía que trabajar muy de cerca con desarrolladores de sistemas operativos, fabricantes de hardware y dispositivos.

Tras analizar todo esto, entiendo que Adobe haya dejado de desarrollar Flash Player para dispositivos, lo cual nos deja nuevos frentes abiertos como AIR, Flex y HTML5.

Flash Player para escritorio

Los que llevamos muchos años trabajando con Flash y ActionScript sabemos que esta tecnología nos ha hecho evolucionar con ella de una forma maravillosa a la que con ninguna otra podríamos haber llegado. Yo llevo 10 años trabajando en este mundo y he sido profesor, animador, programador front-end, programador back-end, he desarrollado webs, banners, aplicaciones empresariales, players de vídeo, juegos, intranets, sistemas de e-learning, aplicaciones para móviles, tablets y hasta consolas, TODO con ActionScript, y para lograrlo he tenido que evolucionar.

En todo este tiempo hemos pasado de línea de tiempo a ActionScript 1, luego ActionScript 2 y por último ActionScript 3, y en cada una de estas evoluciones Flash ha ganado adeptos por un lado y los ha perdido por otro, aunque probablemente sea en la última evolución donde perdió más, ya que muchos desarrolladores no soportaron un lenguaje estricto como AS3 y pasaron de AS2 a JavaScript, mucho más flexible y que les permitía hacer aplicaciones sin preocuparse de tipados, clases y patrones de diseño.

Con esto quiero decir que Flash va a seguir evolucionando y los desarrolladores que lo utilizan también. Esta evolución ahora vendrá de la mano de AIR y durante un tiempo de Flash Player para escritorio, con lo que ya tenemos nuestro siguiente objetivo: las aplicaciones multiplataforma y los juegos 3D.

Los juegos 3D van a permitir extender la vida del Flash Player de escritorio un buen puñado de años, dando además un nuevo sentido a la web como sistema de entretenimiento en la nube que antes no había tenido. Los que recuerden nuestra charla de Lord Of The Pongs de Subflash o BlackBerry DevCon sabrán a lo que me estoy refiriendo.

Como usuario estoy deseando ver qué hace gente como Valve y su plataforma Steam o Epic con su Unreal Engine, el hecho de poder pagar una cuota mensual y jugar a un amplio abanico de juegos a través del navegador se me hace una idea muy interesante.

Y después de todo que nadie se haga ilusiones… el Flash Player no durará siempre, llegará un momento en el que no será necesario, porque HTML5 también avanza (aunque lo hace a un ritmo tan lento y fraccionado que hace que a los desarrolladores ActionScript nos de grima).

Tarde o temprando, HTML5 alcanzará a Flash Player en la mayoría de características, básicamente, porque las características son limitadas. Por ejemplo, existe WebGL, que compite con Stage3D de Flash, pero aunque WebGL a día de hoy apesta, llegará un momento en el que no y por eso a HTML5 cada vez recortará más terreno a Flash.

Una vez más remito a Mike Chambers que resume muy bien todo el dilema en esta frase:

A lot of the things that you have done via Flash in the past, will increasingly be done via HTML5 and CSS3 directly in the browser.

¿Entonces Flash ha muerto?

NO

Adobe AIR

Flash ha pasado a convertirse en un sistema de desarrollo rápido de aplicaciones multiplataforma de la misma forma que hay otros como QT. Con AIR para TVs, móviles, tablets y escritorio, además de las Native Extensions, tenemos el mejor lenguaje para crear aplicaciones multidispositivo y multiplataforma del mercado, que nadie piense que hay otro lenguaje mejor para hacer el CORE (“Code Once Run Everywhere”), porque no lo hay.

Como sabréis, Adobe ha comprado PhoneGap, un framework para desarrollar aplicaciones multiplataforma y multidispositivo con HTML5 y JavaScript el cual creo que es y será la competencia de AIR, aunque PhoneGap tiene tanto por evolucionar que no me aventuro a decir que llegue a ser en algún momento una competencia seria.

El principal problema que tiene que resolver HTML5 es romper la barrera del Enterprise y la fragmentación en los navegadores tanto de escritorio como de dispositivos móviles, y hasta que no consiga eso no será rival para AIR y habrá lugar para Flash.

Por último, quiero poner otra cita de Mike Chambers:

I am not suggesting that all Flash content should or will be done in HTML5. You have to look at each project on a case by case basis and make a decision based on development costs, target platforms and user experience.

Nosotros como profesionales somos los que debemos de decidir qué tecnología es la mejor para cada proyecto en base a costes, plataformas objetivo y otras muchas cosas, y a día de hoy HTML5 es mejor que Flash para muchas cosas, igual que con HTML5 hay cosas que directamente no puedes o no debes hacer.

Creo que el futuro de los programadores ActionScript está en las aplicaciones y en el 3D durante muchos años, pero creo que no debería usarse para la web más que para casos puntuales donde no llega HTML5, que desgraciadamente a día de hoy son muchas cosas.

Mientras tanto seguiré programando en Flash y esperaré a que Adobe me haga evolucionar una vez más

Links recomendados

Si has llegado hasta aquí y quieres leer un poco más, significa que tienes mucha paciencia e interés por este tema xD

Dejo aquí algunos enlaces con algunas opiniones que me han gustado especialmente:

• Mike Chambers – Flash Professional and the Future
• Mike Chambers – Clarifications on Flash Player for Mobile Browsers, the Flash Platform, and the Future of Flash
• Grant Skinner – Flash Player Mobile, a Post Mortem
• Doug Winnie – Thoughts on Stuff and Things + Adobe
• Mariano Carrizo – Adobe elimina el soporte de Flash Player en navegadores móviles

Etiquetas: Artículos, el fin de flash, Flash en Móviles, la muerte de flash, Noticias

19 comentarios