Desarrollo-de-la-aplicacion-movil-podcast-unamovil-para-el-sistema-operativo-Android

Vista previa del material en texto

UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
FACULTAD DE ESTUDIOS SUPERIORES 
 ARAGÓN 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 MÉXICO, 2015. 
 
T E S I S 
QUE PARA OBTENER EL TÍTULO DE: 
INGENIERO EN COMPUTACIÓN 
 
 P R E S E N T A: 
 
ROBERTO ENRIQUE GUDIÑO 
VÁZQUEZ 
 
 
 
 
 
 
 
 
 
 
ASESOR DE TESIS: 
M. EN I. ELIO VEGA MUNGUIA 
“DESARROLLO DE LA APLICACIÓN MÓVIL 
PODCAST UNAMÓVIL PARA EL SISTEMA 
OPERATIVO ANDROID” 
 
Lourdes
Texto escrito a máquina
Ciudad Nezahualcóyotl, Estado de México
 
UNAM – Dirección General de Bibliotecas 
Tesis Digitales 
Restricciones de uso 
 
DERECHOS RESERVADOS © 
PROHIBIDA SU REPRODUCCIÓN TOTAL O PARCIAL 
 
Todo el material contenido en esta tesis esta protegido por la Ley Federal 
del Derecho de Autor (LFDA) de los Estados Unidos Mexicanos (México). 
El uso de imágenes, fragmentos de videos, y demás material que sea 
objeto de protección de los derechos de autor, será exclusivamente para 
fines educativos e informativos y deberá citar la fuente donde la obtuvo 
mencionando el autor o autores. Cualquier uso distinto como el lucro, 
reproducción, edición o modificación, será perseguido y sancionado por el 
respectivo titular de los Derechos de Autor. 
 
 
 
 
UNAM – Dirección General de Bibliotecas 
Tesis Digitales 
Restricciones de uso 
 
DERECHOS RESERVADOS © 
PROHIBIDA SU REPRODUCCIÓN TOTAL O PARCIAL 
 
Todo el material contenido en esta tesis esta protegido por la Ley Federal 
del Derecho de Autor (LFDA) de los Estados Unidos Mexicanos (México). 
El uso de imágenes, fragmentos de videos, y demás material que sea 
objeto de protección de los derechos de autor, será exclusivamente para 
fines educativos e informativos y deberá citar la fuente donde la obtuvo 
mencionando el autor o autores. Cualquier uso distinto como el lucro, 
reproducción, edición o modificación, será perseguido y sancionado por el 
respectivo titular de los Derechos de Autor. 
 
 
 
1 
 
 
ÍNDICE 
 
Agradecimientos 
 
Índice de figuras 
 
Introducción 
 
1. Historia del desarrollo móvil 
1.1. ¿Qué es Android? 
1.2. ¿Por qué Android? 
1.3. Arquitectura de Android 
1.4. Componentes de una aplicación Android 
1.5. Procesos en Android 
1.6. Ciclo de vida de una aplicación Android 
1.7. Android y sus versiones 
1.8. Comparativa de Android frente a otras plataformas 
1.9. Mapa mental de Android 
 
2. Descripción del Podcast de la UNAM 
 
3. Objetivo de la aplicación Podcast UNAMóvil 
 
4. Desarrollo e Implementación 
 
5. Resultados 
 
6. Conclusiones 
6.1. Prospectiva a futuro 
Apéndice A. Diagrama UML de la aplicación Podcast UNAMóvil 
 
Apéndice B. Instalación y configuración de Eclipse y del SDK de Android 
 
Bibliografía 
A) Obras Citadas 
B) Referencias electrónicas 
 
 
 
 
 
 
 
 
 
2 
 
 
 
 
 
AGRADECIMIENTOS 
 
Primero y antes que nada doy gracias a Dios y le dedico éste trabajo ya que 
él es el que me ha dado la fuerza para la conclusión de éste proyecto y para 
dar lo mejor de mi todos los días, sé que él siempre está conmigo. 
 
Doy gracias a mis padres, a mi hermano y a mi sobrino por estar siempre a 
mi lado apoyándome en cada momento y en cada circunstancia siempre 
dándome los mejores consejos y alicientes. Agradezco también a mi prima 
Lilia, a mi primo Víctor y toda su familia por recibir siempre también su gran 
apoyo y compartir su preocupación por mi bienestar. También agradezco a 
Rosita García por todo su apoyo y por darme la fortaleza mental que he 
necesitado. Agradezco también a mi tía Teresa por todo su apoyo, a mi tía 
Alicia, a mi prima Mónica, a mi tía Eréndira y a mi tío Rodolfo por apoyarme 
desde mis primeros estudios y también a mi tío Francisco Vázquez por su 
apoyo. 
 
Agradezco a mi asesor, el profesor Elio Vega Munguía por su infinito apoyo, 
su guía, su paciencia, su experiencia y sabiduría para llevar a cabo y darle 
solidez a éste proyecto. De igual manera agradezco totalmente el apoyo de 
Karlita, Willie y Fabián, encargados del Podcast de la UNAM durante el 
servicio social, durante el desarrollo de éste proyecto y por brindarme toda 
la información para el desarrollo del mismo. Agradezco también todo el 
apoyo de Janet como diseñadora gráfica. Agradezco también infinitamente el 
apoyo del jefe de carrera el Ingeniero Felipe de Jesús. 
 
Agradezco a mi amigo José Roberto por siempre tener las palabras exactas 
para alentarme en cada momento. 
 
Agradezco de manera general a todas las personas cercanas a mi por estar 
en un camino de doble vía en el cual han aprendido de mi y he aprendido de 
todas ellas. 
 
Agradezco de manera general a la máxima casa de estudios que es la UNAM 
y a los profesores que me brindaron sus conocimientos y sabiduría en mi 
formación profesional de la cual estoy orgulloso portar en alto. 
 
 
 
 
 
3 
 
 
 
 
 
 
 
 
 
 
 
 
La confianza en uno mismo es el secreto del éxito 
 
Ralph Waldo Emerson 
 
 
4 
 
ÍNDICE DE FIGURAS 
 
 
Figura 1.2.1: Evolución de los dispositivos móviles……………………………..10 
Figura 1.3.1: Arquitectura de Android………………………………………………….11 
Figura 1.3.2: Ejecución de la Máquina Virtual Dalvik……………………………14 
Figura 1.4.1: Muestra de una Activity…………………………………………………..16 
Figura 1.4.2: Mensajes que lanza un Intent al recibir un SMS………………17 
Figura 1.4.3: Mensaje que lanza un Intent al insertar memoria SD………17 
Figura 1.4.4: Proveedor de Contenidos…………………………………………………18 
Figura 1.4.5. Servicio en segundo plano……………………………………………….19 
Figura 1.4.6. Mensaje de tipo Broadcast Receiver………………………………..20 
Figura 1.4.7. Mensaje de radiodifusión generado por una aplicación…..21 
Figura 1.6.1. Diagrama del ciclo de vida de una aplicación Android………23 
Figura 2.1. Sitio de Internet del Podcast de la UNAM……………………………34 
Figura 2.2. Categorías del Podcast de la UNAM…………………………………….34 
Figura 2.3. Canal RSS del Podcast de la UNAM………………………………………35 
Figura 2.4. Visualización de los videos en el sitio…………………………………..35 
Figura 2.5. Visualización de los videos en ventana emergente……………..36 
Figura 2.6. Descarga de un video del Podcast de la UNAM……………………37 
 
 
 
 
 
 
 
5 
 
 
 
INTRODUCCIÓN 
 
 
Actualmente vivimos en un mundo que se encuentra totalmente inmerso en la 
tecnología, cada vez son más usuarios los que se encuentran conectados de 
algún modo a internet en las redes sociales, viendo videos, conferencias 
escuchando música, audio libros y un largo etcétera. En nuestros días la 
tendencia es que la mayoría de las personas cuenten con un teléfono inteligente o 
Smartphone, y no sólo se limitan a mandar mensajes de texto, ahora también 
gracias a los Smartphones se abren más canales de comunicación y existen 
aplicaciones para que se puedan consultar y enviar correo electrónico, entrar en 
las redes sociales, chatear por medio de distintas aplicaciones, mandar mensajes 
de texto a través de distintas aplicaciones y no necesariamente por el servicio que 
provee el operador; ahora éstos buscan ofrecer los mejores servicios y los 
fabricantes las mejores tecnologías para dar cabida a nuevas plataformas 
móviles, ya que representan también nuevos canales para los desarrolladores lo 
que constituye el que los propios fabricantes ofrezcan las herramientas para éstos 
últimos, pues el desarrollo móvil para empresarios es un gran negocio entre 
fabricantes y operadores por lo que es conveniente para ellos abrir estos canales 
como oportunidades para los desarrolladores, cosa que en nuestras fechas el 
desarrollo móvil se convierte en el pan de cada día para tanto empresas 
desarrolladoras de software como para desarrolladores independientes. Con el 
desarrollo e implementación de la aplicación móvil Podcast UNAMóvil se supone 
y es posible el que se pueda tener un nuevo medio como acceso al conocimiento 
y a la cultura para que asítambién se fomenten el uso de éstos recursos digitales 
entre la comunidad universitaria. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
6 
 
 
 
 
 
 
1. Historia del desarrollo móvil 
Durante más de una década los dispositivos móviles han tenido presencia en 
nuestras vidas, sólo que ahora los vemos diferentes por todas las funciones que 
nos ofrecen y que obviamente se han integrado en éstos. Veamos cómo han 
evolucionado y como han llegado a lo que tenemos ahora. 
 
En 1983 Casio lanzó el PF-300 que fue el primer diario digital. Está era una 
calculadora digital que incluía capacidades para agenda telefónica, calendario y 
notas. 
 
Por otro lado, desde 1987 las comunicaciones celulares se activaron en México. 
En esos momentos teléfono como el Motorola DynaTac de dimensiones similares 
a un ladrillo y pantalla de una línea abrían el camino de ésta industria. 
 
