Dispositivos Moviles Ok PDF

Dispositivos Mviles
Arquitectura del sistema operativo

https://www.youtube.com/watch?v=EB58TNteJ8s
Arquitectura general
El sistema Android es una pila de software para

dispositivos mviles el cual se encuentra
compuesto por el sistema operativo, un
middleware (software intermedio entre las
aplicaciones y el sistema operativo) y un
conjunto de aplicaciones bsicas. Android
provee una plataforma de desarrollo abierto y
ofrece a los desarrolladores la capacidad de
crear aplicaciones ricas e innovadoras, adems
permite tomar las ventajas que ofrece el
hardware del dispositivo para mejorar las
aplicaciones. Como desarrolladores se tiene
total acceso a las APIs del framework, ya que la
arquitectura en Android est diseada para
simplificar el reuso de los componentes, as
como APIs para el control de los dispositivos
para conectividad, sensores, etc.
Principales caractersticas de cada
capa de la arquitectura
Kernel de Linux. Primer capa de la arquitectura, el
ncleo del sistema operativo Android est basado en
la versin 2.6 del kernel de Linux, similar al que puede
incluir cualquier distribucin de Linux, como Ubuntu,
solo que adaptado a las caractersticas del hardware
en el que se ejecutar Android, es decir, adaptado a
dispositivos mviles.
El ncleo acta como una capa de abstraccin

