Apple y Adobe: La ex-pareja sigue con sus disputas

Después de nuestro último post sobre Apple, Adobe y demás actores de esta historia, me prometí no seguir dándole bombo a una situación tan absurda y con tantos intereses “ocultos”.

Obviamente no me he podido resistir después de leer el último capítulo de la disputa en muchos artículos en medios españoles no tecnológicos: 20Minutos, Expansion o Que!

A nivel internacional la repercusión ha sido incluso mayor, pudiendo verse publicado el ya famoso “We love Apple” en los grandes periodicos de medio mundo.

La verdad es que leyendo muchos de estos artículos nos damos cuenta que los articulistas “se tiran a la piscina” muy rápido; pero bueno, la noticia es la que es. Algunos piensan que Adobe se ha rendido, otros piensan que es un ataque directo contra Apple o que es una declaración de intenciones.

Lo más acertado es decir que se trata de una respuesta a la contra-publicidad y jugadas poco elegantes que ha desarrollado Apple durante el último mes contra todo bicho viviente (Microsoft, Google y más).

El primer apartado que Adobe ha dedicado a este tema comienza con el párrafo:

At Adobe, we believe that the open flow of creativity, ideas, and information should be limited only by the imagination. Innovation thrives when people are free to choose the technologies that enable them to openly express themselves and access information where and when they want. Everyone loses when technological barriers impede the exchange of ideas.

A parte de su declaración de intenciones con respecto al desarrollo tecnológico, también queda bastante claro cual es su política respecto a HTML5 … we love HTML5 & H.264.

Y en segundo apartado se detallan una serie de aclaraciones como respuesta a un artículo que publicó Steve Jobs hace unas semanas, el cual a mi parecer está repleto de interesadas medias verdades. Adobe aclara en este punto temas relacionados con aplicaciones orientadas a dispositivos con pantalla táctil, seguridad, video, su política open-source y rendimiento.

Supongo que tras nuestra serie de artículos referentes al tema podeis pensar que somos anti-Apple o algo así, pero ese pensamiento sería equivocado: nos encantan los productos de Apple, los tenemos y los usamos. Lo que no nos gusta es tener que escuchar falsas argumentaciones y ver cómo se propagan ideas erróneas a través de los medios. Es muy perjudicial, a nuestro entender, que una empresa con un papel tan importante como Apple se decida a emprender una batalla por su cuenta al más puro estilo Microsoft de los 90 y atacar de forma injusta a empresas que aportan buenas soluciones, y en este punto no hablo sólo de Adobe, porque las empresas perjudicadas son muchas más, ya sea porque utilizan productos de Adobe o también se han visto afectadas por la nueva claúsula incluida para la publicación de aplicaciones en AppStore.

Como os podreis imaginar, este tema aún no ha acabado y parece que va para largo, ya que incluso parece que Estados Unidos baraja la posiblidad de investigar a Apple por monopolio y se ha generado un gran revuelvo dentro de la comunidad de desarrolladores y no se sabe como acabará este tema. ¿Eliminará Apple la cláusula de la discordia antes de llegar a mayores? ¿No se llegará a mayores? ¿Será engullido Flash por The Flying Spaguetti Monster? Supongo que todo esto se sabrá con el paso del tiempo.

Para concluir, os invitamos a leer también la carta publicada por John Warnock y Chuck Geschke, co-fundadores de Adobe, donde hablan sobre mercados abiertos e innovación, haciendo un guiño a través del título “our thoughts on open markets” a Steve Jobs.

Adobe Catalyst, un nuevo miembro en la familia CS5 con mucho camino por delante

No hemos podido dejar pasar la oportunidad de conocer de primera mano las novedades de la recién horneada suite Creative Suite 5 de Adobe, así que hoy nos hemos acercado al iMax de Madrid, lugar elegido por Adobe España para presentar oficialmente en nuestro país su nueva suite, acompañada por sus partners tecnológicos HP y NVIDIA.

Desde las 9 de la mañana hasta las 5 de la tarde Adobe nos ha presentado la nueva gama de productos CS5 al completo, donde hemos podido ser testigos de la importancia que tiene para Adobe la revolución que actualmente se está produciendo en el mundo, tanto del desarrollo de contenidos como de la distribución de los mismos hacia diferentes tipos de soportes y dispositivos (especialmente hacia los nuevos smartphones al estilo Nexus I).

