Evolucion Web

Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT
UNIVERSIDAD NACIONAL DE TRUJILLO
Facultad de Ciencias Físicas y Matemáticas
Escuela Académico Profesional de Informática
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
DESARROLLO DE UNA APLICACIÓN ANDROID PARA

AT C
M E
EL CONTROL DE UN DISPOSITIVO MÓVIL USANDO

Y AD
ARQUITECTURA CLIENTE-SERVIDOR
T EC
IO
Pedro Luis Novoa Ruiz

BL
BI
Trujillo - La Libertad
2017
Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú.
Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN

AT C
M E
Y AD
T EC
IO
BL
BI
PEDRO LUIS NOVOA RUIZ
S
CA
SI
AS FÍ
IC S
ÁT CIA
Tesis presentada a la Escuela Académico Profesional de Informática en la Fa-
cultad de Ciencias Físicas y Matemáticas de la Universidad Nacional de Tru-
EM IEN
jillo, como requisito parcial para la obtención del Título profesional de Ing.
Informático
AT C
M E
Y AD
ASESOR: EDWIN R. MENDOZA TORRES

T EC
IO
Trujillo - La Libertad
BL
2017
BI
II
HOJA DE APROBACIÓN
Desarrollo de una Aplicación Android para el Control de un

Dispositivo Móvil usando Arquitectura Cliente-Servidor
S
CA
Pedro Luis Novoa Ruiz
SI
AS FÍ
Tesis defendida y aprobada por el jurado examinador:
IC S
ÁT CIA
EM IEN
Prof. Edwin R. Mendoza Torres - Asesor
Departamento de Informática - UNT
AT C
M E
Prof. José L. Peralta Luján

Y AD

EC
Prof. José A. Díaz Pulido

T

IO
BL
Trujillo, 25 de octubre del 2017

BI
III
Dedico esta tesis a :
Mis padres, por el apoyo en los buenos y adversos momentos del desarrollo de
este proyecto. Por estar presentes, por la confianza y estimulación a la superación
en lo personal y profesional cada día.
S
CA
Mis hermanos, por ser la motivación durante el inicio y culminación de mis
SI
estudios, y ahora para la realización de este trabajo de investigación.
AS FÍ
IC S
ÁT CIA
EM IEN
AT C
M E
Y AD
T EC
IO
BL
BI
IV
Agradecimientos
A mi asesor Ing. Edwin R. Mendoza Torres, por aceptar este proyecto de tesis,
por su apoyo y la ayuda otorgada durante el proceso de desarrollo del mismo.
S
CA
A los profesores de la carrera, que durante el proceso de mi formación me otor-
SI
garon los conocimientos y consejos necesarios para la elaboración de este estudio.
AS FÍ
IC S
A mis familiares y amigos, por la perseverancia de sus consejos que fueron bien
ÁT CIA
recibidos y por su apoyo para con este proyecto.
EM IEN
AT C
M E
Y AD
T EC
IO
BL
BI
Resumen
El trabajo de investigación percibe el objetivo de control de un dispositivo móvil
en un entorno de trabajo, mediante el desarrollo de una aplicación Android con
el soporte de un Servidor y una Base de Datos de almacenamiento. El control se
S
planteó con registro de datos y ejecución de acciones remotas en el dispositivo.
CA
En cuanto a los datos se puede mencionar información del hardware, software y
SI
otras características. También a su vez tener funciones activas automatizadas que
AS FÍ
respondan a eventos de cambios e interacción desde el Servidor.
IC S
ÁT CIA
Para la comunicación se hizo uso de la arquitectura cliente-servidor basada en
RMI (Remote Method Invocation) y en una implementación de Java RMI. Además

EM IEN
se empleó una comunicación secundaria con FCM (Firebase Cloud Messaging).

AT C
La fase de desarrollo y pruebas de la aplicación Android se fundamentó en los

M E
Y AD
cambios de versiones de Android y en las funciones de compatibilidad de versiones
4 en adelante, haciendo posible su ejecución dirigida a dispositivos de tipo teléfo-

EC
nos y tabletas; logrando así mismo buenos resultados en las acciones y eventos de
T
control establecidos.
IO
BL
Palabras claves: control, cliente-servidor, RMI, dispositivo móvil, aplicación An-

BI
droid.
VI
Abstract
The research work has the objective of control of a mobile device in a working
environment, through the development of an Android application with the support
S
of a server and a storage database. The control is carried out with data logging
CA
and remote execution of actions on the device. With regard to the data include
SI
information on the hardware, software, and other features. Also, at the same time
AS FÍ
run active and automated functions that respond to events of changes and interaction
IC S
ÁT CIA
from the server, performing an exchange of data, such as messages, inventories or
reports in general.
EM IEN
For communication use was made of the client-server architecture based on

AT C
RMI (Remote Method Invocation) and an implementation of Java RMI. In addition

M E
to the use of FCM (Firebase Cloud Messaging) as a secondary communication.

Y AD
The stage of development and testing of the mobile application, was based on
EC
the changes of Android versions and in the functions of support for versions 4
T
onwards, making possible its implementation directed to devices of type phones

IO
and tablets; thus, obtaining good results in the actions and events set for the control.
BL
Keywords: control, client-server, RMI, mobile device, Android application.

BI
VII
Glosario de términos
TCP: Protocolo Control de Transmisión. Protocolo orientado a conexión.
TCP/IP: Protocolo Control de Transmisión/Protocolo de Internet. Define un conjunto de
S
CA
reglas para la comunicación en una red.
SI
API: Interfaz de programación de aplicaciones.
AS FÍ
Framework: Marco de trabajo.
IC S
ÁT CIA
SDK: Kit de herramientas de Desarrollo de Software.
EM IEN
IDE: Entorno de Desarrollo Integrado. Para el desarrollo de aplicaciones.
AT C
JVM: Máquina Virtual de Java.

M E
Y AD
APK: Fichero resultante de la compilación de una aplicación Android.
APP: Acrónimo de Aplicación, referente en este proyecto a una aplicación móvil.

T EC
XML: Formato de transferencia de información basado en etiquetas, atributos y valores.

IO
JSON: Formato de transferencia de información basada en tipos de datos de lenguajes de

BL
programación como objetos, arreglos y tipos básicos.

BI
VIII
Índice de figuras
S
CA
1.1. Cuota de mercado de Android del 2016. . . . . . . . . . . . . . . . . . . . . . . . 3
SI
2.1. Arquitectura de comunicación de Java RMI. . . . . . . . . . . . . . . . . . . . . . 17
AS FÍ
2.2. Arquitectura de comunicación de LipeRMI. . . . . . . . . . . . . . . . . . . . . . 20
IC S
2.3. Arquitectura del Sistema Android. . . . . . . . . . . . . . . . . . . . . . . . . . . 26
ÁT CIA
2.4. Ciclo de Vida de una Actividad. . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
EM IEN
2.5. Ciclo de Vida de un Servicio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.6. Arquitectura de FCM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

AT C
M E
2.7. Fases y etapas de la metodología ágil Mobile-D. . . . . . . . . . . . . . . . . . . . 43

Y AD
3.1. Arquitectura general del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . 52

EC
3.2. Arquitectura de la comunicación del proyecto. . . . . . . . . . . . . . . . . . . . . 53

T
3.3. Modelo de datos E-R de la comunicación del proyecto. . . . . . . . . . . . . . . . . 58

IO
3.4. Implementación del Cliente RMI de Servidor RMI Principal en la aplicación Android. 60
BL
3.5. Implementación del Servidor RMI en la aplicación Android. . . . . . . . . . . . . . 61

BI
IX
3.6. Diagrama de flujo de recepción de mensajes de FCM en la aplicación Android. . . . . 62
3.7. Servicio de recepción de mensajes de FCM en la aplicación Android. . . . . . . . . . 62
3.8. Registro de políticas de Administración de Dispositivos de la aplicación Android. . . . 63
3.9. Registro del BrodcastReceiver de la API Administración de Dispositivos de la aplica-
ción Android. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
S
CA
3.10. Obtener datos de localización usando el GPS o la Red en la aplicación Android. . . . . 64
3.11. Estructura de mensaje de las acciones remotas. . . . . . . . . . . . . . . . . . . . . 65
SI
3.12. Diagrama de flujo del procesador de acciones remotas de la aplicación Android. . . . . 66
AS FÍ
3.13. Procesador de acciones remotas de la aplicación Android. . . . . . . . . . . . . . . 67
IC S
ÁT CIA
3.14. Implementación del Servidor RMI Principal. . . . . . . . . . . . . . . . . . . . . . 69
3.15. Implementación del Cliente de Servidor RMI Android. . . . . . . . . . . . . . . . . 70

EM IEN
3.16. Cliente Web de FCM para envío de mensajes. . . . . . . . . . . . . . . . . . . . . 71

AT C
3.17. Diagrama de flujo de envío de acciones remotas al dispositivo Android. . . . . . . . . 72

M E
3.18. Envío de acciones remotas al dispositivo Android. . . . . . . . . . . . . . . . . . . 73

Y AD
3.19. Diagrama de flujo de registro y actualización de datos de dispositivos. . . . . . . . . 74

EC
3.20. Métodos principales de operaciones sobre la base de datos con Hibernate. . . . . . . . 75

T
IO
BL
BI
Índice de tablas
S
CA
2.1. Comparación de JAVA RMI y LipeRMI . . . . . . . . . . . . . . . . . . . . . 47
SI
2.2. Comparación de Sistemas Operativos Móviles. . . . . . . . . . . . . . . . . . 48
AS FÍ
2.3. Comparación de la máquina virtual Dalvik y ART de Android. . . . . . . . . . 49
IC S
2.4. Comparación de la metodología Mobile-D y RUP. . . . . . . . . . . . . . . . . 50
ÁT CIA
3.1. Fallos y correcciones de pruebas de comunicación del proyecto. . . . . . . . . 76
EM IEN
3.2. Pruebas de módulos y componentes de la comunicación del proyecto. . . . . . 77
3.3. Fallos y correcciones de pruebas de compatibilidad. . . . . . . . . . . . . . . . 78

AT C
M E
3.4. Fallos y correcciones de pruebas en tipos de dispositivos con Android. . . . . . 79

Y AD
3.5. Fallos y correcciones de pruebas de funcionalidad de la aplicación Android. . . 80
3.6. Fallos y correcciones de pruebas de funcionalidad del servidor de control. . . . 82

T EC
IO
BL
BI
XI
Índice general
S
CA
Dedicatoria IV
SI
AS FÍ
Agradecimientos V
IC S
Resumen VI
Abstract
ÁT CIA VII
EM IEN
Glosario de términos VIII

AT C
M E
Índice de Figuras X
Y AD
Índice de Tablas XI
EC
1. Introducción 1
T
IO
1.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
BL
1.2. Formulación del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

BI
XII
1.3. Importancia de la investigación . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1. Generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.2. Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Contribución de la investigación . . . . . . . . . . . . . . . . . . . . . . . . . 6
S
CA
1.6. Metodología de la investigación . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.7. Estructura de la tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
SI
AS FÍ
2. Marco teórico 11
IC S
2.1. Trabajos previos de la investigación . . . . . . . . . . . . . . . . . . . . . . . 11
ÁT CIA
2.2. Arquitectura cliente-servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
EM IEN
2.2.1. Definición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2. Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
AT C
2.3. Java RMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

M E
Y AD
2.3.1. Definición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
EC
2.4. Lipe RMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

T
IO
2.4.1. Definición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
BL
2.4.2. Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
BI
2.5. Dispositivos Móviles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
XIII
2.5.1. Definición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5.2. Tipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6. Sistemas Operativos Móviles . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6.1. Definición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6.2. Tipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
S
CA
2.7. Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.7.1. Definición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
SI
2.7.2. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
AS FÍ
2.7.2.1. Kernel Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 27
IC S
ÁT CIA
2.7.2.2. Abstracción de hardware (HAL) . . . . . . . . . . . . . . . 27
2.7.2.3. Entorno de ejecución . . . . . . . . . . . . . . . . . . . . . 27

EM IEN
2.7.2.4. Librerías nativas C/C++ . . . . . . . . . . . . . . . . . . . . 28

AT C
2.7.2.5. Framework de la API de Java . . . . . . . . . . . . . . . . . 28

M E
2.7.2.6. Aplicaciones del sistema . . . . . . . . . . . . . . . . . . . 29

Y AD
2.7.3. Máquinas Virtuales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

EC
2.7.3.1. Davilk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
T
2.7.3.2. ART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
IO
2.7.4. Sotfware Development Kit (SDK) . . . . . . . . . . . . . . . . . . . . 30

BL
2.8. Aplicaciones Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

BI
XIV
2.8.1. Definición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.8.2. Tipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.8.3. Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.8.3.1. Actividades . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.8.3.2. Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
S
CA
2.8.3.3. Proveedores de Contenidos . . . . . . . . . . . . . . . . . . 36
2.8.3.4. Receptores de Transmisión . . . . . . . . . . . . . . . . . . 37
SI
2.8.3.5. Intents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
AS FÍ
2.8.4. Sistema de Permisos . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
IC S
ÁT CIA
2.8.5. Opciones de almacenamiento . . . . . . . . . . . . . . . . . . . . . . 38
2.8.6. Administración de dispositivos . . . . . . . . . . . . . . . . . . . . . . 40

EM IEN
2.8.7. Firebase Cloud Messaging (FCM) . . . . . . . . . . . . . . . . . . . . 40

AT C
2.9. Metodología Mobile-D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

M E
2.9.1. Definición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Y AD
2.9.2. Fases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
EC
2.9.2.1. Exploración . . . . . . . . . . . . . . . . . . . . . . . . . . 43
T
2.9.2.2. Inicialización . . . . . . . . . . . . . . . . . . . . . . . . . 44
IO
2.9.2.3. Producción . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
BL
2.9.2.4. Estabilización . . . . . . . . . . . . . . . . . . . . . . . . . 45
BI
XV
2.9.2.5. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.10. Comparativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.10.1. Comparativa de Java RMI y Lipe RMI . . . . . . . . . . . . . . . . . . 46
2.10.2. Comparativa de Sistemas Operativos Móviles . . . . . . . . . . . . . . 48
2.10.3. Comparativa de Máquinas Virtuales de Android . . . . . . . . . . . . . 49
S
CA
2.10.4. Comparativa de Mobile-D y RUP (Rational Unified Process) . . . . . . 50
SI
3. Propuesta o tema central de la tesis 51
AS FÍ
3.1. Arquitectura General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
IC S
3.2. Arquitectura de la comunicación . . . . . . . . . . . . . . . . . . . . . . . . . 53
ÁT CIA
3.2.1. Interfaces de Métodos Remotos . . . . . . . . . . . . . . . . . . . . . 54
EM IEN
3.2.2. Componentes del Servidor de Control . . . . . . . . . . . . . . . . . . 55
3.2.3. Componentes del Cliente en Android . . . . . . . . . . . . . . . . . . 56

AT C
3.3. Modelo de datos de la comunicación . . . . . . . . . . . . . . . . . . . . . . . 57

M E
Y AD
3.4. Desarrollo de la aplicación Android . . . . . . . . . . . . . . . . . . . . . . . 59
3.4.1. Módulo de Cliente RMI de Servidor RMI Principal . . . . . . . . . . . 59

