Curso de Desarrollo Android. Tema 4: Conceptos básicos a tener en cuenta para empezar a desarrollar en Android

Aunque muchos estamos deseando empezar ya a programar, antes de ello es recomendable aprender, o al menos tomar una primera toma de contacto con lo que serán los principales conceptos básicos a los que podemos hacer referencia durante el curso de programación.

Lo primero, y más importante, es que debemos tener conocimientos previos de Java para poder programar aplicaciones para Android. Aunque también es posible programar en C y compilarlo con el NKD que nos facilita Android Studio, lo más habitual es utilizar Java para compilar las aplicaciones utilizando el SDK.

Sin conocimientos, al menos básicos, de Java este curso puede ser bastante complicado para algunos, por lo que os recomendamos dar un repaso a algún curso de programación en este lenguaje, por ejemplo, el curso gratuito de Java que nos ofrece RedesZone.

Conceptos básicos para poder programar aplicaciones para Android con Android Studio

SDK

SDK, Software Development Kit, es el conjunto de herramientas de programación (depurador de código, bibliotecas, emuladores del sistema operativo, documentación, ejemplos, etc) que permiten a los usuarios programar aplicaciones para un sistema operativo concreto. En nuestro caso, cuando hablemos de SDK nos referiremos a las herramientas que nos permiten programar y compilar aplicaciones en Java para ser funcionales en Android.

NDK

El NDK, o Native Development Kit, es el conjunto de herramientas que nos permiten implementar en una aplicación partes de código programadas en lenguajes nativos como C o C ++. El código programado con el NDK generalmente perjudica a las aplicaciones, por lo que siempre se debe procurar utilizar el SDK para el desarrollo. El uso de NDK está limitado a ciertos elementos que requieren una alta carga de CPU, por ejemplo, motores de juego, simulación de físicas o proceso de señales, entre otras.

Máquina virtual DALVIK /ART

Aunque Android se programa en Java no significa que lo que ejecuta un smartphone o tablet sea código Java puro, sino que antes de procesar el código necesita un «traductor» que permita al dispositivo y al sistema operativo interpretar dicho código.

La máquina virtual DALVIK es la encargada de traducir el código fuente en java puro a un lenguaje comprensible por el smartphone o tablet de manera que este sea capaz de procesar los datos. Por ello, cuando se compila una aplicación en Android se generan archivos .dex en lugar de los .jar y .class típicos de Java. Estos ficheros .dex contienen todo lo necesario para que el smartphone sepa interpretar el código que nosotros hemos programado inicialmente en Java.

La máquina virtual ART llegó con Android 4.4 a los usuarios como una plataforma complementaria a la hora de traducir e interpretar las aplicaciones. Esta máquina virtual es mucho más rápida que la DALVIK y, probablemente, en poco tiempo llegue a sustituirla. Esta máquina virtual, entre otras cosas, mejora la velocidad de arranque de las aplicaciones, reduce el gasto de memoria y cada cierto tiempo limpia automáticamente todos los ficheros basura generados durante la compilación, instalación y ejecución de las aplicaciones.

Gradle

Los programas y juegos para Android son cada vez más grandes, complejos y, en muchas ocasiones, contienen varias configuraciones diferentes (con publicidad, ad-free, freemium, lite, full, con motivos navideños, etc). Mantener todos estos proyectos al mismo tiempo suele ser muy complicado, por lo que Google presentó una nueva herramienta integrada en Android Studio, llamada Glade, con la que intentar solucionar todos estos problemas.

Gradle es un sistema de código abierto que nos permite automatizar la tarea de compilación de nuestras aplicaciones en función a ciertas condiciones. Este sistema implementa un nuevo lenguaje de programación, Groovy, con el que se declara la configuración del proyecto.

Un ejemplo de uso de Gradle sería: Tomamos un juego de construcción base donde podemos construir nuestra propia ciudad. En Navidad queremos que las casas salgan nevadas. Podemos hacer esto de dos formas diferentes: La primera de ellas sería incluyendo los gráficos nevados desde el primer día y configurando la aplicación para que cuando se alcance dicha fecha los gráficos clásicos cambien por los navideños. Esto supone dos problemas:

• La aplicación será más pesada y el instalador ocupará más.
• Si cambiamos la fecha del dispositivo aparecerán también los gráficos navideños.

La segunda forma de hacerlo es a través de Gradle. En el proyecto inicial se incluyen todos los recursos, pero podemos configurar Gradle para que según la fecha que sea compile unos u otros.

Otro ejemplo de uso práctico de Gradle sería para la creación de dos aplicaciones: una de pago y una gratuita. Podemos configurar esta herramienta para que, con un solo código, al compilar la aplicación, se generen dos versiones diferentes incluyendo u omitiendo las funciones de cada una de ellas.

Conceptos adicionales para poder programar aplicaciones para Android con Android Studio

Bloques

Mientras programamos aplicaciones de escritorio, es posible comunicarnos con otras aplicaciones, servicios web y partes del sistema operativo a través de las APIs.

Android pone a nuestra disposición una serie de elementos a través de las cuales comunicarnos con otras partes del sistema operativo, pudiendo crear así aplicaciones más complejas y sencillas de utilizar. Estos elementos son:

Activity (Actividades)

Este es el bloque más común en la programación para Android. Las actividades pueden asociarse, en términos de programación de aplicaciones de escritorio, a las ventanas o cuadros de diálogos de las diferentes aplicaciones.

Las Activity son clases donde, mostraremos vistas «Views» para dar lugar a la interfaz del usuario y poder tomar el control de todos los eventos que se generen sobre ella. A cada Activity se le asigna una ventana, donde se dibujará toda la interfaz y todos los elementos necesarios.

El conjunto de Actividades forma la aplicación global, sin embargo, todas ellas se tratan como elementos independientes y se realizan llamadas de unas a otras, se envían parámetros y reciben respuestas de otras actividades a fin de poder funcionar todas como una única.

Broadcast Intent Receiver (Receptor de mensajes)

El Broadcast Intent Receiver es un componente que se encarga de recibir y reaccionar frente a ciertos mensajes emitidos por el sistema operativo. Aunque por lo general la mayoría de estos mensajes son automáticos, es posible configurar mensajes personales según lo que necesite hacer nuestra aplicación e incluso enviar mensajes a otras aplicaciones para que realicen determinadas tareas.

Dos ejemplos de mensajes Broadcast Intent Receiver son:

• Activar el GPS.
• Terminar de tomar y guardar una fotografía.

Service (Servicios)

Mientras que las actividades tienen periodos de vida limitados (se ejecutan, pero al poco tiempo se desechan). Los servicios están diseñados para mantenerse en ejecución por un largo periodo de tiempo, sin que estos se desechen ni dependan de ninguna actividad para funcionar.

Dos ejemplos de servicios serían:

• Una función que conecte de forma periódica a un servidor para ver si ha cambiado la información de ellos.
• Un reproductor de música, que permite seguir funcionando en segundo plano, aunque estemos utilizando otras aplicaciones.

Podemos cerrar sin problemas la Activity que lance un servicio, y este seguirá funcionando sin problemas en segundo plano.

Content Providers (Proveedores de contenidos)

Los Content Providers son capas de abstracción que permiten al desarrollador almacenar datos e información de manera que otras aplicaciones puedan acceder a ella. Estos proveedores de contenidos funcionarían, en cierto como, como una API para acceder a los datos de una aplicación desde otras.

Fragment (Fragmentos)

Los fragmentos se lanzaron junto a Android 3.0 con el fin de solucionar el problema de las múltiples pantallas y resoluciones y poder desarrollar así aplicaciones multi-pantalla y multi-dispositivo. Gracias a estos fragmentos vamos a poder reutilizar código muy fácilmente para mostrar información en dos resoluciones diferentes, por ejemplo, en smartphones una «vista sencilla» y en tablets una «vista completa y detallada» de una aplicación, por ejemplo, una lista de correos electrónicos.

Una Activity puede tener varios Fragments de manera que, en un smartphone, por ejemplo, se muestre un fragmento concreto y en una tablet, de mayor tamaño de pantalla, se muestre otro fragmento e incluso dos.

Intents

