Android busca causar un impacto disruptor en la industria de la comunicación móvil, estableciendo una plataforma abierta que permita un acceso fácil a practicamente todas las funcionalidades hardware de los dispositivos en los que esté instalado, así como proveyendo de serie a los desarrolladores con librerías que favorezcan la creación ágil y rápida de aplicaciones. Se ha hecho especial énfasis en que las aplicaciones creadas por terceros no tendrán ningún tipo de desventaja en cuanto a funcionalidad y acceso al dispositivo que las aplicaciones “nativas” que se distribuirán originalmente con Android.
El origen de Android se remonta a la adquisición por parte de Google de Android Inc., empresa co-fundada por Andy Rubin, que anteriormente había desarrollado el Danger Hiptop/T-Mobile Sidekick en Danger Inc., y con la ilustre compañía de “The Woz”. Una vez en Google, Rubin pasa a ocupar el cargo de “Director de Plataformas Móviles” y es responsable el proyecto que durante muchos meses generará toda clase de rumores y propuestas de prototipos sobre un posible dispositivo “Google Phone” posicionado directamente contra el iPhone de Apple. El anuncio final ha revelado un producto que se posiciona más directamente contra los sistemas operativos multidispositivo como Windows Mobile o Symbian.
Arquitectura
Android proporciona un paquete completo de software a todos los niveles:
- Un kernel linux que sirve como base de la pila de software y se encarga de las funciones más básicas del sistema: gestión de drivers, seguridad, comunicaciones, etc.
- Una capa de librerías de bajo nivel en C y C++, como SQLite para persistencia de datos; SGL, desarrollada por Skia, otra adquisición de Google; OpenGL ES para gestión de gráficos 3D, con aceleración 3D opcional y Webkit como navegador web embebido y motor de rendeado HTML.
- Un framework para el desarrollo de aplicaciones, dividido en subsistemas para gestión del sistema como el “package manager”; gestion del hardware del teléfono anfitrión (“telephony manager”) o acceso a APIs sofisticadas de geolocalización o mensajería XMPP. También incluye un sistema de vistas para manejar el interfaz de usuario de las aplicaciones, que incluyendo posibilidad de visualización de mapas o renderizado html directamente en el interfaz gráfico de la aplicación.
- Una suite de aplicaciones (navegador, agenda, gestión del teléfono)
Las aplicaciones Android están programadas en Java, pero no corriendo sobre Java ME, sino sobre Dalvik, una máquina virtual Java desarrollada “ex profeso” por Google y optimizada para dispositivos empotrados y en la que los fuentes se compilan a ficheros de “bytecode” *.dex. La creación de una VM propia es un movimiento estratégico que permite a Google evitar conflictos con Sun por la licencia de la máquina virtual, así como asegurarse el poder innovar y modificar ésta sin tener que batallar dentro del JCP.
Estructura de una aplicación Android
La estructura de una aplicación Android está definida por la interacción de distintos componentes, haciendo énfasis en la “agrupación debil” de distintas piezas. La aplicación hará uso de las distintas APIs expuestas por Android, de forma que los componentes encargados de realizar cada tarea puedan ser manipulados o reemplazados sin problemas, asegurando la máxima flexibilidad. Por ejemplo, una aplicación puede permitir al usuario elegir fotos mediante el componente “Galería” o, por ejemplo, reemplazar esa “Galería” por una selección de fotos a través de un servicio online. Los principales componentes de una aplicación serían:
- Activity
- Representa cada una de las principales tareas que el usuario puede llevar a cabo en la aplicación. Típica (aunque no necesariamente) corresponderá a una pantalla específica de la aplicación y, también normalmente, una “activity” será el punto de entrada (pantalla inicial) de nuestra aplicación. Desde ella se invocarán las vistas, específicas o layouts, para la aplicación.
- IntentReceiver
- Permite a nuestra aplicación declarar ciertos “callbacks” que responderán a cambios en el estado del terminal. P.ej. llamada o email recibido, cambio en la geolocalización, etc.
- Service
- Una tarea que corre en el background y que puede y debe ejecutarse sin interacción con el usuario. Una aplicación puede mandar los mensajes necesarios a un determinado servicio activo.
- ContentProvider
- Establece una capa que permite a las distintas aplicaciones compartir datos. Con independencia del almacenamiento local que utilicen para sus propósitos, las aplicaciones necesitan declarar ContentProviders para poner a disposición de otros procesos los datos que consideren necesarios.
Estos son algunos de las principales, pero no las únicas piezas de construcción de la aplicación. También es interesante que se defina como pieza de primer nivel, el sistema de notificaciones en pantalla, que se recomienda como principal vía de comunicación con el usuario.
La construcción de una comunidad
Aunque algunos de las primeros ataques que sufrió Android tras su presentación fue la de ser sólamente “vaporware”, o una mera “nota de prensa”, no tardaron demasiado en
aparecer los primeros productos tangibles de la iniciativa: sólo siete días después del anuncio oficial, Google liberó una versión preliminar de su SDK, consistente en ejemplos de código, documentación, un emulador de dispositivos con Android, diversas herramientas de debug y un plugin de desarrollo para Eclipse.
Al mismo tiempo que lanzaba el SDK, Google impulsaba una importante tarea de construcción de una comunidad articulada de evangelistas y desarrolladores: blogs, tutoriales, videos en Youtube que cumplen funciones tanto de creación de marca como pedagógicas. Como gran incentivo para aumentar la masa crítica de desarrolladores necesaria para hacer frente a comunidades más antiguas y numerosas, se creó la Android Developers Challenge que, desde principios de 2008, recompensará con 10 millones de dólares a los mejores proyectos para la plataforma, asegurándose así un poblado ecosistema de aplicaciones disponibles incluso antes de la aparición de los primeros dispositivos capaces de ejecutarlas.
Conclusión y expectativas
Unos meses después de que Apple señalara que el camino de desarrollo de la comunicación móvil pasaba más por revoluciones que por simples saltos evolutivos en las capacidades hardware y software, la OHA insiste en la misma idea, presentando un producto que de base asume la necesidad de marcar un camino propio en vez de conservar el “status quo” actual. Android marca una serie de pautas que definen la visión de fondo de lo que debe ser la (r)evolución a corto y medio plazo de las tecnológicas móviles:
- Respaldar totalmente al código libre y abierto como modelo más favorable para la industria, aunque intentando mantener un equilibrio con los intereses de los participantes tradicionales y más reticentes. De ahí la meditada elección de licencia.
- Bajar drásticamente las barreras de entrada tanto al desarrollo de software, simplificando el proceso de desarrollo y haciendo un guiño a las muchedumbres de “programadores en garajes”, acelerando así el proceso de evolución de todo el ecosistema de aplicaciones; como al desarrollo de hardware, eliminando los costes de licencias para fabricantes.
- Marcar sutilmente cuales son las tecnologías y caminos que deben explorarse, simplemente escogiendo con cuidado las APIs menos obvias que poner a disposición de los desarrolladores. No es casualidad que se apueste por la geolocalización o por XMPP, que es una tecnología que Google está implantando de forma transversal en todas sus plataformas y servicios.
La cadena de acciones y reacciones que ha desencadenado el anuncio de Android en sólo unos días señala que, al igual que el iPhone, si no como otra cosa ya ha servido como catalizador de una serie de cambios a nivel de toda la industria y que repercutirán en la naturaleza del software y el hardware disponible para los usuarios durante los próximos meses y años.
Enlace a la fuente Original del Texto
-
-
-
-