EC
3.4.2. Módulo de Servidor RMI Android . . . . . . . . . . . . . . . . . . . . 60

T
IO
3.4.3. Módulo de Firebase Cloud Messaging . . . . . . . . . . . . . . . . . . 61

BL
3.4.4. Módulo de Administración de dispositivos . . . . . . . . . . . . . . . 63

BI
3.4.5. Módulo de Geolocalización . . . . . . . . . . . . . . . . . . . . . . . 64
XVI
3.4.6. Módulo de Acciones Remotas . . . . . . . . . . . . . . . . . . . . . . 65
3.4.7. Otros Módulos agregados . . . . . . . . . . . . . . . . . . . . . . . . 67
3.5. Desarrollo del Servidor de Control . . . . . . . . . . . . . . . . . . . . . . . . 68
3.5.1. Módulo de Servidor RMI principal . . . . . . . . . . . . . . . . . . . . 68
3.5.2. Módulo de Cliente RMI de Servidor RMI de Android . . . . . . . . . . 69
S
CA
3.5.3. Módulo de Cliente Web de FCM . . . . . . . . . . . . . . . . . . . . . 70
3.5.4. Módulo de envío de Acciones Remotas . . . . . . . . . . . . . . . . . 71
SI
3.5.5. Módulo de Base de Datos . . . . . . . . . . . . . . . . . . . . . . . . 73
AS FÍ
3.6. Ejecución de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
IC S
ÁT CIA
3.6.1. Pruebas de comunicación . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.6.2. Pruebas de compatibilidad . . . . . . . . . . . . . . . . . . . . . . . . 78

EM IEN
3.6.3. Pruebas de dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . 79

AT C
3.6.4. Pruebas de funcionalidad . . . . . . . . . . . . . . . . . . . . . . . . . 80

M E
Y AD
4. Resultados de la tesis 83
EC
5. Consideraciones finales 88
T
5.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
IO
5.2. Trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

BL
Bibliografía 91
BI
XVII
Anexos 96
A. Interfaces y funcionalidades de la aplicación Android 96
B. Interfaces y funcionalidades del Servidor de Control 104
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
AT C
M E
Y AD
T EC
IO
BL
BI
XVIII
Capítulo 1
Introducción
S
CA
SI
En los últimos años se ha visto un gran uso masivo de los teléfonos inteligentes, tabletas
AS FÍ
y otros dispositivos móviles de funcionalidades específicas, que son de buen agrado de los
IC S
ÁT CIA
usuarios, especialmente con el modelo de negocio y el agregado de aplicaciones móviles que
se instalan en los equipos ofreciendo nuevas funcionalidades, que van desde situaciones de uso
EM IEN
personal, de manera académica y siguiendo hasta el nivel profesional en un lugar de trabajo.

AT C
La integración de hardware dedicado y sensores, ha hecho posible la convergencia de datos con

M E
otros equipos como ordenadores y la posibilidad de consumo de datos a través de diversas redes
Y AD
e internet. Estos dispositivos están en constante cambio en hardware y software, lo que apertura
EC
un marco de posibilidades en campos de investigación y desarrollo de soluciones informáticas.

T
Muchas empresas a nivel global dedicadas al rubro de hardware de móviles, han presentado
IO
al mercado una gama de dispositivos con características diferentes, generando el problema de

BL
que no todos los equipos estén al alcance de cualquier usuario y sumarle a esto también que
BI
necesitan de un sistema operativo móvil para realizar sus funciones. En cuanto al costo, es
posible obtener equipos a un bajo precio con Android como sistema.
El sistema Android actualmente posee una elevada cuota de mercado frente a los dos prin-
cipales sistemas para dispositivos móviles, que son el Sistema IOS de Apple y Windows Phone
de Microsoft. El desarrollo de aplicaciones para esta plataforma cada vez va en aumento, así
S
CA
como las herramientas de desarrolladores.
SI
AS FÍ
1.1. Motivación
IC S
ÁT CIA
La gran acogida del sistema operativo Android en dispositivos móviles, ha dado lugar a que
en una empresa por ejemplo, se considere la adquisición de estos equipos como herramienta de
EM IEN
trabajo para sus empleados, siendo estos utilizados en la misma empresa o fuera como opera-
AT C
tivos en la toma de datos en campo. Entonces de acuerdo a lo anterior mencionado, es de alta

M E
prioridad en un lugar de trabajo llevar un registro de estos dispositivos.

Y AD
Otro punto a tratar, es que cada periodo de tiempo se requiere la elaboración de inventarios o
EC
reportes, los cuales se hacen muchas veces a destiempo y de forma manual, lo que conlleva a una
T
pérdida de datos y un elevado tiempo de trabajo. Además no se tiene muchas veces un control
IO
automatizado por parte de algún administrativo, que sirva para dar soporte a los dispositivos.
BL
BI
S
CA
SI
AS FÍ
IC S
ÁT CIA Figura 1.1: Cuota de mercado de Android del 2016.
Fuente: Recuperado de https://www.strategyanalytics.com
EM IEN
1.2. Formulación del problema

AT C
M E
En este trabajo, se propone crear una aplicación móvil basado en el sistema Android, para
Y AD
responder a la siguiente pregunta:

EC
¿Cómo controlar un dispositivo móvil, usando la arquitectura cliente-servidor?

T
IO
BL
BI
1.3. Importancia de la investigación
Con la adquisición y la utilización de dispositivos móviles con Android en un entorno de
trabajo, el volumen de información que poseen y que generan conlleva a que en algún momento
se requiera una comunicación sincronizada, es decir el envío y recepción de datos frente a un
S
servidor. Además de una estructura de almacenamiento y recuperación de dichos datos cuando
CA
se requiera.
SI
El seguimiento de los dispositivos móviles se convierte en un factor prioritario, durante el
AS FÍ
ciclo de uso por los usuarios, donde el desarrollo de aplicaciones automatizadas que se encar-
IC S
ÁT CIA
guen de estas tareas repetitivas resulta de mucha utilidad, en cuanto a ahorro de trabajo y tiempo
se refiere.
EM IEN
El tener una comunicación directa y ejercer algún tipo de control programado sobre los
AT C
dispositivos mientras estos están en uso, sirve de soporte e interacción a las actividades o tareas
M E
Y AD
que se va a desempeñar con estos dispositivos.
El estudio de los dispositivos móviles con Android y el soporte de opciones de control en

EC
la realización de este proyecto, son un inicio para el aprendizaje y crecimiento profesional en

T
IO
estos campos de investigación.

BL
BI
1.4. Objetivos
1.4.1. Generales
La investigación tiene como objetivo el desarrollo de una aplicación Android para el control
de un dispositivo móvil usando arquitectura cliente-servidor.
S
CA
1.4.2. Específicos
SI
AS FÍ
a) Recopilación y análisis de la información relacionada con la arquitectura cliente-servidor
IC S
basada en RMI, sistema operativo Android y desarrollo de aplicaciones Android.
ÁT CIA
b) Elaboración de un modelado base de la comunicación cliente-servidor basada en RMI
EM IEN
para aplicaciones Java y Android.
AT C
c) Diseño y codificación de los algoritmos de comunicación basado en RMI para el cliente

M E
y servidor, realizando luego pruebas de intercambio de datos.

Y AD
d) Implementación de las interfaces de la aplicación, así como funciones específicas de envío

EC
y recepción de datos para el control del dispositivo.

T
IO
e) Ejecución de pruebas sobre el Servidor y la aplicación Android desarrollada.

BL
BI
1.5. Contribución de la investigación
Luego de la culminación de la investigación, los aportes que se logra son:
Se formaliza una arquitectura cliente-servidor base y expandible de comunicación para el
control de dispositivos con Android, que utiliza como principal componente RMI y una nueva
S
implementación de esta tecnología denominada Lipe RMI, con mejoras significativas frente a
CA
Java RMI. Además de tecnologías de nivel secundario en la comunicación como FCM, que
SI
aprovecha la conexión a internet en los dispositivos móviles y que en este proyecto nos ayuda a
AS FÍ
enviar acciones de control cuando la comunicación base no es alcanzable.
IC S
ÁT CIA
Se define una estructura base de almacenamiento, formado por una base de datos relacional
y tablas para registrar datos de los dispositivos, que permite la comunicación de la arquitectura
EM IEN
cliente-servidor y el control deseado.
AT C
Una estructura de acciones remotas de control, que se envían desde el Servidor de Control y
M E
Y AD
se ejecutan en el dispositivo móvil. Estas también son extensibles, permitiendo agregar nuevas
opciones de control que se requieran.

EC
Una aplicación cliente en Android para dispositivos móviles que envía información al Ser-
T
IO
vidor de Control y posee tareas automatizadas de control del dispositivo móvil.

BL
Una aplicación de escritorio que actúa como Servidor de Control centralizado, con soporte
BI
de una base de datos y apoyado en la aplicación cliente en Android, para ejercer un control de
los dispositivos móviles registrados.
Una alternativa de solución de control de dispositivos con Android, que mediante el estudio
realizado, puede abrir nuevas posibilidades de investigación a futuros proyectos.
S
CA
1.6. Metodología de la investigación
SI
Para llegar a los objetivos propuestos, el desarrollo de la investigación se baso en la meto-
AS FÍ
dología ágil Mobile-D y en sus fases:
IC S
ÁT CIA
1) Exploración: Recopilación de información para elaboración del Marco Teórico.
EM IEN
Análisis de la información acerca de RMI.
AT C
Análisis de la información sobre el sistema operativo Android y dispositivos móvi-

M E
les.
Y AD
Revisión de información acerca de RMI en Java y Android.

EC
Estudio de información referente al tema de base de datos.

T
IO
2) Inicialización: Diseño de la comunicación Cliente-Servidor.

BL
Modelamiento de una arquitectura gráfica para la comunicación.

BI
Identificación del nivel de comunicación y tecnologías.
Definición del modelo de datos para la comunicación.
3) Producción: Implementación del modelo cliente-servidor.
Implementación de las interfaces comunes de métodos remotos.
S
CA
Implementación de los componentes de comunicación definidos en la arquitectura
cliente-servidor.
SI
AS FÍ
Definición de una base de datos de almacenamiento en el Servidor de Control.
IC S
Tests de comunicación entre los componentes de la aplicación Android y Servidor
ÁT CIA
de Control.
EM IEN
4) Estabilización: Creación de las interfaces de la aplicación y eventos de control del dispo-
sitivo.
AT C
M E
Diseño y codificación de las interfaces para el proyecto.

Y AD
Implementación de eventos de control automatizados en el dispositivo y envío de

EC
información.
T
Implementación de acciones remotas enviadas desde el Servidor de Control y pro-

IO
cesadas en el dispositivo.
BL
BI
5) Pruebas: Ejecución de pruebas generales.
Ejecución de pruebas de comunicación, en el intercambio de datos de control entre
cliente y servidor.
Evaluación de las interfaces y funcionalidades de la aplicación.
Evaluación del desempeño, almacenamiento de datos y control del dispositivo.
S
CA
1.7. Estructura de la tesis
SI
El presente trabajo está dividido en seis capítulos. El primer capítulo presenta los aspectos
AS FÍ
generales del tema tratado: la formulación del problema, importancia de la investigación, los
IC S
ÁT CIA
objetivos, la contribución, además de la metodología de la investigación y la estructura de la
tesis.
EM IEN
En el capítulo dos se presenta el referencial teórico, soporte del tema, describiendo los
AT C
trabajo previos para esta investigación y contemplando los conceptos de la arquitectura cliente-
M E
Y AD
servidor, los conceptos de Java RMI y Lipe RMI. Luego se hace mención de los temas de
dispositivos móviles, sistemas operativos móviles y el estudio de Android, sus componentes y

EC
herramientas de desarrollo de aplicaciones. Finalmente se culmina este capítulo con una investi-
T
IO
gación de la metodología ágil para el desarrollo de aplicaciones móviles, denominada Mobile-D
y se realiza una comparativa de algunos de los principales conceptos investigados, a tener en

BL
cuenta en la fase de diseño y desarrollo del proyecto.

BI
El tercer capítulo trata del tema central de la tesis, que inicia con el modelado de la arqui-
tectura del proyecto, haciendo una descripción de los componentes y tecnologías de cada parte,
tanto para el cliente como para el servidor, que permitirán la comunicación y el control a im-
plementar. La siguiente fase se realiza la construcción de los módulos de la aplicación Android
y del Servidor de Control, culminado con las pruebas en dispositivos móviles.
S
CA
En el cuarto capítulo se presentan los resultados obtenidos en la investigación. En el capítulo
SI
cinco se presentan las consideraciones finales obtenidas en esta tesis. Inicialmente se presentan
AS FÍ
las conclusiones, seguida de las recomendaciones para futuras investigaciones relacionadas al
IC S
tema en cuestión.
ÁT CIA
Finalmente las referencias bibliográficas usadas para la investigación de esta tesis y los
EM IEN
anexos donde se presentan las aplicaciones elaborados, es decir las funcionalidades principales
e interfaces de la aplicación Android y del Servidor de Control.

AT C
M E
Y AD
T EC
IO
BL
BI
10
Capítulo 2
S
CA
SI
Marco teórico
AS FÍ
IC S
ÁT CIA
En el capítulo se detallan los antecedentes y la información investigada con relación a los
temas considerados y seleccionados para el desarrollo de este proyecto.

EM IEN
AT C
2.1. Trabajos previos de la investigación

M E
Y AD
Luego de realizar la investigación en diversas fuentes de información, se presenta los traba-

EC
jos previos de interés para esta tesis:

T
1) Saavedra (2014), plantean la creación de una aplicación móvil para el control de equipos
IO
en general, el punto de partida en el cual se basa este trabajo es el problema de generación

BL
de reportes de los equipos, que son hechos en un su gran mayoría en papel dentro de un
BI
11
entorno empresarial.
Teniendo en cuenta las desventajas de tener reportes documentados en papel, por pérdi-
das o deterioro por ejemplo, la alternativa de solución dada se resume en la utilización
de códigos de barras como identificadores únicos de los equipos, para lo cual se utiliza
S
algoritmos de procesamiento digital de imágenes e interfaz de video del dispositivo para
CA
la captura de la imagen.
SI
La información de código de barras y datos de reportes de los equipos son almacenados en
AS FÍ
el dispositivo, para luego poder ser enviados cuando se requiera, a través de una interfaz
IC S
ÁT CIA
con comunicación cliente-servidor.
EM IEN
2) Garcia (2014), propone un sistema de control, respetando las reglas y secuencias de un
cronograma a seguir, con la finalidad de mejorar el ámbito de desarrollo laboral e inte-

AT C
lectual, proporcionando el control de las tareas realizadas por el empleado en el área de

M E
Y AD
campo, basado en el flujo de ventas. Se define una interfaz gráfica amigable para el usua-
rio, permitiendo obtener reportes de las actividades en el servidor, las cuales consisten en
EC
realizar el levantamiento de información de pedidos, mediante el dispositivo móvil.

