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

Autor: | Posteado en Android Sin comentarios

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

Lo primero, y más importante, es que debemos tener conocimientos previos de Java para poder programar apps para Android. Aunque también es probable programar en C y compilarlo con el NKD que nos facilita Android® Studio, lo más usual es usar Java para compilar las apps empleando el SDK.

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

Conceptos básicos para poder programar apps para Android® con Android® Studio

SDK

SDK, Programa Informático Development Kit, es el conjunto de herramientas(tools) de programación (depurador de código, bibliotecas, emuladores del sistema operativo, documentación, ejemplos, etc) que aceptan a los clientes programar apps para un sistema operativo concreto. En vuestro caso, cuando hablemos de Software-Development-Kit(SDK) nos referiremos a las herramientas(tools) que nos aceptan programar y compilar apps en Java para ser funcionales en Android.

Android SDK

NDK

El NDK, o Native Development Kit, es el conjunto de herramientas(tools) que nos aceptan 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 continuamente se debe procurar usar el Software-Development-Kit(SDK) para el desarrollo. El uso de NDK está limitado a ciertos elementos que necesitan una alta carga de CPU, por ejemplo, motores de juego, simulación de físicas o proceso de señales, entre otras.

Android NDK

Máquina virtual DALVIK /ART

Aunque Android® se programa en Java no representa que lo que ejecuta un móvil o tableta sea código Java puro, sino que antes de procesar el código requiere un “traductor” que admita al aparato 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 móvil o tableta de manera que este sea apto de procesar los datos. Por ello, cuando se recopila una aplicación en Android® se producen archivos(ordenador) .dex en lugar de los .jar y .class típicos de Java. Estos ficheros .dex contienen todo lo indispensable para que el móvil sepa interpretar el código que nosotros hemos programado inicialmente en Java.

La máquina virtual ART llegó con Android® 4.4 a los clientes 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 rapidez de arranque de las aplicaciones, disminuye 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.

Android Dalvik vs ART

Gradle

Los programas y juegos para Android® son cada vez más grandes, complejos y, en muchas ocasiones, contienen muchas configuraciones distintas (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 renovada herramienta(tool) incluida en Android® Studio, llamada Glade, con la que intentar solucionar todos estos problemas.

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

Diagrama programación Gradle

Un ejemplo de uso de Gradle sería: Tomamos un juego de construcción base donde podemos construir vuestra propia ciudad. En Navidad queremos que las casas salgan nevadas. Podemos inventar esto de dos formas diferentes: La 1.ª de ellas sería incorporando los gráficos nevados desde el 1.er 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 cree dos problemas:

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

La 2.ª forma de hacerlo es a través de Gradle. En el proyecto inicial se incorporan todos los recursos, no obstante podemos programar 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 programar esta herramienta(tool) para que, con un solo código, al compilar la aplicación, se generen dos versiones distintas incorporando u omitiendo las características de cada una de ellas.

Conceptos complementarias para poder programar apps para Android® con Android® Studio

Bloques

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

Android pone a vuestra disposición una serie de elementos a través de las cuales comunicarnos con otras partes del sistema operativo, pudiendo inventar así apps 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 apps de escritorio, a las ventanas o cuadros de diálogos de las distintas aplicaciones.

Las Activity son clases donde, mostraremos vistas “Views” para dar lugar a la interfaz del cliente 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 elaboran llamadas de unas a otras, se envían parámetros y reciben respuestas de otras actividades a término de poder funcionar todas como una única.

Broadcast Intent Receiver (Receptor de mensajes)

El Broadcast Intent Receiver es un componente que se encarga de obtener y reaccionar frente a ciertos msjes emitidos por el sistema operativo. Aunque por lo general la mayoría de estos msjes son automáticos, es probable programar msjes personales según lo que necesite inventar vuestra aplicación e inclusive enviar msjes a otras apps para que realicen determinadas tareas.

Dos ejemplos de msjes 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, no obstante al poco tiempo se desechan). Los servicios están diseñados para mantenerse en ejecución por un extenso tiempo de tiempo, sin que estos se desechen ni dependan de ninguna ocupación para funcionar.