Vivimos un momento en el que ya no basta con hacer bonitas campañas on-line o sitios web bien diseñados, sino que es necesario conocer el impacto que estos producen en los usuarios. Para ello Adobe adquirió en octubre del pasado año la empresa Omniture, líder en el mercado de análisis de negocios on-line. En este contexto, queremos destacar cómo ahora Adobe lleva más allá el flujo de trabajo de los creativos para hacerles partícipes de la importancia que tiene conocer el efecto que su trabajo causa en el consumidor e incluye el acceso a los servicios vía web de Omniture. Lo podremos ver integrado en Flash CS5 y ayudará a las agencias a realizar campañas y sitios web aún más efectivos.

Una vez más, la suite CS5 presenta mejoras orientadas a la productividad (a destacar las que hemos podido ver sobre Dreamweaver en lo referente a la  visualización en vivo de estilos css o la espectacular aceleración por hardware para Photoshop, After Effects y Premiere gracias a la integración nativa con las nuevas tarjetas Quadro de NVIDIA) y también a la mejora del flujo de trabajo entre las distintas aplicaciones. Además la suite incorpora CS Live: múltiples servicios accesibles vía web (gratuitos durante el primer año) y la nueva herramienta que ayudará a la creación de aplicaciones y sitios web interactivos: Adobe Catalyst, orientada especialmente a los diseñadores de contenidos interactivos y RIAs.

Para definirlo a grandes rasgos, Catalyst sirve de puente entre las conocidas herramientas para la creación gráfica de interfaces de usuario (Photoshop, Illustrator o Fireworks) y el entorno profesional de desarrollo de aplicaciones Flash Builder. Pero no se limita ahí, sino que permite generar desde él mismo aplicaciones compiladas para web o para el escritorio.

De esta forma, finalmente se facilita el acceso de toda una comunidad de diseñadores a los entornos de desarrollo de RIAs, poblados actualmente casi en exclusiva por programadores Flex.

Y aquí viene lo bueno: en la demostración de hoy hemos sido testigos de cómo un PSD (con las capas bien nombradas y ordenadas) y unos vídeos H264 se convertían, tras unos pocos clics, en una RIA lista para desplegar en el servidor web o, por el mismo precio, para distribuir como aplicación de escritorio, empaquetada en un instalador AIR. ¿Pero… cómo es posible?

Adobe ha desarrollado un producto nuevo, totalmente independiente de Flash Professional, de uso realmente sencillo. Tan sencillo que no hace falta ni ser programador ni haber usado nunca Flash Professional para ponerse manos a la obra y crear sitios web interactivos, películas interactivas o prototipos de aplicaciones más complejas.

Es precisamente en este último caso, la generación rápida de prototipos interactivos, donde más partido se puede sacar a día de hoy a Catalyst. Realmente hasta ahora ya era posible crear prototipos mediante Flash Professional, pero con la nueva herramienta esta labor resulta mucho más rápida y sencilla; el diseñador de interacción prepara un nuevo diseño para una nueva aplicación web, lo convierte con Catalyst en una aplicación interactiva (obviamente con funcionalidades limitadas), y el ejectivo de cuentas lo presenta al cliente en la revisión planificada.

Creedme, la impresión que trasmite al cliente un prototipo de estas características está a años luz de unas simples muestras jpgs o de un pdf montado con interacción.

Volviendo a las características de esta nueva aplicación, destacar que podremos ver (pero no editar) el código mxml autogenerado, lo cual valoramos muy positivamente ya que como apuntaba anteriormente, permitirá acercar al diseñador, de forma amigable, a la nueva sintaxis de desarrollo de RIAs presente en Flash Builder.

Hablando de Flash Builder, sí, podremos abrir proyectos mxml generados desde Catalyst; pero en cuanto a la verdadera utilidad del código mxml generado… ejem, francamente a los programadores no nos gusta que nos generen código automáticamente; aunque sin duda se tomará como referencia para montar layouts con precisión.