En 1992, IBM presentó el primer Smartphone, conocido como IBM Simon 
Personal Communicator; vendido en Estados Unidos por BellSouth. Este 
dispositivo ya incluia capacidades de agenda, calendario, calculadora, correo 
electrónico, envio/recepción de fax, pantalla táctil y escritura predictiva. Era un 
dispositivo muy avanzado para su época. 
 
El Apple Newton, lanzado en 1992 es considerado como el primer PDA (Personal 
Digital Assistant). De hecho, fue Apple quien acuñó este término para referirse al 
Newton. Este dispositivo contaba con un sistema operativo desarrollado en C++ e 
integraba funciones para envío e impresión de documentos, procesador de 
palabras, agenda, calendario y calculadora. Adicionalmente permitía el desarrollo 
de aplicaciones personalizadas mediante un lenguaje de programación propietario 
llamado NewtonScript. El ambiente de desarrollo para aplicaciones en Newton 
tenía un costo inicial de $1,000 dólares y sólo era soportado en sistemas 
Macintosh, lo cual limitó su popularidad. Eventualmente fue licenciado como 
shareware y finalmente sin costo, soportando adicionalmente Windows 
 
En 1996 Palm Computing lanza su línea Pilot. Estos eran dispositivos 
monocromáticos, algunos sin iluminación en la pantalla ni puerto de 
comunicaciones infrarrojo, con capacidad de almacenamiento que fluctuaba 
desde los 128 kb hasta 1Mb de memoria. Las Pilot rápidamente se hicieron 
populares por su precio y el sistema de reconocimiento de escritura conocido 
como Graffitti. Las funcionalidades esenciales de los PDAs empezaban a 
estandarizarse: todos deberían de incluir cuando menos agenda, calendario, bloc 
de notas y calculadora. Durante estos tiempos el desarrollo de aplicaciones 
estaba basado en C; el IDE preferido para Palm era CodeWarrior de Metrowerks, 
un ambiente de desarrollo originalmente creado para Macintosh que fue portado 
posteriormente a Windows. 
 
En 1998 se acelera la carrera de los PDAs con la incursión en el mercado de HP y 
su línea Jornada. Estos dispositivos estaban basados en el sistema operativo 
7 
 
Windows CE y tenía capacidades iniciales de 16 MB de RAM, pantalla a color 
VGA y modem integrado. Las aplicaciones se desarrollaban en lenguajes de 
programación como Embedded Visual Basic (eVB) y Embedded Visual C++ (eVC) 
usando un ambiente basado en Visual Studio conocido como Microsoft Embedded 
Tools. 
 
Los primeros esfuerzos para integrar comunicaciones inalámbricas en los PDAs 
se dieron a principios de la primera década de los años 2000. En 2001, el 
Handspring Visor ya soportaba un módulo de extensión llamado VisorPhone que 
lo habilitaba como teléfono usando la red GSM. En el 2002 Handspring lanzó el 
Treo 180, que ya integraba capacidades de teléfono celular sin necesidad de 
dispositivos externos. 
 
En el 2002 Research in Motion introduce al mercado los primeros dispositivos 
BlackBerry que incorporan correo electrónico y telefonía celular. Estas 
capacidades hizo del BlackBerry el primer dispositivo completamente integrado y 
optimizado para comunicaciones inalámbricas. 
 
Como consecuencia del incremento de plataformas y funcionalidades, durante 
este periodo los lenguajes de programación y ambientes de desarrollo para 
Smartphones aumentaron significativamente. Surgen RADs (Rapid Application 
Development) para dispositivos móviles, el más destacado: Satellite Forms que 
permite el diseño visual de formas y pantallas para PalmOS y Windows Mobile. 
Los lenguajes tradicionales de desarrollo para dispositivos móviles se consolidan, 
pero también los lenguajes modernos comienzan a permear: Java 2 Micro Edition, 
.Net Compact Framework, Phyton. Esto trae como consecuencia que el universo 
de desarrolladores para dispositivos móviles crezca significativamente y con ello 
la cantidad de aplicaciones móviles. 
 
Durante los años 2003 a 2007 los fabricantes tradicionales de PDA’s pasaron por 
momentos de silencio, seguían produciendo dispositivos con las mismas 
características, aunque incrementaban las capacidades de procesamiento y 
almacenaje. Palm produce nuevas versiones de Treo, algunas con el sistema 
operativo PalmOS y otras con Windows Mobile. HP tampoco incorpora grandes 
innovaciones, más allá de incorporar lectores de huella digital. BlackBerry se 
consolida en el mundo corporativo mediante su BlackBerry Enterprise Server. Por 
el lado de los fabricantes de teléfonos, Nokia incursiona en el sector de los 
Smartphones con la serie N con el modelo N70, basado en el sistema operativo 
Symbian, incorporando pantalla a color, cámara fotográfica, soporte de 
aplicaciones Java, mensajes multimedia, navegador Opera, radio y tonos 
polifónicos. Con esto se inicia una carrera entre los fabricantes de teléfonos 
celulares para brindar cada vez mayor convergencia en sus dispositivos. Por su 
parte ésta etapa los proveedores de redes celulares se dedicaron a madurar sus 
tecnologías y prepararse para la migración hacia GSM y 3G. 
 
El letargo se rompe en 2007 cuando Apple lanza al mercado el iPhone, el cual 
asombró al vender más de 270,000 dispositivos en las primeras 30 horas. Unas 
de las características más importantes del iPhone son su sistema operativo 
propietario con una interfaz de usuario única y un acelerómetro integrado, que 
permite cambiar la posición de la imagen en la pantalla de acuerdo con la posición 
8 
 
física del teléfono. Adicionalmente, el teléfono reconoce “gestos” realizado con los 
dedos sobre la pantalla, para ejecutar acciones. 
 
En 2008 México los principales proveedores de telefonía celular habilitan su red 
para soportar GSM / 3G lo cual abre camino para nuevos dispositivos y servicios. 
 
Apple libera el iPhone SDK, a través del cual se pueden desarrollar aplicaciones 
para el iPhone usando el ambiente de desarrollo XCode. Así mismo, Apple abre 
su App Store, una tienda de aplicaciones en línea donde los desarrolladores 
pueden ofrecer sus aplicaciones para que sean compradas y descargadas por los 
usuarios. En los primeros 9 meses de existencia, la App Store acumuló más de 
35,000 aplicaciones y ha superado el billón (mil millones) de descargas. Queda 
claro que el impacto de éste modelo para ofertar aplicaciones. De igual forma los 
demás proveedores, desde Microsoft hasta Research in Motion anunciaron sus 
propios App Stores. 
 
También en el 2008 se liberó Android, una plataforma Open Source para 
Smartphones. Detrás de éste lanzamiento está Google, Intel, eBay y otros que 
forma el Open Handset Alliance. Android está basado en el sistema operativo 
Linux y las aplicaciones se programan en Java, lo que lo hace atractivo a una 
gran cantidad de desarrolladores. 
 
En el 2009 Apple liberó el beta de iPhone SDK 3.0, Android se encontraba en la 
versión 1.5 y Microsoft liberó la versión 6.5 del Windows Mobile la cual ha 
incorporado capacidades de computo en la nube, Palm lanzó el Palm Pre con el 
sistema operativo WebOS, en el cual las aplicaciones se desarrollan usando 
tecnologías sencillas y conocidas como HTML, Javascript y CSS. 
 
En enero de 2010 Apple anuncia el iPad la cual es una tableta electrónica en la 
que se agreganlas funciones de los smartphones junto con las tareas de 
escritorio que se pueden hacer en una Mac y la cual actualmente es la iPad 3 y el 
iPhone está en la versión 4S, el SDK del mismo en la versión 6, el BlackBerry 
continua con la producción de nuevos modelos y series. 
 
Actualmente Android se encuentra en la versión 5.0 con nombre clave Lollipop 
versión para la cual Google renueva totalmente el sistema operativo cambiando la 
máquina virtual Dalvik por la máquina virtual Android Runtime (ART) y oficializa 
como entorno de desarrollo integrado (IDE) su herramienta Android Studio con la 
cual facilita el desarrollo no sólo para smartphones y tablets sino también para 
relojes inteligentes (smartwatch), televisores, dispositivos con arquitectura x86 y 
de 64 bits. 
 
 
 
 
 
 
 
 
 
9 
 
 
 
 
 
 
1.1. ¿Qué es Android? 
Android es una pila de software creada inicialmente para teléfonos móviles 
(smartphones). No es una plataforma de hardware. Incluye un sistema operativo 
basado en Linux, una completa interfaz de usuario, aplicaciones, bibliotecas de 
código, estructuras para aplicaciones compatibilidad multimedia para que el 
teléfono pueda realizar funciones más allá de los dispositivos que se usaban de 
antaño. 
 
Android era un sistema operativo para móviles prácticamente desconocido 
propiedad de una empresa llamada Android Inc hasta que en 2005 Google lo 
compró, el creador de éste sistema operativo se llama Andy Rubin. Android es un 
producto de Google, en concreto de la Open Handset Alliance, una alianza 
formada por aproximadamente 30 organizaciones dispuestas a instaurar una 
telefonía abierta y de mejor calidad en el mercado. En noviembre de 2007 sólo 
circulaban rumores de que el gigante de Internet tenía en planes lanzar un 
proyecto para móviles y precisamente por esas fechas se lanzó la Open Handset 
Alliance cuando se proporcionó la primera versión de Android, junto con el SDK 
para que los programadores empezaran a crear sus aplicaciones para este 
sistema 
 
 
1.2. ¿Por qué Android? 
Android es la primera plataforma de software a código abierto (OpenSource) para 
aplicaciones móviles con posibilidad de adecuarse a diferentes mercados. Android 
es un sistema operativo basado en el núcleo de Linux, por esa razón tiene 
inmersas las características de ser libre gratuito y multiplataforma. Cualquier 
desarrollador puede crear aplicaciones para Android sin la necesidad de pagar 
membresías anuales para obtener el kit de desarrollo y crear los elementos o 
aumentar las funciones de los que carece ya que como se ha mencionado es una 
plataforma abierta que se puede modificar. Del mismo modo, se pueden obtener 
codecs multimedia y librerías creadas por terceros y no es necesario depender 
de Google para disfrutar de nuevas funciones. 
 