T
IO
3) Pacheco (2011), desarrolló una solución con visión de cliente, para el control de inven-
BL
tarios digitales de equipos u objetos dentro de un ambiente de trabajo, para organizar y

BI
agilizar el proceso de control de reportes, usando una base de datos en un servidor para
12
almacenamiento y recuperación de los datos.
4) Godoy (2015), presenta el desarrollo de una aplicación móvil para Android de captura
de datos de tráfico, dados por los usuarios, que a su vez estos datos son almacenados
en el dispositivo y enviados de manera automatizada a un servidor usando la arquitectura
cliente-servidor, que posee un mecanismos de registro y autentificación previos. Los datos
S
CA
se guardan en una Base de datos para su posterior uso en la toma de decisiones.
SI
5) Borja (2015), realiza una investigación sobre herramientas para el control de dispositivos
AS FÍ
Android y desarrolla un aplicativo para manipulación de los datos almacenados en los
IC S
ÁT CIA
equipos de los usuarios y ejecución de algunos eventos de control remoto mediante una
interfaz web del lado del servidor. La comunicación establecida se da mediante el paso de
EM IEN
mensajes de textos que se traducen en acciones de control en el dispositivo del usuario.
AT C
M E
2.2. Arquitectura cliente-servidor

Y AD
2.2.1. Definición
T EC
Según Roman (2006), la arquitectura cliente/servidor es un modelo para el desarrollo de

IO
sistemas de información, en el que las transacciones se dividen en procesos independientes que

BL
cooperan entre sí para intercambiar información, servicios o recursos.

BI
13
Para Arteaga (2006), un cliente es definido como aquel que solicita un servicio y un servidor
es definido como el proveedor de servicios. Cada vez que se ejecuta una aplicación cliente, esta
contacta con el servidor, le envía una solicitud de servicio y espera la respuesta o resultados del
servicio. El proceso cliente es el encargado de llevar a cabo la interacción con el usuario y de
mostrar los resultados de las peticiones de servicio.
S
CA
2.2.2. Componentes
SI
AS FÍ
Los principales componentes del esquema cliente-servidor son los clientes, los servidores y
IC S
la infraestructura de comunicaciones:
a) Servidor
ÁT CIA
EM IEN
De acuerdo a Espinel (2005), el servidor está continuamente esperando peticiones de ser-
AT C
vicio. Cuando se produce una petición, el servidor despierta y atiende al cliente. Cuando
M E
el servicio concluye, el servidor vuelve al estado de espera. De acuerdo con la forma de

Y AD
prestar el servicio, podemos considerar dos tipos que son los interactivos y concurrentes.
EC
b) Cliente
T
Según Espinel (2005), el cliente es la entidad activa en el establecimiento de una cone-

IO
xión, puesto que es el que toma la iniciativa de la demanda de conexión a un servidor.

BL
BI
c) Infraestructura
14
Se refiere a los elementos hardware y software que garantizan la conexión física y la
transferencia de datos entre los distintos equipos de la red, permitiendo la comunicación
y su gestión, entre los clientes y los servidores.
2.3. Java RMI
S
CA
2.3.1. Definición
SI
AS FÍ
Conforme con Martinez (2005), Java RMI es una extensión del modelo de objetos Java para
IC S
proveer soporte para la comunicación distribuida mediante el uso de Remote Method Invoca-
ÁT CIA
tion. Es importante no confundir RMI y Java RMI, siendo el primero de ellos un modelo de
EM IEN
comunicación y el otro la implementación que se ha realizado en Java de este modelo.
En Java RMI un objeto que realiza una llamada a un objeto remoto es consciente de que
AT C
M E
está trabajando con un objeto remoto ya que tiene que manejar la excepción RemoteException;
Y AD
y el que implementa el objeto remoto es consciente de esto puesto que debe implementar el
interfaz Remote. Aunque este modelo de objetos es integrado en Java la semántica del paso de
EC
parámetros de uno a otro difiere puesto que el invocador y el fuente son remotos uno del otro.
T
IO
BL
BI
15
2.3.2. Arquitectura
La arquitectura RMI está construida por tres capas abstractas que son (Jabba, 2003): la capa
stub/skeleton la capa de referencia remota y la capa de transporte.
a) La capa stub/skeleton
S
Se encuentra ubicada debajo de la vista del desarrollador. Esta capa intercepta las llama-
CA
das a métodos hechas por el cliente a la variable de referencia de la interfaz y redirecciona
SI
estas llamadas a un servicio RMI remoto.
AS FÍ
IC S
El punto de contacto de la aplicación cliente con el objeto remoto se hace por medio del
ÁT CIA
stub (delegado) local. Los stubs actúan corno mediadores en la comunicación y son los
EM IEN
responsables de traducir los objetos a una representación apropiada para entonces realizar
la llamada al método remoto. Para todos los efectos, el stub es la representación local del
AT C
objeto remoto.
M E
Y AD
Del lado del servidor, el skeleton (esqueleto) es el equivalente al stub en el cliente. Se

EC
encarga de traducir las invocaciones que provienen de la capa de referencia remota, así
T
corno de gestionar las respuestas.

IO
b) La capa de referencia remota

BL
La capa de referencia remota descansa debajo de la capa stub/skeleton. Está formada por
BI
16
dos entidades distintas, el cliente y el servidor, que se comunican a través de la capa de
transporte.
c) La capa de transporte
La capa de transporte es responsable del establecimiento y mantenimiento de la conexión,
S
la cual proporciona una canal de comunicación fiable entre las capas de referencia remota
CA
del cliente y del servidor.
SI
Esta capa se basa en conexiones TCP/IP entre nodos de una red. Provee conectividad
AS FÍ
básica, así como también estrategias de penetración (firewall). La capa de transporte de
IC S
ÁT CIA
RMI, en la realidad, está implementada por medio de sockets.
EM IEN
AT C
M E
Y AD
T EC
IO
Figura 2.1: Arquitectura de comunicación de Java RMI.

Fuente: Recuperado de https://github.com/harry1357931/Remote_Method_Invocation-RMI
BL
BI
17
2.4. Lipe RMI
2.4.1. Definición
LipeRMI es una nueva aplicación RMI para reemplazar a la nativa de Java RMI. Es to-
talmente independiente del nativo Java RMI y utiliza un enfoque optimizado para la capa de
S
CA
comunicación de Internet. Utiliza también únicamente un socket por cliente de manera unidire-
cional.
SI
AS FÍ
2.4.2. Características
IC S
ÁT CIA
El desarrollo de LipeRMI tiene algunos puntos clave que son:
EM IEN
Proporcionar una comunicación abstracta entre objetos que residen en diferentes máqui-
nas virtuales.
AT C
M E
Proporcionar una API con una arquitectura clara y extensible.

Y AD
Ser muy ligero y no requiere importaciones externas.

EC
Ser seguro.
T
IO
Proporcionar un API RMI como la creada por SUN (RMI Nativo en Java).
BL
Optimizar el uso del ancho de banda.

BI
18
Optimizar la forma de comunicación con los clientes, por parte del servidor (reutilización
de un mismo socket y mantenerlo activo).
Comunicación transparente en los clientes, de tal modo que estos puedan estar detrás de
una red local, enrutador o cortafuegos.
S
Proporcionar mecanismos para obtener información de la ejecución de eventos orientados
CA
a conexión.
SI
AS FÍ
Proporcionar una manera de conocer, en cualquier momento y sobre cualquier método,
IC S
sobre que socket se hizo esa llamada (saber si se trata de una llamada remota).
ÁT CIA
Requerir pocos ajustes cuando se quiere hacer una migración de una aplicación desarro-
EM IEN
llada usando RMI hacia LipeRMI.
AT C
Ser un proyecto de código abierto y libre para cualquiera que lo use.

M E
Y AD
T EC
IO
BL
BI
19
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
AT C
Figura 2.2: Arquitectura de comunicación de LipeRMI.

Fuente: Recuperado de http://lipermi.sourceforge.net/documentation.php
M E
Y AD
T EC
IO
BL
BI
20
2.5. Dispositivos Móviles
2.5.1. Definición
Para Loayza (2014), un dispositivo móvil es un aparato de tamaño pequeño también cono-
cido como handheld. Son pequeñas computadoras de mano que poseen capacidades de proce-
S
CA
samiento, tienen memoria limitada y que se caracterizan por su facilidad de uso.
SI
2.5.2. Tipos
AS FÍ
IC S
En cuanto a los tipos de dispositivos móviles podemos mencionar los siguientes:
ÁT CIA
a) Teléfonos Inteligentes (SmartPhones)
EM IEN
Según Borja (2015), es un equipo celular que hace funciones más avanzadas que las de te-
AT C
léfonos corrientes. El término se utilizó cuando salieron terminales con correo electrónico
M E
ya preinstalado, configurado y listo para utilizar.

Y AD
b) Tabletas (Tablets)
EC
Conforme con Molina (2012), una tableta (del inglés: tablet o Tablet computer) es un tipo
T
IO
de computadora portátil, de mayor tamaño que un smartphone o una PDA, integrado en

BL
una pantalla táctil (sencilla o multitáctil) con la que se interactúa primariamente con los
dedos o una pluma stylus (pasiva o activa), sin necesidad de teclado físico ni ratón. Estos
BI
21
últimos se ven remplazados por un teclado virtual y, en determinados modelos, por una
mini-trackball integrada en uno de los bordes de la pantalla.
c) Otros dispositivos
PDA (Personal Digital Assistant).
S
Relojes Inteligentes (SmartWatchs), etc.
CA
SI
2.6. Sistemas Operativos Móviles
AS FÍ
IC S
2.6.1.
ÁT CIA
Definición
Según Santana (2009), partiendo de la definición de sistema operativo, capa compleja entre
EM IEN
el hardware y el usuario, concebible también como una máquina virtual, que facilita al usuario
AT C
o al programador las herramientas e interfaces adecuadas para realizar sus tareas informáticas,
M E
Y AD
abstrayéndole de los complicados procesos necesarios para llevarlas a cabo. Se deduce por
tanto, que el uso de uno u otro determinarán las capacidades de los dispositivos y su forma de
EC
interactuar con el usuario.

T
IO
BL
BI
22
2.6.2. Tipos
Existen actualmente 3 versiones distinguidas de los sistemas operativos para móviles, de
mayor uso en el marcado (Lozano, 2012) y estos son:
a) Android
S
Android está basado en una versión modificada del kernel de Linux. Su propietario es la
CA
empresa Google. Es de código abierto, lo que quiere decir que cualquier desarrollador
SI
puede crear y desarrollar aplicaciones para este sistema. Su entorno de ejecución está ba-
AS FÍ
sado en Java. Está instalado en dispositivos de una gran variedad de marcas. Esto hace
IC S
ÁT CIA
que según las características del terminal, podremos instalar una versión u otra del siste-
ma y, por lo tanto, no se podrán ejecutar ni las mismas aplicaciones ni con las mismas
EM IEN
prestaciones en todos ellos.

AT C
b) iOS
M E
Y AD
iOS es el sistema operativo que se incluye en los dispositivos Apple (iPhone, iPod y iPad).
Está basado en la arquitectura de MAC OS X. En el nivel más alto, iOs actúa como un
EC
intermediario entre el hardware y las aplicaciones que aparecen en pantalla. Su arquitec-

T
IO
tura está basada en capas, las capas más bajas contienen los servicios fundamentales y las
BL
tecnologías en las que se apoyan todas las aplicaciones y las capas más altas contienen
BI
servicios y tecnologías más sofisticados.
23
c) Windows Phone
Windows Phone anteriormente llamado Windows Mobile, es un sistema operativo desa-
rrollado por Microsoft. Se basa en el núcleo del sistema operativo Windows CE y cuenta
con un conjunto de aplicaciones básicas utilizando las API de Microsoft Windows. Es un
sistema multitarea y con capacidades multimedia. Se encuentra en dispositivos de varias
S
CA
marcas.
SI
Además cabe mencionar otros sistemas operativos móviles, que tuvieron muha influencia y
AS FÍ
uso en los dispositivos móviles, por un periodo de tiempo y que algunos autores los mencionan:
IC S
ÁT CIA
Symbian OS (Cordero, 2012), BlackBerry OS (Lozano, 2012), etc.
EM IEN
2.7. Android
AT C
2.7.1. Definición
M E
Y AD
Conforme con Veloz (2013), Android es un sistema operativo (OS) para dispositivos mó-
EC
viles (llámese también Sistema Operativo Móvil) no es más que la plataforma informática que
T
establece la interfaz entre el usuario y el hardware del dispositivo móvil, y sobre la cual se pue-
IO
den instalar aplicaciones que agregan utilidad al dispositivo. Entre las funciones más comunes
BL
de un sistema operativo móvil están las de administración de memoria física y virtual, control
BI
24
de hardware (CPU, teclado, pantalla, altavoces, puertos, etc.), lectura y escritura de archivos,
control de procesos multitarea, definición de la interfaz de usuario.
2.7.2. Arquitectura
En el siguiente diagrama se muestran los componentes o capas principales de la plataforma
S
CA
Android y kuego se hace un descripción de cada una.
SI
AS FÍ
IC S
ÁT CIA
EM IEN
AT C
M E
Y AD
T EC
IO
BL
BI
25
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
AT C
M E
Y AD
T EC
IO
Figura 2.3: Arquitectura del Sistema Android.

Fuente: Recuperado de https://developer.android.com/guide/platform/index.html
BL
BI
26
2.7.2.1. Kernel Linux
Acorde con Cruz (2013), la base de la arquitectura Android está formada por el kernel de Li-
nux 2.6 o su sucesor, de la cual hace uso de las funciones básicas del sistema operativo como la
seguridad, la administración de memoria, gestión de procesos, implementación de conectividad
de red (network stack) e intérpretes para la comunicación entre dispositivos físicos.
S
CA
2.7.2.2. Abstracción de hardware (HAL)
SI
AS FÍ
La capa de abstracción de hardware (HAL) brinda interfaces estándares que exponen las
IC S
capacidades de hardware del dispositivo al framework de la API de Java de nivel más alto. La
ÁT CIA
HAL consiste en varios módulos de biblioteca y cada uno de estos implementa una interfaz para
EM IEN
un tipo específico de componente de hardware, como el módulo de la cámara o de bluetooth.
Cuando el framework de una API realiza una llamada para acceder a hardware del dispositivo, el
AT C
sistema Android carga el módulo de la biblioteca para el componente de hardware en cuestión.

M E
Y AD
2.7.2.3. Entorno de ejecución

EC
Para los dispositivos con Android 5.0 (nivel de API 21) o versiones posteriores, cada aplica-
T
ción ejecuta sus propios procesos con sus propias instancias del tiempo de ejecución de Android
IO
(ART).
BL
BI
Antes de Android 5.0 (nivel de API 21), Dalvik era la máquina virtual del sistema operativo.
27
Si una aplicación se ejecuta correctamente en el ART, también debe funcionar en Dalvik, pero
es posible que no suceda lo contrario.
En Android también se incluye un conjunto de bibliotecas de tiempo de ejecución centrales
que proporcionan la mayor parte de la funcionalidad del lenguaje de programación Java; se
incluyen algunas funciones del lenguaje Java 8, que el framework de la API de Java usa.
S
CA
2.7.2.4. Librerías nativas C/C++
SI
AS FÍ
Muchos componentes y servicios centrales del sistema Android, como el ART y la HAL,
IC S
se basan en código nativo que requiere librerías nativas escritas en C y C++. La plataforma
ÁT CIA
Android proporciona la API del framework de Java para exponer la funcionalidad de algunas
EM IEN
de estas bibliotecas nativas a las aplicaciones.
AT C
2.7.2.5. Framework de la API de Java