Personalmente estoy tan acostumbrado a diseñar con Photoshop y Flex sin intermediarios que me costará adoptar al nuevo de la familia, pero sin duda resultará de especial interés para todos los diseñadores que se animen a adentrarse en el creciente mercado del desarrollo de RIAs. No olvidemos que las aplicaciones flash, compiladas con Flash Professional o con Flash Builder, estarán presentes en las plataformas móviles más importantes: Android,  Windows Mobile, Symbian, etc, de modo que no hay que quedarse atrás, hay mucho por hacer y toca ponerse manos a la obra.

¿Qué todavía no sabes cómo es una aplicación web Flex bien diseñada? Visita www.picnik.com y entenderás por qué nos gusta Flex. ;D

Para conocer más a fondo Adobe Catalyst os recomiendo visitar su página en tv.adobe.com: http://tv.adobe.com/product/flash-catalyst/

Y si quereis remangaros y meteros en faena ya podeis descargar la versión de prueba.

Cycle-IT en su nueva máquina

Hola a todos, breve post para comentaros que Cycle-IT ya tiene operativo de nuevo su sitio en el dominio .com y .es. Así mismo, el blog también ha sido trasladado a esta nueva máquina.

Ahora tenemos una máquina linux para nosotros solos; en su día la opción inicial nos bastaba, ahora que estamos creciendo y empezamos a mostrar nuestros progresos necesitamos una máquina que soporte algo más que la anterior, aparte de poder servir a un número mayor de gente, sin que eso repercuta en la calidad del servicio.

De nuevo, sentimos el trastorno que haya podido generar esta migración. ¡Gracias por vuestra comprensión :) !

Ejemplo de CycleFramework

CycleFramework SampleProject screenshot

Hola a todos, ya iba siendo hora de que las estrellas se alineasen para que en primer lugar, escribiese mi primer post y en segundo, que subiésemos por fin un ejemplo de CycleFramerwork.

Aunque el framework es muy sencillo de usar, sí somos conscientes de que a priori puede resultar complejo comprender la potencia que tiene sin tener un ejemplo de código, en el que se resuelvan los problemas cotidianos de la vida del desarrollador.

Para esto, os hemos preparado un ejemplo en el que podéis ver una gestión de usuarios clásica, con todos los problemas que esta conlleva. Para facilitar el seguimiento del ejemplo, os recomiendo que tengais a mano la documentación en PDF de CycleFramework. Además, nuestro Alberto ha diseñado y skineado la aplicación de ejemplo para que podáis ver y disfrutar de su buen gusto, al igual que lo hacemos nosotros día a día con su buen hacer :) .

Lo primero que veréis es una pequeña pantalla de login sin validar que os permitirá entrar directamente al pulsar el botón de enviar. Si seguís el caso de uso, veréis que llegamos hasta la clase ExampleServiceFacade.as.

Aunque el framework sólo se centra en la gestión de las vistas, y para el tratamiento y organización de las llamadas a negocio se suelen usar otros frameworks como Cairngorm, nosotros preferimos una arquitectura propia en la que mediante una o varias fachadas de negocio, tenemos acceso a los  servicios que expone una aplicación servidora. Esto unido a un modelo con ciertas peculiaridades hace que de forma automática se gestionen las peticiones que no requieren de tratamiento, dejando en el modelo los datos recibidos.

En futuras versiones de CycleFramework, esta planificada una ampliación que contemple esta metodología, de forma que se consiga crear un framework integral en el desarrollo de aplicaciones Flex.

Hecha esta aclaración para que podáis seguir el ejemplo, continuemos con la explicación.  De vuelta a ExampleServiceFacade vemos que se ejecuta el método login, sin realizar comunicación alguna con servidor. En caso de realizarse, sería aquí donde invocaríamos a un servicio ofrecido por un RemoteObject, HttpService o cualquier otro que se os ocurra.

En este caso se instancia un objeto de la clase User y se deposita dentro del modelo en la variable loginData. Esta notación tiene que ver con el sistema de manejo automático de peticiones, el cual no se explicara en este post.

Pero, cómo es posible que sólo con un cambio el loginData la aplicación haya cambiado y ahora estemos viendo el “alta de usuario”, bien ahora es el momento de abrir ExampleViewController.as, esta clase al heredar de ViewController nos permitirá de forma fácil, asociar cambios en la vista cuando suceden cambios en el modelo. Esto lo conseguiremos haciendo uso de dos métodos: addWatcher y addHandler.
El primero lo usaremos cuando con el cambio de una variable del modelo (sin importar lo que contenga) queremos navegar a un estado de la aplicación. El segundo lo usaremos en los casos en los que sí que dependemos del valor que cambia para navegar a un estado u otro.