El mercado de la tecnología móvil es muy cambiante y sus agentes tienen 
diferentes objetivos. Consideremos la extraña relación entre operadores, 
fabricantes y distribuidores de software. Los operadores de telefonía móvil quieren 
bloquear sus redes, para controlar y medir el tráfico. Los fabricantes de 
dispositivos desean diferenciarse a través de funciones, fiabilidad y precios. Los 
distribuidores de software desean un acceso sin trabas para proporcionar 
aplicaciones de primer nivel. Si a esto le unimos una base de exigentes clientes, 
tanto consumidores como corporaciones, adicta al teléfono gratuito y operadores 
que recompensan el cambio de servicio pero no la lealtad del cliente. 
 
10 
 
Android se comercializa bajo dos licencias de código abierto diferentes. El núcleo 
de Linux se comercializa bajo la licencia GPL (General Public License), como 
exige todo núcleo de sistema operativo de código abierto. La plataforma Android 
sin el núcleo, tiene una licencia ASL (Apache Software License). Aunque ambos 
modelos de licencia están orientados al código abierto, la principal diferencia es 
que la licencia de Apache se considera más proclive al uso comercial. 
 
Aunque los inicios fueron un poco lentos, debido a que se lanzó el sistema 
operativo antes que el primer móvil, Android rápidamente se ha colocado como 
una plataforma que ya se ha ganado muchos adeptos y que ha demostrado una 
velocidad de madurez importante debido a los diferentes fabricantes que han 
adaptado interesantes piezas de hardware para acompañar las diferentes 
funciones de Android 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 1.2.1. La evolución en la funcionalidad de los dispositivos móviles se ha 
englobado en los smartphones. 
Fuente: Ableson, F.; Collins, C.; Sen, R.; Android, Guía para desarrolladores; 2009: 35 
 
 
 
 
 
 
 
 
 
11 
 
 
 
 
 
1.3. Arquitectura de Android 
Para el desarrollo de aplicaciones para Android es importante conocer como está 
organizado éste sistema operativo. La arquitectura de Android está formada por 
varias capas esta distribución permite acceder a las capas más bajas mediante el 
uso de librerías para que así el desarrollador no tenga que programar a bajo nivel 
las funcionalidades necesarias para que una aplicación haga uso de los 
componentes de hardware de los teléfonos. Cada una de las capas utiliza 
elementos de la capa inferior para realizar sus funciones, es por ello que a este 
tipo de arquitectura se le conoce también como pila. A continuación se muestra el 
diagrama de la arquitectura de Android el cual aparece en la documentación 
oficial del mismo. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1.4. Componentes de una aplicación Android 
 
1.5. Mapa mental de Android 
 
 
 
 
Figura 1.3.1. Arquitectura de Android 
Fuente: http://androideity.com/2011/07/04/arquitectura-de-android/ 
 
 
 
Explicaremos cada una de las capas comenzando por la capa más inferior hasta 
la más superior. 
 
12 
 
 
 
 
 
Kernel de Linux 
 
El núcleo del sistema operativo Android está basado en el kernel de Linux versión 
2.6, similar al que puede incluir cualquier distribución de Linux, como Ubuntu, solo 
que adaptado a las características del hardware en el que se ejecutará Android, 
es decir, para dispositivos móviles. 
 
El núcleo actúa como una capa de abstracción 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 librerías disponibles en capas superiores. Así también se 
evita el complicarse al tener que conocer las características específicas de cada 
teléfono. Si necesitamos hacer uso de la cámara, el sistema operativo se encarga 
de utilizar la que incluya el teléfono, sea cual sea. Para cada elemento de 
hardware del teléfono existe un controlador (o driver) dentro del kernel que 
permite utilizarlo desde el software. 
El kernel también se encarga de gestionar los diferentes recursos del teléfono 
(energía, memoria, etc.) y del sistema operativo en sí: procesos, elementos de 
comunicación (networking), etc. 
 
Librerías 
La siguiente capa que se sitúa justo sobre el kernel la componen las bibliotecas 
nativas de Android, también llamadas librerías. Están escritas en C o C++ y 
compiladas para la arquitectura hardware específica del teléfono. Estas 
normalmente están hechas por el fabricante, quien también se encarga de 
instalarlas en el dispositivo antes de ponerlo a la venta. El objetivo de las librerías 
es proporcionar funcionalidad a las aplicaciones para tareas que se repiten con 
frecuencia, evitando tener que codificarlas cada vez y garantizando que se llevan 
a cabo de la forma “más eficiente”. 
Entre las librerías incluidas habitualmente encontramos OpenGL (motor gráfico), 
Bibliotecas multimedia (formatos de audio, imagen y video), Webkit (navegador), 
SSL (cifrado de comunicaciones), FreeType (fuentes de texto), SQLite (base de 
datos), entre otras. 
Entorno de Ejecución 
Como podemos apreciar en la figura 1.3.1, el entorno de ejecución de Android no 
se considera una capa en sí mismo, dado que también está formado por librerías. 
Aquí encontramos las librerías con las funcionalidadeshabituales de Java así 
como otras específicas de Android. 
El componente principal del entorno de ejecución de Android es la máquina virtual 
Dalvik la cual es una máquina virtual intérprete que ejecuta archivos en el formato 
Dalvik Executable (.dex), un formato optimizado para el almacenamiento eficiente 
y ejecución mapeable en memoria. Su objetivo fundamental es el mismo que 
13 
 
cualquier máquina virtual, permite que el código sea compilado a un bytecode 
independiente de la máquina en la que se va a ejecutar, y la máquina virtual 
interpreta este bytecode a la hora de ejecutar el programa. Una de las razones 
por las cuáles no se optó por utilizar la máquina virtual de Java es la necesidad de 
optimizar al máximo los recursos y enfocar el funcionamiento de los programas 
hacia un entorno dónde los recursos de memoria, procesador y almacenamiento 
son escasos. 
Dalvik está basada en registros y puede ejecutar clases compiladas (válgase la 
redundancia) por un compilador Java y que posteriormente han sido convertidas 
al formato nativo usando la herramienta “dx”. El hecho de que corra sobre un 
kernel Linux le permite delegar las tareas relacionadas con la gestión de hilos y 
memoria a bajo nivel. 
Otra característica importante de Dalvik es que ha sido optimizada para que 
múltiples instancias de ella puedan funcionar al mismo tiempo con un impacto 
muy bajo en el rendimiento de la memoria del dispositivo. El objetivo de esto es 
proteger a las aplicaciones, de forma que el cierre o fallo inesperado de alguna de 
ellas no afecte de ninguna forma a las demás. 
La máquina virtual de Java, que podemos encontrar en casi todas las 
computadoras personales actuales, se basa en el uso de las pilas. De modo 
contrario, Dalvik utiliza los registros, ya que los teléfonos móviles están 
optimizados para la ejecución basada en los mismos. 
Aunque utilizamos el lenguaje Java para programar las aplicaciones Android, el 
bytecode de Java no es ejecutable en un sistema Android. De igual forma, las 
librerías Java que utiliza Android son ligeramente distintas a las utilizadas en Java 
Standard Edition (Java SE) o en Java Mobile Edition (Java ME), guardando 
también características en común. 
El uso de Dalvik permite reducir bastante el tamaño del programa buscando 
información duplicada en las diversas clases y reutilizándola. 
Lo que llamamos en Java como “recolectar basura”, que libera 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 máxima memoria 
posible. 
De igual forma, el hecho de que Android haga un uso extenso del lenguaje XML 
para definir las interfaces gráficas y otros elementos, implica que estos archivos 
deben ser linkeados a la hora de compilar y para que su conversión a bytecode 
pueda mejorar el rendimiento de nuestras aplicaciones. 
 
 
 
14 
 
 
 
 
 
 
 
Figura 1.3.2. Ejecución de la Máquina Virtual Dalvik 
Fuente: http://androideity.com/2011/07/07/la-maquina-virtual-dalvik/ 
 
Framework de Aplicaciones 
La siguiente capa está formada por todas las clases y servicios que utilizan 
directamente las aplicaciones para realizar sus funciones. La mayoría de los 
componentes de esta capa son librerías Java que acceden a los recursos de las 
capas anteriores a través de la máquina virtual Dalvik. De acuerdo a la figura 
1.3.1 encontramos: 
 
1. Activity Manager: Se encarga de administrar la pila de actividades de 
nuestra aplicación así como su ciclo de vida. 
2. Windows Manager: Se encarga de organizar lo que se mostrará en 
pantalla. Básicamente crea las superficies en la pantalla que 
posteriormente pasarán a ser ocupadas por las actividades. 
3. Content Provider: Esta librería crea una capa que encapsula los datos que 
se compartirán entre aplicaciones para tener control sobre cómo se accede 
a la información. 
4. View: En Android, las vistas los elementos que nos ayudarán a construir las 
interfaces de usuario: botones, cuadros de texto, listas y hasta elementos 
más avanzados como un navegador web o un visor de Google Maps. 
5. Notification Manager: Engloba los servicios para notificar al usuario cuando 
algo requiera su atención mostrando alertas en la barra de estado. Un dato 
importante es que esta biblioteca también permite jugar con sonidos, 
activar el vibrador o utilizar los LEDs del teléfono en caso de tenerlos. 
6. Package Manager: Esta biblioteca permite obtener información sobre los 
paquetes instalados en el dispositivo Android, además de gestionar la 
instalación de nuevos paquetes. Con paquete nos referimos a la forma en 
15 
 
