"android de la a a la z" -- unidad 4

Android de la A a la Z

Unidad 4 “Panorama general de funcionamiento”

1 Elaborado por: J. Ulises González Medina [email protected] Noviembre 2011 Versión 1.2

El ambiente de ejecución Las aplicaciones en Android difieren un poco de las de escritorio y de las de servidores, debido a que tienen que ver con características del ambiente de los dispositivos móviles, así como con los objetivos de Google y sus aliados en relación a la plataforma Android; de ahí que sea conveniente al diseñar e implementar una aplicación, tener presentes los siguientes aspectos: Recursos limitados Los dispositivos móviles actuales -aunque poderosos- tienen limitaciones, siendo la principal la capacidad de su batería, la cual consume energía con cada clic del reloj del procesador y/o cada vez que se refresca la memoria y/o con cada

píxel de la pantalla; además de que, al ser más limitado el tamaño de la batería, se tiene que recargar con más frecuencia, lo cual a los usuarios no les agrada. De ahí la necesidad de diseñar aplicaciones que optimen recursos que son más limitados en el caso de los dispositivos móviles.

En comparación con computadoras de escritorio o portátiles, los dispositivos móviles tienen relativamente:

Procesamiento de baja potencia Memoria RAM limitada Limitada capacidad de almacenamiento

permanente Pantallas pequeñas con baja resolución

Altos costos asociados con la transferencia de datos

Lenta tasa de transferencia de datos Vida de la batería limitada

Cada nueva generación de teléfonos mejora muchas de estas restricciones. En particular, los nuevos teléfonos han mejorado drásticamente las resoluciones de pantalla además de que las tarifas de datos se han vuelto significativamente más baratas.

Mezclas (mashups) móviles La práctica de mezclar datos e interfaces de usuario en el ámbito de las aplicaciones para Internet en el escritorio, se aplica también en los ambientes móviles Android, permitiendo crear nuevas aplicaciones con base en las existentes, lo cual permite aplicar el reúso significativamente. Aplicaciones intercambiables En Android mediante el mecanismo de Intentos (Intents), el cual es independiente de implementaciones de aplicaciones específicas, se determina lo que se requiere sin tener que especificar alguna aplicación concreta para realizarlo. Lo cual difiere de otros ambientes móviles en donde si se desea, por ejemplo, enviar un correo -al especificar está función- se tiene que invocar un cliente de correo particular.




Componentes de una aplicación

Las aplicaciones de Android constan de componentes débilmente acoplados, vinculados por un manifiesto de aplicación que describe cada componente y cómo interactúan entre ellos. Los siguientes siete componentes proporcionan los bloques de construcción para las aplicaciones:

Actividades (Activities)

Una actividad es comparable a una aplicación de escritorio y es un concepto vinculado a una interface de usuario, representada la mayoría de las veces por una o más vistas (Views). Es una pieza de código ejecutable, que se utiliza según se requiere, puede interactuar con el usuario y demandar datos o servicios de otras actividades mediante peticiones o Intentos. La mayor parte del código elaborado para Android se ejecuta en el contexto de una Actividad. En términos de desarrollo de escritorio, una actividad es equivalente a un formulario. Servicios (Services) Este componente es una pieza de código ejecutable que corre en segundo plano (background) y no requiere de una interface de usuario. Son análogos a los servicios o demonios de los sistemas operativos para PC´s.

Proveedores de contenido (Content Providers)

Los proveedores de contenido se utilizan para gestionar y compartir bases de datos de aplicación. Son el medio preferido de intercambio de datos a través de los límites de las aplicaciones. Esto significa que puedes configurar tus propios proveedores de contenidos que permitan el acceso de otras aplicaciones y hacer uso de los proveedores de contenidos creados por otras personas y con ellos acceder a los datos almacenados. Android incluyen varios proveedores de contenido nativos que presentan las bases de datos útiles, como el almacén datos de contacto.




Intentos (Intents), Broadcast receivers (Receptores de omnienvío) y Broadcast intents (Intentos de omnienvío)

Los intentos (intents) permiten expresar la intención de que algún componente ejecute una acción sobre ciertos datos. Las intenciones ofrecen un servicio de paso de mensajes que permite interconectar componentes de la misma o de distintas aplicaciones; además se utilizan para arrancar actividades de manera explícita, nombrando su clase, o de manera implícita, nombrando la acción y los datos a los que se quiere aplicar dicha acción, eligiéndose en tiempo de ejecución la actividad receptora.