entre el hardware y el resto de las capas de la
arquitectura. El desarrollador no accede directamente
a esta capa, sino que debe utilizar las bibliotecas
disponibles en capas superiores. De esta forma
tambin se evita tener que conocer las caractersticas
precisas de cada dispositivo. Por ejemplo, si se
requiere hacer uso de la cmara, el sistema operativo
se encarga de utilizar la que incluya el equipo, sea
cual sea. Para cada elemento de hardware del
dispositivo existe un controlador (driver) dentro del
kernel que permite utilizarlo desde el software.
Libraries (Bibliotecas). La siguiente capa
que se sita justo sobre el kernel la
componen las bibliotecas nativas de
Android. Estn escritas en C o C++ y
compiladas para la arquitectura hardware
especfica de cada dispositivo.
Normalmente estn hechas por el
fabricante, quien tambin se encarga de
instalarlas en el dispositivo antes de ponerlo
a la venta. El objetivo de las bibliotecas es
proporcionar funcionalidad a las
aplicaciones para tareas que se repiten con Entre las bibliotecas incluidas habitualmente
frecuencia, evitando tener que codificarlas encontramos OpenGL (motor grfico), Bibliotecas
cada vez y garantizando que las tareas se multimedia (formatos de audio, imagen y
llevan a cabo de forma ms eficientes. video), Webkit (navegador), SSL (cifrado de
comunicaciones), FreeType (fuentes de
texto), SQLite (base de datos), entre otras.
Android Runtime (Entorno de ejecucin). El entorno de ejecucin de
Android no se considera una capa como tal, dado que tambin est
formado por bibliotecas. Aqu se encuentran las bibliotecas con las
funcionalidades habituales de Java, as como otras especficas de
Android.
El componente principal del entorno de ejecucin de Android es la
mquina virtual. Las aplicaciones se codifican en Java y son compiladas
en un formato especfico para que esta mquina virtual las ejecute. La
ventaja de esto es que las aplicaciones se compilan una nica vez y de
esta forma estarn listas para distribuirse con la total garanta de que
podrn ejecutarse en cualquier dispositivo Android que disponga de la
versin mnima del sistema operativo que requiera la aplicacin.
Cabe aclarar que la mquina virtual de Android es una variacin de la
mquina virtual de Java, por lo que no es compatible con el bytecode
Java. Java se usa nicamente como lenguaje de programacin, y los
ejecutables que se generan con el SDK de Android tienen la extensin
.dex que es especfico para la mquina virtual de Android, y por ello no
podemos correr aplicaciones Java en Android ni viceversa.
Application Framework (Marco de
aplicaciones). Esta formada por todas las
clases y servicios que utilizan directamente las
aplicaciones para realizar sus funciones. La
mayora de los componentes de esta capa son
bibliotecas Java que acceden a los recursos de
las capas anteriores a travs de la mquina
virtual.
Desarrollar
Applications (Aplicaciones). En la ltima
capa se incluyen todas las aplicaciones del
dispositivo, tanto las que tienen interfaz de
usuario como las que no, las nativas
(programadas en C o C++) y las
administradas (programadas en Java), las
que vienen preinstaladas en el dispositivo y
aquellas que el usuario ha instalado.
En esta capa encontramos tambin la
aplicacin principal del sistema: Inicio
(Home) o lanzador (launcher), porque es la
que permite ejecutar otras aplicaciones
mediante una lista y mostrando diferentes
escritorios donde se pueden colocar
accesos directos a aplicaciones o incluso
widgets, que son tambin aplicaciones de
esta capa.
La mquina virtual de Android
La versin de Android 4.4.4 (Android Kit-Kat), tuvo un cambio muy importante en
la mquina de virtual del sistema operativo ya que incorpor dos versiones de la
mquina virtual; Dalvik (de manera predeterminada) y ART (como alternativa).
Hasta antes de la versin 4.4.4, la nica mquina virtual incluida en los
dispositivos que ejecutaban Android era Dalvik. Esta versin de la mquina
interprete estuvo presente en Android desde la versin 2.2 (Android Froyo) y a
partir de Android 5.0 (Android Lollipop) desaparece para darle control total a
ART.
Dalvik es una mquina virtual intrprete que ejecuta archivos en el formato Dalvik
Executable (*.dex), un formato optimizado para el almacenamiento eficiente y
ejecucin mapeable en memoria. Su objetivo fundamental es el mismo que
cualquier mquina virtual; permite que el cdigo sea compilado a un bytecode
independiente de la mquina en la que se va a ejecutar, y la mquina virtual
interpreta este bytecode a la hora de ejecutar el programa.
Dalvik est basado en el tipo de compilacin JIT (Just In Time), por lo que cada
vez que se ejecuta una aplicacin en el dispositivo, la parte del cdigo requerida
va a ser compilada a cdigo mquina en ese momento. A medida que se utilice la
aplicacin y se avance en ella el cdigo adicional va a ser compilado y almacenado
en cache para poder reutilizarlo posteriormente mientras la aplicacin este en
ejecucin.
ART, por otro lado, compila el lenguaje intermedio bytecode, en un archivo
binario dependiente del sistema. Todo el cdigo de la aplicacin ser pre-
compilado durante la instalacin de la aplicacin, es decir solo una vez,
eliminando as el retraso que se puede observar cuando una aplicacin es ejecuta
en un dispositivo con Dalvik. A este proceso de pre-compilado se le conoce como
AOT (Ahead Of Time)
Dejando de lado el potencial aumento de velocidad en la ejecucin de las
aplicaciones, el uso de ART proporciona un beneficio secundario muy importante;
como ART ejecuta cdigo mquina directamente de la aplicacin, no hace uso
extenso del CPU, como en el caso de JIT, por lo que implica menos consumo de
batera del dispositivo.
Comparacin entre las dos mquinas
virtuales de Android.
Independientemente de que versin de la mquina virtual de Android se utilice, el
uso de esta permite reducir bastante el tamao del programa buscando
informacin duplicada en las diversas clases y reutilizndola.
Lo que conocemos en Java como recolector de basura, que se encarga de
liberar el espacio en memoria de objetos que ya no utilizamos en nuestros
programas, ha sido perfeccionada en Android con el fin de mantener siempre
libre la mxima memoria posible.
De igual forma, el hecho de que Android haga un uso extenso del lenguaje XML
para definir las interfaces grficas y otros elementos, implica que estos archivos
deben ser vinculados a la hora de compilar y para que su conversin a bytecode
pueda mejorar el rendimiento de nuestras aplicaciones.
Procesos en Android
En la mayora de los escenarios, una aplicacin Android es ejecutada en su propio
proceso y con sus propios recursos. Este proceso Linux es creado para la
aplicacin cuando es ejecutada y seguir corriendo hasta que no sea necesario o
el sistema operativo reclame los recursos para otras aplicaciones.
El tiempo de vida de un proceso en Android es manejada por el sistema
operativo, basndose en las necesidades del usuario, los recursos disponibles,
etc. Si tenemos una aplicacin que est consumiendo muchos recursos y
arrancamos otra nueva aplicacin, el sistema operativo probablemente le diga a
la aplicacin que se queda en segundo plano que libere todo lo que pueda, y si es
necesario la cerrar.
En Android los recursos son normalmente muy limitados y por eso el sistema
operativo tiene ms control sobre las aplicaciones que en programas de
escritorio.
Procesos en Android
El sistema operativo puede decidir eliminar un proceso en el mismo punto,
cuando la memoria es baja y se requiere memoria por otros procesos que estn
sirviendo al usuario. Los componentes de la aplicacin que estn corriendo en el
proceso que se apag, son consecuentemente destruidos y cuando se queda
pendiente trabajo para ellos, se inicia un nuevo proceso.
Para realizar este trabajo de manera eficiente y ordenada Android utiliza un
sistema de jerarquas de importancia" en el cual categoriza cada proceso que se
inicia en base a los componentes que se ejecutan en ese proceso y el estado de
los mismos, por ejemplo, los de importancia ms baja se eliminan primero.
El sistema de jerarquas de importancia cuenta con
cinco niveles, organizndolos en orden de mayor
jerarqua a menor jerarqua seran los siguientes.
1. Proceso en primero plano (Foreground Process). Un proceso que es
requerido para lo que el usuario est haciendo actualmente, aloja una Actividad
que se muestra en primer plano en pantalla y con la cual el usuario esta
interactuando en ese momento. Por lo regular habr muy pocos procesos de este
tipo corriendo a la vez en el sistema y son aquellos que se eliminarn como ltima
opcin si la memoria se encuentra en un estado crtico que ni matando al resto de
procesos se tendrn los recursos necesarios.
2. Proceso visible (Visible Process). Es un proceso que no tiene componentes
en el primer plano (Foreground Process), pero que puede afectar lo que el
usuario ve en la pantalla. Un ejemplo puede ser la aplicacin de correo, en la cual
demos clic en algn enlace de inters lo que provoca que se ejecute el
navegador, este pasara a ser el Foreground Process dejando a la aplicacin de
correo en el concepto de Visible Process. Este tipo de procesos se cerrarn
nicamente cuando el sistema no tenga los recursos necesarios para mantener
corriendo todos los procesos que estn en primer plano.
3. Proceso de servicio (Service Process). Se trata de un proceso que est
ejecutando un servicio que se ha iniciado con el mtodostartService() y adems
no se encuentra contemplado en alguna de las categoras antes mencionadas.
Estos procesos se encargan de realizar tareas en segundo plano que
normalmente son importantes para el usuario (conexin con servidores,
actualizacin del GPS, reproductor de msica, etc.), por lo que el sistema nunca
va a liquidar un proceso de servicio a menos que sea necesario para mantener
vivos todos los procesos visible o en primer plano.
4. Proceso en segundo plano (Background Process). Un proceso que contiene
una Actividad que no es actualmente visible para el usuario y no tiene gran
importancia. Los programas que ejecut el usuario hace tiempo y no los ha vuelto
a usar, pasan a estar enBackground. Es importante que cuando una aplicacin
pase a segundo plano, el sistema libere, en la medida de lo posible, todos los
recursos que pueda para que su rendimiento sea ptimo.
5. Proceso vaco (Empty Process). Entra en esta categora un proceso que no
contiene ningn componente activo de la aplicacin, y que solo est creado para
fines de almacenamiento en cach o para mejorar el tiempo de arranque de un
componente la prxima vez que se ejecute.
Componentes de una aplicacin
https://www.youtube.com/watch?v=xi-ZOFkJ9iI
Actividades (Activities)
Una Actividad o Activity es el componente de la aplicacin que provee una ventana, la
cual puede tomar diferentes tamaos en pantalla, esta ventana es con la que los
usuarios pueden interactuar. Se puedes pensar en una Actividad como el anlogo de
una ventana en una aplicacin de escritorio.
En las Actividades recae la responsabilidad de presentar los elementos visuales y
reaccionar a las acciones del usuario. Es importante tener en cuenta que cada
Actividad es independiente de las dems por lo que no importa el nmero que se
incluyan en una aplicacin.
Cuando se crea una nueva Actividad, la Actividad anterior se detiene mediante
notificaciones llamadas Callbacks que el sistema operativo Android usa para gestionar
el ciclo de vida de cada Actividad.
Callbacks de una Actividad.