Los intentos, o Intents, son una serie de eventos que lanza el sistema operativo constantemente para notificar de diferentes acciones, por ejemplo, la inserción o extracción de una tarjeta micro-sd o cuando el dispositivo se está quedando sin batería.

Las aplicaciones pueden realizar ciertas acciones con estos intentos, responderlos e incluso crear sus propios Intents para lanzar otras actividades o notificar al usuario de que ha pasado algo (por ejemplo, que se ha acabado de descargar un archivo).

En resumen, los intentos son objetos de la clase Intent que contienen los datos del mensaje que se quiere transmitir. Generalmente los Intents sirven para controlar los 5 bloques anteriores.

Filtrado

Como hemos dicho, los Intents son peticiones al ecosistema Android para que se realice una acción concreta, sin embargo, debemos indicar que una Activity es capaz de responder a una acción concreta. Aquí es donde entran los filtros.

Los filtros de intentos, llamados IntentFilter, definen las peticiones Intent a las que los bloques anteriores podrán acceder.

Ciclo de vida

Todos los componentes de las aplicaciones de Android tienen unos ciclos de vida que dependen del estado en el que se encuentren en cada momento, desde que se crea y se ocupan los recursos del dispositivo hasta que se destruye y se librean dichos recursos.

En condiciones normales, una aplicación para Android tendrá los siguientes estados:

• Activa: Cuando la aplicación se encuentra la primera en la pila de ejecución y el usuario la ve en pantalla y puede interactuar con ella.
• Pausada: Cuando la aplicación deja de estar primera en la pila de ejecución, pasa a segundo plano, pero aún es visible para el usuario (la nueva aplicación no la tapa por completo) y esta sigue en ejecución. Si el sistema necesita recursos puede «destruir» una aplicación pausada.
• Parada: La aplicación pasa a segundo plano y esta está tapada por completo por la nueva actividad. Si el sistema necesita recursos puede «destruir» la aplicación.
• Destruida: La actividad ha dejado de estar disponible, se ha eliminado de memoria y se han liberado todos los recursos que ocupaba. La aplicación queda totalmente cerrada.

A continuación, podemos ver un sencillo diagrama:

Mientras las aplicaciones están paradas o pausadas siguen en ejecución, pero en segundo plano. En cualquier momento se puede recuperar la actividad en cuestión, aunque también pueden ser destruidas por el sistema en caso de que sea necesario. Si se finaliza una aplicación en segundo plano y volvemos a llamarla esta se abrirá de nuevo, y habrá perdido toda la información volátil no guardada.

Si nuestra aplicación maneja información importante de deben aplicar mecanismos de persistencia para protegerse de la función finish(), por ejemplo, volcando los datos a un fichero de texto y recuperándolos después.

Tanto Android como el usuario pueden controlar los ciclos de vida. Para ello bastará con llamar, según se necesite, a los métodos correspondientes:

• onCreate(): se llamada nada más crear la actividad. Se utiliza, generalmente, para preparar la interfaz y todos los datos necesarios para que la aplicación comience a funcionar.
• onRestart(): se llama cuando una actividad que se ha parado previamente necesita volver a estar activa, junto antes de empezar de nuevo.
• onStart(): se ejecuta justo antes de que la aplicación vaya a estar visible para el usuario. Cuando la aplicación pasa a segundo plano se llamará a onResume() si la aplicación no se tapa del todo o a onStop() si la aplicación se tapa por completo.
• onPause(): se llama cuando otra actividad va a ser llevada a primer plano y se va a dibujar una actividad por encima de la actual. Tras un onPause() se puede ejecutar un onResume() si la nueva actividad no tapa por completo la actual o un onStop() si la nueva actividad tapa por completo la anterior.
• onResume(): se ejecuta justo antes de que el usuario pueda volver a interactuar con una actividad pausada.
• onStop(): se ejecuta cuando una aplicación ha pasado a segundo plano y una nueva actividad ha tapado por completo la ya existente. Tras esta llamada solo pueden preceder onRestart() para reiniciar la actividad de nuevo o onDestroy() para destruir por completo la actividad.
• onDestroy(): se llama justo antes de destruir una actividad, cuando el sistema ejecuta la función finish() para preparar la aplicación para dejar disponibles los recursos que ocupa y finalizar su actividad.