que se distribuyen las aplicaciones Android, estos contienen el archivo 
.apk, que a su vez incluyen los archivos .dex con todos los recursos y 
archivos adicionales que necesite la aplicación, para facilitar su descarga e 
instalación. 
7. Telephony Manager: Con esta librería se puede realizar llamadas o enviar 
y recibir SMS/MMS, aunque no permite reemplazar o eliminar la actividad 
que se muestra cuando una llamada está en curso. 
8. Resource Manager: Ésta librería permite gestionar todos los elementos que 
forman parte de la aplicación y que están fuera del código, es decir, 
cadenas de texto traducidas a diferentes idiomas, imágenes, sonidos o 
layouts. En un post relacionado a la estructura de un proyecto Android 
veremos esto más a fondo. 
9. Location Manager: Permite determinar la posición geográfica del dispositivo 
Android mediante GPS o redes disponibles y trabajar con mapas. 
10. Sensor Manager: Nos permite manipular los elementos de hardware del 
teléfono como el acelerómetro, giroscopio, sensor de luminosidad, sensor 
de campo magnético, brújula, sensor de presión, sensor de proximidad, 
sensor de temperatura, etc. 
11. Cámara: Con esta librería podemos hacer uso de la cámara del dispositivo 
para tomar fotografías o para grabar vídeo. 
12. Multimedia. Permiten reproducir y visualizar audio, vídeo e imágenes en el 
dispositivo. 
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 también la aplicación 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 
también aplicaciones de esta capa. 
 
 
1.4. Componentes de una aplicación Android 
Las aplicaciones Android se construyen mediante bloques esenciales de 
componentes, cada uno de los cuales existen como una entidad propia y 
desempeña un papel específico; cada elemento es una pieza única que ayuda a 
definir el comportamiento general de la aplicación. Es importante mencionar que 
algunos de estos elementos son el punto de entrada para que los usuarios 
16 
 
interactúen con la aplicación y en muchos casos veremos que unos elementos 
dependen de otros. 
Hay cuatro tipos de componentes en una aplicación Android. Cada uno de ellos 
tiene un propósito y un ciclo de vida distinto que define cómo se crea y se 
destruye el componente. 
Activities (Actividades) 
Es el bloque encargado de construir la interfaz de usuario. Puedes pensar en una 
actividad como el análogo de una ventana en una aplicación de escritorio. En las 
actividades recae la responsabilidad de presentar los elementos visuales y 
reaccionar a las acciones del usuario. 
Si bien podemos pensar en actividades que no posean una interfaz de usuario, 
regularmente el código en estos casos se empaqueta en forma de content 
providers (proveedores de contenido) y services (servicios) que detallaremos en 
un momento. 
Toda actividad se inicia como respuesta a un Intent.Figura 1.4.1. El área que se muestra en la llave es la Activity que contiene una 
interfaz gráfica de usuario 
Fuente: Elaboración propia (2014) 
Intents (Intenciones) 
Son los mensajes del sistema que se encuentran corriendo en el interior del 
dispositivo. Se encargan de notificar a las aplicaciones de varios eventos: 
cambios de estado en el hardware (ej. cuando se inserta una memoria SD al 
17 
 
teléfono), notificaciones de datos entrantes (ej. cuando llega un SMS) y eventos 
en las aplicaciones (ej. cuando una actividad es lanzada desde el menú principal). 
Así como podemos crear actividades que respondan a las intenciones, podemos 
crear también intenciones que lancen actividades o usarlas para detonar eventos 
ante algunas situaciones específicas (ej. que el teléfono nos notifique por medio 
de un mensaje cuando nuestra localización esté a 10 mts del punto de destino). 
Es importante mencionar que el sistema es el que elige entre las actividades 
disponibles en el teléfono y dará respuesta a la intención con la actividad más 
adecuada. 
 
 
 
 
 
 
 
 
 
Figura 1.4.2. Mensaje que lanza/genera un Intent al recibirse un SMS 
Fuente: Elaboración propia (2014) 
 
 
 
 
 
 
 
 
Figura 1.4.3. Mensaje que lanza/genera un Intent al insertarse una memoria SD 
Fuente: Elaboración propia (2014) 
18 
 
 
 
Content Providers (Proveedores de Contenido) 
Este elemento ofrece un conjunto de datos almacenados en el dispositivo para 
que se puedan accesar y compartir por varias aplicaciones. Nosotros podemos 
guardar datos en archivos del sistema, en una base de datos en SQLite, en la 
web o en cualquier otro lugar de almacenamiento persistente a la que la 
aplicación pueda tener acceso. A través del proveedor de contenido, otras 
aplicaciones pueden consultar o incluso modificar los datos (solamente si el 
proveedor de contenidos de esa aplicación lo permite). 
El modelo de desarrollo en Android nos invita a los desarrolladores a pensar 
siempre en hacer los datos de nuestras aplicaciones disponibles para otras 
aplicaciones. De manera que cuando creamos un proveedor de contenido, 
podemos tener un control completo de nuestros datos y definir la forma en que 
éstos serán accesados. 
Un ejemplo sencillo de esto es el proveedor de contenido que tiene Android para 
gestionar la información de contactos (agenda) del teléfono. Cualquier aplicación 
con los permisos adecuados puede realizar una consulta a través de un 
proveedor de contenido como ContactsContract.Data para leer y escribir 
información sobre una persona en particular. 
 
 
 
 
 
 
 
 
 
Figura 1.4.4. Otras aplicaciones pueden tener acceso a datos mediante el 
proveedor de contenidos de una aplicación 
Fuente: Ableson, F.; Collins, C.; Sen, R.; Android, Guía para desarrolladores; 2009: 54 
 
 
19 
 
 
Services (Servicios) 
Las actividades, las intenciones y los proveedores de contenido explicados arriba 
son de corta duración y pueden ser detenidos en cualquier momento. Por el 
contrario, los servicios están diseñados para seguir corriendo, y si es necesario, 
de manera independiente de cualquier actividad. Un ejemplo de un servicio es el 
uso de la aplicación de la radio, donde podemos estar escuchándola y a la vez 
utilizando otra aplicación, pues como se ha mencionado, este servicio es capaz 
de correr en segundo plano respecto a la o a las aplicaciones que estamos 
usando. En la siguiente figura 1.4.4 se observa la captura de pantalla donde se 
está usando la aplicación de notas y el servicio de la aplicación de la radio 
también está en ejecución. 
 
 
 
 
 
 
 
 
Figura 1.4.5. Aquí se ilustra cómo podemos estar en otra aplicación mientras el 
servicio de la aplicación de la radio continua en segundo plano 
Fuente: Elaboración propia (2014) 
 
Broadcast Receivers (Receptores de Radiodifusión) 
Este componente responde a las notificaciones de difusión de todo el sistema 
como por ejemplo que la pantalla se ha apagado, que la batería del teléfono está 
por terminarse o que una fotografía ha sido tomada. Las aplicaciones también 
pueden lanzar este tipo de notificaciones, un ejemplo de ello es el aviso de que 
alguna información ha terminado de descargarse en el dispositivo y se encuentran 
disponibles para su utilización. 
Aunque los broadcast receivers no muestran una interfaz de usuario, pueden 
crear notificaciones en la barra de estado del teléfono para avisarle al usuario 
cuando un evento de este tipo se genera. Podemos pensar en estos elementos 
como el medio por el cual otros componentes pueden ser iniciados en respuesta a 
20 
 
algún evento. Cabe mencionar que cada una de las emisiones de los broadcast 
receivers se representa como una intención. 
Un aspecto único y útil del diseño del sistema operativo Android es que cualquier 
aplicación puede hacer uso de otro componente de otra aplicación. Supongamos 
que la aplicación requiere que el usuario tome una fotografía con la cámara del 
teléfono; es probable que exista otra aplicación que haga exactamente eso, por lo 
que resultará más fácil reutilizar esa función que programar una específica en 
nuestra aplicación. Para ello no es necesario incluir o vincular el código de la 
aplicación de la cámara, simplemente hará falta iniciar la actividad que se 
encargue de capturar la foto. Una vez hecho, la foto estará disponible para usarla 
en la aplicación principal. Para el usuario parecerá que la cámara de su teléfono 
es una parte de la aplicación. 
Debido a que el sistema Android ejecuta cada una de las aplicaciones en un 
proceso separado con permisos de archivos que pueden restringir el acceso a 
otras aplicaciones, las aplicaciones no pueden activar de forma directa un 
componente de otra aplicación. El único que puede hacer esto es el sistema 
operativo en sí. Por lo tanto, para activar un elemento de otra aplicación, debemos 
pasarle un mensaje al sistema dónde se especifique qué elemento es el que 
necesitamos correr. De esta manera el sistema activará el componente y 
podremos manipularlo según sea nuestra necesidad. 
 
 
 
 
 
 
 
 
 
 
Figura 1.4.6. Mensaje que genera un Broadcast Receiver y que lanza a través de un 
Intent 
Fuente: Elaboración propia (2014) 
 
 
21 
 
 
 
 
 
 
 
 
 
 
Figura 1.4.7. Mensaje de radiodifusión generado por una aplicación 
Fuente: Elaboración propia (2014) 
1.5. Procesos en Android 
En la mayoría de los casos, una aplicación Android se ejecuta en su propio 
proceso de Linux. Este proceso es creado para la aplicación cuando la 
arrancamos y seguirá corriendo hasta que no sea necesario y el sistema reclame 
recursos para otras aplicaciones y se los de a éstas. 
Así es, el tiempo de vida de un proceso en Android es manejada por el sistema 
operativo, basándose en las necesidades del usuario, los recursos disponibles, 
etc. Si tenemos una aplicación que está consumiendo muchos recursos y 
arrancamos otra nueva aplicación, el sistema operativo probablemente le diga a la 
aplicación 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 más control sobre las aplicaciones que en programas de escritorio. 
Para determinar qué procesos eliminar ante un escenario dónde el dispositivo 
tenga poca batería u otros en los que sea de relevante importancia administrar los 
recursos, Android les asigna una prioridad a cada uno de ellos basándose en la 
siguiente jerarquía: 
1. Foreground Process 
Es la aplicación que contiene la actividad ejecutada en primer plano en la pantalla 
del usuario y con la cual está interactuando ahora mismo (Se ha llamado a su 
método onResume()). Por lo regular habrá muy pocos procesos de este tipo 
corriendo a la vez en el sistema y son aquellos que se eliminarán como última 
22 
 