Claros ejemplos de esto pueden ser:

addWatcher(ExampleResponseModel.getInstance(),"getUsersData",
                   new ArrayCollection(['vm','userManager',"retrieve"]));

Donde vemos que cuando en getUsersData se deje una lista de usuarios, siempre querremos navegar al listado de usuarios.

addHandler(ExampleResponseModel.getInstance(),"loginData",loginHandler);

Pero en el caso del login, podemos querer, dependiendo del perfil de usuario, navegar a uno u otro estado de la aplicación, con lo que para estos casos especiales usaremos el método addHandler, que nos permitirá usar un manejador a medida para estos cambios de la vista, que en última instancia tienen que estar controlados por el desarrollador.

Aunque en el ejemplo no se hace uso de ExampleServiceController.as, esta clase tendrá un funcionamiento muy similar a ExampleViewController.as, sólo que en este caso lo que queremos es tener organizados los refrescos de datos en función de cambios en el modelo. Ejemplo de esto, puede ser que tras realizar un alta de usuario, recibimos del servidor el usuario creado, pero queremos que la aplicación navegue al listado de usuarios y refresque los datos.

En este caso añadiríamos en ExampleServiceController un handler para que cuando llegue el usuario creado se pida de nuevo la lista de usuarios. A su vez en ExampleViewController tendríamos un watcher al listado de usuarios del modelo para navegar a la vista del listado de usuarios.

Con lo que así tendríamos cerrado el caso de uso de una forma elegante y sencilla, además de realizar de este modo todas las acciones cuando tenemos los datos, creando una experiencia de usuario mejorada, ya que los pintados en pantalla serán siempre limpios y sin “parpadeos”.

Ahora os toca a vosotros investigar, espero que os quede todo claro y en el caso de que no sea así, sólo decidlo para que podamos aclarar todas vuestras dudas. Y como se dice en mi tierra,

“en fin Serafín, que más corre el galgo que el mastín, más si el camino es largo, más corre el mastín que el galgo”

:P

Jugando con @Anywhere de Twitter

Acaban de lanzar definitivamente el servicio @anywhere de @twitter y acabamos de integrarlo en el blog de Cycle-IT para jugar un poco con él y ver que puede aportarnos en nuestro día a día.

Para activarlo en vuestros sitios es tan fácil como seguir los pasos que se indican en el sitio de twitter para desarrolladores. Pues nada, podéis ver su funcionamiento posicionando el ratón encima de cuentas de twitter como las mencionadas arriba.

Y para jugar un poco más, os recuerdo la cuenta de @cycle_it y si os aburrís algo, también os dejo la mía @lasneyx.

La única cuestión es, ¿añadirán la posibilidad de acceder a la aplicación o su API para contenido Flash? ¿se puede jugar ya con su API en este sentido? Creo que serían unas buenas pruebas de concepto integrarlo en alguna aplicación Flex o AIR :)

¿Qué opinais vosotros de este servicio?

CycleFramework actualizado

Este es un pequeño post para comentaros que hemos actualizado nuestro framework MVC CycleFramework. Los cambios los podéis leer en la página de ChangeLog en la wiki del proyecto en google code. Hemos actualizado el proyecto también en RIAForge, así que no dudéis en actualizar vuestras aplicaciones a la nueva versión de CycleFramework. Os aconsejamos  actualizar ya que hemos realizado algunas mejoras en materia de optimización y hemos dejado mucho más claro el código y facilitado el uso del mismo.

También, tened muy en cuenta a la hora de actualizar que hemos realizado un cambio importante en los métodos addWatcher de ServicesController y ViewController. La signatura del método anterior era:

addWatcher(host:Object, property:String, service:Function, handler:Function = null);

De esta forma, tanto si queríamos añadir un watcher como un manejador a medida, usabamos este método. Si queríamos añadir un manejador a medida, debíamos pasar un valor null a nuestro servicio y una referencia a función al handler.

Ahora, hemos partido este método en dos para facilitarlo y que añadir un watcher o un manejador sea algo más natural. De esta forma tenemos:

addWatcher(host:Object, property:String, service:Function):void;
addHandler(host:Object, property:String, handler:Function):void;

Tened esto en cuenta a la hora de actualizar vuestros proyectos. Ibamos a optar por marcar al anterior como deprecado, pero queremos forzaros a que actualicéis vuestras aplicaciones a la nueva forma de trabajar :) . Si os da muchos problemas, no dudéis en comentarnoslo y valoraremos la posibilidad de añadirlo de nuevo, marcándolo como deprecado.

¿A qué esperáis para actualizaros :) ?

Apple sigue dando de qué hablar

“Una de cal y otra de arena”, así es la vida pero si no fuera así, no tendría emoción.

Esta semana estábamos contentos por vislumbrar un futuro con aplicaciones ActionScript dentro de los dispositivos de Apple de una forma rápida y sencilla, sólo nos faltaban 3 días para la presentación de Adobe CS5 (la aplicación que habilita esta posibilidad) cuando Apple ha lanzado la siguiente irreverencia:

“Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited)”.

Es un extracto del nuevo acuerdo de desarrollo que se debe aceptar si quieres ver tu aplicación en ejecución sobre el sistema operativo de Apple. Obviamente, este acuerdo cierra las puertas a nuevas tecnologías como las de Adobe, Microsoft o Sun Oracle entre otras. Para que os hagais una idea, ese texto sustituye al siguiente:

“Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs”.

Cambia un poco, ¿verdad?

Una conclusión que sacamos es que Apple se queda fuera del Open Screen Project de forma casi definitiva, ya que de forma directa se cierran las puertas hacia sus “pantallas”. Digo de forma directa porque de forma indirecta los usuarios al final siempre consiguen lo que quieren, ya sea de forma lícita o ilícita.

Hablando sin tapujos, Apple quiere obligar a los programadores a que desarrollen utilizando única y exclusivamente su tecnología, cerrando la opción de que exista una tecnología multiplataforma de verdad (y estábamos muy cerca).

Obviamente, en Cycle-IT vamos a seguir apostando por la misma tecnología ya que móviles y tablets hay muchos, y habrá más. También vamos a seguir usando macbooks y programando con ellos RIAs y RDAs, pero no vamos a pasar por el sobresfuerzo de desarrollar y probar dos veces la misma aplicación.

Tú, desarrollador ¿qué harás?

Aplicaciones web: ¿Mejor en el escritorio?

Hace ya tiempo que los miembros de Cycle-IT compartimos el discurso sobre el futuro de las aplicaciones web. Ahora que este tema se encuentra en el candelero gracias a Apple con su famoso iPad, creemos conveniente hacerlo vuestro también para saber vuestra opinión.

Allá por el 2006 comenzamos a cuestionarnos el modelo existente para el desarrollo de aplicaciones web. Los motivos eran varios pero todos apuntaban hacia el mismo sitio: ¿cómo podríamos afrontar la creciente complejidad de las aplicaciones web provocada por los nuevos requisitos de los clientes? Estos cada vez demandaban aplicaciones más ricas visual e interactivamente, lo cual desencadenaba en requisitos que cada vez se aproximaban más a aplicaciones de escritorio, alejándose de las tradicionales aplicaciones web que se venían realizando hasta el momento. Y de repente, apareció Flex en nuestras vidas.

Conforme fuimos conociendo sus cualidades, fuimos comprendiendo hacia donde podría virar nuestro mercado. Ese nuevo rumbo suponía un avance espectacular en las posibilidades de los proyectos web, ya que por un lado podíamos decir a todo “Sí, puedes contar con esa característica”, en lugar del típico, “El esfuerzo requerido para hacerlo en HTML y JavaScript no merece la pena”.

Ese “sí” implicaba muchas cosas: implicaba un sí en calidad, un sí en rendimiento, un sí en experiencia de usuario, un sí en reducción de tiempos y en definitiva, un SÍ que contenta a todo el mundo.

Llegado este momento, fuimos espectadores del combate inicial entre Flex/AIR (antes llamado Apollo), Silverlight y JavaFX. Hablar de la situación de mercado de estas tecnologías merece un post aparte, aunque ya os adelanto que JavaFX salió bastante mal parado.