Las intenciones de omnienvío (broadcast intents) se envían a múltiples destinatarios en el sistema y pueden ser procesadas por cualquier receptor de omnienvíos (broadcast receiver).

El sistema genera intenciones de omnienvío para anunciar eventos como la ’batería baja’, la llegada de una llamada de teléfono o de un SMS, entre otros.

Cualquier componente puede registrar un receptor de omnienvíos que los procese.

Notificaciones (Notifications)

Mecanismo que permite a las aplicaciones señalar “algo” a los usuarios sin interrumpir la Actividad en primer plano.

Widgets

Componentes visuales de diversas aplicaciones, mismos que podemos encontrar en la pantalla inicial.




Aplicaciones, actividades y procesos.

Las Aplicaciones Android no son iguales a las aplicaciones en los sistemas operativos tradicionales: solo hay una en primer plano que normalmente ocupa toda la pantalla, pero pueden crearse actividades semi-transparentes, flotantes o que utilizan cajas de dialogo.

Las Aplicaciones están formadas por Actividades (pantallas). Al arrancar una nueva aplicación, pasa a primer plano situando una Actividad encima de la que hubiera, formándose así una Pila de Actividades.

El botón Back (←) cierra la Actividad en primer plano y recupera la que se encuentra en la cima de la Pila (cerrando la aplicación en su caso).




El orden en que los procesos se van matando para liberar recursos se determina mediante las prioridades de las aplicaciones.




Ciclo de vida de una “Actividad”

Inicio (Starting): La actividad comienza.

Activo (Running): La Actividad está encima de la pila, es visible, tiene el foco (recibe la entrada del

usuario). Cuando otra Actividad pase a estar activa, ésta pasará a estar pausada.

Pausado (Paused): La Actividad es visible pero no tiene el foco. Se alcanza este estado cuando pasa a activa otra Actividad transparente o que no ocupa toda la pantalla. Cuando una Actividad es tapada por completo pasa a estar parada.

Parado (Stopped): Cuando la Actividad no es visible. Permanece en memoria reteniendo su estado.

Cuando una actividad entra en parada puede ser bueno que salve todos sus datos y el estado de la Interfaz de usuario.

Destruido (Destroyed): Cuando la Actividad termina, o es matada por el runtime de Android. Sale

de la Pila de Actividades. Necesita ser reiniciada para volver a estar activa.

Métodos de transición en una “Actividad”

onCreate(Bundle): Se invoca cuando la Actividad se arranca por primera vez. Se utiliza para tareas de inicialización a realizar una sola vez, como crear la interfaz de usuario de la Actividad. Su parámetro es NULL o información de estado guardada previamente por onSaveInstanceState().




onStart(): Se invoca cuando la Actividad va a ser mostrada al usuario.

onResume(): Se invoca cuando la Actividad va a empezar a interactuar con el usuario.

onPause(): Se invoca cuando la actividad va a pasar al fondo porque otra actividad ha sido lanzada

para ponerse delante. Se utiliza para guardar el estado persistente de la Actividad.

onStop(): Se invoca cuando la actividad va a dejar de ser visible y no se necesitará durante un tiempo. Si hay escasez de recursos en el sistema, este método podría no llegar a ser invocado y la Actividad ser destruida directamente.

onRestart(): Se invoca cuando la Actividad va a salir del estado de parada para volver a estar activa.

onDestroy(): Se invoca cuando la Actividad va a ser destruida. Si hay escasez de recursos en el sistema, este método podría no llegar a ser invocado y la Actividad ser destruida directamente.

onSaveInstanceState(Bundle): Se invoca para permitir a la actividad guardar su estado, por ejemplo la posición del cursor en una caja de texto. Normalmente no necesita ser redefinido porque la implementación de la clase Activity ya guarda todo el estado de todos los componentes de la Interfaz de Usuario.

onRestoreInstanceState(Bundle): Se invoca para recuperar el estado guardado por onSaveInstanceState(). Normalmente no necesita ser redefinido porque la implementación de la clase Activity ya recupera todo el estado de todos los componentes de la Interfaz de Usuario.

"android de la a a la z" -- unidad 4

Documents