El ciclo de vida de una Actividad est compuesta por siete callbacks que permiten al sistema operativo
administrar el ciclo de vida de una Actividad, adems permiten a los desarrolladores realizar acciones al
pasar por algn punto del ciclo de vida. Las dos callbacks ms importantes que tiene una Actividad son:
onCreate( ). Es la primera en ejecutarse cuando se crea la aplicacin.
onPause( ). Se ejecuta cuando otra Actividad acaba de entrar a primer plano, o acaba de ser instanciada. La
Actividad visible se vuelve parcialmente visible.
Las otras callbacks que conforman el ciclo de vida son:
onRestart( ). Se ejecuta cuando el usuario vuelve a navegar a una Actividad, luego de haber sido ocultada por
otra Actividad.
onStart( ). Se ejecuta justo antes de que la Actividad sea visible para el usuario y pueda interactuar con ella.
onResume( ). Se ejecuta justo antes de que la Actividad comience a interactuar con el usuario.
onStop( ). Se ejecuta cuando la Actividad ya no es visible para el usuario.
onDestroy( ). Se ejecuta justo antes de destruir la Actividad.
Intenciones (Intents)
Los Intents son mensajes (llamados as y definindose como estructuras que describen de forma
abstracta una operacin a realizar o de algo que ha ocurrido). Estos mensajes permiten activar tres de
los componentes bsicos de una aplicacin: Activities, Services, y Broadcast Receivers. Existen
diferentes mecanismos para realizar la entrega de los Intents a cada tipo de componente.
Un Intent se enva como parmetro dentro del mtodo startActivity( ) startActivityForResult( ) para
lazar una actividad.
Un Intent se enva como parmetro dentro del mtodo startService( ) para iniciar un componente
servicio o entregar nuevas instrucciones a un servicio en marcha. Tambin se puede enviar como
parmetro dentro del mtodo bindService( ) para establecer una conexin entre un componente y un
servicio.
Un Intent se enva como parmetro dentro de cualquiera de los mtodos de emisin Broadcast
como; sendBroadcast( ),sendOrderedBroadcast( ) o sendStickyBroadcast( ), los cuales entregan el
Intent a cualquier receptor interesado (Broadcast Receiver).
Un Intent puede contener informacin de inters para el componente que lo recibe, por ejemplo una
accin a realizar o datos para poder realizar la accin, as como para el sistema operativo, como la
categora del componente que recibe el Intent o como ser tratada la Actividad al momento de ser
ejecutada.
Principales elementos que pueden incluirse en un Intent tenemos.
Nombre del componente. Nombre del componente que debe manejar el Intent, en formato de nombre
completo, por ejemplo: mx.com.omnius.MainActivity.
Accin (Action). Es una accin general a realizar. La clase Intent define constantes de accin que se
permiten definir (Intent.ACTION_VIEW, Intent.ACTION_CALL, Intent.ACTION_EDIT,
Intent.ACTION_MAIN, entre otras).
Datos (Data). Datos necesarios para realizar una accin o requeridos por el componente que recibe el
Intent.
Categora. Proporciona informacin adicional sobre el tipo de componente que debe manejar el Intent.
Al igual que las acciones, existen categoras definidas para poder utilizar, por ejemplo;
CATEGORY_HOME, CATEGORY_LAUNCHER.
Extras. Informacin adicional que puede incluir el Intent y es entregada al componente que lo maneja,
se caracterizan por tener un formato llave valor.
Banderas (Flags). Una bandera permite indicarle al sistema operativo como debe ser tratado un
componente al momento de ser ejecutado o despus de realizar su ejecucin, por ejemplo; como debe
ser tratada una Actividad dentro de la lista de Actividades recientes.
Tipos de Intents
Intents Explcitos. Lanzan un componente,
generalmente de la misma aplicacin, a partir
del nombre de la clase y el paquete en el que se
encuentra. Por ejemplo, si queremos mostrar
una Actividad especificaremos el nombre de
esta.
Tipos de Intents
Intents Implcitos. Permiten lanzar
componentes de otras aplicaciones. Utilizan la
accin a realizar como base para designar el
componente a lanzar. Por ejemplo, si queremos
ver una pgina web, se indica la accin y el
sistema determinar que debe lanzar un
navegador web.
Intent Filter
Para el caso especfico de los Intents implcitos, el sistema operativo debe determinar
que aplicacin o aplicaciones son las adecuadas para responder a ciertos Intents. En el
caso de que ms de una aplicacin pueda responder a la necesidad del Intent, se le
mostrara al usuario un cuadro de dialogo con el cual podr elegir que aplicacin es la
ms conveniente para l. Esta seleccin de aplicaciones se lleva a cabo mediante
los Intent Filters, los cuales son definidos dentro del archivo AndroidManifest.xml.
Para reaccionar a determinado Intent implcito un componente de la aplicacin debe
tener registrado un elemento Intent Filterdentro del archivo manifest para el evento
que se quiere pueda responder. En el caso de que el o los componentes no tengan
registrado un Intent filter nicamente podr ser llamado a travs de Intents explcitos.
Proveedores de contenido (Content Providers).

Los proveedores de contenido (Content Providers) son los encargados de administran
el acceso a los datos persistentes de una aplicacin, encapsularlos y de proveer los
mecanismos necesarios para el aseguramiento de la integridad en los datos. Los
proveedores de contenido estn destinados principalmente a ser utilizados por otras
aplicaciones.
Existe un objeto llamado ContentResolver el cual puede ser visto como el cliente que
solicita informacin y se comunica con el objeto proveedor llamado ContentProvider.
Este objeto proveedor recibe solicitudes de los clientes, realiza la accin solicitada y
devuelve los resultados, por ello se dice que un ContentProvider no tiene un ciclo de
vida ms all del ser referenciado por el ContentResolver. El proveedor de contenido
presenta los datos a aplicaciones externas como una o ms tablas de una base de
datos relacional.
Proveedores de contenido (Content

Providers).
Es importante mencionar que cada
proveedor de contenido se identifica
con una URI, la cual contiene una
cadena de texto nica para el
proveedor. Las URI de contenido se
encuentran compuestas por tres
partes importantes:
Esquema URI. Tambin conocido como
URI scheme, es el mximo atributo
esencial para especificar una URI,
algunos ejemplos son: http://, https://,
content://, file://, market://search?
Nombre simblico del proveedor.
Tambin conocido como autoridad o
authority.
El nombre que apunta a la tabla. La
ruta o path separado por una /
Servicios (Services)
Los servicios son componentes de una aplicacin que se caracterizan por no contar
con una interfaz de usuario definida, y que pueden realizar, en segundo plano y cuando
otro componente de la aplicacin lo indica, tareas de larga duracin, incluso si el
usuario decide salir o cambiar de aplicacin. Un componente tambin puede realizar la
vinculacin con un servicio (bound service) para interactuar con l, llegando a realizar
en algunas circunstancias comunicacin entre procesos (IPC). Por ejemplo, un servicio
puede manejar las operaciones de red, reproducir msica, realizar operaciones con de
entrada y salida con archivos o interactuar con un proveedor de contenido, todo desde
segundo plano, ejecutndose, de forma predeterminada, en el hilo principal de la
aplicacin.
Un servicio puede tomar dos formas no excluyentes:
Iniciado. Cuando un componente de la aplicacin (como una Actividad) inicia un servicio
llamando al mtodo startService( ), lo que resulta en una llamada al mtodo
onStartCommand( ) del servicio.
Vinculado. Cuando un competente de la aplicacin se vincula con un servicio llamando al
mtodo bindService( ), lo que resulta en una llamada al mtodo onBind( ) del servicio.
Todos los servicios deben ser declarados en el archivo AndroidManifest.xml de la
aplicacin. Para que el sistema reconozca un servicio y pueda ser utilizado, se debe
agregar el elemento <service> como elemento hijo del elemento <application> del
archivo AndroidManifest.
El elemento <service> deber
especificar, en el atributo
android:name="", el nombre
completo (incluyendo el paquete) de
la clase del servicio.
Receptores de radiodifusin (Broadcast Receiver)