El destino se vislumbraba claro, y no era meterse en un navegador o en un dispositivo en concreto. La idea de era volver a entrar en el escritorio del usuario. Este escritorio puede ser el de un PC de sobremesa, un portátil, un netbook, un tablet, un móvil o cualquier otro dispositivo que esté por venir (¿estas nuevas televisiones conectadas a Internet?), y lo que tenemos claro en Cycle-IT es que no se llegará allí a través de un navegador.

¿Por qué tanto interés en el escritorio? Hay varios motivos. En primer lugar es sorprendente lo habitual que se ha vuelto abrir un navegador y escribir en el buscador de Google “youtube” o “facebook”. Es un poco absurdo pero tiene un motivo: un usuario normal no utiliza marcadores, ni está acostumbrado a escribir “http://…” ; un usuario “va al turrón” y la forma más fácil de llegar para ellos a Facebook o Youtube es esa. No están acostumbrados a esta forma de acceder a las aplicaciones ni quieren acostumbrarse. Por el contrario, un icono en el escritorio es directo; clic y a trabajar.

Imaginaros llevar ese proceso basado en navegación entre páginas a un teléfono móvil, sería un verdadero suicidio tecnológico. Por este motivo los usuarios de Internet comienzan a utilizar sus nuevos dispositivos de forma habitual por la comodidad a la hora de visualizar datos. En mi HTC o mi iPhone tengo un botón como mi dedo de grande para acceder a Facebook o a Youtube. Esta es una de las razones por la que las marcas quieren estar en el móvil del usuario.

En segundo lugar, hablamos de aplicaciones web, no de páginas web. Una aplicación suele ser un sistema complejo y muchas veces requiere interactuar con otros sistemas. Dentro de un navegador se complica la interacción, entre otras cosas ya que por seguridad no se debe tener acceso a muchos recursos, lo cual limita la aplicación desde su nacimiento. En cambio, una aplicación web de escritorio sí que puede, lo cual le da una gran ventaja.

Por otro lado, también es un concepto de marketing. ¿Por qué darle continuamente publicidad a Internet Explorer, Chrome o Mozilla? Si yo hago una aplicación que funciona bien por si misma, no debe de restarle mérito el paso previo (del todo innecesario) que es abrir un explorador. ¿Por qué no puede estar un icono de mi marca en el escritorio de mi cliente?

Con esto no queremos decir que todo deba ir al escritorio. Obviamente hay casos en los que se podría plantear sólo a través del navegador, sólo en el escritorio o una combinación de ambas soluciones.

Podríamos hablar de estas facilidades eternamente, pero lo importante es ¿por qué estamos hablando de esto? Hablamos de esto porque el futuro de Internet pasa por aplicaciones multiplataforma y multidispositivo, pero con una interacción con el usuario distinta a la que te puede ofrecer un navegador. La aplicación debe estar integrada en el dispositivo. Por este motivo no entiendo ni los movimientos de Apple ni los de los detractores por ignorancia tecnológica de Flash, Flex y AIR, ya que mediante estas tecnologías se puede conseguir todo lo que demanda el usuario de hoy en día.

Para muestra, la prueba de concepto de Christian Cantrell de Adobe, donde demuestra que con el mismo código ActionScript se pueden generar aplicaciones para iPhone, Android, iPad, Mac, Linux, Spectrum, Atari y lo que se os ocurra.

Disfrutad del vídeo, merece la pena.

Adobe, Mozilla y Google: Por una fácil y cómoda integración

Esta mañana hemos leído un post de @mcorlan en el que se hacía eco de una noticia publicada por el equipo de desarrollo de Flash Player. En esta noticia se mencionaba que Adobe está trabajando con Google y Mozilla, entre otros, para facilitar la integración de Flash Player en sus navegadores: Chrome y Firefox respectivamente. Integración Flash y navegadores

Pretenden acercar la integración ofreciendo el plugin directamente en la descarga del navegador en cuestión, o facilitando su actualización utilizando los mecanismos propios del navegador, consiguiendo que esta tarea se realice de forma cómoda y transparente al usuario.

Pero no solo se quedan ahí, y esto es lo más importante (pequeña traducción libre del post del equipo de FP):

