Introduccion a Android

PROGRAMACIN DE APLICACIONES MVILES EN ANDROID

Unidad 1 - Introduccin a android.

2

Unidad 1 - Introduccin a la unidad


CONTENIDO COMPONENTES DE UNA APLICACIN ......................................................................................................................3

ACTIVIDADES (O ACTIVITY) ...................................................................................................................................4

SERVICIOS (O SERVICE) .........................................................................................................................................7

RECEPTORES DE MENSAJES DE DISTRIBUCIN (O BROADCAST RECEIVER) .........................................................8

PROVEEDORES DE CONTENIDOS (O CONTENT PROVIDER) ..................................................................................8

INTENTS ................................................................................................................................................................8

INTENT-FILTERS ....................................................................................................................................................9

ANDROIDMANIFEST ..............................................................................................................................................9

BIBLIOGRAFA ........................................................................................................................................................ 11

3



COMPONENTES DE UNA APLICACIN Los componentes principales de una aplicacin Android, son:

Layout

Intent (Intencin)

Service (Servicio)

View (Vista)

Aplicacin Android Fragment (Fragmento)

Content provider (Proveedor de contenido)

Broadcast receiver (Receptor de anuncios)

Figura 1.Componentes de una aplicacin Android. Fuente: Adaptacin de Androidcero.

La reutilizacin de componentes es una de las caractersticas principales del diseo en Android, esto permite que dos aplicaciones totalmente diferentes utilicen el mismo componente, evitando as repetir cdigo de forma innecesaria y, por ende, ahorrando tambin espacio. Los elementos bsicos con los que se construye un proyecto Android son los componentes, existen cuatro tipos, pero las aplicaciones se componen principalmente de actividades. Toda aplicacin tendr tantas actividades como ventanas distintas, sin embargo, por si solos, los componentes no pueden hacer funcionar una aplicacin. Para ello estn los intents.

Antes de empezar, te recomendamos descargar e instalar las siguientes aplicaciones en la estacin de trabajo sobre la que vas a desarrollar tu respuesta a las actividades Tarea y Trabajo de la unidad:

1. Java Development Kit.

2. Eclipse IDE for Java Developers para la arquitectura del equipo en el que vas a trabajar.

Tutorial de instalacin: AQU

3. Android SDK.

4



Figura 2.Pila de actividades. Fuente: Androideity.

La reutilizacin de componentes es una de las caractersticas principales del diseo en Android, esto permite que dos aplicaciones totalmente diferentes utilicen el mismo componente, evitando as repetir cdigo de forma innecesaria y, por ende, ahorrando tambin espacio. Los elementos bsicos con los que se construye un proyecto Android son los componentes, existen cuatro tipos, pero las aplicaciones se componen principalmente de actividades. Toda aplicacin tendr tantas actividades como ventanas distintas, sin embargo, por si solos, los componentes no pueden hacer funcionar una aplicacin. Para ello estn los intents. Todas las actividades deben declararse en el archivo AndroidManifest.xml con el mismo nombre que lleve la clase asociada. Por ejemplo, la clase MainActivity, ser definida en el AndroidManifest con el mismo nombre.

ACTIVIDADES (O ACTIVITY) El componente principal encargado de mostrar al usuario la interfaz grfica es la actividad (o Activity), en palabras ms sencillas, y, como ya lo mencionamos anteriormente, una actividad es el equivalente a una ventana, y corresponde al medio de comunicacin entre la aplicacin y el usuario. Es necesario definir una actividad por cada interfaz del proyecto. Todos los elementos que se muestran en ella deben ser definidos en el fichero xml que llevan asociado (el fichero se guarda en ./res/layout) para poder ser tratados en la clase NombreActivity.class, que hereda de la clase Activity. Dentro del fichero xml asociado a cada actividad, se definen aspectos como ubicacin de los elementos en la pantalla (layouts), botones, textos, checkbox, label, etc.

5



Toda actividad tiene su propio ciclo de vida, durante ese ciclo la actividad pasa por diferentes estados desde que se inicia hasta que se destruye. Los 3 posibles estados de una actividad son:

Activo: la actividad adquiere este estado cuando est en ejecucin, es decir, es la tarea principal.

Pausado: cuando la actividad se est ejecutando y es visible, pero no es la tarea principal, se encuentra en estado Pausado. Cuando la actividad adquiere este estado, se debe guardar la informacin para prevenir una posible prdida de datos en caso de que el sistema quiera destruirla para liberar memoria.

Parado: la actividad se encuentra detenida, tampoco es visible para el usuario y el sistema puede liberar memoria. En caso de ser requerida nuevamente, ser reiniciada desde el principio.

Luego de comprender el ciclo de vida, debemos aprender qu mtodos son importantes en cada parte de ese ciclo. A continuacin describimos los mtodos ms relevantes de una actividad:

OnCreate (Bundle savedInstanceState): es el mtodo que crea la actividad. Recibe un parmetro de tipo Bundle, que contiene el estado anterior de la actividad, para preservar la informacin que hubiera, en caso de ser suspendida, aunque tambin puede iniciarse con un null si la informacin anterior no es necesaria o no existe.

