Para terminar el mes en el Blog, quiero charlar sobre una de las cosas más fascinantes en el desarrollo de Android, que es sin duda, el diseño de las pantallas que invitarán al usuario a usar tu aplicación. Si bien, la funcionalidad no deja de ser importante, en el mundo móvil he observado el patrón constante de que los usuarios no sólo buscan que la aplicación haga lo que tenga que hacer sino que además las pantallas con las que interactúan sean llamativas, bonitas y usables.
Navegando en la web, me he encontrado con un excelente artículo titulado
“Designing for Android” de
Dan McKenzie, que me pareció muy interesante y completo y cuya traducción al español vale la pena para que más personas puedan utilizarlo como referencia. Sin más les dejo mi interpretación del artículo:
Para los diseñadores, Android es el referente a tomar en cuenta cuando se habla de diseño de aplicaciones. Por mucho que a los diseñadores les gustaría pensar que se trata de un mundo de iOS, en el que todos los usuarios utilizáramos iPhone, iPad y la App Store, nadie puede ignorar que Android tiene actualmente la mayor parte de la cuota de mercado de los smartphones y que su uso se está extendiendo hacia todo tipo de dispositivos electrónicos. En poco tiempo, la plataforma Android de Google ha crecido rápidamente y las distintas marcas la han empezado a notar.
Pero seamos realistas. Los múltiples dispositivos con Android que podemos encontrar en el mercado hacen sentir que el diseño para esta plataforma es una cuestión difícil de dominar. Sumando además que la poca documentación es difícilmente un buen punto de partida para empezar a diseñar y producir aplicaciones que luzcan realmente geniales. Navegando por la web en busca de recursos que te hablen del diseño en Android te hará darte cuenta de que sólo encontrarás contados recursos al respecto y que poco de ellos te servirán realmente como guía.
Si esto te parece un poco desalentador (y es la razón por la que no te has animado a diseñar aplicaciones para Android) te tengo una buena noticia, no estás solo. Afortunadamente, Android está comenzando a abordar los problemas de tener varios dispositivos y tamaños de pantalla, y los fabricantes de dispositivos están adoptando lentamente los estándares que eventualmente reducirán la complejidad en el tema de diseño.
Este artículo les ayudará a los diseñadores a familiarizarse con lo que necesitan saber para empezar a trabajar con Android y para entregar los resultados adecuados para el equipo de desarrollo. Los temas que vamos a cubrir son los siguientes:
- Disminuir la densidad de Android pantalla.
- Conocer los aspectos fundamentales del diseño de Android a través de patrones de diseño.
- Diseñar los requerimientos a partir de las necesidades de desarrollo.
- Qué es Android 3.x y qué hay que conocer
Smartphones con Android y tamaños de pantalla
Al comenzar cualquier proyecto de diseño digital, la comprensión del hardware como primer paso es una buena idea. Para aplicaciones de iOS, correspondería al iPhone y al iPod Touch. En Android, por su parte, esto se extiende a docenas de dispositivos y fabricantes. ¿Por dónde empezar?
La línea de tiempo de las pantallas soportadas en los dispositivos Android comienza por el T-Mobile G1, el primer dispositivo Android disponible en el mercado que tiene una pantalla HVGA de 320 x 480 píxeles.
HVGA significa “la mitad de la matriz de gráficos de video” (o VGA de medio tamaño) que es el tamaño de pantalla estándar para los smartphones de hoy en día. El iPhone 3Gs, 3G y 2G utilizan la misma configuración.
Para simplificar las cosas, Android clasifica las pantallas (tomando el cuenta la longitud de una diagonal que va desde la esquina superior izquierda a la esquina inferior derecha de la pantalla del dispositivo) en cuatro tamaños generales: pequeño, normal, grande y extra grande.
320 × 480 se considera un tamaño “normal” de pantalla en Android. Cuando hablemos de tamaño “extra grande” piensa en las pantallas de las tablets. Sin embargo, hay que tomar en cuenta que los smartphones más populares de hoy en día tienen WVGA (es decir, un VGA más grande) 800+ x 480 píxeles HD de pantalla. Por lo tanto, lo que es “normal” está cambiando rápidamente. Por ahora, vamos a tomar como referente que la mayoría de los smartphones con Android tienen pantallas grandes.
La variedad de tamaños de pantalla puede ser un reto para los diseñadores que están tratando de crear un tamaño único para todos los diseños de layout. Para resolver esto, he encontrado que el mejor enfoque consiste en diseñar un conjunto de layouts para 320 x 533 píxeles físicos y luego introducir diseños personalizados para los otros tamaños de pantalla.
Si bien esto crea más trabajo tanto para el diseñador y el desarrollador, el tamaño de pantalla más grande de los dispositivos tales como el Motorola Droid y Evo HTC puede requerir cambios en los diseños base que hagan un mejor uso de los recursos visuales del dispositivo.
¿Qué necesitas saber acerca de las densidades de pantalla?
Los tamaños de pantalla es sólo la mitad del asunto. Los desarrolladores no hacen referencia a la resolución de las pantallas, sino más bien a su densidad. Así es como Android define los términos y conceptos acerca del soporte de las pantallas en la
documentación de Android developers:
- Resolución. El número total de pixeles físicos en una pantalla.
- Densidad de la pantalla. La cantidad de pixeles en un área física de la pantalla, normalmente se conoce como DPI (puntos por pulgada).
- Pixeles independientes de la densidad (DP). Esta es una unidad de pixel virtual que se utiliza en la definición de un diseño de interfaz de usuario con el fin de expresar las dimensiones del diseño o la posición de una manera independiente de la densidad. Los pixeles independientes de la densidad equivalen a un píxel físico en una pantalla de 160 DPI, que es la densidad de referencia asumida por el sistema como la densidad “media” de la pantalla. En tiempo de ejecución, el sistema maneja de manera transparente cualquier ampliación de las unidades de DP según sea necesario, en base a la densidad real de la pantalla que se esté utilizando. La conversión de las unidades de DP a los píxeles de la pantalla es simple: los píxeles = DP * (DPI / 160). Por ejemplo, en una pantalla de 240 DPI, un DP es igual a 1,5 píxeles físicos. Utiliza siempre los DP como unidad para definir los diseños de tu interfaz de usuario para asegurarte de que se mostrará correctamente en pantallas con diferentes densidades.
Es un poco confuso, pero esto es lo que necesitas saber: Al igual que los tamaños de pantalla, Android divide a las densidades de pantalla en cuatro densidades básicas: LDPI (bajo), MDPI (medio), HDPI (alto), y XHDPI (muy alta). Esto es importante porque tendrás que entregar todos los elementos gráficos (bitmaps) en sets de diferentes densidades. Por lo menos, tendrás que entregar un set en MDPI y HDPI para cualquier aplicación Android que hagas.
Lo que esto significa es que todos los gráficos de bitmaps necesitan ser ampliados o reducidos partiendo de su tamaño base (320 x 533). Nota: hay también una forma de
parsear los archivos SVG que proporciona una forma de escalar el vector en diferentes tamaños de pantallas y densidades sin perder calidad en la imagen.
El requerimiento de los bitmaps es similar al de preparar gráficos para imprimir contra los que tenemos para la web. Si tienes experiencia en el campo de las impresiones, sabrás que una imagen de 72 PPI se verá muy pixelada y borrosa cuando son ampliadas o impresas. En lugar de ello, necesitarías rehacer la imagen a modo de vector o utilizar una foto de alta resolución y ajustar la resolución del archivo en torno a 300 PPI con el fin de imprimirla sin perder la calidad de la imagen. La densidad de la pantalla de Android funciona de manera similar, a excepción de que no estamos cambiando la resolución del archivo, sino únicamente el tamaño de la imagen. Un buen estándar a adoptar es 72 PPI.
Ahora supongamos que tomaste un icono en bitmap de 100×100 pixeles de una de tus pantallas de tu diseño base (recuerda que “la base” es un layout de 320×480). Colocando este mismo icono de 100×100 en un dispositivo con una pantalla IDPI haría que la apariencia del icono fuera grande y borrosa. Del mismo modo, colocarlo en otro dispositivo con una pantalla HDPI lo haría verse demasiado pequeño (esto se debe a que el dispositivo tiene más puntos por pulgada que la pantalla MDPI).
Para ajustar las imágenes a las diferentes densidades de pantalla de los dispositivos, necesitamos seguir una relación de escala de 3:4:6:8 entre los cuatro tamaños de densidad. Usando esto y un poco de matemáticas simples, podremos crear cuatro versiones diferentes de nuestro bitmap para poder trabajar en la aplicación:
- 75×75 para pantallas de baja densidad (x0.75);
- 100×100 para pantallas de media densidad (nuestra base);
- 150×150 para pantallas de alta densidad (x1.5);
- 200×200 para pantallas de muy alta densidad (x2.0)
Una vez de que hayas creado todos los gráficos, puedes organizarlos de la siguiente manera:
Imagen tomada del artículo original en el que se muestra la organización y nombrado sugerido de la estructura de directorios y archivos. De esta manera podemos utilizar el mismo nombre para cada uno de los archivos de cada densidad de pantalla.
Puede que te confunda un poco el uso de PPI (pixeles por pulgada) para realizar cada versión de las imágenes. Bastará con crear las imágenes bajo un estándar de 72 PPI y escalar las imágenes según sea la versión que necesites crear.
Usando patrones de diseño en Android
A menudo, los clientes preguntan si pueden usar su diseño de aplicación en iPhone para Android. Si lo que estás buscando son atajos, hacer una aplicación para los navegadores web para móviles utilizando una herramienta como
Webkit HML5 sea quizás la mejor opción para ti. Sin embargo, para crear aplicaciones nativas en Android, la respuesta es no. ¿Por qué? Porque las convenciones de las interfaces de usuario en Android son diferentes a las del iPhone.
La gran diferencia reside en la tecla “Back”, para navegar a las páginas previas. La tecla “Back” en los dispositivos Android es fija y siempre está disponible para el usuario, independientemente de la aplicación. O es una tecla física del dispositivo o se encuentra fija digitalmente en la parte inferior de la pantalla independientemente de cualquier aplicación, tal y como se aprecia en la versión Android 3.x para tablets.
La presencia de una tecla “Back” fuera de la aplicación deja espacio para otros elementos en la parte superior de la pantalla, tales como el logo, título o menú. Mientras que esta convención relacionada con la navegación difiere mucho de la de iOS, existen otras diferencias que en Android se conocen como “patrones de diseño”. De acuerdo con Android, un patrón de diseño es una “solución general a un problema recurrente”. A continuación se presentan los principales patrones de diseño de Android que se introdujeron desde la versión 2.0.
Dashboard
Este patrón resuelve el problema de tener que navegar entre las diferentes capas de una aplicación. Proporciona una plataforma de lanzamiento alternativa para aplicaciones ricas e interactivas como Facebook, Evernote y LinkedIn.
Action Bar
La barra de acciones es uno de los patrones de diseño más importantes de Android y que además lo diferencia. Su funcionamiento es muy similar a la de un banner de los sitios web, con el logo o el título generalmente a la izquierda y los elementos de navegación a la derecha. El diseño de la barra de acciones es flexible y permite que se cierren menús y se amplíen las cajas de búsqueda. Generalmente es usada como una característica global en lugar de una característica contextual.
Search Bar
Le brinda al usuario una forma sencilla de buscar por categoría y ofrece además sugerencias de búsqueda.
Quick Action
Este patrón de diseño es similar al comportamiento de los pop-ups en iOS, que le da al usuario acciones contextuales adicionales. Por ejemplo, hacer el gesto de tapping sobre una foto en una aplicación podría lanzar una barra de acción rápida que le permita al usuario compartir la foto.
Widgets
Los widgets le permiten a una aplicación mostrar notificaciones en la pantalla de inicio del usuario. A diferencia de las notificaciones push en iOS que se comportan como modal dialog temporales, los widgets permanecen en la pantalla de inicio.
Utilizar los patrones de diseño establecidos es importante para mantener la experiencia intuitiva y familiar de los usuarios. Hay que tener presente que los usuarios no quieren la misma experiencia del iPhone en su dispositivo Android. Es por ello que la compresión de los patrones de diseño es el primer paso para aprender a hablar en Android y diseñar una experiencia óptima para los usuarios. ¡Los desarrolladores también te lo agradecerán!
Acerca de las tablets con Android
En la celebración del CESS 2011, las compañías presentaron una gran variedad de tablets con Android, con diferentes tamaños de pantalla. Sin embargo, después de una rápida revisión de las más populares, podemos concluir que los dos tamaños de pantalla más importantes se centran en las medidas de 1280×800 y 800×480 pixeles físicos.
Con el lanzamiento de Android 3 Honeycomb, Google proporciona a los fabricantes de dispositivos una interfaz gráfica especialmente diseñada para tablets, dejando atrás el botón “Back” que ha sido reemplazado por un ancla de navegación y una barra de status del sistema localizada en la parte inferior de la pantalla.
Android 3.0 tiene un aspecto visual renovado, sin dejar de incorporar todos los patrones de diseño que se introdujeron desde la versión 2.0. Una de las grandes diferencias de Honeycomb es que la barra de acciones ha sido actualizada para incluir pestañas y menús desplegables.
Otra nueva característica añadida a Android 3.x es el mecanismo llamado “fragmentos”. Un fragmento es un componente auto-contenido en un layout que puede cambiar de tamaño y posición dependiendo de la orientación y el tamaño de la pantalla. Esto además aborda el problema de hacer diseños para diferentes tipos de pantalla dándole a los diseñadores y desarrolladores una manera de hacer sus componentes flexibles dependiendo de las limitantes de pantalla con las que se tope la aplicación. Así, los componentes de la pantalla pueden estirarse, apilarse, expandirse y contraerse, así como mostrarse y ocultarse.