M E
Y AD
Todo el conjunto de funciones del sistema operativo Android está disponible mediante API
escritas en el lenguaje Java. Estas API son los cimientos que necesitas para crear aplicaciones
EC
de Android simplificando la reutilización de componentes del sistema y servicios centrales y

T
modulares. Algunos marcos que posee esta capa son: Activity Manager, Notification Manager,
IO
Package Manager, Telephony Manager, Location Manager, etc.

BL
BI
28
2.7.2.6. Aplicaciones del sistema
En Android se incluye un conjunto de aplicaciones centrales para correo electrónico, men-
sajería SMS, calendarios, navegación en Internet, contactos, etc. Las aplicaciones del sistema
funcionan como aplicaciones para los usuarios y brindan capacidades claves a las cuales los
desarrolladores pueden acceder desde sus propias aplicaciones.
S
CA
2.7.3. Máquinas Virtuales
SI
AS FÍ
En Android los programas están escritos normalmente en Java y compilados a bytecode
IC S
por la máquina virtual de Java. Luego es traducido a ficheros bytecode para la máquina virtual
ÁT CIA
Dalvik o para ART(Android Runtime):
EM IEN
2.7.3.1. Davilk
AT C
Según Madero (2013), esta máquina virtual ha sido optimizada y adaptada a las peculiari-
M E
Y AD
dades propias de los dispositivos móviles (menor capacidad de proceso, baja memoria, alimen-
tación por batería, etc.) y trabaja con ficheros de extensión .dex (Dalvik Executables).
EC
Dalvik utiliza la compilación tipo JIT (Just-In-Time, Justo a tiempo) para compilar el by-
T
IO
tecode DEX y cachea el código de máquina resultante en el fichero ODEX (Optimized DEX,
BL
fichero DEX Optimizado), que en las posteriores ejecuciones de la misma aplicación se reutiliza
BI
29
el código ya cacheado.
2.7.3.2. ART
La máquina virtual ART realiza una compilación AOT (Ahead-Of-Time, Antes de tiempo)
en el momento de la instalación para obtener el ejecutable ELF (Executable and Linkable For-
S
mat, Formato Ejecutable y Enlazable).
CA
SI
Para las nuevas versiones de Android, precisamente desde la versión 7, se utiliza de manera
AS FÍ
conjunta estos dos métodos de compilación que son, JIT de Dalvik y AOT de la máquina ART;
IC S
ÁT CIA
aprovechando las ventajas de cada tipo de compilación para lograr un mejor rendimiento.
EM IEN
2.7.4. Sotfware Development Kit (SDK)

AT C
El Android SDK es conjunto de herramientas de desarrollo para aplicaciones Android, con-

M E
Y AD
tiene las fuentes y librerías necesarias que son utilizadas en la creación de proyectos. El SDK
también incluye unos componentes adicionales para la creación y posterior fase de pruebas de
EC
las aplicaciones, que los desarrolladores pueden hacer uso. Muchas de estas herramientas son
T
incorporas a su vez con interfaces gráficas en los IDEs de desarrollo como Android Studio. A
IO
continuación se hace mención de los principales componentes que incluye:

BL
BI
1) SDK Manager, programa con interfaz gráfica que posibilita el acceso a los paquetes de
30
herramientas, librerías de versiones Android y algunas componentes extras, para el desa-
rrollo con Android.
2) Android Emulator, herramienta de emulador de dispositivo móvil, que es un dispositivo
móvil virtual que se ejecuta en el ordenador. El emulador permite desarrollar y probar
aplicaciones Android sin necesidad de utilizar un dispositivo físico.
S
CA
3) Adroid Virtual Device (AVD) Manager, herramienta para para definir las características
SI
de un teléfono Android, una tableta,un dispositivo Android Wear o Android TV, que se
AS FÍ
desea simular en Android Emulator.
IC S
ÁT CIA
4) Android Device Monitor (ADM), herramienta independiente que proporciona una inter-
faz de usuario para varios otros programas de depuración y análisis de las aplicaciones
EM IEN
Android
AT C
5) Android Debug Bridge (ADB), herramienta de líneas de comandos versátil que permite
M E
Y AD
la comunicación con una instancia de un emulador o un dispositivo Android conectado.

T EC
IO
BL
BI
31
2.8. Aplicaciones Android
2.8.1. Definición
Las aplicaciones móviles Android, son el resultado de un proceso de desarrollo que se mate-
rializa en un fichero empaquetado APK (Android Application Package), el cual se puede instalar
S
CA
en un dispositivo. Con las aplicaciones se logra dotar de nuevas funcionalidades y tener tareas
para ser usadas por los usuarios. Muchas de las aplicaciones Android son distribuidas en Google
SI
Play o fuentes externas mediante el fichero APK.
AS FÍ
IC S
2.8.2. Tipos
ÁT CIA
EM IEN
Las aplicaciones se pueden clasificar por la forma en que sus procesos son llevados a cabo
(Veloz, 2013):
AT C
M E
a) Aplicaciones de primer plano: Son aplicaciones que son útiles mientras están en primer
Y AD
plano, y que se suspenden totalmente cuando no son visibles. Los juegos y navegadores
de mapas son un ejemplo de estas aplicaciones.

T EC
b) Aplicaciones de fondo: Son aplicaciones con limitada interacción, que a excepción de

IO
cuando son configuradas, pasan la mayor parte de su tiempo ejecutándose de forma oculta.
BL
c) Aplicaciones intermitentes: Son aplicaciones que esperan alguna interactividad, pero ha-
BI
32
cen parte de su trabajo en segundo plano. En ocasiones estas aplicaciones se configuran y
ejecutan silenciosamente, notificando a los usuarios cuando sea necesario
2.8.3. Componentes
Para Veloz (2013), los componentes de una aplicación Android son bloques de construcción
S
CA
esenciales para su funcionamiento; cada componente cumple con un rol específico y existe
como una propia entidad, aunque no son necesariamente entradas de interacción con el usuario.
SI
AS FÍ
A continuación se hace mención de los componentes de mayor importancia:
IC S
2.8.3.1.
ÁT CIA
Actividades
Según Borja (2015), las actividades son pantallas que se visualizarán en el aplicativo, parte
EM IEN
con la que el usuario interactúa. Se compone de dos partes la parte lógica que se programa en
AT C
java, y la parte gráfica que contiene todos los elementos que aparecen en la pantalla, se crea en
M E
Y AD
archivos XML.
T EC
IO
BL
BI
33
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
AT C
M E
Y AD
T EC
IO
Figura 2.4: Ciclo de Vida de una Actividad.

Fuente: Recuperado de
BL
https://developer.android.com/guide/components/activities/activity-lifecycle.html
BI
34
2.8.3.2. Servicios
Según Borja (2015), son componentes que se ejecutan sin interfaz gráfica y se ejecutan en
segundo plano. Estos pueden realizar cualquier acción.
Un servicio en función de su ejecución, puede adoptar dos formas de uso:
S
CA
1. Servicio iniciado: Cuando un componente de aplicación (como una actividad) lo inicia
llamando a al método startService(). Una vez iniciado, un servicio puede ejecutarse en
SI
AS FÍ
segundo plano de manera indefinida, incluso si se destruye el componente que lo inició.
IC S
2. Servicio de enlace: Un servicio es de “de enlace” cuando un componente de la aplicación
ÁT CIA
se vincula a él llamando a bindService(). Un servicio de enlace ofrece una interfaz cliente-
EM IEN
servidor que permite que los componentes interactúen con el servicio, envíen solicitudes,
obtengan resultados e incluso lo hagan en distintos procesos con la comunicación entre

AT C
procesos (IPC).
M E
Y AD
T EC
IO
BL
BI
35
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
AT C
M E
Figura 2.5: Ciclo de Vida de un Servicio.

Y AD
Fuente: Recuperado de https://developer.android.com/guide/components/services.html
2.8.3.3. Proveedores de Contenidos

EC
Para Cabrera (2015), si una aplicación gestiona los datos y necesita exponer los datos a
T
IO
otras aplicaciones ejecuta en el entorno de Android, usted debe considerar un ContentProvider.

BL
Si un componente de aplicación (actividad, servicio o BroadcastReceiver) necesita tener acceso

BI
a datos de otra aplicación, el componente de acceso a la otra aplicación ContentProvider.
36
2.8.3.4. Receptores de Transmisión
De a acuerdo Borja (2015), es un componente que detecta y reacciona ante determinados
mensajes o eventos que se generan en el sistema operativo o por otras aplicaciones.
Como los servicios, BroadcastReceivers no tiene una interfaz de usuario, el código se eje-
S
cuta en el método OnReceive de un BroadcastReceiver implementado en la aplicación.
CA
SI
2.8.3.5. Intents
AS FÍ
Conforme a Cabrera (2015), un Intent es el elemento básico de comunicación entre los
IC S
distintos componentes Android. Es una clase que permite especificar una Activity a ejecutar,
ÁT CIA
llamando a uno de los métodos de la clase Activity con ese Intent de parámetro. Se pueden
EM IEN
entender como los mensajes o peticiones que son enviados entre los distintos componentes de
una aplicación o entre distintas aplicaciones. Un Intent consiste básicamente en la voluntad de

AT C
M E
realizar alguna acción, generalmente asociada a unos datos. Lanzando un Intent, una aplicación
Y AD
puede delegar el trabajo en otra, de forma que el sistema se encarga de buscar qué aplicación
entre las instaladas es la que puede llevar a cabo la acción solicitada.

T EC
IO
BL
BI
37
2.8.4. Sistema de Permisos
Para proteger la integridad del sistema y la privacidad del usuario, Android ejecuta cada
aplicación en una zona de pruebas de acceso limitado. Si la aplicación busca usar recursos o
información fuera de su zona de pruebas, debe solicitar permiso de manera explícita. Según el
tipo de permiso que solicite la aplicación, el sistema puede otorgarlo automáticamente o solicitar
S
CA
al usuario que lo haga. Los permisos son declarados en el fichero manifiesto de la aplicación
SI
Android durante el proceso de desarrollo.
AS FÍ
De acuerdo al grado de confidencialidad del permiso, el sistema podría otorgar el permi-
IC S
ÁT CIA
so automáticamente o el usuario del dispositivo podría tener que conceder la solicitud. Según
la versión de la plataforma, el usuario otorga el permiso cuando se instala la aplicación (en

EM IEN
Android 5.1 y versiones anteriores) o mientras esta se ejecuta (en Android 6.0 y versiones pos-
teriores).
AT C
M E
Y AD
2.8.5. Opciones de almacenamiento

EC
Android ofrece diferentes opciones para guardar datos persistentes de la aplicación. La so-
T
lución que se elija depende de las necesidades específicas; por ejemplo, si los datos deben ser
IO
privados para la aplicación o estar disponibles para otras aplicaciones (y el usuario), y la can-
BL
tidad de espacio que requieran los datos. Las opciones de almacenamiento de datos son las
BI
38
siguientes:
1. Preferencias compartidas: Es un almacenamiento de datos privado en pares clave/valor.
La clase de SharedPreferences ofrece un marco general que permite guardar y recuperar
pares clave/valor persistentes de tipos de datos primitivos, tales como: booleanos, ele-
S
mentos flotantes, valores enteros, valores largos y cadenas. Estos datos se conservarán de
CA
una sesión de usuario a otra (incluso si la aplicación finaliza).
SI
2. Almacenamiento interno: Es posible guardar archivos directamente en el almacenamien-
AS FÍ
to interno del dispositivo. De forma predeterminada, los ficheros que se guardan en el
IC S
ÁT CIA
almacenamiento interno son privados para para la aplicación y otras aplicaciones no pue-
den tener acceso a ellos (tampoco el usuario). Cuando el usuario desinstala la aplicación,
EM IEN
estos archivos se quitan.

AT C
3. Almacenamiento externo: Todo dispositivo compatible con Android admite un almace-

M E
Y AD
namiento externo compartido, que es posible usar para guardar archivos. Puede ser un
medio de almacenamiento extraíble (como una tarjeta SD) o un medio almacenamiento

EC
interno (no extraíble).

T
IO
4. Base de datos SQLite: Es almacenamiento de datos estructurados en una base de datos

BL
privada, aunque esta podría ser accesible si se cambia la ruta del fichero de base datos a
BI
almacenamiento externo.
39
2.8.6. Administración de dispositivos
Según Madero (2013), desde la versión del sistema operativo Android 2.2 y posteriores, se
proporciona un API para la administración de dispositivos Android, que proporciona funciones
de administración de dispositivos a nivel del sistema. Por ejemplo, la aplicación integrada de
correo electrónico utiliza la API de Android para mejorar el soporte “Exchange”. A través de la
S
CA
aplicación de correo electrónico, los administradores de Exchange pueden aplicar políticas de
SI
contraseñas (incluyendo contraseñas alfanuméricas o PIN numérico) a través de los dispositivos.
AS FÍ
Los administradores también pueden borrar de forma remota (es decir, restaurar los valores
IC S
predeterminados de fábrica) en caso de pérdida o robo del teléfono móvil.
ÁT CIA
2.8.7. Firebase Cloud Messaging (FCM)
EM IEN
Firebase Cloud Messaging, es una solución multiplataforma que permite enviar, de forma
AT C
gratuita y segura, mensajes y notificaciones. Al usar FCM, es posible notificarle a una aplicación
M E
Y AD
cliente sobre ciertos eventos, acciones u otros datos que están disponibles para la sincronización.
Se puede enviar notificaciones para aumentar la recaptación y retención de usuarios. Para casos
EC
de uso como mensajería instantánea, un mensaje puede transferir una carga de hasta 4 KB a una
T
IO
aplicación cliente.
BL
FCM es la nueva alternativa a Google Cloud Messaging (GCM), es decir es la nueva versión
BI
40
que se recomienda usar cuando se inician proyectos nuevos y se desea incorporar esta tecnolo-
gía. Si ya se tiene proyectos en producción con GCM, existen herramientas y guías para hacer
una migración de GCM a FCM en pocos pasos y manteniendo la compatibilidad.
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
AT C
M E
Y AD
Figura 2.6: Arquitectura de FCM.

EC
Fuente: Recuperado de https://firebase.google.com/docs/cloud-messaging

