Gua del desarrollador Android. Traduccin por ~p. Fuente: http://developer.android.

com/

I Fundamentos de las aplicaciones

Las aplicaciones para el sistema Android, son aplicaciones escritas en Java. La herramienta SDK de Android las compila en un paquete .apk. Todo el cdigo en un .apk es considerado una aplicacin y es el archivo que los dispositivos con Android usan para instalar la aplicacin. Una vez instaladas en un sistema android, las aplicaciones viven en su propia caja de seguridad: -el sistema android es un sistema linux multi usuario, cada aplicacin es un usuario diferente. -el sistema asigna a cada aplicacin una id de usuario. -la id la usa solo el sistema, y es este quien configura permisos para los archivos en la aplicacin, para que slo la ID de usuario asignada a la aplicacin pueda accesar a ellos. -cada proceso tiene su propia mquina virtual, por lo que el cdigo de una aplicacin corre aislado de las otras. -por defecto, cada aplicacin corre su propio proceso Linux. Android inicia el proceso cuando alguno de los componentes de la aplicacin necesita ser ejecutado, luego termina el proceso cuando se necesita memoria para otras aplicaciones. El sistema implementa el principio del ltimo privilegio, esto es, cada aplicacin, por defecto, tiene acceso slo a componentes que requieren para realizar su trabajo y no ms.

Esto crea un entorno seguro en el cual una aplicacin no puede acceder a partes del sistema en las que no tiene permiso. Hay formas de que una app comparta datos con otras o que una app acceda a servicios del sistema: -dos app pueden compartir la misma ID de usuario Linux, en dicho caso, son capaces de acceder a los archivos de cada una, y para optimizar recursos, las app con la misma id pueden correr en el mismo proceso linux y compartir la misma mquina virtual (VM). -una app puede pedir permiso para acceder a dispositivos como los contactos del usuario, mensajes SMS, acceso a datos de la tarjeta SD, la cmara u otros. Estos permisos deben ser dados por el usuario en el momento de instalacin.

Componentes de la aplicacin. Son bloques de construccin de la aplicacin. Cada componente es un punto con el que el sistema puede entrar a la aplicacin, no lo son necesariamente para los usuarios. Algunos componentes dependen de los dems, pero cada uno existe como una entidad propia y juega un rol especfico.

Activities (actividades). Es una pantalla con interfaz de usuario. Por ejemplo: una actividad que muestra una lista de nuevos emails, otra que permite escribir un mail y otra para leer los e mails. Aunque funcionan juntas para dar una experiencia coherente al usuario, cada una es independiente. As, una aplicacin diferente puede iniciar cualquiera de estas actividades (si la aplicacin de email lo permite). Por ejemplo, una

aplicacin de cmara puede inciar la actividad de redactar nuevo correo para compartir una foto. Una actividad es implementada como subclase de activity.

Servicios. Son componentes que corren en el background (fondo) para realizar operaciones de ejecucin larga o trabajar para procesos remotos. No proveen interfaz de usuario. Por ejemplo, reproducir msica mientras el usuario est en una aplicacin diferente; enviar datos a travs de la red sin bloquear interaccin del usuario con la actividad en curso. As, otro componente, tal como una actividad, puede iniciar el servicio y dejarlo correr o traerlo al frente para interactuar con este. Es implementado como subclase de Service. Content Providers. Administran un conjunto compartido de datos de aplicaciones. Puedes dejar datos en el sistema de archivos, BDD, web u otra ubicacin de persistencia a la que tu aplicacin pueda acceder. A travs del content provider, otras aplicaciones pueden acceder y hasta modificar datos (si se les permite). Por ejemplo, el sistema Android trae un content provide que administra la informacin de los contactos del usuario. Como tal, cualquier aplicacin con los permisos correctos pueden obtener parte de ese contenido para leerlo o escribir informacin sobre una persona en particular. Los content providers son tiles para leer y escribir datos privados para la app, y no compartidos. Por ejemplo, notepad usa un content provider para guardar notas. Son implementados como subclase de ContentProvider, y debe ser implementados como un conjunto standard de APIs que permiten a otras aplicaciones realizar transacciones.

Broadcast receivers.