opción si la memoria es tan baja que ni matando al resto de procesos tenemos los 
recursos necesarios. 
2.Visible Process 
Es un proceso que aloja una Activity que no se está ejecutando en primer plano 
(es decir, su método onPause() ha sido llamado). Un ejemplo puede ser la 
aplicación de correo en la cual demos click en algún enlace de interés que nos 
lance el navegador, este pasaría a ser el Foreground Process dejando a la 
aplicación de correo en el concepto de Visible Process. Este tipo de procesos se 
cerrarán únicamente cuando el sistema no tenga los recursos necesarios para 
mantener corriendo todos los procesos que estén en primer plano. 
3. Service Process 
Son aquellos que corren cuando un Service ha sido invocado. Estos procesos 
hacen cosas en segundo plano que normalmente son importantes para el usuario 
(conexión con servidores, actualización del GPS, reproductor de música, etc.), el 
sistema nunca va a liquidar un servicio a menos que sea necesario para mantener 
vivos todos los Visible y Foreground. 
4. Background Process 
Es un proceso que contiene una Activity que actualmente no es visible por el 
usuario y que ya no tienen demasiada importancia. Por ejemplo, los programas 
que ejecutó el usuario y que tarda en volver a usar, pasan a estar en background. 
Por eso es importante que cuando nuestra aplicación pase a Background, el 
sistema libere, en la medida de lo posible, todos los recursos que pueda para que 
su rendimiento sea óptimo. 
5. Empty Process 
Es un proceso que no aloja ningún tipo de componente. Su razón de ser es el de 
tener una caché disponible para la próxima aplicación que lance el usuario. Es 
común que el sistema elimine este tipo de procesos con frecuencia para así poder 
obtener memoria disponible. 
 
 
 
 
 
 
 
23 
 
1.6. Ciclo de vida de una aplicación Android 
Como se ha mencionado en los procesos de Android, el sistema operativo es el 
encargado de pausar, parar o destruir nuestra aplicación según las necesidades 
de recursos del dispositivo, aun así, nosotros como desarrolladores debemos 
aprender a controlar todos estos eventos para hacer nuestras aplicaciones 
robustas y mejorar el rendimiento de los teléfonos. 
Para explicar el ciclo de vida de una aplicación citamos el diagrama que se 
encuentra en la documentación oficial de Android. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 1.6.1. Diagrama del Ciclo de vida de una aplicación Android 
Fuente: http://developer.android.com/intl/es/reference/android/app/Activity.html 
A continuación explicaremos cada uno de los procesos del ciclo de vida 
 
24 
 
 
 
 onCreate() 
Se dispara cuando la Activity es llamada por primera vez. Aquí es donde debemos 
crear la inicialización normal de la aplicación, crear vistas, hacer los bind de los 
datos, etc. Este método da acceso al estado de la aplicación cuando se cerró. 
Después de esta llamada siempre se llama al onStart(). 
 onRestart() 
Se ejecuta cuando la Activity ha sido parada y se quiere volver a utilizar. Como se 
ilustra en el diagrama se puede ver que después de un onStop() se ejecuta el 
onRestart() e inmediatamente llama a un onStart(). 
 onStart() 
Se ejecuta cuando la Activity se está mostrando apenas en la pantalla del 
dispositivo del usuario. 
 onResume() 
Se ejecuta una vez que la Activity ha terminado de cargarse en el dispositivo y el 
usuario empieza a interactuar con la aplicación. Cuando el usuario ha terminado 
de utilizarla es cuando se llama al método onPause(). 
 onPause() 
Se ejecuta cuando el sistema arranca una nueva Activity que necesitará los 
recursos del sistema centrados en ella. Hay que procurar que la llamada a este 
método sea rápida ya que hasta que no se termine su ejecución no se podrá 
arrancar la nueva Activity. Después de esta llamada puede venir un onResume() 
si la Activity que haya ejecutado el onPause() vuelve a aparecer en primer plano o 
un onStop() si se hace invisible para el usuario. 
 onStop() 
Se ejecuta cuando la Activity ya no es visible para el usuario porque otra Activity 
ha pasado a primer plano. Si vemos el diagrama, después de que se ha ejecutado 
este método nos quedan tres opciones: ejecutar el onRestart() para que 
la Activity vuelva a aparecer en primer plano, que el sistema elimine este proceso 
porque otros procesos requieran memoria o ejecutar el onDestroy() para apagar la 
aplicación. 
 onDestroy() 
Esta es la llamada final de la Activity, después de ésta, es totalmente destruida. 
Esto pasa por los requerimientos de memoria que tenga el sistema o porque de 
25 
 
manera explícita el usuario manda a llamar este método. Si quisiéramos volver a 
ejecutar la Activity se arrancaría un nuevo ciclo de vida. 
 
1.7. Android y sus versiones 
Android en sus distintas versiones, desde la primera versión comercial contiene 
nombres claves en orden alfabético los cuales hacen alusión a distintos alimentos. 
Con cada versión de Android se agregan mejoras a la interfaz de programación 
de aplicaciones (API por sus siglas en inglés) las cuales se agregan a la biblioteca 
de clases y métodos de dicho sistema. A continuación se describirán cada versión 
de Android y su nivel de API correspondiente. 
Android Beta 
La versión Beta de Android fue lanzada el 5 de noviembre de 2007 mientras que 
las herramientas de desarrollo (Software Development Kit SDK) fue lanzado el 12 
de noviembre de 2007. 
 
Android Apple Pie 1.0 nivel de API 1 (septiembre 2008) 
Ésta es la primera versión comercial de Android, el primer dispositivo que la uso 
fue el HTC Dream que incorporó las siguiente características. 
 
Aparece Android Market como tienda digital para la descarga y actualización de 
aplicaciones. Soporte para cámara fotográfica pero con poca resolución y calidad 
en las fotos. Incorpora también la mensajería instantánea (chat) servicio de 
mensajes de texto (sms) y mensajes multimedia (mms). Con ello implementa 
también la versión móvil de YouTube para Android. Comienza a dar soporte a 
redes y conexiones inalámbricas por Wi-Fi y Bluetooth. 
 
Android 1.1 Banana Bread nivel de API 2 (febrero 2009) 
Fue lanzada inicialmente para el HTC Dream, no se añadieron funcionalidades 
simplemente se corrigieron algunos errores de la versión anterior y cambió la API. 
Alguna de las funcionalidades que implementó fue la posibilidad de adjuntar 
archivos en los mensajes de texto y mostrar la información de los negocios en su 
búsqueda en los mapas. 
 
Android Cupcake 1.5 nivel de API 3 (abril 2009) 
Es la primera versión que se publicó comercialmente. Como novedades se 
incorpora la posibilidad de teclado en pantalla con predicción de texto, los 
terminales ya no tienen que tener un teclado físico, así como la capacidad de 
grabación avanzada de audio y video. También aparecen los widgets de escritorio 
y live folders. Incorpora soporte para bluetooth estéreo, por lo que permite 
conectarser automáticamente a auriculares bluetooth. Las transiciones entre 
ventanas se realizan mediante animaciones. Además de la capacidad de subir 
videos a YouTube. 
 
Android Donut 1.6 nivel de API 4 (septiembre 2009) 
Permitió capacidades de búsqueda avanzada en todo el dispositivo, También 
incorporó gestos (gestures) y tecnología multitáctil (multi-touch). Permitió la 
26 
 
síntesis de texto a voz. Así mismo facilitó que una aplicación pueda trabajar con 
diferentes densidades de pantalla. Soporte para resolución de pantallas WVGA. 
Aparece un nuevo atributo XML, onClick, que puede especificarse en una vista. 
Aparece Play Store antes Android Market, en el cual se añade una mejora que 
permite una búsqueda más sencilla de aplicaciones. También se agregaron 
mejoras en la aplicación de la cámara. Actualización de soporte para la tecnología 
CDMA/EDVO, 802.1x y VPNs 
 
Android Éclair 2.0 nivel de API 5 (octubre 2009) 
Ésta versión de API contó con pocos usuarios, dado que la mayoría de los 
fabricantes permitieron actualizar directamente de la versión 1.6 a la versión 2.1. 
Como novedades cabría destacar que incorpora un API para manejar el bluetooth 
2.1. Nueva funcionalidadque permite sincronizar adaptadores para conectarlo a 
cualquier dispositivo. Ésta versión ofreció un servicio centralizado de manejo de 
cuentas de correo electrónico y de redes sociales. Mejoró la gestión de contactos 
y ofreció más ajustes en la cámara. Optimizó la velocidad del hardware. Se 
aumentó el número de tamaños de ventana y resoluciones soportadas. Nueva 
interfaz del navegador y comenzó a dar soporte para el Lenguaje Marcado de 
Hipertexto en su versión 5 (HTML5). Añadió mejoras en la aplicación del 
calendario y dio soporte para Microsoft Exchange. Se añade la clase MotionEvent 
para soportar eventos en pantallas multitactiles. En la versión 2.0.1 tuvo cambios 
menores en la API. 
 
Android 2.1 nivel de API 7 (enero 2010) 
Se consideró una actualización menor, por lo que le siguieron su nombre clave 
continuó siendo Éclair. Se destacó el reconocimiento de voz que permitió 
introducir un campo de texto dictado sin necesidad de utilizar el teclado. También 
permitió desarrollar fondos de pantalla animados. Se podía obtener información 
sobre la red de la señal actual que posea el dispositivo. En el paquete WebKit se 
incluyen nuevos métodos para manipular bases de datos almacenadas en la web. 
También comenzó a permitir obtener los permisos de geolocalización y 
modificarlos en WebView. Incorporó mecanismos para administrar la 
configuración de la memoria caché de aplicaciones, almacenamiento web y 
modificar la resolución de la pantalla. 
 
Android Froyo 2.2 nivel de API 8 (mayo 2010) 
Como característica más destacada se puede indicar la mejora de velocidad de 
ejecución de las aplicaciones (ejecución del código de la CPU de 2 a 5 veces más 
rápido que en la versión anterior). Esto se consiguió con la introducción de un 
nuevo compilador JIT de máquina virtual Dalvik 
 
Se añadieron varias mejoras relacionadas con el navegador Web, como el 
soporte de Adobe Flash 10.1 y la incorporación del motor Javascript v8 utilizado 
en chrome o la incorporación del campo subir archivo en un formulario. 
 
El desarrollo de aplicaciones permite las siguientes novedades en esta versión: se 
puede preguntar al usuario si desea instalar una aplicación en un medio de 
almacenamiento externo (como una tarjeta SD), como alternativa a la instalación 
en la memoria interna del dispositivo. Las aplicaciones comenzaron a actualizarse 
de manera automática cuando aparece una nueva versión. Proporcionó un 
27 
 