Dos ejemplos de servicios serían:

  • Una función que conecte de forma periódica a un servidor para mirar si ha modificado la información de ellos.
  • Un reproductor de música, que admite continuar funcionando en 2.º plano, sin embargo estemos empleando otras aplicaciones.

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

Content Providers (Proveedores de contenidos)

Los Content Providers son capas de abstracción que aceptan al programador almacenar datos e información de manera que otras apps puedan entrar a ella. Estos distribuidores de contenidos funcionarían, en cierto como, como una API(Interfaz Programación Aplicaciones) para entrar a los datos de una aplicación desde otras.

Fragment (Fragmentos)

Los fragmentos se lanzaron junto a Android® 3.0 con el término de solucionar el problema de las múltiples pantallas y resoluciones y poder construir así apps 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 teléfonos una “vista sencilla” y en tabletas una “vista completa y detallada” de una aplicación, por ejemplo, una lista de correos electrónicos.

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

Intents

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

Las apps pueden efectuar ciertas acciones con estos intentos, responderlos e inclusive inventar sus propios Intents para anunciar otras actividades o comunicar al cliente de que ha pasado algo (por ejemplo, que se ha acabamiento 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(cinco) bloques anteriores.

Filtrado

Como hemos dicho, los Intents son solicitudes al planeta Android® para que se realice una acción concreta, sin embargo, debemos indicar que una Activity es apto de contestar a una acción concreta. Aquí es donde entran los filtros.

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

Ciclo de vida

Todos los elementos de las apps de Android® tienen unos ciclos de vida que dependen del estado en el que se encuentren en cada momento, desde que se desarrolla y se ocupan los recursos del aparato hasta que se destruye y se librean dichos recursos.

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

  • Activa: Cuando la aplicación se descubre la 1.ª en la pila de ejecución y el cliente la ve en pantalla y puede interactuar con ella.
  • Pausada: Cuando la aplicación deja de estar 1.ª en la pila de ejecución, pasa a 2.º plano, no obstante aún es visible para el cliente (la renovada aplicación no la tapa por completo) y esta continua en ejecución. Si el sistema requiere recursos puede “destruir” una aplicación pausada.
  • Parada: La aplicación pasa a 2.º plano y esta está tapada por completo por la renovada actividad. Si el sistema requiere recursos puede “destruir” la aplicación.
  • Destruida: La ocupación 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 mirar un simple diagrama:

Ciclo de Vida en Android

Mientras las apps están paradas o pausadas continuan en ejecución, no obstante en 2.º plano. En cualquier instante se puede recuperar la ocupación en cuestión, sin embargo también pueden ser destruidas por el sistema en caso de que sea necesario. Si se finaliza una aplicación en 2.º plano y volvemos a llamarla esta se abrirá de nuevo, y habrá perdido toda la información volátil no guardada.

Si vuestra aplicación maneja información importante de deben aplicar dispositivos 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 cliente 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 inventar 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 ocupación que se ha parado previamente requiere 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 2.º 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 ocupación va a ser llevada a 1.er plano y se va a dibujar una ocupación por encima de la actual. Tras un onPause() se puede ejecutar un onResume() si la renovada ocupación no tapa por completo la reciente o un onStop() si la renovada ocupación tapa por completo la anterior.
  • onResume(): se ejecuta justo antes de que el cliente pueda volver a interactuar con una ocupación pausada.
  • onStop(): se ejecuta cuando una aplicación ha pasado a 2.º plano y una renovada ocupación ha tapado por completo la ya existente. Tras esta llamada solo pueden preceder onRestart() para reiniciar la ocupación de renovado 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 abandonar libres los recursos que ocupa y finalizar su actividad.

Si teneis alguna duda, pásate por el Foro de MovilZona donde hemos inventado un post(artículo) para las consultas al respecto de este tema.

Enlaces

El capítulo Curso de Desarrollo Android. Tema 4: Conceptos básicos a tener en cuenta para empezar a construir en Android se publicó en MovilZona.

MovilZona


Fuente del contenido original se encuentra más arriba (enlace), respetando todos los derechos de autor.

La prensa de Core i7

También puedes revisar estas noticias relacionadas.

Agrega tu comentario