T
IO
BL
BI
41
2.9. Metodología Mobile-D
2.9.1. Definición
Conforme con Grimaldo (2013), Mobile-D es una metodología ágil para el desarrollo de
software. Además del desarrollo de software para dispositivos móviles, es conveniente para
S
CA
varios contextos, por ejemplo, la seguridad, financiera, logística y aplicaciones de productos de
simulación.
SI
AS FÍ
Esta metodología ágil se basa en las prácticas de desarrollo de XP (Programación Extre-
IC S
ma), el método de escalabilidad de la metodología Crystal, y la cobertura ciclo de vida de la
ÁT CIA
metodología RUP (Rational Unified Process).
EM IEN
AT C
M E
Y AD
T EC
IO
BL
BI
42
S
CA
SI
AS FÍ
IC S
ÁT CIA
Figura 2.7: Fases y etapas de la metodología ágil Mobile-D.
EM IEN
Fuente: Durán (2013)
AT C
2.9.2. Fases
M E
Y AD
El desarrollo siguiendo el enfoque de Mobile-D se compone de 5 fases que son: Exploración,
Inicialización, Producción, Estabilización y Pruebas del sistema.

EC
2.9.2.1. Exploración
T
IO
Para Durán (2013), el propósito de la fase de exploración es planear y establecer el proyecto.

BL
Esta fase es importante para establecer las bases para la arquitectura del producto, la elección
BI
43
del entorno, y la implementación del sistema. Los objetivos de la fase de exploración son:
Establecer los grupos de actores necesarios en la planificación y el seguimiento del pro-
yecto de desarrollo de software.
Definir los alcances y límites del proyecto de desarrollo de software de desarrollo.
S
CA
Planificar el proyecto respecto al entorno, el personal y los problemas del proceso.
SI
2.9.2.2. Inicialización
AS FÍ
IC S
Según Durán (2013), el propósito de la fase de inicialización es posibilitar el éxito de las si-
ÁT CIA
guientes fases del proyecto preparando y verificando todos los problemas críticos del desarrollo,
de manera que todos ellos sean corregidos con prontitud en el final de la fase de aplicación de
EM IEN
los requisitos. Además se preparan todos los recursos físicos, tecnológicos y de comunicaciones
AT C
para las actividades de producción. Los objetivos de esta fase son:

M E
Y AD
Obtener una buena compresión global del producto para el equipo de desarrollo del pro-
yecto, sobre los requisitos iniciales y la línea de la arquitectura.

T EC
Preparar los requisitos físicos, técnicos y humanos, así como la comunicación con el
IO
cliente, los planes del proyecto y todas las cuestiones fundamentales de desarrollo a fin
BL
de que todo esté en plena disposición para la implementación.

BI
44
2.9.2.3. Producción
La fase de producción tiene como propósito implementar la funcionalidad requerida en el
producto aplicando un ciclo de desarrollo iterativo e incremental. El desarrollo basado en prue-
bas es utilizado en la implementación de las funcionalidades. Los objetivos de esta fase son:
S
Implementar la funcionalidad del producto priorizando los requerimientos del cliente.
CA
Centrarse en la funcionalidad básica fundamental para permitir múltiples ciclos de mejo-
SI
ra.
AS FÍ
IC S
2.9.2.4. Estabilización
ÁT CIA
El propósito de la fase de estabilización es asegurar la calidad de la implementación del
EM IEN
proyecto. Los objetivos de la fase de estabilización son:

AT C
Finalizar la implementación del producto.

M E
Y AD
Mejorar y garantizar la calidad del producto.

EC
Finalizar la documentación del proyecto.

T
IO
2.9.2.5. Pruebas
BL
El propósito de la fase de pruebas del sistema es comprobar si el producto implementa las

BI
funcionalidades requeridas correctamente, y corregir los errores encontrados. Los objetivos de
45
la fase de pruebas son:
Probar el sistema basado en la documentación producida en el proyecto.
Proporcionar información de defectos encontrados.
Planificar la solución a los defectos encontrados.
S
CA
Fijar los errores hallados.
SI
Producir un sistema libre de errores como sea posible.
AS FÍ
IC S
2.10. ÁT CIA
Comparativas
EM IEN
Luego de investigar y plasmar los conceptos del marco teórico necesarios para el proyecto;
en esta sección se realizó un análisis comparativo entre los conceptos de mayor importancia a
AT C
tener en cuenta en la siguiente fase de desarrollo.

M E
Y AD
2.10.1. Comparativa de Java RMI y Lipe RMI

EC
LipeRMI se presenta como una alternativa a la implementación nativa de Java, en esta sec-
T
IO
ción se comparan los aspectos y problemas en RMI, que dieron origen a la creación de LipeRMI.
BL
A cada aspecto se le ha agregado una calificación posible del 0 al 5, siendo 0 una calificación
BI
nula y 5 una calificación excelente.
46
Tabla 2.1: Comparación de JAVA RMI y LipeRMI
Aspecto Lipe RMI Java RMI

No muy bueno, ya que su
Optimizado en su imple-
Desempeño vía Internet. implementación es gene-
mentación. (4)
ral. (2)
Configuración de la comu-
Sencilla (5) Compleja (3)
nicación.
Optimizada para reutilizar
Comunicación con los Se crean varios sockets en
S
un mismo socket y mante-
clientes. la comunicación.(3)
CA
nerlo activo. (4)
El cliente no tiene que
Requiere conocer la topo-
Transparencia de comuni- preocuparse si está en una
SI
logía de red, en algunos
cación en los clientes. red local, enrutador, corta-
casos. (2)
AS FÍ
fuegos, etc. (4)
Proporciona mecanismos
Eventos orientados a cone- No se tiene información
IC S
para obtener información
xión. clara. (2)
ÁT CIA
Información de llamada a
un método remoto.
de estos eventos. (5)
Se puede obtener datos del
método, socket, etc. (3)
Información
control. (2)
escasa de
EM IEN
Si es posible utilizarlo con
Debido a que Android usa
Acoplamiento con An- Android, agregándolo co-
Java, este está incorporado
droid. mo una librería externa.
en las librerías de Java. (5)
AT C
(5)
Licencia de uso. De libre uso. (5) De libre uso. (5)
M E
Total 35 24
Y AD
Fuente: Elaboración propia.

EC
En las sumatorias de las calificaciones otorgadas por cada aspecto tanto para LipeRMI y
T
IO
Java RMI nativo, se puede afirmar la elección de LipeRMI como una alternativa aceptable en el
BL
desarrollo de la comunicación cliente-servidor.

BI
47
2.10.2. Comparativa de Sistemas Operativos Móviles
En la siguiente tabla comparativa se toma en cuenta las características de los sistemas ope-
rativos de mayor uso en los dispositivos móviles, que son Android, IOS y Windows Phone.
Tabla 2.2: Comparación de Sistemas Operativos Móviles.
Aspecto Android iOS Windows Phone
S
Kernel Linux OS X Windows NT
CA
Tipo de código de
Abierto Cerrado Cerrado
desarrollo.
SI
Lenguaje(s) de pro- Objetive C, Java, C y
C, C++ y Java C# .NET
gramación. C++
AS FÍ
Aceleración de hard-
Sí Sí Sí
ware.
IC S
Seguridad de datos Device Adminsitra-
del usuario. ÁT CIA
Sistema de notifica-
tors
Sí
Find My iPhone
Sí
Find My Phone
Sí
ciones.
EM IEN
Soporte para table-
Sí Sí Sí, vía Windows RT.
tas.
AT C

M E
Y AD
La tabla anterior nos muestra las características del sistema Android frente Windows Phone
EC
e iOS, donde a principio los aspectos comparativos parecen mantener una equidad, sin embargo
la licencia de código abierto de Android, la diversidad de herramientas de desarrollo y la cuota

T
IO
de mercado elevada, siendo el sistema operativo más usado actualmente; dan lugar a que sea
BL
aceptable la elección de la solución para el sistema operativo Android.

BI
48
2.10.3. Comparativa de Máquinas Virtuales de Android
Luego de la investigación de las máquinas virtuales de Android se muestra una comparativa
entre Dalvik y ART.
Tabla 2.3: Comparación de la máquina virtual Dalvik y ART de Android.
Aspecto Dalvik ART
S
Método de compilación. JIT (Just-in-Time). AOT (Ahead-of-Time).
CA
Estrategia de compilación Compilación por partes
Compilación completa.
de código. usando cache.
SI
Cache de código en tiempo
Sí utiliza Dalvik cache. No utiliza.
de ejecución.
AS FÍ
Utiliza memoria cache no
Paginación de memoria. Sí con memoria RAM.
paginable.
IC S
Herramienta de compila-
ÁT CIA
ción de ficheros DEX.
Ficheros de ejecución.
Herramienta dexopt.
Usa los ficheros ODEX.
Herramienta dex2oat.
Usa los ficheros ELF.
EM IEN
AT C
La realización de la comparativa anterior, nos ayuda a tener una visión de las características
M E
Y AD
de las máquinas virtuales en las versiones de Android, Dalvik en Android 4 y ART en Android
5 en adelante. También a considerar en el desarrollo un estado de compatibilidad con versiones

EC
4 de Android y las nuevas versiones, en las cuales se ha combinado estas dos tecnologías.
T
IO
BL
BI
49
2.10.4. Comparativa de Mobile-D y RUP (Rational Unified Process)
En la tabla de esta sección se hace una comparación entre la metodología ágil Mobile-D y
la metodología tradicional RUP.
Tabla 2.4: Comparación de la metodología Mobile-D y RUP.
Aspecto Mobile-D RUP
S
Modelo ágil de desarrollo Se caracteriza por ocupar
CA
rápido, enfocado a grupos el modelo iterativo e incre-
Descripción
pequeños y que busca rá- mental. Esta centrado en la
SI
pidas respuestas. arquitectura.
Proyectos de aplicaciones Principalmente proyectos
AS FÍ
Tipos de proyectos
móviles. grandes.
Interactúa con el cliente y Conocimientos de UML
IC S
Programador / Relación
tiene buena relación con el (Unified Modeling Lan-
con el usuario
ÁT CIA grupo.
Exploracación, inicializa-
guage).
Inicio, elaboración, cons-
Etapas o fases ción, producción, estabili-
EM IEN
trucción y transición.
zación y pruebas.
AT C
M E
Y AD
Luego del estudio de Mobile-D como metodología de desarrollo de aplicaciones móviles,
el objetivo de esta comparativa con RUP, es para reafirmar la elección de Mobile-D, haciendo
EC
énfasis en la modularización y la sencillez para ser usada en esta investigación en el desarrollo

T
de una aplicación móvil para Android.

IO
BL
BI
50
Capítulo 3
S
CA
SI
Propuesta o tema central de la tesis
AS FÍ
IC S
ÁT CIA
Con base en los conceptos del marco teórico y en las tablas comparativas de los temas
investigados, en este capítulo se define la arquitectura del proyecto y otros aspectos involucrados
EM IEN
en el desarrollo, junto con las pruebas finales.

AT C
M E
Y AD
3.1. Arquitectura General

EC
La arquitectura de comunicación principal propuesta es la de RMI, mediante la creación de
un cliente, un servidor y una base de datos.

T
IO
BL
BI
51
S
Figura 3.1: Arquitectura general del proyecto.
CA
SI
Donde:
AS FÍ
a) RMI, es la comunicación base y en este caso se hace uso de una alternativa de Java RMI,
IC S
ÁT CIA
denominada LipeRMI, con algunas mejoras considerables con respecto a la implementa-
ción nativa en Java.

EM IEN
b) Cliente, es una aplicación para dispositivos con Android y RMI.

AT C
c) Servidor, es una aplicación de escritorio en el lenguaje Java con uso de RMI para la
M E
Y AD
comunicación. Es un Servidor de Control de los dispositivos móviles.

EC
d) Base de Datos, es un almacenamiento de datos en el servidor y es una base de datos

T
relacional que registra datos de los dispositivos y de control de los mismos.

IO
BL
BI
52
3.2. Arquitectura de la comunicación
La arquitectura se compone de dos partes distinguidas, basadas en la funcionalidad de
cliente-servidor, donde se tiene una aplicación cliente para Android y una aplicación de es-
critorio que actúa como Servidor de Control o Servidor Principal.
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
AT C
M E
Y AD
EC
Figura 3.2: Arquitectura de la comunicación del proyecto.

T
IO
BL
BI
53
3.2.1. Interfaces de Métodos Remotos
En la implementación de la comunicación cliente-servidor con RMI, se debe definir en pro-
gramación las interfaces remotas, que contienen la definición de los métodos de objetos del ser-
vidor y del cliente. Las interfaces son comunes y permiten establecer la correcta comunicación
a nivel de objetos. En este proyecto tenemos dos tipos de interfaces de métodos, denominadas
S
CA
interfaces remotas principales y las de nivel secundario.
SI
1) Interfaces Remotas Principales
AS FÍ
Las interfaces remotas de este componente definen los métodos, donde la comunicación
IC S
ÁT CIA
es iniciada por la aplicación en Android. Las dos interfaces son:
EM IEN
La interfaz remota de servidor, denominada como IPLMainServerListener en la im-
plementación, posee los métodos que son llamados desde la aplicación Android y
AT C
ejecutados en el Servidor de Control.

M E
Y AD
La interfaz remota de cliente, denominada IPLMainClientListener en la implemen-
tación, registra los métodos que pueden ser llamados desde el Servidor de Control
EC
y ejecutados en el dispositivo Android, luego que se haya establecido la correcta

T
IO
comunicación en la misma linea de conexión.

BL
2) Interfaces Remotas Secundarias

BI
54
Las interfaces remotas encapsulan los métodos, donde el Servidor de Control inicia la
comunicación. Las dos interfaces son:
La interfaz remota de servidor, denominada IPLDevServerListener en la implemen-
tación, posee los métodos a ser llamados desde el Servidor de Control y ejecutados
S
en el dispositivo Android.
CA
La interfaz remota de cliente, que lleva el nombre de PLDevClientListener en la
SI
implementación y que los métodos que tiene son llamados desde la aplicación An-
AS FÍ
droid, con una ejecución en el Servidor de Control, luego que la comunicación haya
IC S
ÁT CIA
sido satisfactoria en la misma conexión.
EM IEN
3.2.2. Componentes del Servidor de Control
AT C
Los componentes de comunicación en el Servidor de Control, según la arquitectura anterior

M E
son:
Y AD
a) Servidor RMI Principal

EC
El Servidor RMI implementa la interfaz remota principal de métodos de servidor. Así

T
IO
mismo este servidor espera que los clientes inicien la comunicación.

BL
b) Cliente RMI de Servidor RMI Android

BI
55
El cliente RMI implementa la funcionalidad de la interfaz remota secundaria de métodos
del cliente, identificando al Servidor RMI Android e iniciando la comunicación directa-
mente cuando sea necesario.
c) Cliente Web de Firebase Cloud Message
S
El cliente web está encargado de enviar datos al servicio web de Google, directamente
CA
al servicio de Firebase que se encarga de hacer llegar notificaciones y datos hacia la
SI
aplicación en el dispositivo. Usa un token único para cada dispositivo registrado en el
AS FÍ
servicio como identificación.
IC S
3.2.3. ÁT CIA
Componentes del Cliente en Android
EM IEN
Los componentes de la comunicación en el Cliente en Android, que interactúan con el Ser-
AT C
vidor de Control son:

M E
Y AD
a) Servidor RMI Android
El servidor RMI implementa la funcionalidad de la interfaz remota secundaria de mé-

EC
todos en el dispositivo Android, permitiendo que los clientes se conecten al dispositivo

T
IO
directamente, cuando se requiera desde el Servidor de Control.