servicio para la copia de seguridad de datos que se puede realizar desde la propia 
aplicación para garantizar al usuario el mantenimiento de sus datos. Por último se 
facilita que las aplicaciones interaccionen con el reconocimiento de voz y que 
terceras partes proporcionen nuevos motores de reconocimiento. 
 
Se comenzó a mejorar la conectividad: en ésta versión de pudo comenzar a 
utilizar el teléfono celular para dar acceso a internet a otros dispositivos, tanto por 
conexión usb como por Wi-Fi. También se añadió el soporte a Wi-Fi IEEE 802.11n 
y notificaciones de tipo push. 
 
Se añadieron varias mejoras en diferentes componentes: en el API gráfica 
OpenGL ES comenzó a soportar la versión 2.0. También se pueden tomar fotos o 
video en cualquier orientación, vertical u horizontal y configurar otros ajustes de la 
cámara. Para finalizar, permite definir modos de interfaz de usuario como 
“automóvil” y “noche” para que las aplicaciones se configuren según el modo 
seleccionado por el usuario. 
 
Android Gingerbread 2.3 nivel de API 9 (diciembre 2010) 
Debido al éxito de android en las nuevas tabletas ahora soporta mayores tamaños 
de pantalla y resoluciones (WXGA y superiores). En ésta versión incorporó una 
nueva interfaz de usuario con un diseño actualizado, dentro de éstas mejoras se 
destaca la funcionalidad de cortar, copiar y pegar y un teclado en pantalla con 
capacidad multitáctil. 
 
Se incluye soporte nativo para varias cámaras, pensando en la segunda cámara 
usada para videoconferencia. La incorporación de ésta segunda cámara ha 
propiciado la inclusión de reconocimiento facial para identificar el usuario del 
terminal. 
 
La máquina virtual Dalvik introduce un nuevo recolector de basura que minimiza 
las pausas de la aplicación ayudando a garantizar una mejor animación y el 
aumento de la capacidad de respuesta en juegos y aplicaciones similares. Se 
trata de corregir así uno de los errores de este sistema operativo móvil, que en 
versiones previas no ha sido capaz de cerrar bien las aplicaciones en desuso. Se 
dispone de mayor apoyo para el desarrollo del código nativo (NDK). También se 
mejoró la gestión de energía y control de las aplicaciones y se cambió el sistema 
de ficheros que pasa de YAFFSS a ext4. 
 
Entre otras novedades se destaca el soporte nativo para telefonía sobre internet 
VoIP/SIP. El soporte para reproducción de video WebM/VP8 y codificación de 
audio AAC. El soporte para la tecnología Near Field Communication (NFC). Las 
facilidades en el audio, gráficos y entradas para los desarrolladores de 
videojuegos. El soporte nativo para más sensores como giroscopios y barómetros. 
Un gestor de descargas para descargas largas. 
 
Android Honeycomb 3.0 nivel de API 11 (febrero de 2011) 
Para mejorar la experiencia de Android en las nuevas tabletas se lanza la versión 
3.0 optimizada para dispositivos con pantallas grandes. La nueva interfaz de 
usuario ha sido completamente rediseñada con paradigmas nuevos para la 
interacción, navegación y personalización. La nueva interfaz se pone a 
28 
 
disposición de todas las aplicaciones incluso las construidas para versiones 
anteriores de la plataforma. 
 
Las principales novedades de este SDK son las siguientes: 
 
Con el objetivo de adaptar la interfaz de usuario a pantallas más grandes se 
incorporan las siguientes características: resolución por defecto WXVGA 
(1280x800) escritorio 3D con widgets rediseñados, nuevos componentes y vistas, 
notificaciones mejoradas, arrastrar y soltar, nuevo, cortar, y pegar, barra de 
acciones para que las aplicaciones dispongan de un menú contextual siempre 
presente y otras características para aprovechar las pantallas más grandes. 
 
Se mejora la reproducción de animaciones 2D/3D gracias al renderizador OpenGL 
acelerado por hardware. El nuevo motor de gráficos Rederscript saca un gran 
rendimiento de los gráficos en Android e incorpora e incorpora su propia API. 
 
Primera versión de la plataforma que soporte procesadores multinúcleo. La 
máquina virtual Dalvik ha sido optimizada para permitir multiproceso, lo que 
permite una ejecución más rápida de las aplicaciones, incluso aquellas que son 
de hilo único. 
 
Se incorporaron varias mejoras multimedia, como listas de reproducción a través 
de HTTP Live Streaming, soporte a la protección de derechos musicales (DRM) y 
soporte para la transferencia de archivos multimedia a través de USB con los 
protocolos MTP y PTP. 
 
En esta versión se añaden nuevas alternativas de conectividad, como las nuevas 
API de Bluetooth A2DP y HSP con streaming de audio. También se permite 
conectar teclados completos por USB o Bluetooth. 
 
El uso de los dispositivos en un entorno empresarial es mejorado. Entre las 
novedades introducidas destacamos las nuevas políticas administrativas con 
encriptación del almacenamiento, caducidad de contraseña y mejoras para 
administrar los dispositivos de empresa de forma eficaz. 
 
A pesar de la nueva interfaz gráfica optimizada para tabletas, Android 3.0 es 
compatible con las aplicaciones creadas para versiones anteriores. La tecla de 
menú, inexistente en las nuevas tabletas, es reemplazada por un menú que 
aparece en la barra de acción (ActionBar) 
 
Android 3.1 nivel de API 12 (mayo 2011) 
Se permite manejar dispositivos conectados por USB (tanto host como 
dispositivo). Protocolo de transferencia de fotos y video (PTP/MTP) y de tiempo 
real (RTP). Bloqueo de Wi-Fi de alto rendimiento, manteniendo conexiones Wi-Fi 
de alto rendimientos cuando la pantalla del dispositivo está apagada. 
 
Android3.2 nivel de API 13 (julio 2011) 
Mejoras de soporte de hardware, incluyendo optimizaciones para un amplio rango 
de tabletas. Se incrementó la capacidad de las aplicaciones para acceder a 
archivos de las tarjetas SD, por ejemplo para sincronización. Se implementó el 
29 
 
modo de vista de compatibilidad para aplicaciones que no han sido optimizadas 
para resoluciones de pantallas de tabletas. Se añaden nuevas funciones de 
soporte de pantalla, dando a los desarrolladores un mayor control sobre la 
apariencia de la pantalla en diferentes dispositivos. 
 
Android Ice Cream Sandwich 4.0 nivel de API 14 (octubre 2011) 
La característica más importante es que se unifican las dos versiones anteriores 
(2.x para teléfonos y 3.x para tabletas) en una sola compatible con cualquier tipo 
de dispositivo. Entre las características más interesantes destacamos: 
 
Se introduce un nuevo interfaz de usuario totalmente renovado. Por ejemplo se 
reemplazan los botones físicos por botones en pantalla (como ocurría en las 
versiones 3.x). 
 
Un nuevo API de reconocedor facial que permite, entre otras muchas aplicaciones 
desbloquear el dispositivo a su propietario. También se mejora en el 
reconocimiento de voz. Por ejemplo se puede empezar a hablar en cuanto 
pulsamos el botón. 
 
Aparece un nuevo gestor de tráfico de datos por internet, donde podremos ver el 
consumo de forma gráfica y donde podremos definir los límites a ese consumo 
para evitar cargos inesperados con la operadora. Incorpora herramientas para la 
edición de imágenes en tiempo real, con herramientas para distorsionar, 
manipular e interactuar con la imagen al momento de ser capturada. Se mejora el 
API para comunicaciones por NFC y la integración con redes sociales. 
 
En diciembre de 2011 aparece una actualización de mantenimiento (versión 4.0.2) 
que no aumenta el nivel de API 
 
Android 4.0.3 nivel de API 15 (diciembre 2011) 
Se añaden numerosas optimizaciones y corrección de errores. Mejoras en los 
gráficos, calendario, bases de datos, corrección ortográfica y funcionalidades 
Bluetooth. Se implementa una nueva API para desarrolladores, incluyendo una 
API de actividad social en el proveedor de contactos. Se agregan nuevas 
aplicaciones de la cámara en mejora de la estabilidad en los videos y resolución 
QVGA. Se implementan mejoras de accesibilidad tales como la mejora de acceso 
al contenido para lectores de pantalla. 
 
Android 4.0.4 (noviembre 2012) 
Se añadieron a ésta versión, mejoras de estabilidad, un mejor rendimiento de la 
cámara, rotación de la pantalla más fluida y mejoras en el reconocimiento de los 
números en el teléfono. 
 
Android Jelly Bean 4.1 nivel de API 16 (julio 2012) 
En ésta versión se hace hincapié en mejorar un punto débil de Android: la fluidez 
de la interfaz de usuario. Con este propósito se incorporan varias técnicas, como: 
sincronismo vertical, triple búfer y aumentar la velocidad del procesador al tocar la 
pantalla. 
 
30 
 
Se mejoran las notificaciones con un sistema de información expandible 
personalizada. Los widgets de escritorio pueden ajustar su tamaño y tomar su 
espacio de forma automática al situarlos en el escritorio. El dictado por voz puede 
realizarse sin conexión a Internet. 
Se introducen varias mejoras en Google Search. Se potencia la búsqueda por voz 
con resultados en forma de ficha. La función Google Now permite utilizar 
información de posición, agenda y hora en las búsquedas. 
 
Se incorporan nuevos soportes para usuarios internacionales: como texto 
bidireccional y teclados instalables. Para mejorar la seguridad, las aplicaciones 
son cifradas. También se permiten actualizaciones parciales de aplicaciones. 
 
Android 4.2 nivel de API 17 (noviembre 2012) 
Una de las novedades más importantes es que podemos crear varias cuentas de 
usuario en el mismo dispositivo. Aunque, esta característica solo está disponible 
en tabletas. Cada cuenta tendrá sus propias aplicaciones y configuración. 
 
