Documente Academic
Documente Profesional
Documente Cultură
EN ANDROID
CONTENIDO
COMPONENTES DE UNA APLICACIN ......................................................................................................................3
INTENTS ................................................................................................................................................................8
INTENT-FILTERS ....................................................................................................................................................9
ANDROIDMANIFEST..............................................................................................................................................9
BIBLIOGRAFA ........................................................................................................................................................ 11
2. Eclipse IDE for Java Developers para la arquitectura del equipo en el que vas a trabajar.
Tutorial de instalacin: AQU
3. Android SDK.
Layout
View
Intent
Service
(Intencin)
(Servicio)
Aplicacin Android
Fragment
(Vista)
(Fragmento)
Content provider
Broadcast receiver
(Proveedor de contenido)
(Receptor de anuncios)
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.
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.
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:
OnRestart(): reinicia una actividad tras haber sido parada (si contina en la pila de tareas). Se inicia
desde cero.
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().
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.
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).
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 <Intent>.
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:
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.
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 <intent-filter>. 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.
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 <manifest > 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
<uses-sdk>).
A continuacin, el usuario definir la aplicacin, incluyendo todos sus componentes en la etiqueta
<application>. 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 <activity>. 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 <Service> 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 <receiver> 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
<provider> 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.
10
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
11