BL
b) Cliente RMI de Servidor RMI Principal

BI
56
El cliente RMI implementa los métodos de la interfaz remota de métodos principales del
cliente. Siendo el primero que inicia la comunicación con el Servidor RMI Principal.
c) Servicio Firebase Cloud Messaging
Es un servicio que proporcionan las librerías de Google para la funcionalidad de FCM,
S
que permanece a la escucha de nuevas notificaciones y datos enviados desde el Servidor
CA
de FCM. Su importancia es de carácter secundario, como un servicio complementario
SI
a la comunicación del Servidor de Control, aprovechando la conexión a Internet en los
AS FÍ
dispositivos móviles.
IC S
3.3.
ÁT CIA
Modelo de datos de la comunicación
EM IEN
El modelo de datos general para la comunicación entre el cliente y el servidor está definido
AT C
por las siguientes entidades base, tales como: DEVICE, Fcm_Dev y Network_Interface.
M E
Y AD
T EC
IO
BL
BI
57
S
CA
SI
AS FÍ
Figura 3.3: Modelo de datos E-R de la comunicación del proyecto.
IC S
Donde:
ÁT CIA
1) Entidad DEVICE: es la entidad base de identificación de los clientes, mediante un ID
EM IEN
único generado en el dispositivo.

AT C
2) Entidad Network_Interface: es una entidad de referencia de las interfaces de red que po-
M E
Y AD
seen los dispositivos móviles para la comunicación cliente-servidor en este proyecto. En
cuyo caso será posible dos opciones a considerar, que son Wifi o Mobile.
T EC
3) Entidad FCM_Dev: es una entidad que corresponde a la comunicación mediante FCM.

IO
Donde uno de sus atributos principales es el registro de un token generado por el servicio
BL
FCM para el envío de mensajes a los dispositivos Android.

BI
58
3.4. Desarrollo de la aplicación Android
En esta sección se realizó la creación de la aplicación Android, la implementación de los
módulos de control y comunicación con el Servidor de Control.
3.4.1. Módulo de Cliente RMI de Servidor RMI Principal
S
CA
Se implementa la funcionalidad de conexión con el Servidor RMI Principal en modo cliente
SI
desde el dispositivo Android. Para luego hacer llamado a los métodos remotos del Servidor RMI
AS FÍ
Principal. También se hace una implementación de la funcionalidad de los métodos que se eje-
IC S
ÁT CIA
cutan en dispositivo, cuando se haga invocaciones a métodos desde el Servidor RMI Principal.
EM IEN
AT C
M E
Y AD
T EC
IO
BL
BI
59
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
Figura 3.4: Implementación del Cliente RMI de Servidor RMI Principal en la aplicación Android.
AT C
3.4.2. Módulo de Servidor RMI Android

M E
Y AD
Mediante este módulo se crea los servicios y tareas para la ejecución de un servidor RMI
en el dispositivo, que permite a los clientes establecer la comunicación y poder llamar a los
EC
métodos que este servidor implementa, ejecutando acciones de control, intercambios de datos y
T
IO
otras operaciones desde el Servidor de Control.

BL
BI
60
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
Figura 3.5: Implementación del Servidor RMI en la aplicación Android.

AT C

M E
3.4.3. Módulo de Firebase Cloud Messaging

Y AD
El módulo de FCM se encarga de recibir notificaciones y datos enviados a través del servicio
EC
en la nube de FCM Server. Las notificaciones son mostradas en el módulo de notificaciones y

T
los datos enviados podrían ser acciones que se procesan en el módulo de acciones remotas como
IO
tal.
BL
BI
61
S
CA
SI
AS FÍ
IC S
ÁT CIA
Figura 3.6: Diagrama de flujo de recepción de mensajes de FCM en la aplicación Android.
EM IEN
AT C
M E
Y AD
T EC
IO
BL
Figura 3.7: Servicio de recepción de mensajes de FCM en la aplicación Android.

BI
62
3.4.4. Módulo de Administración de dispositivos
Con la activación de la administración de dispositivos en la aplicación se controla algunas
configuraciones del sistema Android y es posible hacer cambios en los datos del usuario.
Las políticas a tomar de la API de Administración de dispositivos fueron registradas en un
S
fichero en formato XML denominado device_admin_policies.xml en el directorio de recursos
CA
xml.
SI
AS FÍ
IC S
ÁT CIA
EM IEN
Figura 3.8: Registro de políticas de Administración de Dispositivos de la aplicación Android.
AT C
Luego de la creación de las políticas y de la clase de recepción de cambios de la API de

M E
Y AD
Administración de Dispositivos, se registró el BrodcastReceiver en el fichero manifiesto de la
aplicación.
T EC
IO
BL
BI
63
Figura 3.9: Registro del BrodcastReceiver de la API Administración de Dispositivos de la aplicación
S
Android.
CA
SI
3.4.5. Módulo de Geolocalización
AS FÍ
Cada periodo de tiempo se obtiene los datos de la localización del dispositivo, usando los
IC S
ÁT CIA
dos proveedores principales que son el GPS y la Red. Los datos son enviados al servidor para
registrarse en la base de datos. Se incorporó métodos para escuchar cambios en los datos de la
EM IEN
localización, por periodos de tiempo, tanto para el proveedor GPS como en el de la Red.
AT C
M E
Y AD
T EC
IO
Figura 3.10: Obtener datos de localización usando el GPS o la Red en la aplicación Android.
BL
BI
64
3.4.6. Módulo de Acciones Remotas
Recibe las acciones remotas a ejecutar en el dispositivo, enviadas desde el Servidor de Con-
trol. La estructura de envío de mensajes de acciones remotas se muestra en la siguiente figura.
S
CA
SI
AS FÍ
IC S
ÁT CIA Figura 3.11: Estructura de mensaje de las acciones remotas.
EM IEN
Donde:
AT C
Action Code: es un dato numérico, representa un código para la ejecución de alguna

M E
acción registrada.
Y AD
Notification: es un objeto que contiene datos para mostrar una notificación en el disposi-
EC
tivo, usando el módulo de notificaciones de la aplicación.

T
IO
Data: es un objeto de tipo lista de datos, que son dinámicos y por cada acción remota.
BL
Está representado por un par ordenado clave/valor.

BI
65
Las acciones remotas que llegan, se ejecutan en el procesador de acciones remotas, usando
el ActionCode junto con los datos propios almacenados en Data, por cada acción en particular.
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
AT C
M E
Y AD
T EC
IO
Figura 3.12: Diagrama de flujo del procesador de acciones remotas de la aplicación Android.
BL

BI
66
S
CA
Figura 3.13: Procesador de acciones remotas de la aplicación Android.
SI
3.4.7. Otros Módulos agregados
AS FÍ
IC S
Módulo de almacenamiento en local, que almacena datos mediante las preferencias com-
ÁT CIA
partidas del sistema Android, las cuales son guardas usando el formato clave-valor y
mediante del almacenamiento en SQLite. Las preferencias y datos que se guardan son de
EM IEN
configuraciones de la aplicación y opciones de control.

AT C
Módulo de notificaciones, que lanza mensajes descriptivos en la barra de notificaciones

M E
Y AD
del sistema Android, mostrando alertas, información de acciones remotas, etc.

EC
Módulo de información de almacenamiento, que se encarga de enviar información de

T
algunos lugares de almacenamiento (información de directorios y ficheros), dentro del

IO
dispositivo cuando se requiera y ejecutar operaciones remotas sobre los mismos, desde el
BL
Servidor de Control. La información se transfiere en formato JSON.

BI
67
Módulo de Transferencia de ficheros, que posibilita la funcionalidad de transferir y recibir
ficheros desde el Servidor de Control. La transferencia de dichos ficheros también lleva
un código agregado para realizar alguna operación antes o después de la transferencia.
Módulo de mensajes, que permite al usuario de la aplicación enviar mensajes persona-
lizados con un título y un texto descriptivo, cuando sea necesario. Así mismo, desde el
S
CA
Servidor de Control también se reciben mensajes que se muestran en notificaciones del
SI
sistema del dispositivo.
AS FÍ
IC S
3.5. Desarrollo del Servidor de Control
ÁT CIA
En la sección siguiente se detalla los módulos de mayor importancia que posee la aplicación
EM IEN
que actúa como Servidor de Control, en este modelo cliente-servidor.

AT C
M E
3.5.1. Módulo de Servidor RMI principal

Y AD
Se creo un servidor en un puerto para escuchar y establecer conexiones con los clientes.
EC
Además de métodos de eventos orientados a conexión para el control cuando un cliente se

T
conecta o desconecta del servidor.

IO
BL
BI
68
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
Figura 3.14: Implementación del Servidor RMI Principal.
AT C
3.5.2. Módulo de Cliente RMI de Servidor RMI de Android

M E
Y AD
Permite crear una conexión al servidor RMI Android mediante un cliente y poder llamar a
los métodos que este implemente. También se tiene métodos orientados a conexión que detectan
EC
cuando este cliente se desconecta del servidor.

T
IO
BL
BI
69
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
Figura 3.15: Implementación del Cliente de Servidor RMI Android.

AT C