Los widgets de escritorio pueden aparecer en la pantalla de bloqueo. Se incorpora 
un nuevo teclado predictivo deslizante al estilo Swype. Posibilidad de conectar 
dispositivo y TVHD mediante Wi-Fi (miracast). Mejoras menores en las 
notificaciones. Nueva aplicación de cámara que incorpora la funcionalidad Photo 
Sphere para hacer fotos panorámicas inmersivas en 360°. 
 
Android 4.3 nivel de API 18 (julio 2013) 
Soporte para Bluetooth de baja energía. Incorpora la versión 3.0 de OpenGL ES. 
Implementa el modo de perfiles con acceso restringido. Se mejora la escritura, la 
seguridad, el modo de conexión externa y de desarrollador. Se añade el soporte 
para más de 5 idiomas algunos de ellos son el hebreo y árabe. Se agrega la 
función de autocompletar en el marcado. 
 
Permite enviar a la impresora fotos, documentos y páginas web desde el 
Smartphone o tableta de manera inalámbrica mediante Google Cloud Print. Se 
implementa una nueva máquina virtual de ejecución experimental Android 
Runtime (ART). Además de implementar una nueva funcionalidad cuando se 
recibe la llamada de un número desconocido, el dispositivo buscará coincidencias 
en una lista local de Google Maps. 
 
Android KitKat 4.4 nivel de API 19 (octubre 2013) 
 
Se implementa de manera opcional para desarrolladores la máquina virtual ART. 
La barra de estado y la barra de navegación ahora poseen transparencia, estas 
misma se ocultan en determinadas aplicaciones para permitir la visualización en 
pantalla completa. Se mejora el rendimiento del sistema. Se corrigen los 
problemas en el sonido de las aplicaciones. Se implementó el acceso directo a las 
fotos desde la aplicación de la cámara, siendo este un paso más hacia la 
integración como galería por defecto. Existe la posibilidad de impresión por Wi-Fi. 
Los monitores de actividad de red y señal son desplazados al menú de ajustes 
rápidos. Así mismo el widget de acceso rápido a Ajustes que hasta ahora permitía 
activar y desactivar la localización, ahora permite cambiar también los modos de 
ahorro de energía. En Android 4.3 se añadía soporte a Bluetooth Smart pero sólo 
31 
 
permitía sincronizar hasta 4 dispositivos, ahora a partir de Android 4.4.1 el límite 
se aumentó hasta 7 dispositivos 
 
 
Android Lollipop 5.0 nivel de API 20 (noviembre de 2014) 
 
Las características esenciales y de manera general de ésta nueva versión de 
Android son las siguientes: 
 
Material Design: Un diseño intrépido, colorido y sensible interfaz de usuario para 
las experiencias coherentes e intuitivos en todos los dispositivos. Movimiento de 
respuesta natural, iluminación y sombras realistas y familiares elementos visuales 
hacen que sea más fácil de navegar su dispositivo. Nuevos colores vivos, 
tipografía e imágenes de ayuda de borde a borde de enfocar su atención. 
 
Notificaciones: Nuevas formas de controlar cuándo y cómo se reciben mensajes - 
sólo ser interrumpido cuando se quiere ser. Ver y responder a mensajes 
directamente desde la pantalla de bloqueo. Incluye la capacidad de ocultar 
contenido sensible para estas notificaciones. Se puede programar el tiempo 
durante el cual sólo las notificaciones de prioridad aparecen. También, las 
llamadas entrantes no interrumpen lo que estés haciendo. Se puede optar por 
responder a la llamada o simplemente seguir haciendo lo que se esté haciendo. 
Clasificación más inteligente de notificaciones. Ver todas las notificaciones en un 
solo lugar tocando la parte superior de la pantalla. 
 
Batería: Una característica de ahorro de batería que se extiende el uso de 
dispositivos de hasta 90 minutos. El tiempo estimado de batería restante aparece 
cuando el dispositivo está enchufado. El tiempo restante de batería antes de tener 
que cargar el dispositivo de nuevo ahora se puede encontrar en la configuración 
de la batería. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
32 
 
1.8. Comparativa de Android frente a otras plataformas 
 