Responden a anuncios de transmisiones de todo el sistema. Varias transmisiones vienen del sistema -batera baja, pantalla apagada, imgen capturada-, pero las app tambin pueden iniciar transmisiones (por ejemplo, para decir a otras app que algunos datos han sido descargados al dispositivo y estn disponibles para su uso. No usan interfaz de usuario, pero pueden crear una notificacin en una barra de estado para alertar que un evento de transmisin ocurre.

Comnmente, son solo una entrada para otros componentes y es deseado que hagan muy poco trabajo. Pueden iniciar un servicio para realizar trabajo basado en un evento. Son implementadas como subclase de BradcastReceiver y cada transmisin es entregada como un objeto Intent (un intent es algo que una aplicacin desea hacer).

Un aspecto nico del diseo de Android, es que cualquier aplicacin puede iniciar un componente de otra. Por ejemplo, si quieres que el usuario tome una foto con la cmara, es probable que otra aplicacin permita que tu aplicacin pueda usarla la cmara-, en vez de desarrollar una actividad que capture la foto. No se necesita ni siquera linkear al cdigo de la aplicacin de cmara; en vez de eso, simplemente puedes iniciar la actividad en la aplicacin de la cmara para tomar la foto. Cuando est completo, la foto es enviada a tu aplicacin y puedes usarla. Al usuario le parecer que la cmara es parte de tu aplicacin.

Cuando el sistema inicia un componente, inicia el proceso de aquella aplicacin e instancia la clase necesaria (si tu app inicia una actividad de la cmara para capturar una foto, la actividad corre en el proceso que pertenece a la app de la cmara. As, a diferencia de app en otros sistemas, las app de Android no tienen slo un punto de entrada (no hay funcin main(), por ejemplo). El sistema corre cada aplicacin en un proceso separado con permisos de archivo que restringen el acceso a otras aplicaciones (a menos que compartan ID, ya que los permisos se dan por ID). Tu app no puede directamente activar un componente de otra aplicacin. El sistema, no obstante, puede. Para activar un componente en otra aplicacin, debes enviar un mensaje al sistema, especificando el intent de iniciar un determinado componente en particular. El sistema lo activa por ti.

Activacin de componentes. El intent, un mensaje asncrono que sirve como mensajero que pide una accin a otros componentes, activa tres componentes (activities, services y broadcast receivers). Los intent traen un componente individual a otro en tiempo de ejecucin, sea que el componente pertenezca a tu aplicacin o otra. Un intent es creado por un objeto Intent. ste define un mensaje para activar ya sea un componente especfico o un tipo de componente, siendo as, el intent, explcito o implcito, respectivamente. Los intentos definen la accin a realizar para actividades y servicios (por ejemplo, "ver" o "enviar" algo) y especifica la URL o los datos

en los que se debe actuar (entre otras cosas que el componente que se iniciar debe saber). Por ejemplo, un intento puede conducir una peticin para una actividad que muestra una imagen o abre una pgina web. En algunos casos, puedes iniciar la actividad para recibir un resultado, en cuyo caso la actividad tambin retorna el resultado en un Intent (por ejemplo, puedes necesitar un intento para dejar que el usuario seleccione un contacto y tener de vuelta esa informacin. El intento de retorno incluye un sealamiento del URI del contacto seleccionado).

Para braodcast receivers, el intento define el anuncio que est siendo transmitido (por ejemplo, batera baja, que incluye slo una accin conocida : un string que indica "batera baja").

El otro componente, content provider, no es activado por intents, sino cuando es seleccionado por una peticin de un ContentResolver. El content resolver maneja todas las transacciones directamente con el content provider, as que el componente que est realizando transacciones con el proveedor no necesita mtodos de llamada en el objeto ContentResolver. Esto deja una capa de abstraccin entre el proveedor de contenido y el componente que pide informacin (para seguridad).

Hay mtodos separados para activar cada tipo de componente: -Puedes iniciar una actividad (or darle una nueva accin para realizar) pasando de Intent a startActivity() o startActivityForResult() (cuando quieras que la actividad retorne un resultado). -Iniciar un servicio (o darle nuevas instrucciones) pasando un Intent a startService() (o traer al frente un servicio pasando un Intent a bindService()).

-Se puede iniciar una transmision pasando un intento a mtodos como sendBroadcast(), sendOrderedBroadcast() o sendStickyBroadcast(). -Puedes realizar una query a un proveedor de contenido llamando a query() en un ContentResolver.

El archivo Manifest

Antes de que el SO inicie un componente de aplicacin, el sistema debe saber que el componente existe leyendo el archivo AndroidManifest.xml de la aplicacin. La app declara todos sus componentes en el archivo manifest, el que debe estar en el root del directorio del proyecto de la app. El manifest hace un nmero de cosas en adicin a declarar los componentes de la aplicacin, como: -identificar cualquier permiso de usuario que la app necesite, como acceso a internet o acceso de lectura a los contactos del usuario. -declarar el nivel mnimo de API requerido por la app, basado en cul API usa la app. -declarar software y hardware requerido por la app (cmara, bluetooth, multitouch...). -declarar libreras API que la app necesitar conectar o usar (por ejemplo la biblioteca de google maps). -y ms.

Declarando componentes.

La tarea primaria del manifest, es informar al sistema acerca de los componentes de la app. Por ejemplo, un manifest puede declarar una actividad como sigue:

<?xml version="1.0" encoding="utf-8"?> <manifest ... > <application android:icon="@drawable/app_icon.png" ... > <activity android:name="com.example.project.ExampleActivity" android:label="@string/example_label" ... > </activity> ... </application> </manifest>

-en el elemento <aplication>, el atributo android:icon seala los recursos para un cono que identificar la app. -en el elemento <activity>, el atributo android:name especifica el nombre de la clase totalmente calificado de la subclase Activity y android:label especifica un string que servir de etiqueta visible al usuario.

Se pueden declarar componentes de estos modos: -<activity> : elementos para actividades. -<service> : elementos para servicios -<receiver>: elementos para broadcast receivers. -<provider>: elementos para proveedores de contenido.

Las actividades, servicios y contenedores que incluyas en tu fuente pero no declares en el manifiesto no son visibles para el sistema y no corrern. No obstante, los broadcast receivers pueden ser declarados en el manifiesto o ser creados dinamicamente en el cdigo (como objetos BroadcastReceiver) y registrados en el sistema llamando a registerReceiver().

Declarando capacidades de los componentes.

Se pueden iniciar componentes con un Intent de manera explcita nombrando el componente objetivo (usando el nombre de la clase del componente) en el intento. El verdadero poder de los intents yace en el concepto de acciones del intent, con las que simplemente se describe el tipo de accin que se quiere realizar (y opcionalmente, los datos sobre los que quieres realizarla) y permite al sistema encontrar un componente en el dispositivo que pueda realizar la accin e iniciarla. Si hay varios componentes que puedan realizar la accin descrita por el intent, el usuario seleccionar cul usar. El sistema identifica los componentes que responden a un intent, comparando el intent recibido con los intent filter provistos en el manifest de otras app en el dispositivo. Cuando declaras un componente en el manifiesto de tu app, puedes, opcionalmente, incluir intent filters que declaran las capacidades del componente para respoder a intents deotras aplicaciones. Puedes declarar un intent filter para tu componente, agregando un elemento <intent-filter> como hijo del elemento que declara los componentes. Por ejemplo, una app de email con una actividad de redactar un nuevo email puede declarar un intent filter en sus anotaciones del manifest para responder a los intents de "enviar" (para enviar un email). Una activity en tu aplicacin puede, despues, crear un intent con la accin"enviar (ACTION_SEND), el cual es relacionado

por el sistema a la activity "enviar" de la aplicacin de email y lo lanza cuando invocas el intent con startActivity().

Declarando requerimientos de aplicaciones.

Hay una variedad de dispositivos con sistema Android, y no todos ellos proveen las mismas caractersticas y capacidades. Para prevenir que tu app sea instalada en aparatos que no presentan las caractersticas necesarias, es importante que definas claramente un perfile para los tipos de aparatos que tu aplicacin soportar, declarando requerimientos de dispositivos y software en el archivo manifest. La mayora de estas declaraciones son slo informacin, y el sistema realmente no las lee, pero los servicios externos, como Google Play, las leen para proveer filtros a los usuarios, cuando buscan aplicaciones para sus dispositivos. -Por ejemplo, si tu aplicacin requiere una cmara y usa APIs introducidas en Android 2.1 (API Level 7), deberas declarar estos requerimientos en tu archivo manifest. De ese modo, los aparatos que no tengan cmara y tengan una versin de Android inferior a la 2.1, no pueden instalar tu app desde Google Play. No obstante, puedes tambin declarar que tu app use la cmara, pero no lo "requiere". En tal caso, tu app debe realizar un chequeo en tiempo de ejecucin para determinar si el aparato tiene una cmara, y desactivar cualquier mdulo que use la cmara si es que no est disponible.

Aqu hay algunas caractersticas importantes que deberan ser consideradas cuando diseas y desarrollas tu app:

a)Tamao y densdad de la pantalla.

Para categorizar los aparatos por su tipo de pantalla, Android define dos caractersticas para cada aparato: tamao de la pantalla(dimensiones fsicas) y densidad (densidad fsica de los pixeles-o pdi, dots per inch). Para simplificar todos los diferentes tipos de configuracin de pantalla, Android los generaliza en grupos, lo que los hace fcil de identificar. -los tamaos de pantalla son: pequeo, normal, grande y extra grande. -las densidades de pantalla son: baja, media, alta y extra alta densidad. Por defecto, tu app es compatible con todos los tamaos y densidades, porque el sistema Android realiza los ajustes apropiados al contenedir de interfaces de usuario y recursos de imgenes; no obstante, deberas crear contenedores especializados para ciertos tamaos de pantalla y proveer de imgenes especializadas para ciertas densidades, usando recursos alternativos de los contenedores, y declarando, en tu manifest, exactamente cual tamao de pantalla es el que tu app soporta (con el elemento <suportsscreens>.

b) Configuraciones de entrada. Muchos aparatos proveen diferentes mecanismos de entrada, como un teclado, un "trackball", un "five way navegation pad". Si tu app requiere un tipo particular de hw de entrada,

entonces deneras declararlo en tu manifest, usando el elemento <usesconfiguration>. Sin embargo, es raro que una aplicacin deba requerir un tipo especfico de entrada.

c) Caractersticas de dispositivo. Hay varias caractersticas de hw y sw que pueden o no existir en un dispositivo con Android, como la cmara, sensor de luz, bluetooth, una cierta versin de OpenGL o la fidelidad de la pantalla tctil. Nunca se debera asumir que una cierta caracterstica (distinta de las disponibles en la biblioteca standard de Android) est disponible en todos los aparatos con Android, por lo que deberas declarar cualquier caracterstica usada por tu app con <uses-feature>.