Este componente responde a las notificaciones de difusin de todo el sistema como
por ejemplo que la pantalla se ha apagado, que la batera del telfono est por
terminarse o que una fotografa ha sido tomada. Las aplicaciones tambin pueden
lanzar este tipo de notificaciones, un ejemplo de ello es el aviso de que alguna
informacin ha terminado de descargarse en el dispositivo y se encuentran disponibles
para que el usuario pueda utilizarla.
Receptores de radiodifusin (Broadcast Receiver)

Los Broadcast Receivers permiten a las aplicaciones recibir Intents que se emiten por
el sistema o por otras aplicaciones, incluso cuando los otros componentes de la
aplicacin no se estn ejecutando. Un objeto BroadcastReceiver slo es vlido
mientras dure la llamada al mtodo onReceive(Context, Intent), durante el cual se
considera que es un proceso en primer plano, que es el nivel ms alto de importancia
que el sistema Android proporciona a un componente y que destruye nicamente
como ltimo recurso; cuando termina la ejecucin de ese mtodo el sistema considera
que el objeto ya no est activo y puede terminarlo. Es importante aclarar que no es
posible mostrar un dilogo o vincularse a un servicio desde dentro de un
BroadcastReceiver, si es necesario hacerlo se debe usar el API NotificationManager
para mostrar un dialogo y Context.startService( ) para enviar un comando al servicio.
Receptores de radiodifusin
(Broadcast Receiver)
Al igual que la mayora de los
componentes es requerido registrar
en el archivo AndroidManifest.xml el
Receiver al cual queremos que
nuestra subclase de
BroadcastReceiver pueda escuchar.
Fundamentos de una aplicacion
https://youtu.be/7mmTpf3G7LE
Creacin y estructura de un proyecto
Android
Para crear un nuevo proyecto en
Android Studio, una vez instalado
todo lo requerido, debemos ejecutar
el IDE y desde la pantalla principal
de bienvenida seleccionaremos la
opcin Start a new Android Studio
Project para iniciar el asistente de
creacin de nuevo proyecto.
Creacin y estructura de un proyecto
Android
Si ya se ha abierto anteriormente Android Studio es
probable que se habr directamente la ltima aplicacin
creada en vez de la pantalla de bienvenida, si este es el
caso accederemos a la creacin del nuevo proyecto
mediante el men File / New project.
El asistente de creacin de un nuevo proyecto Android

nos guiara de manera muy intuitiva por las distintas
opciones de creacin y configuracin del nuevo
proyecto.
Una vez finalizado el asistente de nuevo proyecto,

Android Studio crear toda la estructura de proyecto y
los elementos indispensables que se requieren para la
aplicacin. Si todo se ha creado adecuadamente
aparecer la pantalla principal de Android Studio con el
proyecto creado.
En la lateral izquierda de la ventana, podemos observar

todos los elementos creados inicialmente para el nuevo
proyecto, por defecto vemos la estructura del proyecto
en la vista Android, pero se tiene disponible tambin las
vistas Packages y Project.
Estructura del proyecto
A continuacin se describirn los Carpeta app/res/drawable
contenidos principales de la vista Contiene las imgenes y los elementos
Android. grficos usados por la aplicacin (con
excepcin del cono launcher de la
Carpeta app/java aplicacin). Para poder definir los
diferentes recursos dependiendo de la
resolucin y densidad de la pantalla del
En su interior se encuentran dos dispositivo, se suele dividir en varias
mdulos con el nombre del paquete subcarpetas.
principal de la aplicacin definido
durante la creacin del proyecto. Una /drawable (recursos independientes de
de los mdulos destinados a la densidad).
almacenar el cdigo fuente de la /drawable-ldpi (recursos densidad
aplicacin y otro para generar los baja)
casos de prueba necesarios para la /drawable-mdpi (recursos densidad
misma (androidTest). media)
/drawable-hdpi (recursos densidad
Inicialmente, Android Studio crea por alta)
nosotros el cdigo bsico para la /drawable-xhdpi (recursos densidad
Actividad principal de la aplicacin, por muy alta)
lo regular la primera clase creada lleva /drawable-xxhdpi (recursos densidad
el nombre de MainActivity.java sper alta)
Carpeta app/res/layout Carpeta app/res/men
Contiene los ficheros de definicin XML de las Contiene la definicin XML de los mens de la
diferentes pantallas de la interfaz grfica. Para aplicacin.
definir distintos layouts dependiendo de la
orientacin del dispositivo se puede dividir
tambin en subcarpetas: Carpeta app/res/xml (no creada por default)
/layout (destinada a recursos XML con orientacin
vertical) Contiene otros ficheros XML de datos utilizados
por la aplicacin.
/layout-land (destinada a recursos XML con
orientacin horizontal) Carpeta app/res/raw (no creada por default)
Carpeta app/res/anim app/res/animator (no Contiene recursos adicionales, normalmente en

creada por default) formato distinto a XML, que no se incluyan en el
resto de carpetas de recursos, por ejemplo .mp3,
.mp4, .txt, etc.
Contienen la definicin de las animaciones
utilizadas por la aplicacin.
Carpeta app/res/color (no creada por default)
Contiene ficheros XML de definicin de colores.