M E
Y AD
3.5.3. Módulo de Cliente Web de FCM
Para la funcionalidad de este módulo, se hizo uso de una librería denominada FcmJava (web
EC
del proyecto http://bytefish.de/blog/fcmjava/). Se extendió la funcionalidad para el envío de

T
IO
mensajes, acciones remotas, etc. Los mensajes se envían al servidor FCM y luego este encarga
BL
de enviarlos al dispositivo usando su token. La librería necesita la URL del servicio web de
BI
FCM y también la clave de registro otorgada por Google. Esta librería también posee métodos
70
para la creación de mensajes y para el envío mediante el método send.
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
Figura 3.16: Cliente Web de FCM para envío de mensajes.
AT C
3.5.4. Módulo de envío de Acciones Remotas

M E
Y AD
El módulo de envío de acciones remota se encarga de preparar los mensaje y enviarlos
utilizando el cliente de Servidor RMI Android o el cliente web FCM.

T EC
IO
BL
BI
71
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
AT C
M E
Y AD
T EC
IO
Figura 3.17: Diagrama de flujo de envío de acciones remotas al dispositivo Android.

BL

BI
72
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
Figura 3.18: Envío de acciones remotas al dispositivo Android.
AT C
3.5.5. Módulo de Base de Datos

M E
Y AD
El módulo de base de datos se encarga de la conexión entre Java y el gestor de base de datos
relacional, permitiendo almacenar los datos y realizar operaciones de control sobre los mismos.
EC
Para el manejo de conexiones y operaciones sobre la base de datos, se hizo uso de la librería
T
IO
para Java denominada Hibernate (http://hibernate.org/) y junto con la API de persistencia (JPA).
BL
Hibernate requiere unas configuraciones de conexión para la creación de sesiones, que este caso
se hicieron usando un fichero en formato XML y también código Java directamente.

BI
73
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
AT C
M E
Y AD
T EC
Figura 3.19: Diagrama de flujo de registro y actualización de datos de dispositivos.

IO

BL
Se creó también en este módulo, métodos principales de control de datos y tablas de la base
BI
74
de datos, que son indispensable en la comunicación cliente-servidor, el control deseado, etc.
S
CA
SI
Figura 3.20: Métodos principales de operaciones sobre la base de datos con Hibernate.
AS FÍ
3.6. Ejecución de pruebas
IC S
ÁT CIA
En la realización de pruebas, se tiene un módulo de registro de logs. Su funcionalidad es la
EM IEN
de escribir estos logs en ficheros de texto y también filtrarlos en pantalla mediante las funciones
de logs de Android (usando android.util.Log y las herramientas del SDK de Android).

AT C
M E
Las pruebas se hicieron en dispositivos con varias versiones de Android y también en al-
Y AD
gunos emuladores, que sirvieron para pruebas sencillas de funcionalidad. Otro aspecto de las
EC
pruebas es que al dividir en módulos el desarrollo, se hizo las pruebas en partes individualmente
T
y luego con los otros módulos por la dependencia existente.

IO
BL
BI
75
3.6.1. Pruebas de comunicación
La realización de las pruebas de comunicación tiene como objetivo mantener una arquitec-
tura base de conexión entre el cliente en Android y el Servidor de Control. Las pruebas fueron
de carácter simple y sujetos a un análisis visible sobre los errores encontrados. A continuación
se detalla una tabla con algunos fallos generales encontrados y los cambios realizados de las
S
CA
correcciones.
Tabla 3.1: Fallos y correcciones de pruebas de comunicación del proyecto.
SI
AS FÍ
Módulos o métodos Descripción de fallos Correcciones
Se presentó un fallo por regis-
Se hizo una verificación y ac-
IC S
Obtención de datos tro de métodos con diferen-
tualización de las interfaces
ÁT CIA
para comunicación
cliente-servidor.
tes parámetros o no registra-
dos en algunas interfaces re-
motas.
remotas tanto en el cliente co-
mo en el servidor.
EM IEN
Registro de in-
Fallos de devolución de al-
terfaces remotas Para objetos complejos se la
gunos datos no permitidos o
y métodos de información de transfiere en
complejos por los métodos de
AT C
comunicación formato JSON.

las interfaces remotas.
cliente-servidor.
M E
Error de reinicio (que el ser-

Y AD
Se registró variables de con-

vidor vuelva a estar activo y
Servidor secundario trol para estados, los principa-
escuchar conexiones de clien-
en el dispositivo les que son activo e inactivo.
tes).
Android.
EC
Antes de establecer el inter-

Error de validación de datos cambio de datos se colocó
T
de cliente para establecer la una validación de cliente me-

IO
comunicación con el servidor. diante el ID de dispositivo re-

gistrado.
BL

BI
76
Para la tabla anterior se muestran algunas capturas de los errores mostrados en los logs.
1.
2.
Después de haber concretado las correcciones necesarias; se hizo unas pruebas finales de la
S
CA
comunicación. Los resultados se muestran en la siguiente tabla:
SI
Tabla 3.2: Pruebas de módulos y componentes de la comunicación del proyecto.
AS FÍ
Módulos de pruebas Información y requerimientos Resultados
IC S
RMI principal.
ÁT CIA
Conexión al servidor
El cliente debe tener la informa-
ción de identificación del servi-
dor RMI principal para estable-
Conexión satisfactoria.
EM IEN
cer la conexión.
Intercambio de datos
Luego que el dispositivo se co- La invocación de métodos
con el servidor RMI
necta al servidor RMI principal. remotos es correcta.
AT C
principal.
El servidor se inicia co-
M E
Crear el servidor Iniciar el servidor en el disposi-

rrectamente en un servicio
RMI Android. tivo en un puerto.
Y AD
en el dispositivo.
Intercambio de datos
Luego que un cliente se conecta La invocación de métodos
con servidor RMI
el servidor RMI Android. remotos es correcta.
EC
Android.
En el dispositivo se debe obtener
Los mensajes mediante
T
Notificaciones y el token de registro (para este pa-

FCM llegan correctamente
IO
mensajes de FCM. so el dispositivo debe tener acce-

al dispositivo.
so a internet).
BL

BI
77
3.6.2. Pruebas de compatibilidad
En la realización de estas pruebas se obtuvo inconvenientes, debido a cambios en las ver-
siones del sistema Android y fue necesario codificar funciones condicionales dependientes del
nivel de API correspondiente.
Tabla 3.3: Fallos y correcciones de pruebas de compatibilidad.
S
CA
Android Descripción de fallos Correcciones
Problemas de invocación de la Se agregó una variable de
Nivel de API 21 o
SI
interfaz de activación de la Ad- control para bloquear las ope-
superior (versión
ministración de dispositivos del raciones cuando se lanza la
AS FÍ
5.0 o superior).
sistema. interfaz.
Errores de grupos de permisos, Se definió algunas validacio-
IC S
Nivel de API 23 o
para algunos permisos registra- nes adicionales de permisos
ÁT CIA
superior (versión
6.0 o superior).
dos en el fichero Manifiesto de
la aplicación.
de versión antes de la realiza-
ción de alguna operación.
EM IEN
AT C
M E
Y AD
T EC
IO
BL
BI
78
Para la tabla anterior se muestran algunas capturas de los errores.
3.6.3. Pruebas de dispositivos
Los dispositivos con Android son variantes hoy en día, en este proyecto se tomó dos ti-
S
CA
pos, que son los teléfonos inteligentes y tabletas. Después de las pruebas se obtuvo los fallos
mostrados a continuación:
SI
AS FÍ
Tabla 3.4: Fallos y correcciones de pruebas en tipos de dispositivos con Android.
Dispositivo Descripción de fallos Correcciones
IC S
ÁT CIA Algunos datos de informa-
ción del dispositivo, no se
pueden obtener o se obtiene Se implementó validaciones y
EM IEN
Teléfono inteligente datos inconsistentes, debido a los datos inconsistentes no se
que cada fabricante de dis- tomaron.
positivos modifica el sistema
AT C
Android.
Se implementó validaciones
M E
para permisos correspondien-

Error al obtener información
Y AD
tes a telefonía y la obtención

Tableta de telefonía.
de datos que tengan depen-
dencia de esta funcionalidad.
EC
Problemas al obtener datos

Se validó los valores nulos en
de conexión a interfaz de red
caso de no existir dicha fun-
T
móvil, por interfaz no exis-

cionalidad de red.
IO
tente en algunas tabletas

BL
BI
79
3.6.4. Pruebas de funcionalidad
En esta sección se hicieron pruebas de las funcionalidades principales y se obtuvieron una
lista de fallos que se describen, por consiguiente:
Tabla 3.5: Fallos y correcciones de pruebas de funcionalidad de la aplicación Android.
Módulos de
S
Descripción de fallos Correciones
aplicación Android
CA
Un problema de formación Se quitaron algunos carac-
Obtención de informa- incorrecta del formato JSON, teres de las cadenas de da-
SI
ción del dispositivo. en la creación de textos largos tos y se revisó el formato
de información. correcto de JSON.
AS FÍ
Errores de conversión de da- Los valores se obtienen
tos almacenados en local, como cadenas y luego se
IC S
Almacenamiento en lo-
cuando se intenta recuperar encapsuló la conversión en
cal.
ÁT CIA los datos de los ficheros me-
diante su clave.
un capturador de excepcio-
nes.
Cuando se obtenía los datos
EM IEN
del texto en formato JSON, Se validó los valores nulos
Acciones remotas. se produjo un error de conver- y los nombres del objeto
sión de datos para crear el ob- JSON.
AT C
jeto.
M E

Y AD
T EC
IO
BL
BI
80
Para la tabla de pruebas de funcionalidad en aplicación Android, se muestran algunas cap-
turas de los errores.
Para la tabla de pruebas de funcionalidad del Servidor de Control, se muestran algunas
capturas de los errores.
S
CA
SI
1.
AS FÍ
IC S
2. ÁT CIA
EM IEN
3.
AT C
M E
4.
Y AD
T EC
IO
BL
BI
81
Tabla 3.6: Fallos y correcciones de pruebas de funcionalidad del servidor de control.
Módulos de
Descripción de fallos Correcciones
Servidor de Control
Se utilizó una librería de
conversión de datos pri-
Problema al obtener valores
Procesamiento de datos mitivos de JSON a valo-
de arreglos y convertirlos a
en formato JSON. res primitivos de Java co-
objetos de Java.
mo String, Integer, Boo-
S
lean, etc.
CA
Se presentó un fallo en la con- Se agregó la creación de
currencia de transacciones so- nuevas sesiones para cada
SI
Base de datos con bre operaciones con la base transacción concurrente en
Hibernate. de datos. una nueva tarea.
AS FÍ
Se hizo las correcciones
Errores comunes por malfor-
con ayuda de los logs al
IC S
mación de consultas en SQL.
formato correcto de SQL.
ÁT CIA Problemas con uso de cache
por parte de la librería en la
Se utilizó una alternativa
de sesiones para consultas
creación de sesiones de cone- nativa en SQL del gestor
EM IEN
xión a la base de datos. de base de datos.
Errores comunes de creación Con los logs de errores
de acciones remotas en JSON se agregó validaciones pa-
AT C
Acciones remotas. y procesamiento de envío al ra crear y enviar acciones

M E
dispositivo. remotas.
Se siguió la descripción de
Y AD
Incorrecta creación de texto

parámetros de notificacio-
de notificaciones en formato
nes de FCM en los méto-
JSON para enviarlas a FCM.
dos para Android.
EC
Algunos campos de las tablas

con valores nulos generaban Con Hibernate se convirtió
T
Visualización de tablas
errores al ser mostrados en las tipos de datos de la base de
IO
de la base de datos.
interfaces de tipo tabla de Ja- datos a datos de Java.
va.
BL

BI
82
Capítulo 4
S
CA
SI
Resultados de la tesis
AS FÍ
IC S
ÁT CIA
A continuación se presenta un análisis de los resultados computacionales obtenidos. Así
mismo se realiza una contrastación con los trabajos previos de esta investigación:
EM IEN
El objetivo del desarrollo de una aplicación Android que permita el control de un dispositivo
AT C
móvil es lo que percibe esta investigación y para su realización se planteó una descomposición
M E
Y AD
en objetivos específicos; iniciando con el análisis de la información obtenida de diversas fuentes
y la elaboración de comparativas sobre los temas de interés y tecnologías de desarrollo de

EC
aplicaciones.
T
IO
La definición de un modelado base de comunicación usando la arquitectura cliente-servidor,

BL
se hizo indispensable en el control requerido; tomando en este caso como soporte los métodos
BI
83
de la tecnología RMI y el almacenamiento centralizado en una base de datos; que dan lugar
a dos componentes definidos como una aplicación Android actuando de cliente y un servidor
principal de control en Java, ambos con características extensibles.
En la implementación del modelo de comunicación fundamentado en RMI tanto en An-
droid y Java, se tomo una alternativa denominada LipeRMI. Los resultados de la codificación
S
CA
de los algoritmos de inicio y establecimiento de la comunicación fueron de menos dificultad con
SI
LipeRMI, así como la definición e invocación de métodos remotos. Con respecto a la configura-
AS FÍ
ción e implementación de FCM, también fue simple; aunque esta tecnología es dependiente de
IC S
los servicios de Google y de Internet, suma una opción adicional de control mediante el envío
ÁT CIA
de mensajes al dispositivo.
EM IEN
La implementación del intercambio de datos en la comunicación y los métodos de control,
se hizo uso del formato JSON; empezando con la obtención de información del dispositivo, que
AT C
M E
se envía al Servidor de Control, donde es almacenada en las tablas de la base de datos, para
Y AD
posteriormente ser usada en el envío de las acciones remotas a ejecutar sobre el dispositivo.
Tanto el envío de información como las acciones remotas, se crearon como una estructura base
EC
de control y a la vez extensible.

T
IO
Para las pruebas de la aplicación Android junto con el Servidor de Control, se consideró
BL
como población los dispositivos con Android 4 en adelante y como se tiene la premisa de
BI
84
que Android es el mismo sistema instalado en los dispositivos, la muestra se restringe a un
dispositivo físico del tipo tableta o teléfono inteligente. Así mismo la aplicación esta enmarcada
para Android de nivel de API 14 o superior (Android 4 o superior), cabe destacar que la versión
4 (Nivel de API 14 hasta 20) esta quedando obsoleta, por lo que la mayor parte de pruebas se
realizó sobre Android 5 hasta 7 (Nivel de API 21 hasta 24); considerando también que estas
S
CA
versiones ofrecen nuevas opciones a los desarrolladores para el control de los dispositivos, no
presentes en Android 4.
SI
AS FÍ
La compatibilidad de la aplicación con las versiones de Android, fue resuelta agregando
IC S
librerías de compatibilidad desarrolladas por Google y escribiendo funciones condicionales a
ÁT CIA
los niveles de API. Sin embargo ciertas opciones de control solo estarán disponibles en algunas
EM IEN
versiones de Android, ya que en muchos casos no es posible encontrar funciones equivalen-
tes, debido a limitaciones de tipo de dispositivo o nivel de API de Android. Para versiones 7
AT C
de Android (Nivel de API 25) o superiores no es posible asegurar en su totalidad la correcta

M E
Y AD
funcionalidad en los dispositivos.
De acuerdo al primer trabajo de Saavedra (2014); quienes utilizaron una arquitectura cliente-
EC
servidor solamente de envió de datos de inventarios de otros equipos y precaria información

T
IO
del mismo dispositivo móvil a un servidor. De este antecedente se ha tomado e implementado

BL
la idea de tener información digital almacenada en una base de datos y no en documentos

BI
85
físicos, para consultas, elaboración de reportes, etc. Agregando también el control sobre los
dispositivos, con la ayuda de estos datos registrados.
El segundo trabajo de Garcia (2014); utilizó los datos de geolocalización del dispositivo
Android y los envía a un servidor, permitiendo tener el control desde la aplicación de servidor
sobre el dispositivo y el usuario. La misma solución se plantea en este trabajo; restringiendo
S
CA
solo a las 10 últimas posiciones, evitando sobrecargar la base de datos y haciendo uso de Google
SI
Maps.
AS FÍ
En el tercer trabajo de Pacheco (2011); se toma inventarios de otros equipos, y así como en
IC S
ÁT CIA
el primer antecedente, estos se envían a un servidor; pero también se envía poca información del
mismo dispositivo móvil. Lo usado de este antecedente en esta tesis desarrollada es el formato
EM IEN
de transferencia de datos JSON, en la comunicación cliente-servidor y mejorando el envío de
mayor información, transfiriéndolos en ficheros JSON temporales y procesándolos de manera

AT C
M E
conjunta en el servidor.
Y AD
En cuanto al cuarto trabajo de Godoy (2015); se recauda información de uso del dispositivo
EC
y principalmente datos de geolocalización, que se envía a un servidor, como en el segundo

T
antecedente. Esta idea fue tomada e implementada, pero descartando la obtención de los datos
IO
de geolocalización del servicio del Google Maps, que requiere de una conexión a Internet. La
BL
mejora que se desarrollo, es una solución para obtener datos mediante el GPS o Red en el
BI
86
dispositivo.
El último trabajo de Borja (2015); se planteó una solución de control, enviando información
del dispositivo móvil con Android; utilizando una arquitectura cliente-servidor, para luego con
estos datos ejercer algún control delimitado y haciendo uso también del módulo de Adminis-
tración de dispositivos del sistema Android. Esta solución también se ha tomado para esta tesis
S
CA
desarrollada, haciendo cambios para tener un servidor activo en el dispositivo, usar FCM y el
SI
uso de acciones remotas en los dispositivos de tipo celular y tableta.
AS FÍ
IC S
ÁT CIA
EM IEN
AT C
M E
Y AD
T EC
IO
BL
BI
87
Capítulo 5
S
CA
SI
Consideraciones finales
AS FÍ
IC S
5.1.
ÁT CIA
Conclusiones
EM IEN
Se vio finalizada la fase investigación mediante la creación de una arquitectura de comu-

AT C
nicación cliente-servidor basada en RMI, con los componentes de la aplicación Android y una
M E
Y AD
aplicación de escritorio actuando como Servidor de Control.
Se cumplió el objetivo de implementar la comunicación basada en el modelo cliente-servidor

EC
y mediante FCM para las conexiones entre la aplicación Android y el Servidor de Control, que
T
IO
se estableció en la arquitectura del proyecto.

BL
Se definió los módulos principales e interfaces tanto en la aplicación Android como en

BI
88
el Servidor de Control, que nos ayudan a controlar y obtener la información deseada de los
dispositivos con Android.
Luego del análisis de versiones de Android se programaron métodos dependientes de un
nivel de API de Android, ya que debido a los cambios muchas funcionalidades no trabajaban
correctamente o ciertos módulos tenían fallas.
S
CA
La inclusión de FCM al proyecto fue de mucha ayuda, cuando no se logra una comunicación
SI
con el dispositivo mediante la arquitectura cliente-servidor basada en RMI, pero si se tiene una
AS FÍ
conexión a Internet en el dispositivo móvil con Android.
IC S
5.2.
ÁT CIA
Trabajos futuros
EM IEN
Para el presente proyecto finalizado, se tiene las siguientes recomendaciones a considerar

AT C
para la continuación de la línea de investigación, construcción de mejoras y posibles trabajos

M E
Y AD
futuros:
Se puede agregar nuevas funciones para obtener información del dispositivo Android, según
EC
se requiera y crear los datos en formato JSON para enviarlos al Servidor de Control.
T
IO
En el Servidor de Control y en la base de datos se pueden registrar nuevas tablas o campos

BL
de almacenamiento de información del dispositivo o datos de control.

BI
89
Con las opciones de control basadas en acciones remotas, solo basta agregar también nuevas
acciones de control que se requiera, identificándolos por un código numérico de grupo y de
ejecución en el dispositivo.
Con una base de datos conteniendo información de dispositivos Android y datos de control,
se puede crear nuevas aplicaciones dedicas para tablas específicas o de tal modo que ayuden a
S
CA
tener nuevas funcionalidades como reportes, estadísticas, etc.
SI
Las versiones del sistema Android están en constante incorporación de mejoras y es de
AS FÍ
vital importancia tener a buen criterio revisar la documentación que ofrece Google, antes de la
IC S
ÁT CIA
apertura de cambios en la aplicación Android y en el Servidor de Control.
EM IEN
AT C
M E
Y AD
T EC
IO
BL
BI
90
Bibliografía
S
CA
SI
Arteaga, E. (2006). Sistema Cliente Servidor para Visión de un Robot Móvil usando
AS FÍ
una Wireless Lan. Recuperado el 02/05/2016, de http://tesis.pucp.edu.pe/
IC S
repositorio/bitstream/handle/123456789/984/ARTEAGA_OSORIO_
ÁT CIA
EDWARD_ROBOT_MOVIL_WIRELESS_LAN.pdf?sequence=1.
EM IEN
Borja, S. (2015). Aplicativo de rastreo para Sistemas Android, mediante una pla-
taforma web y mensajes de texto en caso de pérdida o robo. Recuperado el

AT C
M E
30/04/2016, de http://repositorio.ute.edu.ec/bitstream/123456789/
Y AD
13840/1/62027_1.pdf.
EC
Cabrera, A.; Cueva, D. (2015). Arquitectura adaptada para el diseño de aplicaciones mó-
T
viles en Android. Recuperado el 30/04/2016, de http://repositorio.upao.

IO
edu.pe/bitstream/upaorep/1221/1/CABRERA_ALAN_DISE%C3%91O_
BL
APLICACIONES_MOVILES.pdf.
BI
91
Cordero, N. (2012). Diseño de un Cliente para Dispositivos Móviles para un Siste-
ma de Almacenamiento Voluntario en la Nube. Recuperado el 07/05/2016, de
http://e-archivo.uc3m.es/bitstream/handle/10016/16337/TFG_
Nicolas_Cordero_Fernandez.pdf?sequence=1.
Cruz, J. (2013). Desarrollo de una Aplicación Móvil para el Abandono del Tabaco usando
S
CA
Sistema Operativo Android. Recuperado el 06/05/2016, de http://tesis.blanque.
SI
com.ar/tesis/Home_files/Tesis_Juan_Cruz_Manuel_Gorreri.pdf.
AS FÍ
Durán, F. (2013). Desarrollo de un Sistema de Información para el Campeonato Ecuatoriano
IC S
ÁT CIA
de Futbol Primera A para Iphone. Recuperado el 02/07/2017, de http://bibdigital.
epn.edu.ec/bitstream/15000/6546/1/CD-5012.pdf.
EM IEN
Espinel, F. (2005). Sistema Cliente/Servidor aplicado a punto de ventas a través de Sockets para
AT C
la Ferretería San Agustín. Recuperado el 02/05/2016, de http://repo.uta.edu.ec/

M E
bitstream/123456789/398/1/Tesis_t143si.
Y AD
Garcia, W. (2014). Desarrollo de una Aplicación Web que Monitoree las Actividades La-
EC
borales de un Empleado Mediante Smartphone Aplicado con Android. Recuperado el

T
30/04/2016, de http://repositorio.ug.edu.ec/bitstream/redug/6547/
IO
1/TesisCompleta-495.pdf.
BL
BI
Godoy, M. (2015). Diseño de una aplicación Android para la recogida de datos de tráfico y su
92
comunicación a un servidor. Recuperado el 30/04/2016, de https://riunet.upv.es/
bitstream/handle/10251/53940/Memoria.pdf?sequence=2.
Grimaldo, G. (2013). Desarrollo de Aplicación Móvil de apoyo a la Plataforma Web del Obser-
vatorio “Monitoreo de Variables Físicas y Fisiológicas en niños y adolescentes en edad es-
colar de Risaralda”. Recuperado el 02/07/2016, de http://repositorio.utp.edu.
S
CA
co/dspace/bitstream/11059/4087/1/0053G861.pdf.
SI
Jabba, D.; Alies, M. (2003). Conectividad de Java con base de datos mediante invocación de
AS FÍ
objetos con métodos remotos (objetos RMI). Recuperado el 10/05/2016, de http://www.
IC S
ÁT CIA
redalyc.org/articulo.oa?id=85201405.
Loayza, A. (2014). Aplicación para la autoconfiguración de dispositivos móviles Android basa-

EM IEN
da en la información de contexto. Recuperado el 10/05/2016, de http://repositorio.

AT C
ute.edu.ec/bitstream/123456789/5617/1/56830_1.pdf.
M E
Y AD
Lozano, M. (2012). Desarrollo de una Aplicación Móvil Android para Control Remoto
de un Servicio Web. Recuperado el 30/04/2016, de http://e-archivo.uc3m.

EC
es/bitstream/handle/10016/16913/TFG_Maria_Lozano_Perez.pdf?
T
IO
sequence=1.
BL
Madero, C. (2013). Controles y seguridad bajo entorno Android. Recuperado

BI
93
el 10/05/2016, de http://e-archivo.uc3m.es/bitstream/handle/10016/
18102/PFC_Cristian_Madero_Garcia.pdf?sequence=1.
Martinez, A. (2005). Diseño de un Entorno Colaborativo y su Aplicación a platafor-
mas de aprendizaje. Recuperado el 07/05/2016, de http://www.tesisenred.net/
bitstream/handle/10803/10929/MartinezCarreras.pdf?sequence=1.
S
CA
Molina, Y.; Sandoval, J. (2012). Sistema Operativo Android: Características y Funcionalidad
SI
para Dispositivos Móviles. Recuperado el 30/04/2016, de http://repositorio.utp.
AS FÍ
edu.co/dspace/bitstream/11059/2687/1/0053M722.pdf.
IC S
Pacheco, V. (2011).
ÁT CIA Diseño e Implementación de una Aplicación Distribuida de
Gestión de Inventario para Dispositivos Móviles. Recuperado el 30/04/2016,

EM IEN
de http://e-archivo.uc3m.es/bitstream/handle/10016/13006/
AT C
Memoria_PFC_Victor_Pacheco_FINAL.pdf?sequence=1.
M E
Y AD
Roman, J. (2006). Diseño e Implementación de un Sistema Colaborativo de Mensa-
jería Electrónica para la Universidad de Pamplona. . Recuperado el 02/05/2016, de

EC
http://e-archivo.uc3m.es/bitstream/handle/10016/16337/TFG_
T
Nicolas_Cordero_Fernandez.pdf?sequence=1.
IO
BL
Saavedra, P.; Solorzano, J. (2014). Diseño de una Aplicación Móvil en el Sistema Operati-
BI
vo Android para el Reconocimiento de Códigos de Barras utilizando Procesamiento Digital
94
de Imágenes y Modelo Cliente-Servidor para Áreas de Soporte Técnico. Recuperado el
16/04/2016, de http://www.repositorioacademico.usmp.edu.pe/handle/
usmp/1156.
Santana, A. (2009). Infraestructura Cliente-Servidor para Aplicaciones Móviles. Recu-
perado el 16/04/2016, de http://itzamna.bnct.ipn.mx/dspace/bitstream/
S
CA
123456789/9891/1/210.pdf.
SI
Veloz, W. (2013). Control GSM
R para el bloqueo y desbloqueo remoto de un
AS FÍ
vehículo mediante una aplicación móvil para dispositivos Android .
R Recuperado el
IC S
ÁT CIA
10/05/2016, de http://repositorio.ute.edu.ec/bitstream/123456789/
5754/1/53556_1.pdf.
EM IEN
AT C
M E
Y AD
T EC
IO
BL
BI
95
Anexo A
S
CA
SI
Interfaces y funcionalidades de la
AS FÍ
IC S
aplicación Android ÁT CIA
EM IEN
Se describen los resultados finales visibles de la interfaces y los principales resultados fun-
AT C
cionales de la aplicación Android en un dispositivo móvil.

M E
Y AD
1. Interfaces de activación de permisos necesarios en Android 6 o superior.

T EC
IO
BL
BI
96
S
CA
SI
AS FÍ
IC S
2. Interfaces de registro de la aplicación en la lista blanca del sistema para Android 6 o
superior. ÁT CIA
EM IEN
AT C
M E
Y AD
T EC
IO
BL
BI
97
3. Interfaces de activación del módulo de Administración de Dispositivos para la aplicación
Android.
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
4. Imagen del Servicio de la aplicación Android en ejecución en segundo plano y mostrando

AT C
notificaciones de estado.
M E
Y AD
T EC
IO
BL
BI
98
S
CA
SI
AS FÍ
IC S
ÁT CIA
5. Menú lateral y desplegable de la aplicación Android.
EM IEN
AT C
M E
Y AD
T EC
IO
BL
BI
99
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
6. Interfaz de inicio y de información de la aplicación Android.

AT C
M E
Y AD
T EC
IO
BL
BI
100
S
CA
SI
AS FÍ
IC S
ÁT CIA
7. Interfaz de mensajes recibidos desde el Servidor de Control en la aplicación Android. Se
EM IEN
muestra una notificación en la barra del sistema cuando se recibe uno nuevo.
AT C
M E
Y AD
T EC
IO
BL
BI
101
S
CA
SI
AS FÍ
IC S
ÁT CIA
8. Interfaz de preferencias de la aplicación Android.
EM IEN
AT C
M E
Y AD
T EC
IO
BL
BI
102
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
AT C
M E
Y AD
T EC
IO
BL
BI
103
Anexo B
S
CA
SI
Interfaces y funcionalidades del Servidor
AS FÍ
IC S
de Control ÁT CIA
EM IEN
Se detallan los interfaces de mayor importancia, junto con los datos de los dispositivos
AT C
enviados por la aplicación Android para el control deseado.

M E
Y AD
1. Interfaz del Servidor dec Control para la visualización de datos de los dispositivos y
EC
opciones de control generales, acciones remotas y de administración de dispositivitos del
sistema Android.
T
IO
BL
BI
104
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
2. Interfaz de opciones generales de control.
AT C
M E
Y AD
T EC
IO
BL
BI
105
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
3. Interfaz de envío de mensajes al dispositivo Android. Se ingresa un título descriptivo y
un texto de mensaje.
AT C
M E
Y AD
T EC
IO
BL
BI
106
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
4. Interfaz de envío de ficheros al dispositivo. Se selecciona un fichero del sistema y este
se envía al dispositivo Android, almacenándose en el directo principal de la aplicación

AT C
Android.
M E
Y AD
T EC
IO
BL
BI
107
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
5. Interfaz de control de directorios de almacenamiento y ficheros del dispositivo. Se tiene
una navegación sobre los directorios y ficheros; así como opciones de control sobre los
AT C
mismos.
M E
Y AD
T EC
IO
BL
BI
108
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
6. Interfaz de geolocalización con Google Maps. Usando los datos de geolocalización que
AT C
la aplicación Android envía cada periodo de tiempo, se actualiza la posición en el Mapa;

M E
mostrando ademas información en la parte inferior dia.

Y AD
T EC
IO
BL
BI
109
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
7. Interfaz de consola de envió de acciones remotas. Cada vez que selecciona una acción
AT C
remota se muestra esta interfaz con información de su ejecución.

M E
Y AD
T EC
IO
BL
BI
110
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
8. Interfaz de acciones remotas generales para los dispositivos registrados en el servidor

AT C
M E
principal.
Y AD
T EC
IO
BL
BI
111
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
9. Interfaz de acciones remotas con ayuda del módulo de Administración de Dispositivos del
sistema Android. Estas opciones requieren que este activo este módulo en la aplicación
AT C
Android.
M E
Y AD
T EC
IO
BL
BI
112
S
CA
SI
AS FÍ
IC S
ÁT CIA
EM IEN
AT C
M E
Y AD
T EC
IO
BL
BI
113

Evolucion Web

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Evolucion Web

Uploaded by

Copyright:

Available Formats

Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT

UNIVERSIDAD NACIONAL DE TRUJILLO

Facultad de Ciencias Físicas y Matemáticas

Escuela Académico Profesional de Informática

DESARROLLO DE UNA APLICACIÓN ANDROID PARA

EL CONTROL DE UN DISPOSITIVO MÓVIL USANDO

Pedro Luis Novoa Ruiz

EL CONTROL DE UN DISPOSITIVO MÓVIL USANDO

PEDRO LUIS NOVOA RUIZ

DESARROLLO DE UNA APLICACIÓN ANDROID PARA

ASESOR: EDWIN R. MENDOZA TORRES

Desarrollo de una Aplicación Android para el Control de un

Prof. José L. Peralta Luján

Departamento de Informática - UNT

Prof. José A. Díaz Pulido

Departamento de Informática - UNT

Trujillo, 25 de octubre del 2017

Dedico esta tesis a :

este proyecto. Por estar presentes, por la confianza y estimulación a la superación

en lo personal y profesional cada día.

por su apoyo y la ayuda otorgada durante el proceso de desarrollo del mismo.

El trabajo de investigación percibe el objetivo de control de un dispositivo móvil

en un entorno de trabajo, mediante el desarrollo de una aplicación Android con

el soporte de un Servidor y una Base de Datos de almacenamiento. El control se

RMI (Remote Method Invocation) y en una implementación de Java RMI. Además

se empleó una comunicación secundaria con FCM (Firebase Cloud Messaging).

La fase de desarrollo y pruebas de la aplicación Android se fundamentó en los

cambios de versiones de Android y en las funciones de compatibilidad de versiones

4 en adelante, haciendo posible su ejecución dirigida a dispositivos de tipo teléfo-

Palabras claves: control, cliente-servidor, RMI, dispositivo móvil, aplicación An-

environment, through the development of an Android application with the support

For communication use was made of the client-server architecture based on

RMI (Remote Method Invocation) and an implementation of Java RMI. In addition

to the use of FCM (Firebase Cloud Messaging) as a secondary communication.

onwards, making possible its implementation directed to devices of type phones

Keywords: control, client-server, RMI, mobile device, Android application.

TCP: Protocolo Control de Transmisión. Protocolo orientado a conexión.

TCP/IP: Protocolo Control de Transmisión/Protocolo de Internet. Define un conjunto de

JVM: Máquina Virtual de Java.

APK: Fichero resultante de la compilación de una aplicación Android.

APP: Acrónimo de Aplicación, referente en este proyecto a una aplicación móvil.

XML: Formato de transferencia de información basado en etiquetas, atributos y valores.

JSON: Formato de transferencia de información basada en tipos de datos de lenguajes de

programación como objetos, arreglos y tipos básicos.

2.6. Arquitectura de FCM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.7. Fases y etapas de la metodología ágil Mobile-D. . . . . . . . . . . . . . . . . . . . 43

3.1. Arquitectura general del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.2. Arquitectura de la comunicación del proyecto. . . . . . . . . . . . . . . . . . . . . 53

3.3. Modelo de datos E-R de la comunicación del proyecto. . . . . . . . . . . . . . . . . 58

3.5. Implementación del Servidor RMI en la aplicación Android. . . . . . . . . . . . . . 61

3.6. Diagrama de flujo de recepción de mensajes de FCM en la aplicación Android. . . . . 62

3.7. Servicio de recepción de mensajes de FCM en la aplicación Android. . . . . . . . . . 62

3.8. Registro de políticas de Administración de Dispositivos de la aplicación Android. . . . 63

3.9. Registro del BrodcastReceiver de la API Administración de Dispositivos de la aplica-

3.11. Estructura de mensaje de las acciones remotas. . . . . . . . . . . . . . . . . . . . . 65

3.15. Implementación del Cliente de Servidor RMI Android. . . . . . . . . . . . . . . . . 70

3.16. Cliente Web de FCM para envío de mensajes. . . . . . . . . . . . . . . . . . . . . 71

3.17. Diagrama de flujo de envío de acciones remotas al dispositivo Android. . . . . . . . . 72

3.18. Envío de acciones remotas al dispositivo Android. . . . . . . . . . . . . . . . . . . 73

3.19. Diagrama de flujo de registro y actualización de datos de dispositivos. . . . . . . . . 74

3.20. Métodos principales de operaciones sobre la base de datos con Hibernate. . . . . . . . 75

3.3. Fallos y correcciones de pruebas de compatibilidad. . . . . . . . . . . . . . . . 78

3.4. Fallos y correcciones de pruebas en tipos de dispositivos con Android. . . . . . 79

3.5. Fallos y correcciones de pruebas de funcionalidad de la aplicación Android. . . 80