OnRestart(): reinicia una actividad tras haber sido parada (si contina en la pila de tareas). Se inicia desde cero.

Onstart(): inmediatamente despus de onCreate(Bundle savedInstanceState), o de onRestart(), segn corresponda. Muestra al usuario la actividad. Si esta va a estar en un primer plano, el siguiente mtodo debe ser onResume(). Si por el contrario, se desarrolla por debajo, el mtodo siguiente ser onStop(). Es recomendable llamar al mtodo onRestoreInstanceState() para asegurar la informacin.

OnResume(): establece el inicio de la interactividad entre el usuario y la aplicacin. Solo se ejecuta cuando la actividad est en primer plano. Si necesita informacin previa, el mtodo onRestoreInstanceState() aportar la situacin en que estaba la actividad al llamar al onResume(). Tambin puede guardar el estado con onSaveInstanceState().

OnPause(): se ejecuta cuando una actividad va a dejar de estar en primer plano, para dar paso a otra. Guarda la informacin, para poder restaurar cuando vuelva a estar activa en el mtodo onSaveInstanceState (). Si la actividad vuelve a primer plano, el siguiente mtodo ser onResume(). En caso contrario, ser onStop ().

OnStop(): la actividad pasa a un segundo plano por un largo perodo. Como ya se ha dicho, el sistema puede liberar el espacio que ocupa, en caso de necesidad, o si la actividad lleva parada mucho tiempo.

OnDestroy(): es el mtodo final de la vida de una actividad, cuando esta ya no es necesaria, o cuando se ha llamado al mtodo finish().

6



Adems de estos siete mtodos, existen dos ms, que son de vital importancia:

OnSavedInstanceState (): guarda el estado de una actividad. Es muy til cuando se va a pausar una actividad para abrir otra.

OnRestoreInstanceState (): restaura los datos guardados en onSavedInstanceState () al reiniciar una actividad.

Figura 3.Ciclo de vida de un Activity. Fuente: Google Android.

7



SERVICIOS (O SERVICE) Los servicios (o service) son tareas no visibles, se ejecutan siempre por debajo o segundo plano. Todo servicio tiene un hilo propio, lo que permite llevar a cabo cualquier tarea, por pesada que sea. No necesita una interfaz, a no ser que se pida explcitamente, en cuyo caso la clase Service la exportara. El ciclo de vida de un servicio se inicia con el mtodo onCreate(Bundle) y se libera con el mtodo onDestroy(). Sin embargo, el desarrollo puede llevarse a cabo de dos maneras, dependiendo de cmo se lance:

Si se llama al mtodo startService() implica que el servicio ejecutar todo su ciclo vital. El siguiente mtodo tras onCreate(Bundle) ser onStartComand(Intent, int, int). Para terminar el servicio externamente, se usa stopService(), e internamente, stopSelf() o stopSelfResult(), ambos de la clase Service.

En otro caso, si el servicio se llama con bindService(), el usuario podr interactuar mediante la interfaz que exporta el servicio, y tras onCreate(Bundle) se ejecutar el mtodo onBind(Intent). En este caso, el servicio se termina llamando al mtodo onUnbind(Intent). Tambin es posible reiniciarlo con el mtodo onRebind(Intent).

Figura 4.Ciclo de vida de un Service. Fuente: Google Android.

8



RECEPTORES DE MENSAJES DE DISTRIBUCIN (O BROADCAST RECEIVER) Son los componentes encargados de reaccionar ante los eventos ocurridos en el dispositivo, ya sean generados por el sistema o por una aplicacin externa. Este componente no tiene interfaz, pero pueden lanzar una actividad por medio de un evento. La clase que defina estos componentes heredar de la clase BroadCastReceiver. Respecto a su ciclo de vida podemos mencionar que es muy corto, ya que solo estn activos mientras se ejecuta el mtodo onReceive(Context, Intent), que es equivalente al onCreate(Bundle) de otros componentes. El objeto Context nos pasa al estado actual, y el intent, nos permitir lanzar el evento.

PROVEEDORES DE CONTENIDOS (O CONTENT PROVIDER) Son los encargados de que la aplicacin pueda acceder a la informacin que necesita, siempre que se haya declarado el correspondiente provider en el archivo xml AndroidManifest, compartiendo informacin sin revelar estructura u orden interno. Implementan una interfaz, pero se comunica con ella a travs de la clase ContentResolver. Cada vez que se usa un ContentResolver, se activa un ContentProvider. Para obtener los datos necesarios, es necesario conocer la URI (identificador) del dato, los campos que tiene, y los tipos de esos campos. Con esto ya podemos llamar al mtodo ContentResolver.query().

INTENTS Son el medio de activacin de los componentes (excepto los content provider, que se activan usando ContentResolver). Contiene los datos que describen la operacin que desarrollar el componente a quien va dirigido. Se declaran en el archivo xml AndroidManifest con la etiqueta . Pueden ser explcitos o implcitos. Los implcitos no especifican el componente al que va destinado, mientras que los explcitos, s. Segn el componente, los intents se tratan de diferentes maneras:

Activity: los intents se lanzan desde el mtodo starActivity(Intent) o startActivitForResult(Intent). La informacin se extrae con el mtodo getIntent(). Los intents tienen definidas algunas acciones para las activity, es decir informan de la accin a realizar. Entre ellas, por ejemplo se encuentra ACTION_CALL que inicia una llamada.

Service: para este tipo de componentes, los intents se pasan a los mtodos startService(Intent) o bindService(Intent), dependiendo del tipo de ciclo que escojamos. La informacin ser extrada por el mtodo getIntent() en el primer caso y onBind() en el segundo. Otra posibilidad es que el servicio sea lanzado por un intent, si an no est en funcionamiento.

Broadcast Receiver: en este caso, el intent ser enviado a todos los mtodos que pueden recibir el intent: sendBroadcast(), sendOrderedBroadcast(Intent, String, BroadcastReceiver, android.os.Handler, int, String, Bundle), sendStickyBroadcast(), que lo analizarn en su mtodo onReceive(Context, Intent). Tambin tienen acciones definidas para este componente, aunque en este caso lo que hacen es informar qu causa el evento. Por ejemplo tenemos ACTION_BATTERY_LOW, que informa cuando la batera est baja, o ACTION_SCREEN_ON, cuando la pantalla se ilumina.

9



INTENT-FILTERS Utilizados nicamente por los intents implcitos. Los intent-filters definen (y delimitan) qu tipos de intent puede lanzar la actividad, o qu tipos de intent puede recibir un broadcast. Por ejemplo, para un intent que no especifica a qu actividad va dirigido, se consulta el intent filter de una de ellas, y si lo satisface, el intent usar/ lanzar esa actividad. Se definen en el archivo xml AndroidManifest con la etiqueta . La informacin que pasan los intents debe estar contenida en la definicin del intent filter para que la componente pueda ser activada (o pueda recibirlo en el caso del broadcast). Esta informacin se compone de tres campos:

Action: string que informa del tipo de accin llevada a cabo. Las acciones pueden ser dadas por la clase intent, por una API de Android o definidas por el diseador.

Data: informa del identificador (URI) del dato que se asocia a la accin y del tipo de ese dato. Es importante la coherencia, ya que si la accin requiere un dato de tipo texto, un intent con un dato de tipo imagen no podra ser lanzado.

Category: string que contiene informacin adicional sobre el tipo de componente al que va dirigido el intent. La lista de categoras est incluida en la clase intent.

ANDROIDMANIFEST Corresponde a un documento xml en el que se declaran los elementos de la aplicacin, as como sus restricciones, permisos, procesos, acceso a datos e interacciones con elementos de otras aplicaciones. Cada elemento se declara con una etiqueta nica. No debe confundirse este documento con el xml asociado a cada actividad. Los elementos grficos y distribucin de la pantalla sern definidos para cada actividad dentro de su xml, pero no en el AndroidManifest. Al implementar el AndroidManifest se deben seguir pautas para hacer ms comprensible el documento.

10



Figura 5. Ejemplo de AndroidManifest.xml. Fuente: Elaboracin propia.

El cdigo del ejemplo es generado por el SDK a partir de la informacin que se ha proporcionado al crear el proyecto. Se declara el manifiesto con la etiqueta y dentro se incluye el paquete en que se encuentra la aplicacin y la versin del cdigo. Tambin incluye la versin del sdk que usa (con la etiqueta ). A continuacin, el usuario definir la aplicacin, incluyendo todos sus componentes en la etiqueta . La declaracin de componentes puede ser desordenada, pero para un mejor manejo de este fichero, se recomienda seguir algn tipo de orden. Las actividades se declaran con la etiqueta . En ellas, lo primero es aadir el nombre de la actividad (android:name), que coincidir con el de la clase en que se define el comportamiento. Adems se pueden aadir imgenes, as como cambiar los atributos de los que se dispone. A continuacin, se declararan los intent filters asociados a la actividad, en caso de que los tenga. Los servicios se declaran con la etiqueta y aunque tienen menos atributos que las actividades, lo principal es darles un nombre y especificar si el sistema puede o no utilizarlo mediante el atributo enabled (android:enabled). Despus continan los intent filters. Los broadcast receiver utilizan y al igual que los servicios, necesitan los atributos name y enabled, as como intent filter en caso de necesitarlos. Todos los componentes anteriores declaran del mismo modo sus intent filters. Los content provider utilizan la etiqueta y son los nicos componentes en los que no se declaran intent filters, ya que no son necesarios y nuevamente el nico atributo necesario es el nombre.

11



BIBLIOGRAFA Google S.A., Android Developers, Biblioteca [en lnea]. Recuperado en enero de 2015, desde:

http://developer.android.com El Androide Libre, Blog [en lnea], Recuperado en enero de 2015, desde: http://developer.android.com Androideity - Programacin Android, Blog [en lnea]. Recuperado en enero de 2015, desde:

http://developer.android.com

Introduccion a Android

Documents

Transcript of Introduccion a Android