La próxima versión de Android, llamada Ice cream sándwich, promete traer esta funcionalidad a los smartphones con Android, dándole a los diseñadores y desarrolladores la opción de construir un único layout que se ajuste a las necesidades de la aplicación. Esto podría ser un cambio de paradigma para los diseñadores y desarrolladores, que tendrán que aprender a pensar en el diseño como si fuese las piezas de un rompecabezas que puede ser ampliado o reducido para ajustarse a la pantalla de los dispositivos. En resumen, esto le permitirá al sistema operativo Android correr en cualquier dispositivo (¡con posibilidades infinitas!).
Un consejo
Trata de comprarte un teléfono o Tablet con Android y tómate el tiempo de descargar aplicaciones para explorar sus interfaces. Con el fin de diseñar para Android, tienes que sumergirte en el entorno y conocerlo a profundidad. Esto puede sonar obvio, pero es siempre sorprendente escuchar que incluso el jefe del producto no tiene un dispositivo con Android.
Conclusiones
Los invito a visitar el apartado de recursos que nos comparte el autor del
artículo original en inglés. En lo personal aprendí mucho de esta publicación porque pone sobre la mesa puntos muy importantes del desarrollo de aplicaciones móviles y que a veces se nos olvida tomar en cuenta, espero que te haya gustado la interpretación del mismo.
Publicado el 29/04/2012
Cuando empezamos a trabajar con las distintas clases en Android es común que se nos ocurra que alguna funcionalidad quedaría muy bien en la aplicación pero a veces por falta de experiencia y porque estamos empezando con el desarrollo en esta plataforma desconocemos los métodos y propiedades de cada clase lo cuál puede limitarnos si no sabemos dónde consultar esta información.
El equipo de desarrolladores de Android se preocupó por poner a nuestra disposición la información de referencia de los paquetes y clases que podemos utilizar en nuestras aplicaciones desde
el sitio oficial de Android Developers.
Antes de empezar a conocer la distribución de la API de Android, debemos tener en claro que es una API.
Una Api es un conjunto de reglas para escribir funciones o hacer llamados a subrutinas y acceder a otras funciones en una librería.
Generalmente las API’s las podemos consultar desde un sitio web y nos hará una recopilación de errores, funciones, definiciones y muchas cosas útiles para entender cómo es que funciona alguna plataforma de desarrollo.
Estructura de la documentación
Cuando nos encontremos en el sitio esta es la estructura que veremos:
- En el panel izquierdo encontraremos en la parte superior, el listado de los paquetes Android y Java que podemos utilizar en nuestras aplicaciones.
- En la parte inferior de este panel se encuentra el árbol de navegación de las clases que nos muestra el conjunto de clases e interfaces dentro del paquete que seleccionamos en el listado de paquetes.
- Y en el panel principal se desplegará toda la información de detalle de la clase o interfaz que hayamos seleccionado en el árbol de navegación.
Si por ejemplo nos vamos al paquete android.widget, en el árbol de navegación podremos ver todas las interfaces que corresponden a los listeners que manejan los eventos de los elementos de la GUI y las clases que son todos los elementos de la GUI que podemos incluir en las aplicaciones.
Encabezado de las clases
Una vez que hemos seleccionado la clase que nos interesa inspeccionar, veremos en el panel principal toda la información correspondiente. Vamos por partes.
En el encabezado de la clase veremos los siguientes elementos:
- El nombre de la clase indicando si se trata de una clase o interfaz.
- El árbol de herencia nos sirve para conocer las clases de las que podemos utilizar métodos o atributos y nos provee de los links directos hacia el detalle de cada una de ellas.
- Las subclases directas e indirectas nos sirven para conocer si podemos trabajar con clases que tal vez sean más específicas de alguna función de la que requiera la aplicación. Podemos incluso optar por ocupar alguna de ellas en lugar de la clase que nos interesaba.
- El menú de navegación contiene los links para que podamos saltarnos a secciones específicas de la documentación de la clase. Entre ellos tenemos los atributos XML heredados y con los que es válido trabajar en los layouts, la lista de métodos que podemos utilizar desde el código Java, etc. En un momento más detallaremos el contenido de cada uno de estos apartados.
Vistazo rápido de las clases
En este apartado veremos algunos links útiles como son:
- En algunos casos la misma documentación de Android Developers tendrá algún tutorial o artículo técnico que podemos visitar para ver el uso de la clase en cuestión.
- También, en esta parte, la documentación nos agrega los links directos hacia el detalle de los atributos XML que podemos utilizar, desde las clases padre de las que hereda la clase seleccionada hasta los propios de la clase.
Atributos XML
La parte principal de la documentación se encuentra en las tablas de resumen que tiene cada clase de la API. La primera tabla corresponde a los atributos XML que son válidos para crear el aspecto visual del elemento.
En esta tabla se enumeran las clases padre y la clase en cuestión para que identifiquemos los atributos que utilizamos y que se heredan de la otra clase y que aún así son válidos en el elemento actual.
Si expandimos la tabla (dando clic sobre el triángulo negro de la izquierda) veremos lo siguiente:
- El nombre del atributo tal y como se escribe en el archivo XML, ejemplo:android:autoText.
- Si estamos manipulando las interfaces directamente en el código Java, a veces nos preguntaremos cómo definir tal o cuál atributo al elemento, pues bien, la segunda columna corresponde al método en Java equivalente al atributo en XML de la izquierda. Muy útil ¿no?
- La tercera columna corresponde a la descripción del atributo, el aspecto visual o funcional que desencadenará el uso del atributo en el elemento de la aplicación.
Atributos Java heredados
La segunda tabla nos presenta los atributos que hereda la clase, los encontraremos de varios tipos y nos sirven para consultar o asignar valores muy específicos a los elementos con los que trabajamos. Esta parte tiene mucho que ver con Java, por lo que te recomiendo consultes
los tipos de atributos de este lenguaje para que tengas más clara la idea.
- La primera columna nos indicará el tipo de atributo y los modificadores de acceso del mismo.
- La segunda columna contiene el nombre del atributo.
- La tercera columna contiene la descripción del atributo, es decir, el tipo de característica que define en el elemento.
Constructores
Esta tabla nos enlista los diferentes constructores por medio de los cuáles podemos crear una instancia de la clase en nuestra aplicación. Te invito a visitar
este link para ampliar el aprendizaje de qué son y para qué sirven los constructores en Java.
La parte interesante de esta tabla reside en que si los constructores reciben como parámetros otras clases, nos coloca el link para que veamos el detalle de esas clases.
Métodos de la clase
Después nos topamos las tablas que contienen la lista de métodos públicos, protegidos (en caso de haberlos) y con otro tipo de modificador de acceso que son propios de la clase.
- En la primera columna se nos indicará el valor de retorno del método, lo cuál es útil cuando invocamos las funciones desde las aplicaciones.
- En la segunda columna encontraremos el nombre del método tal y como se escribe en el código Java, indicando los argumentos que debe recibir para que su llamado no genere error de compilación y una breve descripción de lo que hace.
Métodos heredados
Por último nos encontraremos con los métodos de las clases padre de las que hereda (en caso de que aplique). Como ves, se nos enlistan todas las clases padre con la opción de expandir la información que sigue el mismo formato que el de la tabla anterior.
Con esto terminamos, si te das cuenta la información está muy bien ordenada y nos brinda varios datos que nos facilitan la manipulación y conocimiento de los elementos con los que trabajamos en nuestras aplicaciones Android. Ahora que ya sabes la razón de ser de la documentación utilízala para ahorrarte tiempo (y quebradera de cabeza) a la hora de buscar el detalle de alguna clase, atributo y función.
Publicado el 28/04/2012
En cualquier entorno de desarrollo de software, resulta importante llevar a cabo prácticas que nos ayuden a detectar de forma temprana la existencia de cualquier bug para que al final de todo el proceso de creación, obtengamos aplicaciones más robustas y de las que podamos estar seguros que todo funciona a la perfección.
Si hablamos específicamente de aplicaciones Android podemos dividir las pruebas orientándolas a diferentes apartados en las que podemos incluir el ciclo de vida de los Activity, las operaciones con bases de datos o el sistema de ficheros y las características físicas del dispositivo.
Hay que tomar en cuenta también, que existen distintos tipos de test: unitarios, rendimiento, integración o funcionales. Todo ellos forman un conjunto completo que nos asegurarán que nuestra aplicación funciona y lo hace sin errores.
Para que los conceptos básicos de testing en Android te vayan quedando claros, el día de hoy te comparto la siguiente presentación que se encuentra disponible en slideshare. Su autor es Diego Torres y hace una completa introducción a la realización de test en Android.
De la misma forma, el mismo autor tiene un libro llamado Android Application Testing Guide dónde podemos aprender cómo hacer test en Android con Junit y desde Eclipse, descubrir cómo utilizar los distintos componentes para hacer test, trabajar con TDD en Android, diferentes recetas de test, Integración continua usando Hudson y hacer test de rendimiento de nuestra aplicación.
Una lectura muy recomendada para todo desarrollador Android. Recuerda que el testing lejos de ser un proceso tedioso e inservible, es una fase del proceso de desarrollo que debes tomar en cuenta siempre para que las aplicaciones que hagan realmente le sirvan al usuario final. Tambien, he publicado algo de informacion practica en la revista Pixels & Code , de Abril 2012, acà el link:
http://pixelscode.com/abril-2012/
Publicado el 27/04/2012
Las aplicaciones Android se construyen mediante bloques esenciales de componentes, cada uno de los cuales existe como una entidad propia y desempeña un papel específico; cada elemento es una pieza única que ayuda a definir el comportamiento general de la aplicación. Es importante mencionar que algunos de estos elementos son el punto de entrada para que los usuarios interactúen con la aplicación y en muchos casos veremos que unos elementos dependen de otros.
Hay cuatro tipos de componentes en una aplicación Android. Cada uno de ellos tiene un propósito y un ciclo de vida distinto que define cómo se crea y se destruye el componente.
Activities (actividades). Es el bloque encargado de construir la interfaz de usuario. Puedes pensar en una actividad como el análogo de una ventana en una aplicación de escritorio. En las actividades recae la responsabilidad de presentar los elementos visuales y reaccionar a las acciones del usuario.
Si bien podemos pensar en actividades que no posean una interfaz de usuario, regularmente el código en estos casos se empaqueta en forma de content providers (proveedores de contenido) y services (servicios) que detallaremos en un momento.
Toda actividad se inicia como respuesta a un Intent.
Intents (intenciones). Son los mensajes del sistema que se encuentran corriendo en el interior del dispositivo. Se encargan de notificar a las aplicaciones de varios eventos: cambios de estado en el hardware (ej. cuando se inserta unaSD al teléfono), notificaciones de datos entrantes (ej. cuando llega un SMS) y eventos en las aplicaciones (ej. cuando una actividad es lanzada desde el menú principal).
Así como podemos crear actividades que respondan a las intenciones, podemos crear también intenciones que lancen actividades o usarlas para detonar eventos ante algunas situaciones específicas (ej. que el teléfono nos notifique por medio de un mensaje cuando nuestra localización esté a 10 mts del punto de destino). Es importante mencionar que el sistema es el que elige entre las actividades disponibles en el teléfono y dará respuesta a la intención con la actividad más adecuada.
Content providers (proveedores de contenido). Este elemento ofrece un conjunto de datos almacenados en el dispositivo para que se puedan accesar y compartir por varias aplicaciones. Nosotros podemos guardar datos en archivos del sistema, en una base de datos en SQLite, en la web o en cualquier otro lugar de almacenamiento persistente a la que la aplicación pueda tener acceso. A través del proveedor de contenido, otras aplicaciones pueden consultar o incluso modificar los datos (solamente si el proveedor de contenidos de esa aplicación lo permite).
El modelo de desarrollo en Android nos invita a los desarrolladores a pensar siempre en hacer los datos de nuestras aplicaciones disponibles para otras aplicaciones. De manera que cuando creamos un proveedor de contenido, podemos tener un control completo de nuestros datos y definir la forma en que éstos serán accesados.
Un ejemplo sencillo de esto es el proveedor de contenido que tiene Android para gestionar la información de contactos (agenda) del teléfono. Cualquier aplicación con los permisos adecuados puede realizar una consulta a través de un proveedor de contenido comoContactsContract.Data para leer y escribir información sobre una persona en particular.
Services (servicios). Las actividades, las intenciones y los proveedores de contenido explicados arriba son de corta duración y pueden ser detenidos en cualquier momento. Por el contrario, los servicios están diseñados para seguir corriendo, y si es necesario, de manera independiente de cualquier actividad. El ejemplo más simple para aterrizar este concepto es el del reproductor de música, que es un servicio que puede mantenerse corriendo mientras mandamos un SMS o realizamos alguna otra función en nuestro teléfono.
Dependiendo de la fuente consultada o el autor, podrán encontrar también un elemento llamado Broadcast receivers (receptores de radiodifusión). Este componente responde a las notificaciones de difusión de todo el sistema como por ejemplo que la pantalla se ha apagado, que la batería del teléfono está por terminarse o que una fotografía ha sido tomada. Las aplicaciones también pueden lanzar este tipo de notificaciones, un ejemplo de ello es el aviso de que alguna información ha terminado de descargarse en el dispositivo y se encuentran disponibles para su utilización.
Aunque los broadcaster receivers no muestran una interfaz de usuario, pueden crear notificaciones en la barra de estado del teléfono para avisarle al usuario cuando un evento de este tipo se genera. Podemos pensar en estos elementos como el medio por el cual otros componentes pueden ser iniciados en respuesta a algún evento. Cabe mencionar que cada una de las emisiones de los broadcaster receivers se representa como una intención.
Un aspecto único y útil del diseño del sistema operativo Android es que cualquier aplicación puede hacer uso de otro componente de otra aplicación. Supongamos que la aplicación requiere que el usuario tome una fotografía con la cámara del teléfono; es probable que exista otra aplicación que haga exactamente eso, por lo que resultará más fácil reutilizar esa función que programar una específica en nuestra aplicación. Para ello no es necesario incluir o vincular el código de la aplicación de la cámara, simplemente hará falta iniciar la actividad que se encargue de capturar la foto. Una vez hecho, la foto estará disponible para usarla en la aplicación “principal”. Para el usuario parecerá que la cámara de su teléfono es una parte de la aplicación.
Debido a que el sistema Android ejecuta cada una de las aplicaciones en un proceso separado con permisos de archivos que pueden restringir el acceso a otras aplicaciones, las aplicaciones no pueden activar de forma directa un componente de otra aplicación. El único que puede hacer esto es el sistema operativo en sí. Por lo tanto, para activar un elemento de otra aplicación, debemos pasarle un mensaje al sistema dónde se especifique qué elemento es el que necesitamos correr. De esta manera el sistema activará el componente y podremos manipularlo según sea nuestra necesidad.
Todos los elementos expuestos en este post son objetos y su comportamiento está definido en su correspondiente clase base convirtiendo a cada elemento en una subclase del elemento original. Esto lo hacemos por medio de la
herencia, una característica básica de Java y de los lenguajes orientados a objetos, y que nos evitará tener que volver a implementar aspectos comunes en todos los objetos del mismo tipo, y poder al mismo tiempo, personalizar su comportamiento tanto como lo necesite nuestra aplicación por medio de la sobre escritura de los métodos de la clase padre.
Espero que este post te haya sido de utilidad, es un tema que hemos repetido varias veces, pero siempre es útil tener a mano esta información.