La plataforma Flash tiene una larga historia proporcionando innovación para la Web, y esto es gracias a Adobe Flash Player, nuestro runtime de aplicaciones basado en navegador. Actualmente, Flash Player está instalado en prácticamente todos los entornos de escritorio que poseen conexión a internet, y facilita el acceso a contenido atractivo e interactivo con aplicaciones Web, accesibles estas desde cada vez más dispositivos: smartphones, tabletas y netbooks. Continuamos mejorando Flash Player por medio de nuestro equipo de desarrollo y a través de otras contribuciones como el Open Screen Project, el cual incluye cerca de 70  partners (entre ellos Google y Mozilla).

Fruto del proyecto Open Screen Project y relacionado con la noticia inicial es la historia que hemos leido también hoy en TechCrunch: el sistema operativo Google Chrome OS facilitará la integración de Flash Player en los dispositivos netbook. Todo maravillosas noticias para el mundo del desarrollo de aplicaciones Web :) .

Además, una de las direcciones donde están enfocando sus esfuerzos estos miembros de la industria Web, es hacia el desarrollo de una API que facilite la forma en la que interactúan los navegadores con los plugins instalados en ellos. Pretenden descartar la actual NPAPI, ya que consideran que carece de la flexibilidad y poder de soportar la innovación por la cual están apostando desde Adobe. Entre los beneficios de esta nueva API podemos ver:

  • API agnóstica del sistema operativo y el navegador, lo que minimiza inconsistencias entre diferentes plataformas.
  • Integración mayor entre plugins y navegadores.
  • Mejoras de rendimiento al permitir que el navegador sea capaz de compartir directamente más información sobre su estado actual.
  • Mejorar las medidas de seguridad en esta integración y facilitar y unificar los modelos de seguridad.

Es gracias a este esfuerzo con el que están consiguiendo que Flash sea una tecnología atractiva, que facilita al fin y al cabo la vida al usuario y la enriquece mediante interactividades y experiencias de usuario únicas. Motivo por los cuales Cycle IT ha apostado por el desarrollo de aplicaciones Web y de escritorio a través de las tecnologías Flex y AIR, también de Adobe.

En Cycle IT conocemos las tecnologías que hay en el mercado para el desarrollo de RIAs, y vemos este movimiento como uno inteligente que no beneficia a unos pocos, sino a todos los usuarios. Entendemos que el futuro del desarrollo de aplicaciones Web y escritorio parte de fomentar la integración de las diferentes tecnologías existentes, tanto desde el punto de vista de integración en todos los dispositivos, como en realizar la integración entre estas mismas tecnologías. Particularmente veo una convivencia sana entre la nueva tecnología HTML5 y la tecnología Flash, y ni los defensores a ultranza, ni los detractores más duros de unas u otras conseguirán que estas dos tecnologías se acoplen perfectamente y puedan beneficiarse entre si.

Todo esto debido a los esfuerzos de Adobe, Google y Mozilla entre otros, que nos permitirán disfrutar por un lado como desarrolladores para crear verdaderas maravillas de aplicaciones, y por otro como usuarios, facilitándonos el día a día y consiguiendo maravillarnos por su uso diario.

Por esto no entendemos movimientos (bueno sí, pero esto es mención aparte) como los de Apple y su iPad, obstaculizando y dejando de lado a Flash Player. ¿Por qué no ayudar a mejorar la tecnología, si es que realmente lo necesita, en lugar de prohibir su integración? ¿Por qué perderse una parte del mercado o no facilitar su acceso a los usuarios? ¿Es que no ven el potencial de estas tecnologías integradas en sus plataformas? Para muestra un botón una tableta, como la que pudimos ver tiempo atrás en Wired.com.

AdvancedDataGrid y componentes charting, ahora también open source

Acabo de leer un retweet de @mcorlan en el que comentaba que Flex es ahora más open source al liberarse los componentes avanzados y librerías de gráficos (AdvancedDataGrid y Charting). Para poder utilizar estos componentes era necesario disponer de una licencia Profesional del IDE Flex Builder, así que ahora simplemente podemos emplearlos en nuestras aplicaciones de forma totalmente libre.

Es una muy buena noticia y un gran movimiento por parte de Adobe fomentando, por un lado al software libre y por otro, la utilización de su ahora 100% libre SDK de Flex. De alguna u otra forma esto hará su IDE mucho más asequible, aunque todavía estamos a la espera de que lancen la primer versión estable de Flash Builder 4 (antes Flex Builder).

Switch to our mobile site