d) Versin de la plataforma. Los diferentes dispositivos con Android a menudo corren diferentes versiones de la plataforma Android, tales como Android 1.6 o Android 2.3. Cada versin suele incluir APIs no disponibles en las versiones previas. Para indicar qu sed de APIs est disponible, cada plataforma especifica el nivel de APIs (por ejemplo, Android 1.0 es el nivel 1 de APIs, y Android 2.3 es el nivel 9). Si usas cualquier nivel de APIs que fueron incorporadas a la plataforma despus de la versin 1.o, deberas declarar el nivel API mnimo en el cual dichas APIs fueron introducidas, usando el elemento <uses-sdk>.

Es importante declarar todos los requerimientos para tu app, pues cuando la distribuyes en Google Play, la tienda usa dichas declaraciones para filtrar qu app estarn disponibles

para qu dispositivo. As mismo, tu app debera estar disponible slo para los dispositivos que renan todos los requerimientos de tu app.

Recursos de la aplicacin.

Una app Android est compuesta de ms que slo cdigo: recursos que estn separados del cdigo fuente; imgenes, archivos de audio y cualquier cosa relacionada a la presentacin virtual de la app. Por ejemplo, debers definir animaciones, mens, estilos, colores y los contenedores de actividades de interfaz de usuario con sus archivos XML. Usar recursos de aplicacin hace fcil actualizar varias caractersticas de tu app, sin modificar el cdigo y mediante la provisin de juegos de recursos alternativos- te permite optimizar tu app de acuerdo a una variedad de configuraciones de dispositivos (como diferentes lenguajes y tamaos de pantallas). Para cada recurso que incluyes en tu proyecto Android, la herramienta de desarrollo SKD define una ID nica de tipo integer, que puedes usar para referenciar recursos del cdigo de tu app o de otros recursos definidos en el xml. Por ejemplo, si tu app contiene una imagen llamada logo.png (imgenes se guardan en el directorio /res/drawable), la herramienta SDK genera una ID para el recurso, llamada R.drawable.logo, la que puedes usar para referenciar la imagen e insertarla en tu interfaz de usuario. Uno de los aspectos ms importantes de separar los recursos del cdigo fuente, es la capacidad de proveer recursos alternativos para diferentes configuraciones de dispositivos.