Carpeta app/res/values
Contiene otros ficheros XML de
recursos de la aplicacin, como por
ejemplo cadenas de texto
(strings.xml), estilos (styles.xml),
colores (colors.xml), arrays de
valores (arrays.xml), tamaos
(dimens.xml), etc.
archivo AndroidManifest.xml
Cada aplicacin debe tener, en su directorio raz, un archivo llamado AndroidManifest.xml. El
archivo manifiesto es el encargado de presentar informacin esencial acerca de la aplicacin al
sistema operativo, esta informacin es la que el sistema Android debe tener antes de poder
ejecutar cualquier cdigo de la aplicacin. Entre otras cosas, el AndroidManifest.xml permite
definir lo siguiente.
Nombra el paquete Java de la aplicacin. Este nombre de paquete sirve como identificador
nico para la aplicacin.
Describe los componentes de una aplicacin Actividades, Servicios, receptores de
radiodifusin y proveedores de contenido. Tambin permite nombrar a las clases que
implementan cada uno de los componentes y publica las capacidades de cada uno. Este tipo de
declaraciones permiten al sistema operativo Android conocer qu tipo de componentes
integran la aplicacin y como deben ser lanzados. Determina los procesos que utilizar la
aplicacin.
Declara los permisos que la aplicacin debe tener y que permiten acceder a partes protegidas
de la API y la interaccin con otras aplicaciones.
Definir el nivel mnimo de API en el que corre la aplicacin (opcional). Definir el nivel objetivo de
API en el que corre la aplicacin (opcional).
Este archivo manifiesto, que es un recurso del proyecto, est compuesto por una
coleccin estructurada de elementos en XML, los cuales, junto con los atributos de
cada uno de ellos sirven para proporcionarle la informacin descrita anteriormente al
sistema Android, algunos de estos elementos y sus atributos son:
<manifest>: Es el elemento raz del archivo, debe contener de manera obligatoria un
elemento <application> y especificar dentro de sus atributos un y un nombre de
paquete.
<uses-permission>: Pide un permiso que el usuario debe conceder a la aplicacin para
que esta pueda funcionar adecuadamente. Estos permisos son otorgados por el
usuario cuando se instala la aplicacin y no mientras se ejecuta.
<application>: Este elemento contiene subelementos que declaran cada uno de los
componentes de la aplicacin y tiene atributos que pueden afectar a todos los
componentes. Algunos atributos como icon, label, permision y process pueden ser
modificados por cada componente de manera independiente. Otros como
debuggable, enable y description no pueden ser sobrescritos por los componentes
individuales.
<activity>: Declara una Actividad (una subclase de Activity) que implementa parte de
la interfaz de usuario de una aplicacin. Todas las actividades deben ser
representadas por un elemento <activity> dentro del archivo AndroidManifest.xml,
cualquiera que no sea declarada no podr ser vista por el sistema y nunca se
ejecutar.
<intent filter>: Especifica los tipos de Intents (intenciones), que una Activity,
Services o Broadcast Receiver puede responder. Un Intent Filter permite definir las
capacidades de un componente (lo que una Activity o Service puede hacer o un
Broadcast Receiver puede enviar) y filtra los Intents que no son significativos para el
mismo.
<action>: Permite aadir una accin a un Intent Filter. Un elemento <intent filter>
debe tener uno o ms elementos <action>. Si no contiene al menos uno, ningn
objeto Intent podr ser entregado al elemento.
<category>: Permite aadir una categora a un Intent Filter. Es una cadena de texto
que contiene informacin adicional sobre el tipo de componente que debe manejar la
intencin. Por lo regular un Intent Filter no requiere una categora.
<service>: Define un componente servicio (una subclase de Service) como uno de los
componente de la aplicacin. Recordar que los servicios no cuentan con una interfaz
de usuario definida, a diferencia de otros componentes como las Activities, y que
tiene como propsito principal realizar tareas de larga duracin en segundo plano.
Todos los servicios deben ser representados por un elemento <services> dentro del
archivo AndroidManifest.xml. Cualquier que no sea declarado no ser visible para el
sistema operativo y no podr ser ejecutado.
<receiver>: Declara un receptor de radiodifusin (una subclase de Broadcast
Receiver) como uno de los componentes de la aplicacin. Estos receptores permiten
a las aplicaciones recibir las notificaciones que emite el sistema operativo u otras
aplicaciones.
<provider>: Define un componente proveedor de contenido (una subclase de
Content Provider) que suministra el acceso estructurado a una base de datos
gestionada por la aplicacin. Todos los proveedores de contenido deben ser
registrados bajo un elemento <provider> en el archivo manifiesto, de lo contrario no
ser visible para el sistema operativo y no podr ser ejecutado.
archivo Build.gradle
Gradle es un conjunto de herramientas de construccin que realiza la gestin de
dependencias y permite generar una construccin lgica personalizada de un
proyecto. Android Studio utiliza una envoltura Gradle para la integracin plena
entre el plugin de Android y Gradle.
El plugin de Android Studio para Gradle tambin funciona independiente sin
Android Studio, esto implica que se puede llegar a realizar la construccin de
aplicaciones Android sin la necesidad de tener instalado el IDE de Android Studio,
todo esto desde una lnea de comandos.
Toda la configuracin para la generacin de un proyecto se lleva a cabo en un par
(o ms) de archivos llamados build.gradle ubicados en la seccin Gradle Script
dentro del proyecto Android. Los build.gradle son archivos escritos en texto sin
formato que utilizan las sintaxis Gradle y del plugin de Android para realizar la
configuracin de los siguientes aspectos en la aplicacin.
Construccin de variantes. El sistema de construccin permite generar mltiples
archivos apk con diferentes productos y construir configuraciones diferentes para un
mismo mdulo. Esto es til cuando se requiere construir deferentes versiones de la
misma aplicacin sin tener que crear proyectos o mdulos por separado para cada
versin.
Dependencias. El sistema de construccin maneja las dependencias del proyecto y

brinda soporte a las dependencias del sistema de archivos local y repositorios
remotos. Esto evita tener que buscar, desplegar y copiar los paquetes binarios para
cada una de las dependencias en el directorio del proyecto.
Entradas para el archivo AndroidManifest.xml. El sistema de construccin tambin

permite especificar valores de entrada para algunos elementos del archivo manifiesto
de la aplicacin. Estos valores de construccin anulan los definidos en el archivo
AndroidManifest. Esto es til si desea generar mltiples archivos apk para los
mdulos, donde cada uno de los archivos apk tiene un nombre diferente de
aplicacin, versin mnima del SDK (minSdkVersion), o versin objetivo del SDK
(targetSdkVersion).
Firmar la aplicacin. El sistema de construccin permite especificar la
configuracin para realizar el procedimiento y despliegue de la aplicacin. Esto
para firmar la aplicacin durante el proceso de construccin.
Pruebas. Para la mayora de las plantillas existentes en Android Studio, el sistema