A continuación se presentará una tabla comparativa de Android en su versión más 
reciente frente a otrasplataformas. 
Tabla 1. Android frente a otras plataformas 
Fuente: http://www.androidcurso.com/index.php/tutoriales-android-fundamentos/31-unidad-1-
vision-general-y-entorno-de-desarrollo/98-comparativa-con-otras-plataformas 
 
 
 
 
 
 
Apple iOS 8 Android 5.0 Windows Phone 8 BlackBerry 10 Firefox OS 2.2 
Compañía 
Apple 
Open Handset 
Alliance 
Microsoft BlackBerry 
Mozilla 
Foundation 
Núcleo S.O. Mac OS X Linux Windows NT QNX Linux 
Licencia Propietaria Libre y abierto Propietaria Propietaria Libre y abierto 
Año de lanzamiento 2007 2008 2010 1999 2013 
Fabricante único Si No No Si No 
Variedad de 
dispositivos Modelo único Muy Alta Media Baja Muy baja 
Soporte memoria 
externa 
No Si Si Si Si 
Motor del navegador 
web 
WebKit 
WebKit/Chromium 
(Blink) 
Trident WebKit WebKit 
Tienda de aplicaciones App Store Google Play 
Windows 
Marketplace 
BlackBerry 
World 
Firefox 
Marketplace 
Número de aplicaciones 
800,000 
(marzo 2013) 
800,000 (marzo 
2013) 
130,000 (enero 2013) 100,000 (enero 
2013 
Costo de publicar $99 / año $ 25 una vez $ 99 / año Sin costo Sin costo 
Otras tiendas sin 
supervisión 
No Si No Si Si 
Familia CPU soportada ARM ARM, MIPS, x86 ARM ARM ARM, x86 
Soporte 64 bits Si Si No No No 
Maquina Virtual No Dalvik / ART .net No Navegador Web 
Lenguaje de 
programación 
Objective-C, 
C++ 
Java, C++ C#, Visual Basic, C++ C, C++, Java HTML5, CSS, 
Javascript 
Plataforma de 
desarrollo 
Mac Windows, Mac, 
Linux 
Windows Windows, Mac Windows, Mac, 
Linux 
Multiusuario No Si No No No 
Modo Invitado Si Si No No No 
3
3
 
 
1
.9
. 
M
a
p
a
 m
e
n
ta
l d
e
 A
n
d
ro
id
 
 
 
Fuente: E
laboración propia (2014) 
 
4
Cti
V¡0'40'"" 
PrCNeedores 
de contenldo 
.. ,¡."'iIP' 
.. 
~ 
'\~~ 
~" 
1'. Jl.1)o¡c:-. 
" ~ 
(.1 !,l.{ 
oC 
Qli'ftrl ,.IIdIO 
.;' 
~ .<0 
<1'" 
"""''' .. ~ "'-'" "4,:. 
R, 
Linux 
Gr! 
"'. . ..... ~ , 
1/ 
! ~# 
' .. 
34 
 
2. Descripción del Podcast de la UNAM 
El proyecto Podcast, tiene como objetivo promover en audio y video, actividades 
académicas, cursos, talleres, diplomados y conferencias, previamente grabados 
para su consulta en Internet. 
 
 
 
Figura 2.1. Sitio de internet del Podcast de la UNAM 
Fuente: Elaboración propia (2014) 
 
En el panel de la derecha se pueden observar las categorías que existen dentro 
del mismo. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 2.2. Categorías del Podcast de la UNAM 
Fuente: Elaboración propia (2014) 
35 
 
El Podcast de la UNAM cuenta con más de 30 categorías y algunas contienen 
varias subcategorías. Un Podcast cuenta con un archivo índice (feed) que 
almacena todas las entregas publicadas en el programa, lo que facilita su 
publicación digital. En la siguiente figura podemos ver el feed RSS del mismo. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 2.3. Canal RSS del Podcast de la UNAM 
Fuente: Elaboración propia (2014) 
 
Sobre el sitio se pueden visualizar los videos como vemos en la figura 2.4. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 2.4. Visualización de los videos en el sitio 
Fuente: Elaboración propia (2014) 
 
36 
 
 
Así mismo se pueden reproducir en una ventana emergente, si así se desea. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 2.5. Visualización de los videos en una ventana emergente 
Fuente: Elaboración propia (2014) 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
37 
 
 
 
 
Y también se encuentran disponibles para su descarga 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 2.6. Descarga de un video del Podcast de la UNAM 
Fuente: Elaboración propia (2014) 
 
 
 
 
 
 
 
 
 
 
 
 
38 
 
 
3. Objetivo de la aplicación Podcast UNAMóvil 
 
El objetivo de la aplicación Podcast UNAMóvil es el brindar y facilitar un nuevo 
canal de acceso al Podcast de la UNAM con la finalidad de compartir y fomentar 
la cultura y el aprendizaje para toda la comunidad universitaria a través del 
material de audio y video que existe en dicho Podcast. 
 
4. Desarrollo e implementación 
El formato de Sindicación Realmente Simple (RSS por sus siglas en inglés, Really 
Simple Syndication), es un formato XML para sindicar o compartir contenido en la 
web. Se utiliza para difundir información actualizada frecuentemente a usuarios 
que se han suscrito a ésta fuente de contenidos de algún sitio. El Podcast de la 
UNAM cuenta con su canal RSS, el cual ha sido aprovechado para el desarrollo 
de dicha aplicación móvil ya que se implementó para que el Podcast de la UNAM 
se visualice de forma correcta en un dispositivo móvil con el sistema operativo 
Android. Para ello se implementó una clase con la cual se procesa el parseo1 del 
archivo xml mediante el Modelo de Objetos del Documento o Modelo en Objetos 
para la representación de Documentos (DOM por sus siglas en inglés, Document 
Object Model) el cual proporciona un conjunto estándar de objetos para 
representar documentos html y xml, un modelo estándar sobre cómo pueden 
combinarse dichos objetos, y una interfaz estándar para acceder a ellos y 
manipularlos. A través de DOM, los programas pueden acceder y modificar el 
contenido, estructura y estilo de los documentos html y xml, que es para lo que se 
diseñó principalmente. 
 
A continuación se describirá cada segmento de código de la clase que procesa 
dicho parseo. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
Es el proceso de transformar una entrada de texto en una estructura de datos 
39 
 
Inicialmente se importan todos los paquetes de las clases que se ocuparán, en 
primera instancia se importan los paquetes de java que se utilizarán para la 
obtención de los datos de la url del Podcast de la UNAM, posteriormente se 
importan los paquetes que nos ayudan a construir un documento xml, por último 
como se mencionó anteriormente se importan los paquetes de DOM que se 
utilizarán. 
 
En las siguientes líneas de código, inicialmente se crea una nueva clase pública 
llamada XMLParser, a esta clase se le agregan dos variables globales, una 
variable privada de tipo URL y llamada del mismo modo como url, una variable 
estática de tipo int llamada numItems. Posteriormente se crea el constructor de 
la clase el cual recibe como parámetro una variable de tipo String que para éste 
caso se le llama url, lo que se inicializa en el constructor es la variable global url 
asignando lo que se reciba en la variable local url del constructor, a su vez se 
maneja la excepción de ésta variable si la url que se reciba como una cadena de 
tipo String no está escrita de forma correcta en alguna de sus partes arrojando 
como resultado la parte errónea de la misma. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Posteriormente se crea un método llamado parse() el cual es un método público 
y de tipo LinkedList<HashMap<String, String>> ya que para ordenar los se 
formaran pares de clave y valor dentro del HashMap y para evitar las colisiones 
dentro de éste mismo se organizan en una lista ligada. Dentro del método se 
comienza por instanciar un objeto de la clase DocumentBuilderFactory llamado 
factory para que se pueda construir el documento xml y pueda ser leído por 
DOM. Seguido de esto se crea un objeto del tipo LinkedList<HashMap<String, 
String>> llamado listaDatos y un objeto de tipo HashMap<String, String> 
llamado entrada para formar los pares de datos. 
 
 
 
 
 
 
 
 
40 
 
Posteriormente se abre un bloque try-catch donde se instancia un objeto de tipo 
DocumentBuilder llamado builder a través del objeto factory que se creó 
anteriormente, seguido de esto se instancia un objeto de tipo Document llamado 
dom que inicializa una conexión mediante el método parse() del objeto builder 
a la url que se ha recibido como parámetro a través de los método 
openConnection() y del método getInputStream(), en la siguiente línea se 
crea un objeto de tipo Element llamado root al cual se le asigna lo que se 
obtiene del método getDocumentElement() del objeto dom, después de estose 
crea un objeto llamado ítems de tipo NodeList al cual se le asigna lo que se 
obtiene del método getElementByTagName() el cual obtiene los elementos del 
documento xml de la cadena que se le haya indicado como parámetro que en 
este caso es ítem, éste método corresponde al objeto root que se instanció en la 
línea inmediata superior. Por último se asigna a la variable numItems lo que que 
se obtuvo del método getLength() el cual obtiene el número de elementos con la 
cadena ítem dentro del documento xml, éste método corresponde al objeto ítems 
que se creó en la línea anterior a ésta 
 
 
 
 
Una vez que se ha realizado lo anterior, se inicia un ciclo for el cual se inicializa 
desde cero hasta la cantidad de ítems que se hayan obtenido en la variable 
numItems y se va incrementando ésta variable de control de tipo entera. Dentro 
del ciclo, se termina de instanciar el objeto entrada de tipo HashMap que se creó al 
inicio del método, se crea un objeto de tipo Node llamado ítem al cual se le asigna 
lo que se obtenga en el objeto ítems para que con la variable de control del ciclo 
for se realice un recorrido de los elementos que se especifiquen dentro del 
documento xml lo cual se indica en la línea siguiente de código donde con el 
objeto nodos de tipo NodeList se obtienen a través del método 
getChildNodes() los nodos hijos en este caso de cada elemento o nodo ítem del 
documento xml 
 
 
 
 
 
 
 
 
 
 
 
 
 
41 
 
 
Posteriormente se abre un nuevo ciclo for anidado el cual se inicializa desde cero 
con la variable j de tipo int hasta el número de nodos que haya dentro de cada 
elemento ítem lo cual se indica en la primera línea dentro del ciclo para que se 
realice el recorrido de éstos elementos y es asignado a una variable de tipo Node 
llamada itemData, después de esto a través de ésta misma variable se obtienen 
mediante el método getNodeName() los nombres de los elementos que contienen 
los nodos ítems y se asignan a una variable de tipo String llamada nombre. 
 
 
 
 
Enseguida de lo anterior se abre una condición if-else-if, dentro de la 
condición if se evaluará con el método equalsIgnoreCase() una búsqueda 
comparando la cadena dada como parámetro, en este caso “title” con los 
elementos del nodo ítem y a su vez ignorando aquellos que no sean iguales, si 
esta condición se cumple entonces se añade como clave con el método put() del 
objeto entrada que es de tipo HashMap. Para la condición de else-if la condición 
se evalúa del mismo modo, sólo que en éste caso la cadena a buscar y comparar 
es “link” y de la misma forma, si ésta condición se cumple entonces de la misma 
manera se añade lo que exista en la cadena link a la tabla de HashMap como 
valor, de esta forma la tabla de HashMap se llena con pares de clave-valor con 
cada iteración del ciclo for interno, por último se cierra dicho ciclo 
 
 
 
 
 
 
 
 
 
 
 
Culminando con la función que se implementa en la clase XMLParser, con el 
método add() del objeto listaDatos, se agregan todos los datos obtenidos del 
parseo y ordenados en la tabla HashMap a la lista ligada, de ésta forma como se 
mencionaba se evita que los datos colisionen dentro de la tabla HashMap. En la 
línea subsecuente se cierra el ciclo for externo. Se cierra el bloque try y se 
maneja la excepción en la sentencia catch donde se puede obtener alguna 
excepción en tiempo de ejecución y se cierra el cuerpo de dicha sentencia. En la 
línea subsecuente la clase regresa el objeto listaDatos como se indicó al inicio 
del método en el tipo de valor de retorno por lo que la clase que reciba estos 
datos para su presentación debe de instanciar y parametrizar un objeto del mismo 
tipo para procesar correctamente todos los datos. Por último se cierra la clase 
XMLParser. 
42 
 
 
 
 
 
Continuando con el desarrollo de la aplicación, se crea una clase llamada Datos 
(línea 3 a la 21), con el único propósito de mantener protegida la variable que va a 
contener la url a la que se conecte y evitar que en el código que se utilice 
posteriormente se modifique arbitrariamente. La clase Datos contiene la variable 
de acceso privado y de tipo String llamada feedUrl (línea 5). En el constructor 
de ésta clase (línea 7 a 9) se inicializa dicha variable global con la variable local 
del constructor del mismo tipo String llamada urlCanal. Posteriormente de la 
línea 11 a la 14 se crea un método setUrl() que recibe como parámetro una 
variable de tipo String llamada urlCanal para que en el momento en que se 
requiera se establezca alguna otra url a la que se desee conectar, asignando un 
nuevo valor hacia la variable feedUrl mediante su variable local urlCanal, 
seguido de esto, de la línea 16 a la 19 se crea el método getUrl() para obtener 
de manera inmediata el valor que al momento exista en la variable feedUrl. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
43 
 
Posteriormente, se crea la actividad principal que va a contener y mostrar todos 
los datos al usuario, en éste caso estos mismos se trataran como las 
publicaciones más recientes que existan en el Podcast de la UNAM, para ello se 
implementó una vista en forma de lista, dicho elemento gráfico de la interfaz de 
usuario se le conoce en Android como un adaptador, el cual como su nombre lo 
indica, adaptará los datos que se obtuvieron del parseo gracias a la clase anterior 
a una lista que puede ser visualizada por el usuario, dicho adaptador se le conoce 
como ListView, el cual se comienza definiendo y diseñando desde código xml con 
ciertos atributos en específico como se puede observar en el código siguiente. 
 
 
 
 
 
En la línea 1 se declara el documento xml. Para el diseño de una actividad en 
Android se comienza definiendo un elemento raíz, este elemento raíz se le 
conoce como el contenedor padre de los elementos o vistas que contenga, el cual 
se conoce como LinearLayout (línea 3 a la 9), para éste caso se engloban sus 
atributos donde en primer lugar se tiene un identificador el cual se crea con el 
atributo android:id = “@+id/LL01” llamado LL01. Posteriormente se indica el 
ancho con el atributo android: layout_width = “match_parent” el cual indica 
que va a cubrir todo el ancho de la actividad. De la misma forma en el atributo 
android: layout_height = “match_parent” indica que el alto del 
LinearLayout cubrirá todo el alto de la actividad. 
 
 
 
 
44 
 
Con el atributo android: orientation = “vertical” se indica si la orientación 
de la actividad será vertical u horizontal, en este caso es vertical. En la línea 8 con 
el atributo android: background = “@drawable/fondo2 se define un fondo 
personalizado para la aplicación. En la línea 9 indica la url donde Android provee 
todos los recursos para los esquemas de diseño. 
 
Posteriormente de las líneas 12 a 15 se define una vista, la cual es una franja de 
color que cubre todo el ancho del LinearLayout que lo contiene y de altura como 
se indica en la línea 14 tiene una medida de 5dp lo cual significa densidad en 
pixeles. En la línea 15 con el atributo background se define un color con efecto 
degradado. Este efecto, es un recurso de tipo drawable que se definió en otro 
archivo xml llamado degradado.xml, en el siguiente listado de código se puede 
observar que se define como gradient, en sus atributos se establece un color 
inicial, un color final y un ángulo el cual puede ser de 0, 90, 180 o 270 grados, 
para este caso es de cero. 
 
A su vez, los colores que podrán utilizarse en la aplicación se definieron en otro 
archivo xml de recurso el cual se llama colors.xml 
 
Dentro de éste archivo se encuentran definidos con nombres personalizados, 
todos los colores y para cada uno de ellos se especifica su valor hexadecimal. 
45 
 
Continuando con el diseño de nuestra actividad principal de las líneas 17 a la 22 
se define el ListView, el cual, como se mencionaba, ayudará a que la actividad 
adapte una forma de lista, en sus atributos podemos observar que se le asigna un 
identificador llamado list_data para que posteriormente