Por ejemplo, al definir strings de interfaces de usuario en XML, puedes traducir dichos strings en otros lenguajes y guardarlos en arcivos separados. Luego, basado en un discriminador de lenguajes que puedes anexar al nombre del directorio del recurso (como res/values-fr para valores string en francs) y las configuracioens de idioma del usuario, el sistema Android aplica las cadenas string apropiadas para tu interfaz de usuario.

Android soporta diferentes qualifiers o discriminadores para tus recursos alternativos. El qualifier es una cadena string corta que incluyes en el nombre de los directorios de tus recursos, y est destinado a definir las configuraciones con las cuales los recursos sern usados en el dispositivo. Otro ejemplo: deberas crear, a menudo, diferentes contenedores (layouts) para tus actividades, dependiendo del tamao y orientacin de la pantalla del dispositivo. As, cuando la pantalla del aparato est en vertical, puedes querer que los botones del contenedor estn verticales; pero cuando la pantalla est horizontal, los botones debera estar alineados horizontalmente. Para cambiar el contenedor, dependiendo de la orientacin, puedes definir dos contenedores diferentes y aplicar el discriminador correcto para el directorio del nombre de cada contenedor. As, el sistema automticamente aplicar el contenedor correcto, dependiendo de la orientacin actual del aparato.