de construccin crea un directorio de prueba, llamado androidTest y genera un
apk prueba con los archivos de prueba en el proyecto, evitando as tener que
crear un proyecto de prueba independiente. El sistema de construccin tambin
puede ejecutar las pruebas durante el proceso de construccin.
Archivo Proyect Build
Se trata de uno de los archivos
generados por Gradle para la
configuracin del proyecto. Se
caracteriza por tener incluido el
nombre del proyecto en su nombre.
Por defecto el archivo Gradle a nivel
de proyecto,
build.gradle(proyect:nombreAplicaci
n), utiliza buildScript para definir
los repositorios y las dependencias
Gradle. Esto permite que los
diferentes repositorios a utilizar
puedan hacer uso de versiones
diferentes de Gradle.
Archivo Module Build
Este archivo build.gradle para el mdulo de la aplicacin, permite realizar ajustes
al mdulo de construccin, incluyendo las modificaciones que anularn los
parmetros por defecto que se encuentran en el archivo AndroidManifest.xml.
Tambin permite establecer opciones personalizadas de empaquetado. A
continuacin algunos parmetros que pueden ser configurados en este archivo.
Creacin y manejo de
actividades
Video Del tema
https://youtu.be/lkI24AohGpA
Creacin y manejo de actividades
Una vez creado un proyecto Android y para poder iniciar con la creacin de la
interfaz de usuario de la aplicacin, se debe tomar en cuenta que esta debe ser
diseada usando una estructura de jerarqua de vistas (views) y grupos de vistas
(viewGroup). Las vistas o views, son usualmente elementos grficos como
botones, campo de texto o etiquetas, y los viewGroup son los contenedores
invisibles que definen como las vistas son presentadas en pantalla. La clase
viewGroup es la clase base que se tiene para los layouts Manager.
Existen diferentes tipos de viewGroup con diferentes caractersticas:
Linear Layout. Permite organizar a las vistas (views) en su interior en una nica fila o
columna dependiendo de la orientacin que se establezca.
Frame Layout. Es un contenedor que dispone todos los elementos vista alineados en
el vrtice superior izquierdo del contenedor, por lo que si se aaden dos o ms
elementos estos se apilarn.
Table Layout. Alinea los elementos vista en su interior en un formato de filas y

columnas. Un aspecto a considerar es que este tipo de contenedores no tiene lmites
fronterizos en sus celdas, filas o columnas.
Grid Layout. Este contendor fue introducido a partir del API 14 de Android (Android
4.0). Se caracteriza por dividir en lneas invisibles el espacio, estas lneas forman una
cuadrcula que permiten la definicin de filas y columnas. Los elementos view en su
interior pueden ocupar una o varias celdas de manera horizontal o vertical.
Existen diferentes tipos de viewGroup con diferentes caractersticas:
Absolute Layout. Se encuentra obsoleto desde la versin de API 3 de Android. Permite
organizar a las vistas en su interior por posiciones en coordenadas especificas X y Y.
Relative Layout. Es quiz el ms potente de todos los viewGroup, su flexibilidad se basa en

permitir posicionar a los elementos vista en relacin a otros elementos vista y a su propio
contenedor.
ListView. Un viewGroup que permite mostrar los elementos en una lista vertical con una barra
de desplazamiento.
GridView. Permite mostrar los elementos en una tabla bidimensional con barra de
desplazamiento.
TabLayout. Permite crear una interfaz de usuario con pestaas, las cuales pueden contener
views dentro de una sola Actividad o usar pestaas para cambiar entre diferentes Actividades.
Este diseo de jerarquas puede ser construido desde cdigo, el cual en tiempo
de ejecucin se convierte en elementos grficos, o definiendo los elementos en
archivos XML. Creando archivos XML se tiene la ventaja de poder tener diferentes
versiones de interfaz para usarlas en dispositivos con caractersticas diferentes,
por ejemplo en pantallas pequeas o grandes.
Si se desea construir el diseo de interfaz por cdigo se deben definir las
propiedades llamando a los mtodos correspondientes para crear, en tiempo de
ejecucin, la interfaz de usuario de manera adecuada.
Cabe recalcar que todos los archivos XML para crear las interfaces de usuario
deben encontrarse en la carpeta res/layout del proyecto.
Uso de recursos en una aplicacin
Al ejecutar una aplicacin, independientemente si se realiza en un emulador de
Android o en un dispositivo fsico, los archivos que la aplicacin usa, aparte de los
archivos de cdigo fuente, son manejados como recursos dedicados para la
aplicacin, para el buen funcionamiento de la aplicacin estos deben ser
agrupados en directorios de recursos bajo la carpeta res/ del proyecto con un
nombre especial. El sistema Android usa automticamente el recurso basado en
la configuracin del dispositivo por lo que el desarrollador no debe preocuparse
por definir que elemento utilizar en cada situacin que se presente.
Algunos de los tipos de recursos que se tienen disponibles son:
Recursos de animacin. Permite definir animaciones predeterminadas, las animaciones de tipo
Tween son almacenas en el directorio res/anim o res/animator; las animaciones de tipo Frame
son guardadas en el directorio res/drawable.
Recursos de colores. Definen un recurso de color que cambia segn el estado del componente
View. Guardados en res/color/y su acceso desde cdigo es a travs de la clase R.color.
Recursos dibujables. Definen imgenes de mapa de bits (.png, .jpg o .gif) o en archivos XML tipo
"bitmap". Guardados enres/drawable/ y accedidos desde cdigo por la clase R.drawable.
Recursos layout. Definen la disposicin (layout) de la interfaz de usuario. Guardados

en res/layout/ y accedidos desde cdigo por la clase R.layout.
Recursos de men. Definen los contenidos men de la aplicacin. Guardados en res/menu/ y

accedidos desde cdigo por la clase R.menu.
Algunos de los tipos de recursos que se tienen disponibles son:
Recursos de cadenas de texto. Definen cadenas de texto, arreglos de cadenas de

texto y "plurales" (opciones para reglas de concordancia gramatical con la cantidad) y
pueden incluir formato y estilo de cadenas de texto. Guardados en res/values/ y
accedidos desde cdigo por las clases R.string, R.array y R.plurals.
Recursos de estilo. Definen el aspecto y el formato de los elementos de la interfaz de

usuario. Guardados en res/values y accedidos por la clase R.style desde cdigo.
Recursos de datos en bruto (raw). Contiene archivos que son guardados en su forma
original (raw) y que se necesitan leer mediante flujos de datos (manejados por
objetos Stream como InputStream), como archivos de audio o video. Almacenados
en res/raw y accedidos desde cdigo por la clase R.raw.
Seguridad y permisos
Para proteger algunos recursos y caractersticas especiales del dispositivo,
Android define un esquema de permisos explcitos. Toda aplicacin que dese
acceder a un recurso crtico del sistema est obligada a definir la intencin de
usarla. En el caso de que una aplicacin intente acceder a un recurso del que no
ha solicitado permiso, se genera una excepcin de permisos y la aplicacin es
interrumpida inmediatamente.
Los permisos de una aplicacin son definidos en el archivo AndroidManifest.xml,
como se coment en captulos anteriores, y autorizados por el usuarios cuando
instala la aplicacin. El esquema de permisos de Android impide que se realiza
una concesin parcial de permisos, por lo que si un permiso no es concedido por
el usuario la aplicacin no se instalar en el dispositivo. A continuacin se
mencionan algunos de los permisos ms importantes y el nivel de riesgo en el que
se clasifica.
Nombre del permiso Descripcin Nivel de riesgo
CALL_PHONE Llamar a nmeros telefnicos Muy alto
directamente sin la intervencin
del usuario. Implica servicios
por los que se tiene que pagar.
INTERNET Permite establecer conexiones Muy alto
a Internet. Es quiz el permiso
ms importante.
READ_PHONE_STATE Leer el estado del dispositivo y Muy alto
su ID. Permite el acceso al
nmero telefnico, nmero
IMEI, identificador SIM, nmero
de identificacin nico de
Google, el nmero de una
llamada entrante entre otros
datos
SEND_SMS Enviar mensajes de texto Muy alto
(SMS) sin intervencin del
usuario. Implica servicios por
los que se tiene que pagar
RECEIVE_SMS Permite identificar cuando un Alto
mensaje de texto (SMS) ha
llegado, as como leer su
contenido, modificar o borrar el
mensaje
CAMERA Permite el acceso a la(s) Moderado
cmara(s) y tomar fotos y
video. El usuario puede o no
intervenir al realizar la accin.
RECORD_AUDIO Permite grabar sonidos desde Moderado
el dispositivo. El usuario puede
o no intervenir en la accin.
READ_CONTACTS Permite leer la informacin de Moderado
los contactos almacenados.
WAKE_LOCK Impide que el telfono entre en Bajo
modo suspensin
Uso de los mensajes Log
Android proporciona una API para el envo de mensajes a la consola de
depuracin de Android Studio, comnmente son conocidos como mensajes Logs.
Generalmente se usan los mtodos: Log.v() Log.d() Log.i() Log.w() y Log.e(), la
letra despus de "Log." indica el nivel de detalle que se desea usar: VERBOSE,
DEBUG, INFO, WARN, ERROR.
Los mtodos reciben como parmetro dos cadenas de texto; la primera permite
etiquetar el mensaje y la segunda es el contenido del mensaje
Interfaz de usuario y
controles
Interfaz de usuario y controles
https://youtu.be/lnjIIjDBRRU
Unidades y layout
Cuando se disea una aplicacin que admita diferentes densidades de pantalla, lo
NO recomendado es usar pxeles absolutos (px) para definir tamaos o
distancias, lo cual genera problemas porque cada pantalla tiene densidades de
pxeles diferentes, resultando en que el mismo nmero de pxeles absolutos (px)
corresponda a varios tamaos fsicos.
Para comprender las unidades de medicin utilizadas en Android se deben
entender los siguientes trminos :
Resolucin. El nmero total de pixeles fsicos en una pantalla.
Densidad de la pantalla. La cantidad de pixeles en un rea fsica de la pantalla,

normalmente se conoce como DPI (puntos por pulgada).
Unidades y layout
Lo que S es recomendado es usar pxeles independientes de la densidad que
tenga el dispositivo y hay dos unidades de medicin posibles:
dp: pxeles independientes de la densidad, es una unidad de pixel virtual que
escala el tamao fsico de un pxel a 160dpi (puntos por pulgada) y se utiliza para
definir los diseos de interfaz de usuario con el fin de expresar las dimensiones
del diseo o la posicin de una manera independiente de la densidad.
sp: igual que el anterior pero escalada en funcin del tamao de la letra
configurado por el usuario, usado para tamao de letra.
Unidades y layout
Ejemplo de aplicacin sin soporte para diferentes densidades (px), como se muestra en baja, media
y pantallas de alta densidad.
Ejemplo de aplicacin con un buen soporte para diferentes densidades (es independiente de la
densidad ), como se muestra en baja, media y pantallas de alta densidad.
Objetos Widgets.
TextView
Control que se utiliza como medio de salida, es decir, para mostrar un
determinado texto al usuario. Tambin es posible cambiar el texto a mostrar.
Para agregar un TextView desde el editor grfico del layout, se arrastra alguno de
los tipos del objeto TextView, localizados en la paleta de componentes del panel
Widgets, lo que aade un elemento <TextView> al archivo XML Layout.
Objetos Widgets.
TextView
Este control y las dems vistas cuenta con diferentes atributos dentro de las principales se encuentran:
android:text. Texto del control a mostrar.
android:id. ID (Identificador) del control , con el que se identificar de forma nica en el cdigo con findViewById().
android:layout_width y android:layout_height. Especifica el ancho y la altura de la vista con respecto al layout que
lo contiene. Estos valores pueden ser, una dimensin por ejemplo "12dip", o una de las constantes especiales de
ajuste; match_parent, constante especial para la altura o el ancho de una vista. La vista debe ser tan grande
como su padre menos el relleno (padding), wrap_content, constante especial para la altura o el ancho de una
vista. La vista debe ser lo suficientemente grande como para incluir su contenido adems del relleno (padding).
android:layout_margin. Propiedad que indica el espacio entre el control y su padre Layout.
android:padding. Indica el espacio entre Texto o Imgenes que pongamos dentro del control y el propio control.
android:gravity. Gravedad del control, permite poner una alienacin.
android:TextSize. Se indica un tamao en sp , si no ponemos esto, se selecciona un tamao por defecto estndar.
android:backgroud. Con esta propiedad se define el color de fondo del control.
android:textColor. Color del texto.
android:typeface. Estilo del texto, negrita, cursiva, etc.
Objetos Widgets.
EditText
Los controles de entrada de texto le
permiten al usuario escribir texto
mediante un teclado flotante en
pantalla, el cual aparece cuando el
usuario "toca" el control. El campo de
texto puede ser de una o varias lneas
y, adicionalmente, permite otras
acciones, como seleccionar texto,
copiarlo o pegarlo y autocompletado
de texto.
Para agregar un campo de texto,
desde el editor grfico del layout, se
arrastra alguno de los tipos del objeto
EditText, localizados en la paleta de
componentes del panel Text Fields, lo
que aade un elemento <EditText> al
archivo XML Layout.
Objetos Widgets.
EditText
Aparte de los atributos que comparte con el TextView, este control tiene
atributos exclusivos, los ms utilizados son estos dos:
android:hint. Permite poner un texto por defecto mientras el campo esta vaco.
android:inputType. Esta propiedad indica el tipo de teclado que a aparecer cuando se
pulsa sobre el campo, por ejemplo si solo se requiere introducir nmeros se indica el
valor en numrico.
Objetos Widgets.
Button
Un botn es un control que consta de un texto o cono (o ambos) el cual puede responder
a una accin o evento que se produce cuando el usuario lo toca.
Se pueden crear botones de tres maneras :
1. Con texto, utilizando la clase Button
Objetos Widgets.
Button
2. Con un cono, utilizando la clase ImageButton
Objetos Widgets.
Button
3. Con texto e cono, utilizando la clase Button con el atributo android: drawableLeft
Objetos Widgets.
Button
Para agregar un botn, desde el editor grfico del layout, se arrastra alguno de los tipos
del objeto Button o ImageButton, localizados en la paleta de componentes ampliando el
panel Widgets, los cuales agregan los elementos <Button> o <ImageButton>,
respectivamente, al archivo XML layout.
Tambin es posible modificar la propiedad background el botn, permitiendo con esto
darle un estilo ms personalizado, aadiendo ya sea un color o una imagen.
Objetos Widgets.
CheckBox
Permiten al usuario seleccionar una o ms
opciones de un conjunto y por lo general
se debe presentar cada opcin en una lista
vertical. Para cada opcin se debe crear un
elemento <CheckBox> en el layout y
registrar un clic listener, ya que cada
opcin se gestiona por separado.
Para agregar un ckeckbox, desde el editor
grfico del layout , se arrastra el objeto
localizado en la paleta de componentes
del panel Widgets.
Aparte de los atributos que comparte con
el TextView, este control tiene un atributo
adicional android:checked, que permite a
la opcin estar seleccionada, si el valor
es true y false en caso contrario .
Objetos Widgets.
Radio Button
El radiobutton permiten al usuario
seleccionar una opcin de un conjunto,
para cada opcin se debe crear un
elemento<RadioButton> en el layout. Sin
embargo , ya que los radiobuttons son
mutuamente excluyentes, se deben agrupar
dentro de un RadioGroup, al agruparlos, el
sistema asegura que slo una opcin puede
ser seleccionada a la vez.
Para agregar un radiobutton, desde el editor
grfico del layout, se arrastra el objeto
localizado en la paleta de componentes del
panel Widgets.
Aparte de los atributos que comparte con
el TextView, este control tiene un atributo
adicional android:checked, que permite a la
opcin estar seleccionada, si el valor
es true y false en caso contrario .
Objetos Widgets.
Spinners
Los Spinners proporcionan una manera rpida para

seleccionar un valor de un conjunto . Por defecto
muestra un valor seleccionado, al tocar el spinner
muestra un men desplegable con todos los dems
valores disponibles, de las cuales se puede
seleccionar uno nuevo.
Para trabajar con los Spinners es indispensable

proporcionar un adaptador de datos por medio del
mtodo setAdapter() y proveer de un listener para
poder manipular las opciones que se eligen a travs
del mtodo setOnItemSelectedListener(). Tambin
se puede definir en un recurso de cadenas las
opciones a mostrar, este recurso se indica en la
propiedad entries del spinner.
Para agregar un Spinner, desde el editor grfico del

layout, se arrastra el objeto localizado en la
paleta de componentes del panel Widgets.
Objetos Widgets.
Spinners
Aparte de los atributos bsicos, el spinner cuenta

con atributos propios los cuales son:
android:prompt: indica el texto a mostrar cuando
se muestra la lista de opciones.
android:entries. indica el nombre de un recurso
array xml que contiene los elementos a mostrar.
Para agregar los datos desde un adaptador primero

se obtiene la referencia en cdigo del spinner con
findViewById(), posteriormente se define el arreglo
de datos a mostrar y se pasa como parmetro al
adaptador, una vez definido el adaptador se agrega
al spinner con el mtodo setAdapter().
Finalmente para manipular las opciones

seleccionadas se establece un
setOnItemSelectedListener al spinner y
sobreescribiendo el callback onItemSelected()
podremos acceder al elemento que fue
seleccionado de la lista.
Objetos Widgets.
EVENTOS:
En Android, hay ms de una forma de interceptar eventos desde la interaccin del
usuario con la aplicacin, el enfoque principal es capturar los eventos especficos de
una vista (view). Y la clase View nos proporciona los medios para hacerlo, mediante
mtodos "callback" que el sistema de Android llama cuando la respectiva accin
ocurre en esa vista (view), estos mtodos estn contenidos dentro de unas
interfaces de la clase View llamadas detectores de eventos (event listeners).
Objetos Widgets.
EVENTOS: fuera del elemento, usando las teclas de
navegacin.
Estos detectores de eventos (event listeners)
contienen un solo mtodo "callback", los
cuales son: onKey(): de View.OnKeyListener. Llamado
cuando el usuario se centra en el elemento y
onClick(): de View.OnClickListener. Llamado presiona o suelta una tecla en el hardware del
cuando el usuario da click en el elemento, o dispositivo.
presiona "enter" sobre l con las teclas de
navegacin.
onTouch(): de View.OnTouchListener.
Llamado cuando el usuario realiza una accin
onLongClick(): de View.OnLongClickListener. calificada como un evento de toque,
Llamado cuando el usuario da click y sostiene incluyendo presionar, liberar, o cualquier
el click en el elemento, o presione y mantiene gesto de movimiento en la pantalla (dentro de
el "enter" con las teclas de navegacin. los lmites del elemento).
onFocusChange(): de onCreateContextMenu(): de
View.OnFocusChangeListener. Llamado View.OnCreateContextMenuListener. Llamado
cuando el usuario se desplaza sobre o cuando se est construyendo un men
contextual (resultado de un click sostenido).

Dispositivos Moviles Ok PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Dispositivos Moviles Ok PDF

Caricato da

Copyright:

Formati disponibili

Dispositivos Mviles

Arquitectura del sistema operativo

El sistema Android es una pila de software para

El ncleo acta como una capa de abstraccin

Callbacks de una Actividad.

Proveedores de contenido (Content Providers).

Proveedores de contenido (Content

Receptores de radiodifusin (Broadcast Receiver)

Receptores de radiodifusin (Broadcast Receiver)

El asistente de creacin de un nuevo proyecto Android

Una vez finalizado el asistente de nuevo proyecto,

En la lateral izquierda de la ventana, podemos observar

Carpeta app/res/anim app/res/animator (no Contiene recursos adicionales, normalmente en

Carpeta app/res/color (no creada por default)

Contiene ficheros XML de definicin de colores.

Dependencias. El sistema de construccin maneja las dependencias del proyecto y

Entradas para el archivo AndroidManifest.xml. El sistema de construccin tambin

Pruebas. Para la mayora de las plantillas existentes en Android Studio, el sistema

Table Layout. Alinea los elementos vista en su interior en un formato de filas y

Relative Layout. Es quiz el ms potente de todos los viewGroup, su flexibilidad se basa en

Recursos layout. Definen la disposicin (layout) de la interfaz de usuario. Guardados

Recursos de men. Definen los contenidos men de la aplicacin. Guardados en res/menu/ y

Recursos de cadenas de texto. Definen cadenas de texto, arreglos de cadenas de

Recursos de estilo. Definen el aspecto y el formato de los elementos de la interfaz de

Densidad de la pantalla. La cantidad de pixeles en un rea fsica de la pantalla,

Los Spinners proporcionan una manera rpida para

Para trabajar con los Spinners es indispensable

Para agregar un Spinner, desde el editor grfico del

Aparte de los atributos bsicos, el spinner cuenta

Para agregar los datos desde un adaptador primero

Finalmente para manipular las opciones

Potrebbero piacerti anche