Desarrollo e implementación de una solución completa … · Diagrama de estados de las tareas....

Rubén Moral Miera

Desarrollo e implementación de una solución completapara empresas de mensajería/paquetería utilizando

dispositivos Android y la nube de dispositivos de Digi

Angel Luis Rubio García

Facultad de Ciencias, Estudios Agroalimentarios e Informática

Grado en Ingeniería Informática

2012-2013

Título

Autor/es

Director/es

Facultad

Titulación

Departamento

TRABAJO FIN DE GRADO

Curso Académico

© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2013

publicaciones.unirioja.esE-mail: [email protected]

Desarrollo e implementación de una solución completa para empresas demensajería/paquetería utilizando dispositivos Android y la nube de

dispositivos de Digi, trabajo fin de gradode Rubén Moral Miera, dirigido por Angel Luis Rubio García (publicado por la Universidad

de La Rioja), se difunde bajo una LicenciaCreative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported.

Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a lostitulares del copyright.

FACULTAD DE CIENCIAS, ESTUDIOS AGROALIMENTARIOS E INFORMÁTICA

TRABAJO DE FIN DE GRADO

GRADO EN INGENIERÍA INFORMÁTICA

Desarrollo e implementación de una solución completa para empresas de mensajería/paquetería utilizando

dispositivos Android y la nube de dispositivos de Digi – Aplicación Móvil

Autor: Director: D. Rubén Moral Miera D. Ángel Luis Rubio García

Departamento de Matemáticas y Computación Curso 2012/2013

II

Antes de comenzar quiero dar las gracias a mi director, Ángel, por su dedicación, su ayuda, sus consejos y su

colaboración a lo largo de estos últimos años.

III

Resumen Actualmente, existen multitud de empresas que ofrecen servicios de paquetería y mensajería urgente (Correos, Seur, FedEx, UPS, DHL…). Todas ellas operan a nivel nacional o internacional; sin embargo, existen muy pocas que trabajen en el ámbito de una ciudad y sus suburbios, donde en vez de utilizar el coche o la furgoneta para repartir los paquetes se use una bicicleta.

La idea del proyecto, propuesto por la empresa Digi International Spain como parte de su oferta de prác-ticas para Grado, ha sido desarrollar un sistema destinado a este tipo de empresas pequeñas, donde con una bicicleta y un tablet baste para realizar todas las tareas de reparto.

Palabras clave: sistema multiplataforma, servicios de paquetería, reparto en bicicleta.

Abstract Currently, there are many companies offering delivery and courier services (Correos, Seur, FedEx, UPS, DHL…). They all operate at national or international level; however, there are very few that work in the area of a city and its suburbs, where deliverers use a bicycle instead the car or van to deliver the pack-ages.

The idea of the project, proposed by the company Digi International Spain as part of their practices of-fered to Computer Engineering Degree, has been the development of a system intended for this kind of small companies, where with a bicycle and a tablet is enough to perform all delivery tasks.

Keywords: cross-platform system, delivery services, bicycle messenger.

IV

Índice general

Capítulo 1. Introducción ....................................................................................................... 7

1.1. Antecedentes ................................................................................................................... 7

1.2. Objetivos .......................................................................................................................... 9

1.3. Planificación ................................................................................................................... 10

1.4. Seguimiento del proyecto .............................................................................................. 11

Capítulo 2. Desarrollo ........................................................................................................ 14

2.1. Análisis ............................................................................................................................ 14

2.1.1. Identificación de los usuarios participantes ........................................................... 14

2.1.2. Catálogo de requisitos del sistema ......................................................................... 14

2.1.3. Casos de uso ............................................................................................................ 19

2.2. Diseño ............................................................................................................................. 28

2.2.1. Diseño de la interfaz de usuario ............................................................................. 28

2.2.2. Diagrama de navegación ......................................................................................... 32

2.2.3. Arquitectura del sistema ......................................................................................... 33

2.2.4. Almacenamiento de datos ...................................................................................... 33

2.2.5. Patrones de diseño ................................................................................................. 35

2.2.6. Diseño de clases ...................................................................................................... 36

2.2.7. Diseño del plan de pruebas .................................................................................... 38

2.3. Implementación ............................................................................................................. 39

2.3.1. Tecnologías usadas ................................................................................................. 39

2.3.2. Librerías empleadas ................................................................................................ 40

2.3.3. Estructura del proyecto .......................................................................................... 40

2.3.4. Desarrollo de las aplicaciones ................................................................................. 42

Fase 1. Adaptación del código, incidencias y servicios y horas límite ............................... 42

Fase 2. Sincronización ........................................................................................................ 44

Fase 3. Creación de las interfaces de la nueva aplicación ................................................. 46

V

Fase 4. Funcionalidad de la aplicación para los clientes .................................................... 48

2.4. Pruebas ........................................................................................................................... 52

Capítulo 3. Conclusiones .................................................................................................... 56

3.1. Evaluación de objetivos .................................................................................................. 56

3.2. Problemas planteados y procedimiento para su resolución ......................................... 56

3.3. Conocimientos adquiridos ............................................................................................. 57

3.4. Mejoras del proyecto ..................................................................................................... 58

Capítulo 4. Bibliografía ....................................................................................................... 59

VI

Índice de figuras Figura 1. Arquitectura del sistema. ................................................................................................. 8

Figura 2. Comparación entre tareas creadas y tareas resueltas. ................................................. 13

Figura 3. Diagrama de estados de las tareas. ............................................................................... 15

Figura 4. Diagrama de casos de uso para la aplicación de repartidores. ..................................... 19

Figura 5. Diagrama de casos de uso para la aplicación de clientes. ............................................. 21

Figura 6. Diagrama de actividad del caso de uso [Localizar pedido]. ........................................... 23

Figura 7. Diagrama de actividad del caso de uso [Crear nuevo pedido]. ..................................... 25

Figura 8. Diagrama de actividad del caso de uso [Iniciar sesión]. ................................................ 27

Figura 9. Interfaces al comienzo del proyecto. ............................................................................. 28

Figura 10. Evolución de la pantalla de inicio................................................................................. 29

Figura 11. Evolución de la pantalla de detalles de la tarea. ......................................................... 29

Figura 12. Pantalla inicial. ............................................................................................................. 30

Figura 13. Pantalla del primer paso de nuevo pedido. ................................................................. 31

Figura 14. Arquitectura en capas y niveles. .................................................................................. 33

Figura 15. Diagrama de paquetes. ................................................................................................ 36

Figura 16. Diagrama de clases del modelo de objetos. ................................................................ 36

Figura 17. Diagrama de clases de la capa de lógica de negocio. .................................................. 37

Figura 18. Diagrama de clases de la capa de persistencia. ........................................................... 37

Figura 19. Diferencia entre Java VM y Dalvik VM. ........................................................................ 39

Figura 20. Contenido de la carpeta /src. ....................................................................................... 41

Figura 21. Contenido de /res. ....................................................................................................... 41

Figura 22. Excepción que aparecía al arrancar la aplicación. ....................................................... 42

Figura 23. Implicaciones de ambos modos de conexión. ............................................................. 45

Figura 24. Estructura de los layouts de la aplicación. ................................................................... 46

Figura 25. Comparación de ambas vistas. .................................................................................... 49

Figura 26. Vista de las direcciones almacenadas y la información de la empresa. ...................... 51

7

Capítulo 1. Introducción La presente memoria trata de recoger los aspectos más importantes del trabajo realizado por Rubén Moral en el proyecto “Desarrollo e implementación de una solución completa para empresas de mensa-jería/paquetería utilizando dispositivos Android y la nube de dispositivos de Digi – Aplicación Android”, realizado en el ámbito de la empresa Digi International Spain S.A.U.

1.1. Antecedentes Durante los últimos años y gracias a la expansión de Internet, cada vez más personas en el mundo reali-zan sus compras a través de la red. Debido a este hecho, las empresas de paquetería y servicio urgente están proliferando, ya que son una de las bases del comercio electrónico. La mayoría de ellas operan a nivel nacional o internacional; sin embargo, existen muy pocas que trabajen en el ámbito de una ciudad y sus suburbios, donde en vez de utilizar el coche o la furgoneta para repartir los paquetes se use una bicicleta.

Por otra parte, las tecnologías móviles también crecen rápidamente. Los nuevos teléfonos inteligentes (conocidos como smartphones) son capaces de realizar actividades semejantes a las que se pueden ha-cer con un ordenador a muy bajo coste, con la ventaja de la gran movilidad que permiten.

La idea de este proyecto ha sido unir los dos hechos anteriores, es decir, desarrollar un sistema que permita a pequeñas empresas de paquetería realizar todas las funciones necesarias sin necesidad de contar con herramientas complejas, simplemente con un smartphone o un tablet.

El proyecto en sí empezó a realizarse en septiembre de 2012, en el periodo de Prácticas I. Puesto que su tamaño era demasiado grande, ya que no solo incluía la aplicación Android sino también la creación de un portal web para clientes y administradores, se decidió dividirlo en dos componentes: Web y An-droid1, cada una de ellas desarrollada por un alumno de prácticas. El proyectante escogió la segunda parte, ya que sentía curiosidad por algo en lo que no había desarrollado nunca.

El proyecto se planificó para ser realizado desde septiembre de 2012 hasta mayo de 2013, englobando las asignaturas de Prácticas I, Prácticas II y Trabajo de Fin de Grado.

SOBRE DIGI

Digi International es una empresa norteamericana centrada en la industria del hardware. Combina pro-ductos y servicios M2M (Máquina a Máquina) para gestionar de manera eficiente las empresas. Entre

1 La componente Web está formada por la aplicación web para el personal de administración de la empresa y el portal para los clientes. Mientras, la componente Android engloba la aplicación destinada a los trabajadores de la empresa y la aplicación para los clientes.

INTRODUCCIÓN Antecedentes

8

sus productos más importantes destacan: sistemas embebidos, conectividad inalámbrica, Zero-Clients, servidores de consola, video/sensores y conectividad serie y USB.

Digi además posee una nube pública para la gestión de redes de dispositivos, Etherios Device Cloud. Proporciona mensajería segura entre aplicaciones, almacenamiento de datos y gestión de dispositivos para redes cableadas y dispositivos celulares. Una red de dispositivos, también referidas en ocasiones como M2M, permite que sistemas cableados o inalámbricos se comuniquen con otros dispositivos o aplicaciones a través de diferentes tipos de red. Por ejemplo, un dispositivo (como un sensor) captura un evento (como un cambio de temperatura) y lo envía a través de una red a una aplicación, que lo traduce en información útil (como una alerta por cambio de temperatura).

Gracias a este proyecto Digi podrá demostrar, a través de una aplicación real, las características y la mul-titud de posibilidades que ofrece su nube de dispositivos, pudiendo llevar a cabo cantidad de proyectos que hagan uso de ella.

* * *

En el caso que nos ocupa, la red está compuesta por dispositivos Android, que se conectan a la nube a través del Cloud Connector for Android (conjunto de librerías, plug-ins y herramientas diseñadas para facilitar el desarrollo de aplicaciones Etherios en dispositivos Android).

Cada repartidor de la empresa de paquetería posee un dispositivo Android (bien un smartphone o bien un tablet), que tiene instalada la aplicación desarrollada y el Cloud Connector for Android. La aplicación sube archivos a la nube y llama a servicios web del servidor para gestionar todas las tareas requeridas.

En la Figura 1 se puede observar la arquitectura global del sistema completo.

Figura 1. Arquitectura del sistema.

INTRODUCCIÓN Objetivos

9

El funcionamiento del sistema es el siguiente: cuando un cliente acceda al portal web o a su aplicación Android y solicite un envío, se generará en el servidor una tarea, que se asignará de forma automática al repartidor adecuado (según su posición y la carga de tareas en ese instante). La aplicación de este recibi-rá dicha tarea, que contendrá la información necesaria para poder ser llevada a cabo. Todos los cam-bios, tanto en el estado de la tarea como en la posición donde se encuentre el repartidor, serán actuali-zados en el servidor en el momento en que se produzcan. La tarea finalizará cuando el paquete se en-tregue al destinatario y firme en el dispositivo la recogida. Esta firma se digitalizará y se incluirá en la factura que se le envíe al cliente.

La Device Cloud de Etherios permite el almacenamiento de datos en la nube (fichero con la localización de los trabajadores, firmas digitalizadas de los clientes…), la comunicación bidireccional entre ambas aplicaciones y el envío de notificaciones dese el servidor a la aplicación móvil.

Durante los periodos de Prácticas I y Prácticas II (de septiembre a diciembre de 2012), el proyectante comenzó a diseñar el sistema, aprendiendo primero los fundamentos básicos de Android, y empezando más tarde a desarrollar la aplicación destinada a los trabajadores de la empresa de paquetería.

Se definieron los tipos de tarea (envío y recogida) y se implementaron las actividades para mostrar ta-reas, para interactuar con ellas, para recibir mensajes de la empresa y para mostrar el perfil del trabaja-dor. Se creó también un servicio de localización en tiempo real, una actividad para trazar rutas entre la posición del trabajador y el destino, una actividad para recoger la firma del usuario a la hora de entregar el paquete y una actividad para asociar un código QR a una tarea.

La aplicación anteriormente mencionada está destinada a los trabajadores de la empresa, es decir, a los repartidores. Por otro lado, existe otra aplicación, esta para los clientes, a través de la cual pueden reali-zar un pedido, hacer el seguimiento del mismo o ver el historial de pedidos.

De este modo, las tareas para este trabajo han sido terminar y re-implementar la aplicación para los repartidores (puesto que desde la empresa se dio libertad a la hora de desarrollarla y no se siguieron estrictamente las fases de desarrollo de software) y realizar la aplicación para los clientes siguiendo la metodología Scrum.

1.2. Objetivos El objetivo general de este proyecto es desarrollar un sistema completo y fácil de usar que se encargue de la logística necesaria para el buen funcionamiento de una empresa de paquetería a pequeña escala.

Otros objetivos también importantes, relativos al sistema global, son:

Comunicación bidireccional entre las dos plataformas (Web y Android), ya sea directamente en-tre ellas o a través de la nube de dispositivos.

Demostración del funcionamiento del sistema completo al personal de la empresa Digi.

INTRODUCCIÓN Planificación

10

Comprobación del correcto funcionamiento del sistema mediante la realización de tests, lleva-dos a cabo por los dos alumnos y por el equipo de test de la empresa Digi.

Realización de un vídeo promocional, donde se expliquen las principales características del sis-tema.

Por otro lado, los objetivos específicos de la plataforma Android son:

Terminar y mejorar determinados aspectos de la aplicación para los trabajadores. Diseñar e implementar una aplicación con la que cualquier cliente pueda: realizar un pedido, ha-

cer el seguimiento del mismo y ver el histórico de pedidos. Las aplicaciones deben tener una interfaz de usuario intuitiva y fácil de usar, tanto para los tra-

bajadores como para los clientes. Las aplicaciones deben estar realizadas para dispositivos que tengan al menos la versión 2.3.3,

Gingebread, según los datos que se muestran en el primer informe de 20132. Las aplicaciones se deben ajustar a pantallas de entre 3,2 y 7 pulgadas, bien sean smartphones o

tablets.

1.3. Planificación Como se ha comentado anteriormente, el sistema se empezó a diseñar en septiembre de 2012, ya que el proyecto estaba pensado para ser realizado en ocho meses. Aunque la frontera entre qué correspon-de a Prácticas externas y qué al Trabajo de Fin de Grado es algo difusa, este último comenzó a desarro-llarse el 21 de enero de 2013, fecha en la que comenzó el segundo cuatrimestre.

En la siguiente lista se muestra la descomposición de tareas del proyecto:

1. Gestión del proyecto, 57 horas.

a. Reuniones con el tutor y la empresa (22 horas). Cada último martes de mes, a partir del mes de enero, tendrá lugar una reunión en la Universidad con el tutor Ángel Luis Rubio para ir mostrándole el avance del proyecto. También habrá una reunión con la empresa cada miércoles de las semanas pares, con el mismo objetivo.

b. Creación de los objetivos y redacción de la introducción (10 horas). Durante las dos pri-meras semanas se confeccionarán los objetivos que deberá cumplir la aplicación para los clientes. También se redactará el resumen y la introducción de la memoria.

c. Elaboración de la memoria (25 horas).

2 El primer informe de 2013 realizado por Google indica que el 88,2% de los dispositivos Android utilizan como mínimo la versión 2.3.3 (API Level 10). Es la versión más utilizada a esa fecha (47,4%), seguida por la 4.0.3 (29,1%).

INTRODUCCIÓN Seguimiento del proyecto

11

2. Aplicación para los repartidores, 46 horas.

a. Análisis (4 horas). Se analizará la situación de la aplicación realizada en el periodo de Prácticas y se establecerán una serie de directrices para la finalización de dicha aplica-ción.

b. Diseño (4 horas). Se establecerán unos criterios para realizar el cambio en las interfaces de la aplicación.

c. Implementación (35 horas). Se construirán los tres módulos restantes: incidencias, ser-vicios y horas límite y sincronización.

d. Pruebas (3 horas). Se realizarán pruebas unitarias de los módulos construidos y pruebas de integración.

3. Aplicación para los clientes, 192 horas.

a. Análisis (15 horas). Se identificarán los participantes del sistema, se establecerá el catá-logo de requisitos y se crearán los diagramas de casos de uso.

b. Diseño (30 horas). Se elaborarán los prototipos de la nueva aplicación, se establecerá cómo deben almacenarse los datos, se creará el diagrama de clases y se diseñará el plan de pruebas.

c. Implementación (144 horas). Se crearán las interfaces de usuario y se construirán las clases de las tres capas de la aplicación.

d. Pruebas (3 horas). Se realizarán pruebas unitarias de los módulos construidos y pruebas de integración.

4. Material promocional del sistema completo, 5 horas.

a. Elaboración del vídeo (5 horas). Se creará un vídeo promocional del sistema, donde se expongan todas las características del mismo.

Duración total ESTIMADA: 300 horas

1.4. Seguimiento del proyecto El seguimiento del proyecto se ha realizado a través del software JIRA. Es una aplicación basada en web para el seguimiento de errores, de incidencias y para la gestión operativa de proyectos. Además, permi-te utilizar metodologías ágiles como Scrum (la que fue elegida para llevar a cabo este proyecto).

La principal característica de Scrum es que es un proceso iterativo e incremental. Sin embargo, para este proyecto no se han seguido rigurosamente los principios y recomendaciones de Scrum, sino que esta metodología solo se ha tomado como base de la gestión.


12

Los roles para este proyecto se dividieron de la siguiente manera:

ScrumMaster (director del proyecto): Diego Escalona (desarrollador en Digi). ProductOwner (dueño del producto): Pedro Pérez (responsable de Digi International Spain). Team (equipo de trabajo): César Estebas y Rubén Moral.

La implementación del proyecto comenzó el 25 de febrero. Durante los dos primeros días se estableció la pila del producto y las características de los sprints. Se decidió que estos tuviesen una duración de 2 semanas, iniciándose los miércoles (coincidiendo con la reunión bisemanal en la empresa).

A continuación se muestra una breve descripción del desarrollo del proyecto por cada sprint:

Primer sprint (27/02/13 – 13/03/13), 19 horas:

- Adaptación del código a la versión 4.x de Android. - Cambio en el diseño de las interfaces. - Arreglo de bugs encontrados. - Implementación del sistema de notificación de incidencias. - Implementación de los tipos de servicios. - Implementación de las horas límite. - Modificación de la lista de tareas para mostrar primero las prioritarias.

Segundo sprint (13/03/13 – 27/03/13), 22 horas:

- Diseño del layout para la sincronización. - Implementación de la sincronización offline. - Internacionalización. - Test de funcionalidad. - Prueba de la aplicación en varios dispositivos.

Tercer sprint (27/03/13 – 10/04/13), 40 horas:

- Diseño del layout para la pantalla de inicio. - Diseño del layout para la pantalla de login. - Diseño del layout para la pantalla de “Seguimiento de un pedido”. - Diseño del layout para la pantalla de “Mis pedidos”. - Diseño del layout para la pantalla de “Nuevo pedido”.

Cuarto sprint (10/04/13 – 24/04/13), 82 horas:

- Implementación de la pantalla de inicio. - Implementación de la pantalla de login. - Implementación de la pantalla de “Seguimiento de un pedido”. - Implementación de la pantalla de “Mis pedidos”. - Implementación de la pantalla de “Nuevo pedido”.


13

- Internacionalización. - Test de funcionalidad. - Pruebas en varios dispositivos.

Quinto sprint (24/04/13 – 8/05/13), 18 horas:

- Vídeo corporativo. - Prueba global del sistema.

Figura 2. Comparación entre tareas creadas y tareas resueltas.

Las estimaciones iniciales no fueron del todo exactas, puesto que el tiempo total de dedicación al pro-yecto ha sido un 2% superior al estimado. A continuación se puede observar las desviaciones en cada apartado del proyecto:

Tarea Horas estimadas Horas reales Desviación

Gestión del proyecto +5 en Creación de los objetivos 57 62 +5 h.

Aplicación para los repartidores +3 en Implementación 46 49 +3 h.

Aplicación para los clientes +8 en Análisis +6 en Diseño -25 en Implementación

192 181 -11 h.

Material promocional 5 15 +10 h.

TOTAL 300 307 +7 h.

14

Capítulo 2. Desarrollo

2.1. Análisis Esta especificación tiene como objetivo analizar y documentar las necesidades funcionales que deberán ser soportadas por el sistema a desarrollar. Para ello, se identificarán los requisitos que ha de satisfacer el nuevo sistema mediante el estudio de los problemas de las unidades afectadas y sus necesidades ac-tuales. Además de identificar los requisitos se deberán establecer las prioridades, lo cual proporciona un punto de referencia para validar el sistema final que compruebe que se ajusta a las necesidades del usuario.

2.1.1. Identificación de los usuarios participantes

Los objetivos de esta tarea son identificar a los responsables de cada una de las unidades y a los princi-pales usuarios implicados. En la organización se identificaron los siguientes usuarios:

Clientes finales: Son aquellos a los que va dirigido el servicio de reparto. Pueden realizar un pe-dido a través del portal web o de la aplicación móvil que se desarrollará en este trabajo.

Repartidores: Son los encargados de realizar las tareas de recogida y entrega de paquetes. A ellos va destinada la aplicación desarrollada en el periodo de Prácticas.

Personal de administración: Son los que trabajan en la sede de la empresa y controlan las asig-naciones de tareas y la posición de los repartidores.

2.1.2. Catálogo de requisitos del sistema

i. Definiciones, acrónimos y abreviaturas

Tarea: Unidad básica de trabajo. Es creada a petición de un usuario, y contiene la siguiente información: identificador, tipo, estado, datos del emisor, datos del receptor y detalles. En el ámbito de los clientes, tarea es sinónimo de pedido.

Estado: Situación en que se encuentra una tarea en un momento determinado. Existen un total de 7 estados, que son los siguientes:

New (nueva): La tarea ha sido creada pero aún no se ha iniciado. Pickup in progress (recogida en progreso): La tarea está siendo realizada; el repartidor va en

camino hacia el cliente para recoger el paquete. Delivery in progress (entrega en progreso): La tarea está siendo realizada; el repartidor va en

camino hacia el cliente para entregar el paquete.

DESARROLLO Análisis

15

Paused (pausada): La tarea había sido iniciada pero se ha parado. La causa de este hecho es bien porque el repartidor ha iniciado otra tarea o porque el paquete no debe entregarse en el día de recogida y se ha guardado en el almacén.

Finished (finalizada): El paquete ha sido entregado y la tarea se ha completado con éxito. Incidence (incidencia): La tarea no ha podido finalizarse correctamente debido a una incidencia. Canceled (cancelada): La tarea ha sido cancelada.

Figura 3. Diagrama de estados de las tareas.

Tipo: Clase de una tarea, que engloba a una serie de estados. Toda tarea, a lo largo de su vida, necesa-riamente tiene que tener los siguientes tipos:

Pickup (recogida): Acción en la que el repartidor recoge un paquete de un cliente. Delivery (entrega): Acción en la que el repartidor entrega un paquete a un cliente.

Tipo de servicio: Está asociado a la urgencia que tiene una tarea. Es elegido por el cliente a la hora de crear el pedido. Existen 4 tipos, ordenados de mayor a menor urgencia/coste:

2 horas: El paquete se entregará antes de 2 horas a contar desde el instante de la creación del pedido.

6 horas: El paquete se entregará antes de 6 horas a contar desde el instante de la creación del pedido.

Madrugador: El paquete se entregará antes de las 20 horas del día en el que se haya creado. Siguiente día: El paquete se entregará antes de las 14 horas del día siguiente al de creación.

Hora límite: Fecha y hora máxima que tiene un repartidor para finalizar la tarea y entregar el paquete. Se calcula en base al tipo de servicio contratado por el cliente.


16

Número de seguimiento: Código único asociado a una tarea que permite al cliente visualizar el estado del pedido.

ii. Descripción general

Esta sección nos presenta una descripción general del sistema con el fin de conocer las funciones que debe soportar, los datos asociados, las restricciones impuestas y cualquier otro factor que pueda influir en la construcción del mismo.

Las funciones que debe realizar el sistema se pueden agrupar de la siguiente manera:

Seguimiento de un pedido: La aplicación permitirá que el usuario pueda ver dónde y en qué estado se encuentra su pedido, a través del número de seguimiento generado a la hora de crearlo.

Historial de pedidos: La aplicación permitirá que el usuario pueda ver una lista con todos los pedidos creados hasta ese momento. Permitirá acceder a cada uno de ellos y ver todos sus detalles.

Realización de pedidos: La aplicación permitirá que el usuario cree un nuevo pedido. Este deberá introducir sus datos si todavía no está registrado, así como los del emisor y el recep-tor del paquete. También deberá seleccionar el tipo de servicio y el método de pago.

iii. Requisitos funcionales

En esta sección se listan los requisitos funcionales de las aplicaciones. Los siguientes corresponden con los requisitos restantes de la aplicación para repartidores:

A. Incidencias.

Debe ser posible que el repartidor pueda notificar una incidencia o una cancelación si ocurre algún pro-blema en el transcurso del proceso. Es posible que cuando vaya a entregar un paquete no haya nadie en el hogar de destino, o la dirección sea incorrecta. Por ello, se le facilitará una lista con una serie de inci-dencias predefinidas, aunque también se permitirá que él mismo redacte una.

B. Servicios y horas límite.

La lista de tareas del repartidor estará ordenada según el tipo de servicio y la hora límite. Hasta ahora, las tareas estaban ordenadas según su fecha de creación. Cuando la aplicación recibía una tarea nueva, la insertaba al final de la lista. Sin embargo, algunas tareas son más urgentes que otras (para ello el cliente paga más si quiere que su paquete llegue al destino a las dos horas en vez de al día siguiente). Por lo tanto, todas las tareas deberán contener el tipo de servicio y la hora límite de entrega, de modo que cuando vayan llegando nuevas tareas a la aplicación se ordenen según esos parámetros.


17

C. Sincronización offline.

Será posible que el trabajador pueda seguir usando la aplicación en zonas donde no haya 3G o WiFi. Cada vez que se produce un cambio en alguna tarea (inicio de la tarea, cambio de estado, firma del cliente), la aplicación comunica dicho cambio al servidor, por lo que es necesario que tenga conexión a Internet. De este modo, se permitirá que el repartidor llegue a lugares donde no haya cobertura (puesto que generalmente estará conectado a la red a través de 3G). La aplicación guardará todos los cambios en la memoria del dispositivo y los actualizará en el servidor web cuando se vuelva a conectar a Internet.

A continuación se enumeran los requisitos de la aplicación para clientes a realizar en este trabajo, orde-nados de mayor a menor importancia:

A. Seguimiento de un pedido.

Será posible que el usuario pueda localizar un pedido en curso, bien introduciendo el número de segui-miento o escaneando un código QR. La aplicación mostrará todos los detalles del pedido asociado a ese código, así como una tabla donde se muestren los estados por los que ha ido pasando. Si el usuario está autenticado, no hará falta que introduzca el número de seguimiento, puesto que se mostrará una lista con todos los pedidos en curso que disponga en ese instante.

B. Autenticación.

Debe existir la posibilidad de que el usuario se autentique antes de realizar cualquier operación. Esta función sirve para evitar que usuarios registrados tengan que introducir sus datos constantemente cada vez que realicen una operación. El sistema mostrará el formulario de acceso y realizará la autenticación. Una vez hecha, mantendrá la sesión abierta hasta que el usuario la cierre manualmente.

C. Creación de un nuevo pedido.

Debe ser posible que cualquier usuario pueda crear un nuevo pedido. El sistema mostrará un formulario para que este introduzca los datos de origen, de destino y el tipo de servicio. Una vez que acepte el pe-dido, si no se ha autenticado antes, el sistema abrirá el formulario de acceso. Tras iniciar sesión, se mos-trará un resumen con los datos del pedido para que el cliente lo confirme.

D. Historial de pedidos.

El usuario podrá ver un listado con sus pedidos realizados. Una vez que se haya autenticado, el usuario podrá ver una tabla con todos los pedidos que haya realizado hasta ese momento, incluyendo tanto los finalizados como los que estén en progreso. Clicando sobre cada uno de ellos podrá acceder a la infor-mación concreta de ese pedido.


18

iv. Requisitos de usuario y tecnológicos

Requisitos de usuario:

Existen dos tipos de usuario que van a hacer uso de estas aplicaciones: empleados de la empresa y clien-tes. Ambas interfaces deben ser intuitivas, fáciles de usar y amigables. El funcionamiento de la aplica-ción para los repartidores es más complejo, por lo que requerirá un manual de usuario detallado; sin embargo, la aplicación de los clientes está destinada a un mayor número de usuarios, con distintas habi-lidades y conocimientos, por lo que debe ser más intuitiva y debe cumplir los estándares de accesibili-dad y usabilidad.

Requisitos tecnológicos:

Las aplicaciones están destinadas a smartphones o tablets Android, con una pantalla de entre 3,2’’ y 7’’, que tengan la versión 2.3.3 o superior.

Los dispositivos deberán tener cámara de fotos y conexión a Internet a través de 3G. Sería re-comendable que también tuvieran GPS integrado.

El sistema deberá adaptarse a la gran variedad de dispositivos móviles existentes. Más concre-tamente deberá tener en cuenta el área de presentación y adaptar las visualizaciones para apro-vechar al máximo el tamaño disponible.

El ancho de banda desde dispositivos móviles suele ser bastante reducido, por lo que hay que controlar no saturar con contenidos demasiado pesados que influyan en el tiempo de respuesta de la aplicación.

Las aplicaciones se ejecutarán sobre un esquema cliente/servidor, con los procesos e interfaz de usuario ejecutándose en los clientes y estos solicitando requerimientos al servidor que cumple su proceso.

v. Requisitos de interfaces externas

Interfaces de usuario: La interfaz de usuario de la aplicación de clientes debe ser similar a la del portal web (en cuanto a diseño y colores).

Interfaces hardware: Smartphone o tablet Android.

vi. Requisitos de rendimiento

El tiempo de respuesta de la aplicación a cada función solicitada por el usuario no debe ser superior a 5 segundos, exceptuando la función de “crear un nuevo pedido”, donde se podrá demorar como máximo hasta 10 segundos.


19

vii. Requisitos de desarrollo y restricciones de diseño.

El marco de trabajo de desarrollo de software elegido para este proyecto es Scrum, cuya característica principal es que es un proceso iterativo e incremental. Para controlar los sprints y realizar la gestión operativa del proyecto se utilizará JIRA.

En cuanto a las restricciones de diseño, los códigos QR deberán seguir el estándar ISO/IEC 18004:2006, y contendrán una cadena de texto referente al número de seguimiento.

2.1.3. Casos de uso

En esta sección se especificarán los casos de uso más relevantes en el sistema. El resto están incluidos en el Anexo 1 (Casos de uso).

A continuación se muestra el diagrama de casos de uso de la aplicación para los repartidores, junto con la especificación de los dos casos de uso que restan por implementar en el sistema.

Figura 4. Diagrama de casos de uso para la aplicación de repartidores.


20

Caso de uso Sincronizar Descripción Actualizar en el servidor todos los cambios que se hayan

producido en el dispositivo cuando no estaba conectado a Internet.

Actores Repartidor.

Precondiciones El dispositivo debe estar conectado a Internet.

Postcondiciones Todos los cambios almacenados offline en el dispositivo son sincronizados en el servidor correctamente.

Flujo básico

1. El repartidor pulsa el botón de sincronizar. 2. El sistema se conecta con el servidor y actualiza los cambios. 3. El sistema sube las firmas digitalizadas a la nube.

Flujos alternativos y excepciones

No hay.

Anotaciones No hay.

Caso de uso Notificar incidencia Descripción Reportar una incidencia al servidor para que el personal de

administración pueda gestionarla.

Actores Repartidor.

Precondiciones El repartidor debe estar en [Ver detalles de tarea].

Postcondiciones La incidencia es notificada correctamente.

Flujo básico

1. El repartidor pulsa el botón de incidencia. 2. El sistema muestra un diálogo con una lista de las incidencias más

habituales y un campo de texto. 3. El repartidor selecciona una incidencia de las de la lista o escribe una

personalizada en el campo de texto, y pulsa “Enviar”.


No hay.

Anotaciones No hay.


21

Por otra parte, el siguiente diagrama muestra los casos de uso de la aplicación para los clientes. Se inclu-yen también la especificación de los casos de uso más relevantes junto con los diagramas de actividad.

Figura 5. Diagrama de casos de uso para la aplicación de clientes.


22

Caso de uso Localizar pedido Descripción Localizar un pedido en curso introduciendo su número de

seguimiento o escaneando su código QR.

Actores Cliente.

Precondiciones No hay.

Postcondiciones Se muestra un resumen del pedido a localizar.

Flujo básico

1. El cliente elige la opción “Localizar pedido” en la pantalla inicial. 2. El sistema muestra: un cuadro de texto para introducir el número de

seguimiento, un icono con una cámara y un botón de Buscar. 3. El cliente introduce el número de seguimiento y pulsa Buscar. 4. El sistema muestra un resumen del pedido que corresponde con el

número de seguimiento introducido.


Si el cliente está autenticado en el sistema, tras el punto 1 se mostrará direc-tamente un resumen con los pedidos en curso de dicho usuario. En el punto 3, el cliente puede llevar a cabo [Escanear código QR] en vez de introducir el número de seguimiento. Tras el punto 4, el cliente puede pulsar sobre el pedido e ir a [Ver detalle pedi-do]. Si el número de seguimiento o el código QR no se corresponde con ningún pe-dido se avisa al cliente del error.

Anotaciones Para escanear un código QR en vez de introducir el número de seguimiento, el cliente deberá pulsar sobre el icono de la cámara.


23

Figura 6. Diagrama de actividad del caso de uso [Localizar pedido].


24

Caso de uso Crear nuevo pedido Descripción Crear un pedido nuevo para que sea llevado a cabo por la

empresa de paquetería en el tiempo establecido.

Actores Cliente.


Postcondiciones El pedido se crea correctamente.

Flujo básico

1. El cliente elige la opción “Nuevo pedido” en la pantalla inicial. 2. El sistema muestra un formulario con los datos requeridos. 3. El cliente rellena el formulario, con al menos los siguientes campos:

datos de quien envía el paquete, datos de quien lo recibe, tipo de servicio y método de pago. Luego pulsa en “Continuar”.

4. El sistema comprueba si el cliente está autenticado en el sistema. 5. El usuario confirma el pedido.


En el punto 4, si el cliente no ha iniciado sesión se lleva a cabo [Iniciar sesión]. Hasta que el cliente no confirme el pedido en el punto 5, puede cancelarlo en cualquier momento.

Anotaciones No hay.


25

Figura 7. Diagrama de actividad del caso de uso [Crear nuevo pedido].


26

Caso de uso Iniciar sesión Descripción Autenticarse en el sistema con nombre de usuario y contra-

seña.

Actores Cliente.


Postcondiciones La sesión del cliente queda abierta en el sistema hasta que este la cierre.

Flujo básico

1. El cliente elige la opción “Iniciar sesión” en la pantalla inicial. 2. El sistema muestra un formulario con dos campos: nombre de usuario

y contraseña. 3. El cliente introduce sus datos y pulsa sobre el botón de Iniciar sesión.


No siempre se accede a este caso a través del punto 1, sino que se puede llegar desde [Ver historial de pedidos] o [Crear nuevo pedido]. Si el nombre de usuario o la contraseña no son correctos se avisará al usuario a través de un mensaje de error.

Anotaciones No hay.


27

Figura 8. Diagrama de actividad del caso de uso [Iniciar sesión].

DESARROLLO Diseño

28

2.2. Diseño En el siguiente apartado se enumeran las decisiones tomadas a lo largo de este proyecto con respecto al diseño de las interfaces de usuario, a la arquitectura del sistema y al almacenamiento de los datos.

2.2.1. Diseño de la interfaz de usuario

1. Aplicación para los trabajadores.

Como se ha mencionado anteriormente, al comienzo de este proyecto la aplicación destinada a los re-partidores de la empresa de paquetería estaba casi finalizada. Sin embargo, el diseño de la misma no era el adecuado, puesto que las exigencias de la empresa en el periodo de prácticas se habían dirigido más hacia el funcionamiento y no tanto al diseño.

Figura 9. Interfaces al comienzo del proyecto.

Las decisiones tomadas respecto a la interfaz de esta aplicación fueron las siguientes:

Cambiar el contraste general, pasando del fondo negro al blanco o gris claro. Cambiar la barra de título predeterminada de Android por una personalizada, donde apareciera

el nombre de la aplicación y el logotipo. Cambiar los iconos del menú por otros más significativos. Adaptar correctamente la aplicación a pantallas de alta resolución, especialmente en tablets,

puesto que hasta el momento no se había gestionado la resolución de las pantallas.

DESARROLLO Diseño

29

Establecer una paleta de colores para la aplicación. Inicialmente se planteó una paleta de naran-jas, pero en una de las últimas revisiones en la empresa se decidió cambiarla junto con los colo-res de la página web a una paleta de verdes, como se puede apreciar en la Figura 10 y en la Figu-ra 11.

Figura 10. Evolución de la pantalla de inicio.

Figura 11. Evolución de la pantalla de detalles de la tarea.

DESARROLLO Diseño

30

2. Aplicación para los clientes.

En este caso, al partir de cero, había que diseñar unos prototipos que se aproximasen a cómo iba a ser la aplicación una vez finalizada, con el objetivo de realizar los cambios oportunos en la fase de diseño y no en la de implementación.

A continuación se muestran los primeros prototipos realizados. Por similitud no se muestran todos, el resto aparecen en el Anexo 2 (Mockups).

Figura 12. Pantalla inicial.

Esta es la pantalla que aparece al iniciarse la aplicación. A través de los botones se puede acceder a las tres funciones principales: seguimiento, histórico y nuevo pedido. Mediante el menú, el usuario puede loguearse y ver la información de la empresa de paquetería.

DESARROLLO Diseño

31

Figura 13. Pantalla del primer paso de nuevo pedido.

Cuando el usuario comience un nuevo pedido verá esta pantalla. El proceso de realización de un nuevo pedido se ha dividido en tres pasos:

Datos personales: el usuario deberá introducir los datos del remitente y del receptor del pa-quete.

Pago: el usuario elegirá el tipo de servicio y el método de pago. Revisión y finalización: el sistema mostrará un resumen con todos los datos que ha introducido

el usuario, para que este los revise y decida si finalizar el pedido o cancelarlo.

En el siguiente punto se mostrará el diagrama de navegación de la aplicación para los clientes.

DESARROLLO Diseño

32

2.2.2. Diagrama de navegación

Menu -> About us Menu -> Login

New orderOrder tracking Order tracking (logged) Order history

Order details

Full details

Next step

Next step

DESARROLLO Diseño

33

2.2.3. Arquitectura del sistema

Las aplicaciones desarrolladas poseen una arquitectura de tres capas y dos niveles (cliente/servidor), ya que algunos procesos de negocio y gran parte de los datos provienen del servidor web y de la base de datos almacenada allí.

Figura 14. Arquitectura en capas y niveles.

La capa de presentación es la encargada de interactuar con los usuarios de la aplicación. Está conforma-da por múltiples archivos XML, uno por cada vista de la aplicación.

La capa de lógica de negocio se encarga de realizar los procesos de la aplicación. Hace de nexo entre la capa de presentación y la de persistencia.

La función de la capa de persistencia es acceder a los datos almacenados para consultarlos o modificar-los. El almacenamiento de datos está especificado en la sección 2.2.4.

2.2.4. Almacenamiento de datos

Al ser este un sistema distribuido, los datos se almacenan en tres ubicaciones distintas:

1. Base de datos del servidor. Aquí se almacena la mayor parte de la información del sistema, in-cluyendo tareas, trabajadores y clientes. Cada vez que cualquiera de las aplicaciones Android necesita obtener o actualizar un determinado dato, utiliza el servicio web adecuado creado por el otro miembro del proyecto. De esta manera, la información más importante del sistema está

DESARROLLO Diseño

34

almacenada en un único lugar (base de datos) al que todas las aplicaciones Android pueden ac-ceder vía API.

2. Device Cloud de Etherios. La nube es el medio que hace posible recibir mensajes o notificacio-nes desde la página web. Únicamente se almacenan los ficheros con la posición de los trabaja-dores en tiempo real, las firmas digitalizadas de los clientes y las fotografías de perfil de los tra-bajadores.

3. Dispositivo Android.

En el caso de la aplicación para los repartidores, debido a que los datos que se iban a almacenar en la memoria del dispositivo eran mínimos y se utilizarían en contadas ocasiones, el proyectan-te decidió guardar la información en ficheros XML en vez de utilizar una base de datos.

El primer fichero está destinado a guardar los cambios en las tareas, y únicamente se utiliza cuando el dispositivo pierde la conexión a Internet. En ese instante, entra en funcionamiento el modo offline, que permite al trabajador seguir usando la aplicación prácticamente igual que cuando está conectada a la red. Todos los cambios producidos durante el tiempo que el disposi-tivo no tenga conexión se guardarán en el fichero XML, localizado en el almacenamiento privado de la aplicación, y se subirán al servidor una vez vuelva la conexión.

<status_changes> <task id="…" status="…" date="…" details="…" /> </status_changes> En el anterior código XML podemos observar la estructura del fichero. Por cada cambio que se produzca en una tarea se añadirá un nodo task, cuyos atributos son el identificador de la tarea, el estado al que ha cambiado, la fecha y hora del cambio y los detalles.

El segundo fichero es el encargado de almacenar los mensajes que se reciben desde la aplicación web. El código sería similar al anterior; por cada mensaje se guarda un nodo message, cuyos hijos son el contenido del mensaje, la fecha y hora de recepción y el identificador del remitente.

<messages> <message> <sender>…</sender> <content>…</content> <time>…</time> </message> </messages>

Por último, se guarda un fichero de preferencias globales, que es gestionado por el S.O. Android. En él se almacena los datos personales del repartidor, la última posición y el hash de los datos de acceso a la aplicación.

DESARROLLO Diseño

35

En el otro caso, el de la aplicación para los clientes, únicamente se almacena el fichero de prefe-rencias con el nombre del cliente y el hash de los datos de acceso.

2.2.5. Patrones de diseño

Pese a que en la documentación oficial no se hace referencia a ningún patrón, en realidad muchos auto-res consideran que el sistema operativo implementa el patrón Modelo-Vista-Controlador (MVC). Esto es debido a lo siguiente:

Se definen una serie de interfaces en ficheros XML. Se definen una serie de recursos (locales, estructuras de datos) en ficheros XML. Se extienden diversas clases, como listas o tabs, y se instancian dentro de sus correspondientes

vistas. Se crean tantas clases como sean necesarias para el modelo. Existen muchas clases que facilitan el acceso a bases de datos, HTML, etc.

Es por ello que al programar en Android, implícitamente, se usa el patrón MVC.

Además, el proyectante ha utilizado el patrón Singleton en ambas aplicaciones, que garantiza que una clase solo tenga una instancia, proporcionando un punto de acceso global a ella.

Android no permite modificar la interfaz gráfica desde hilos que no sean el principal. Acciones tan bási-cas como mostrar un toast (mensaje en forma de popup) únicamente se pueden lanzar desde el hilo principal, algo que puede ser un problema. Además, es necesario en muchas ocasiones acceder a las clases que gestionan la persistencia (tareas y mensajes). Por ello se decidió implementar el patrón Sin-gleton en la clase principal de las aplicaciones, de manera que desde cualquier clase se pueda acceder a todos los métodos básicos sin necesidad de crear objetos de esas clases.

public class PackagingApplication extends Application {

private static PackagingApplication instance;

public void onCreate() { super.onCreate(); instance = this; …

} public static PackagingApplication getInstance() { return instance; } … }

DESARROLLO Diseño

36

2.2.6. Diseño de clases

Como se ha comentado anteriormente, ambas aplicaciones poseen una arquitectura de tres capas. To-das ellas usan el modelo de objetos que se explicará más adelante. Los siguientes diagramas y clases pertenecen a la aplicación para los clientes.

Figura 15. Diagrama de paquetes.

En el siguiente diagrama se muestran las clases correspondientes al modelo de objetos. Por simplicidad, los accesores y modificadores de los atributos (getters y setters) se han obviado.

Figura 16. Diagrama de clases del modelo de objetos.

DESARROLLO Diseño

37

Como se puede observar, la clase Order es la más relevante. Servirá para almacenar los datos de cada pedido que tenga un usuario. Las características más importantes de un pedido son las siguientes:

Tendrá un identificador único (idTask). Estará relacionado con dos clientes: el emisor y el receptor del paquete. Almacenará una lista con todos los cambios de estado que se hayan producido. A lo largo de su ciclo de vida pasará por varios estados, pero en un instante determinado solo

tendrá uno. Tendrá asignado un único tipo de servicio.

La capa de Lógica de negocio es la encargada de gestionar todas las operaciones internas de la aplica-ción. Generalmente, cada pantalla de una aplicación Android corresponde con una clase que extiende de Activity (o de subclases de ella, como ListActivity o TabActivity).

Figura 17. Diagrama de clases de la capa de lógica de negocio.

Por último, en la capa de Persistencia existirán dos clases: una gestionará los pedidos y la otra las prefe-rencias de la aplicación.

Figura 18. Diagrama de clases de la capa de persistencia.

DESARROLLO Diseño

38

2.2.7. Diseño del plan de pruebas

En esta sección se van a especificar las pruebas que posteriormente se ejecutarán en la última fase del desarrollo. Esta definición va a servir como guía de testeo y como medio de verificación de que todas las partes del sistema cumplen los requisitos iniciales con unos niveles de calidad aceptables.

Se llevarán a cabo tres tipos de pruebas:

Pruebas unitarias: aquellas que sirven para asegurar que cada módulo funciona de la manera correcta.

Pruebas de integración: aquellas en las que se verifica la validez de varios módulos en conjunto. Pruebas de aceptación: aquellas que determinan si se cumplen o no los requisitos iniciales.

Cada prueba que se realice deberá ser documentada mediante la siguiente plantilla:

Prueba nº Tarea:

Descripción

Procedimiento

Resultado

DESARROLLO Implementación

39

2.3. Implementación Esta fase tiene como objetivo poner en práctica todas las características y reglas que se han ido estable-ciendo en las dos fases anteriores. En este capítulo se describen brevemente las principales tecnologías usadas en el proyecto, las librerías externas que se han empleado, los problemas que han surgido y cuál ha sido la manera de resolverlos.

2.3.1. Tecnologías usadas

Como ya se ha señalado en varias ocasiones a lo largo de esta memoria, el proyecto está destinado a la obtención de dos aplicaciones para el sistema operativo Android.

Android no utiliza Java SE, sino que usa una implementación libre de Java llamada Apache Harmony, que alcanza el 97% de Java SE 6. La máquina virtual de Android se llama Dalvik, cuyo núcleo está basado en Apache Harmony. Dalvik ejecuta ficheros .dex, que son versiones optimizadas de los ficheros .class. Desde el punto de vista del desarrollador, Java de Android es similar a Java SE, pero sin las librerías AWT/Swing y añadiendo APIs de Android personalizadas.

Figura 19. Diferencia entre Java VM y Dalvik VM.

En la actualidad, existen al menos dos formas para desarrollar aplicaciones en Android: con la ayuda de un framework (como Titanium, Adobe AIR o PhoneGap) o desde el lenguaje nativo Java. Pese a que los frameworks anteriormente citados poseen ciertas ventajas con respecto al desarrollo nativo, como la mayor simplicidad o la exportación a varios sistemas operativos, la realidad es bastante diferente.

A diferencia del desarrollo en iOS, donde hay dos únicos modelos de dispositivos, en Android existe una gran variedad de terminales, pantallas y resoluciones, por lo que se hace más complicado desarrollar


40

aplicaciones que funcionen y se visualicen correctamente en todos los dispositivos con el mismo código. Desarrollando en Android nativo con Java podremos:

1. Crear aplicaciones para todos los dispositivos Android, ya que comparten la misma API base. 2. No poner límites a nuestras aplicaciones (puesto que el uso de los frameworks anteriores aca-

rrea unas ciertas limitaciones a la hora de acceder a ciertas funciones del terminal).

Por todo lo anterior, el proyectante decidió desarrollar las aplicaciones en Android nativo con Java, usando el Software Development Kit (SDK) de Android, Eclipse como IDE y el plugin Android Develop-ment Tools (ADT).

Para el desarrollo de las interfaces y elementos gráficos se ha usado XML, puesto que es la manera ade-cuada para hacerlo, recomendada por Google.

2.3.2. Librerías empleadas

Con el objetivo de facilitar el desarrollo de ciertas partes del proyecto, se han usado varias librerías ex-ternas. Algunas de ellas (las relacionadas con la gestión de la nube) han sido proporcionadas por la em-presa Digi International Spain.

1. Cloud Connector Android. Es una librería diseñada por los desarrolladores de Digi para comuni-car las aplicaciones Android con la Device Cloud. Permite, entre otros, detectar los cambios de estado del Cloud Connector, recibir notificaciones o enviar ficheros a la nube.

2. Etherios Client Library. Es una librería diseñada por los desarrolladores de Digi que permite co-municar las aplicaciones Java con la Device Cloud. Su función principal es la de gestionar la co-nexión con la nube.

3. Dom4j. Es una librería Java open source que sirve para trabajar con XML, XPath y XSLT. Es com-patible con los estándares DOM, SAX y JAXP. Es usada en la transmisión de datos entre el servi-dor web y los dispositivos Android, ya que se envían en XML.

4. Joda Time. Es una librería que sirve de reemplazo de las clases Java date y time. Permite tra-bajar con fechas de una forma más sencilla, potente y eficiente. La inclusión de intervalos y du-raciones a la librería ha sido muy útil a la hora de calcular las horas límite de entrega de los pa-quetes por parte de los repartidores.

2.3.3. Estructura del proyecto

A la hora de comenzar el proyecto, el propio Eclipse se encarga de crear el árbol de directorios, con las carpetas y ficheros necesarios para su funcionamiento. Todo proyecto en Android se divide generalmen-te en 6 carpetas: src, gen, assets, bin, libs y res, siendo las más relevantes la primera y la última:


41

/src. Aquí se almacenan las actividades y el resto de clases creadas, con sus paquetes corres-pondientes.

Figura 20. Contenido de la carpeta /src.

/res. Es la carpeta de recursos del proyecto. Está subdividida en,

como mínimo, 4 directorios: - drawable: contiene ficheros bitmap, formas, animacio-

nes, imágenes, botones y otros elementos de dibujo.

- layout: en ella se encuentran los ficheros XML que co-rresponden con las interfaces de la aplicación.

- menu: contiene los ficheros XML que definen los menús de las actividades.

- values: en ella se encuentran los ficheros XML que con-tienen valores simples, como colores, cadenas de texto o estilos.

Esta última carpeta puede contener además variaciones de los 4 subdirectorios mencionados, como se puede observar en la figura de la derecha. En este caso, las imágenes que se encuen-tren en drawable-nodpi no se escalarán dependiendo de la resolución de la pantalla; las interfa-ces de layout-land se mostrarán cuando el dispositivo móvil esté colocado en orientación hori-zontal (landscape); los valores que aparezcan en values-es serán visualizados cuando el idioma del terminal se español…3

Otro elemento fundamental dentro de un proyecto es el AndroidManifest. Este fichero XML se genera automáticamente y en él se declaran todas las especificaciones de la aplicación, como actividades, servi-cios, nombre de la aplicación, versión, hardware necesario o permisos que usa del sistema operativo. En el Anexo 3 (AndroidManifest.xml) se pueden ver los ficheros de ambas aplicaciones.

3 La especificación completa se puede leer en http://developer.android.com/tools/projects/index.html

Figura 21. Contenido de /res.


42

2.3.4. Desarrollo de las aplicaciones

Como se comentó al inicio de esta memoria, el proyectante escogió Scrum como metodología de desa-rrollo. Esto implica ir haciendo el trabajo en pequeños incrementos (o sprints), en este caso de dos se-manas, de manera que al finalizar cada sprint se obtenga una parte funcional de la aplicación.

Por ello, en este apartado se profundizará en lo expuesto en el punto 1.4, es decir, se irá describiendo el desarrollo realizado por cada sprint, los problemas que aparecieron y cómo el proyectante los resolvió (las fases 1 y 2 corresponden con la finalización de la aplicación para los repartidores; las siguientes con la nueva aplicación para los clientes).

Fase 1. Adaptación del código, incidencias y servicios y horas límite

Al inicio del trabajo, el proyectante se encontró con una aplicación sin finalizar, cuyas interfaces eran austeras y rudimentarias (Figura 9), y cuyo código solo era compatible con las versiones de Android 2.3.*. Todo esto desembocaba de la primera etapa del proyecto, el semestre de prácticas, debido a que fue una fase de aprendizaje y adaptación a Android, con el desarrollo de pequeñas porciones funciona-les de código que luego se ensamblarían para formar la aplicación.

El primer paso fue analizar el problema más importante, es decir, por qué la aplicación no funcionaba correctamente en las nuevas versiones de Android.

Figura 22. Excepción que aparecía al arrancar la aplicación.

Tras varias búsquedas en foros, se llegó a la siguiente conclusión: a partir de la versión 3.0 de Android no se puede realizar una operación de red en el hilo principal de la aplicación. Hasta ese momento, todas las llamadas a los servicios web del servidor (autenticación, petición o actualización de tareas…) se ha-cían en dicho hilo, por lo que hubo que buscar una alternativa para el correcto funcionamiento de la aplicación: crear tareas asíncronas. Se creó una clase llamada WebConnection, que extiende de AsyncTask (clase utilizada para ejecutar tareas simples o atómicas en un hilo aparte), de manera que cada vez que se desea realizar una conexión web se crea un objeto de esa clase, pasando la URL de co-nexión y los parámetros.

Se advierte al lector de que todas las porciones de código que se presenten a partir de ahora pueden no corresponderse totalmente con el código de la aplicación, puesto que son pequeñas reducciones para ilustrar mejor los ejemplos.


43

Por ejemplo, para pedir al servidor la información relativa a la tarea cuyo identificador es 1111, crearía-mos un objeto de la clase WebConnection, llamaríamos a su método execute (pasándole los pará-metros adecuados), y por último recogeríamos el resultado mediante el método get.

WebConnection connection = new WebConnection(); connection.execute("https://bybike-delivery.appspot.com/getTask", "idTask=1111"); result = connection.get();

public class WebConnection extends AsyncTask<String, Void, String> { protected String doInBackground(String... params) { String data = ""; URL url = null; HttpURLConnection connection = null; DataOutputStream dos = null; DataInputStream dis = null; try { url = new URL(params[0]); connection = (HttpURLConnection) url.openConnection(); connection.setDoInput(true); connection.setDoOutput(true); connection.setRequestMethod("POST"); connection.setRequestProperty("Content-Type", "application/x-www-form-urlencoded"); connection.setRequestProperty("charset", "UTF-8"); connection.setRequestProperty("Content-Length", "" + Integer.toString(params[1].getBytes().length)); dos = new DataOutputStream(connection.getOutputStream()); dos.writeBytes(params[1]); dos.flush(); dos.close(); dis = new DataInputStream(connection.getInputStream()); String line; while ((line = dis.readLine()) != null) data += line; } catch (IOException e) { e.printStackTrace(); } finally { try { if (dos != null) dos.close(); if (dis != null) dis.close(); } catch (IOException e) { e.printStackTrace(); } } return data; } }


44

En esta fase se implementaron además los siguientes módulos:

Notificación de incidencias: cuando el repartidor pulse sobre el icono de incidencia de la tarea aparecerá un diálogo con una serie de inciden-cias predeterminadas y un cuadro de texto, donde podrá dar cualquier detalle adicional del motivo de la incidencia.

Para ello se creó la clase ReportIncidenceDialog (que extiende de Dialog). En el mo-mento en el que se crea un objeto de la clase debemos establecer el comportamiento del diálo-go cuando se vaya a cerrar. En este caso la aplicación volverá a la actividad que ha creado el diá-logo a través de un Intent.

ReportIncidenceDialog incidenceDialog = new ReportIncidenceDialog(context, task); incidenceDialog.setDialogResult(new OnMyDialogResult() { @Override public void finishTask(Task task) { Intent intent = new Intent(); intent.putExtra("task", task); setResult(RESULT_OK, intent); finish(); } }); incidenceDialog.show();

Implementación de tipos de servicio y horas límite: se crearon cuatro tipos de servicio, repre-

sentados por la enumeración Service (ver Figura 16). Por cada tarea se guarda el tipo de ser-vicio y la hora de creación de la misma, que servirá para calcular la hora límite de entrega (espe-cificada en el punto 2.1.2). Se añadió estas horas en la lista de tareas, y se creó un método que comprueba si queda menos de una hora para que llegue la hora límite de una tarea; si es así, muestra una alerta para que el repartidor se dé cuenta de ello.

Ordenación de las tareas en base a su prioridad: se creó la clase SortTasksByStatu-sAndTime, que implementa a la interfaz Comparator<>, con el objetivo de poder ordenar la lista de tareas en base a su estado (primero las que están en progreso, después las que están sin comenzar y por último las que están finalizadas) y a su hora límite, para que el repartidor sepa qué tarea debe hacer en cada momento.

Fase 2. Sincronización

Hasta este momento, la aplicación funcionaba siempre y cuando estuviera conectada a Internet, bien a través de WiFi o de datos móviles. El proyectante pensó que una característica que podría dar valor a la aplicación era que pudiera ser utilizada en aquellos lugares donde no hubiera cobertura. Para ello, ideó un sistema mediante el que el repartidor pudiera seguir utilizándola en dichas zonas.


45

El primer paso fue detectar los cambios en la red, es decir, cuándo el terminal perdía la conexión a In-ternet y cuándo la recuperaba. La forma de hacerlo fue comprobando el estado del Cloud Connector4. Para ello se creó la clase CloudConnectorStatusReceiver, cuya misión es captar los mensajes de broadcast emitidos por el Cloud Connector cuando hay un cambio en el estado de la red del terminal.

Cuando se pierde la conexión se activa el “modo offline”; cuando vuelve, se regresa al “modo online” o modo normal. En la siguiente figura se pueden observar las implicaciones de cada modo:

Figura 23. Implicaciones de ambos modos de conexión.

La principal consecuencia del paso al modo sin conexión es que todos los cambios que se produzcan en las tareas deben ser almacenados localmente. Esto incluye tanto los cambios de estado como las firmas digitalizadas de los clientes (que se generan cuando un envío es entregado). Cuando la conexión vuelve al dispositivo, el sistema actualiza los cambios de las tareas en el servidor y sube las firmas almacenadas a la nube.

Uno de los mayores problemas surgió en el método creado para subir las firmas a la nube. Dicho méto-do accede al almacenamiento privado de la aplicación, lista todos los ficheros y aquellos cuya extensión es .png (correspondientes con las firmas digitalizadas) son enviados a la nube mediante el Cloud Con-nector, y borrados más tarde. La anomalía apareció a la hora de subirlas, puesto que el Cloud Connector se cerraba repentinamente.

4 El funcionamiento del Cloud Connector se explica en el punto 1.1.


46

Tras múltiples pruebas, depuraciones y cambios en el código se llegó a la siguiente conclusión: el méto-do que proporciona el Cloud Connector para subir un fichero a la nube es, por defecto, asíncrono. Tal cual estaba el código hasta ese momento, se invocaba dicho método y seguidamente se borraba el fi-chero .png, por lo que aparecía una excepción en el Cloud Connector y se cerraba. La solución fue invo-car al método síncrono, con timeout 10 segundos, para subir un fichero (que devuelve true si la opera-ción se ha realizado con éxito o false en caso contrario) y borrarlo una vez subido.

En las siguientes porciones de código se puede ver el antes y el después:

… PackagingApplication.getInstance().getCloudConnectorManager().

sendFile(Constants.FOLDER + File.separator + Constants.SIGNATURES_FOLDER + File.separator + f.getName(), directory + File.separator + f.getName());

f.delete(); … if (PackagingApplication.getInstance().getCloudConnectorManager().

sendFile(Constants.FOLDER + File.separator + Constants.SIGNATURES_FOLDER + File.separator + f.getName(), directory + File.separator + f.getName(), false, 10000)) {

f.delete(); }

Fase 3. Creación de las interfaces de la nueva aplicación

La primera tarea de la nueva aplicación para los clientes (después del análisis y diseño) fue el desarrollo de las interfaces de usuario. Fue un proceso sencillo, puesto que solo había que copiar los prototipos realizados en el diseño y el proyectante ya dominaba la programación de layouts en Android.

Figura 24. Estructura de los layouts de la aplicación.


47

Todos los layouts tienen la misma estructura: un LinearLayout vertical que contiene 3 elementos, la cabecera (siempre la misma), la barra de título y el cuerpo de la actividad.

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:tools="http://schemas.android.com/tools" android:layout_width="match_parent" android:layout_height="match_parent" android:orientation="vertical" > <include layout="@layout/header" /> <RelativeLayout android:id="@+id/layoutTitle" … > </RelativeLayout> <LinearLayout android:layout_width="match_parent" android:layout_height="match_parent" … >

</LinearLayout> </LinearLayout>

La mayor dificultad que encontró el proyectante fue en el layout de “Nuevo pedido”, puesto que se quería simular un proceso en varios pasos (primero introducir los datos del remitente y el receptor, luego elegir el tipo de servicio y por último ver un resumen antes de aceptar el pedido). Además, se quería que fuese un proceso animado, con transiciones de entrada y salida en cada paso.

Para ello se creó el layout new_order.xml, dentro del cual se utilizó el componente ViewFlipper, que incluye los cuatro pasos del proceso de nuevo pedido (finalmente se decidió dividir el primer paso en dos: información del remitente primero y luego la del receptor).

<ViewFlipper> <include layout="@layout/new_order_step1" />

<include layout="@layout/new_order_step2" /> <include layout="@layout/new_order_step3" /> <include layout="@layout/new_order_step4" /> </ViewFlipper>

La clase NewOrderActivity es la encargada de gestionar las transiciones, de manera que cuando se pulsa el botón de siguiente la animación cambia de paso de derecha a izquierda.

btNext.setOnClickListener(new OnClickListener() { @Override public void onClick(View v) {

viewFlipper.showNext(); } });


48

En las últimas semanas de desarrollo, cuando el proyecto estaba prácticamente acabado, la empresa proporcionó al proyectante un nuevo tablet para que probara la aplicación, el Nexus 7 de Google. Este tablet, de 7 pulgadas, posee una gran resolución (800x1280, 216ppi), por lo que se presentó el problema de que las interfaces se veían muy pequeñas. Este inconveniente se resolvió de la siguiente manera: se estableció que las interfaces diseñadas hasta ese momento se muestren en dispositivos con resolución menor a 600dp (generalmente móviles de hasta 7 pulgadas). Para el resto de dispositivos (tablets de 7 pulgadas o más), se duplicaron y adaptaron las interfaces existentes, y se introdujeron dentro de la car-peta res/layout-sw600dp. El propio S.O. Android detecta la resolución de la pantalla donde se está eje-cutando la aplicación y decide qué interfaces mostrar.

Fase 4. Funcionalidad de la aplicación para los clientes

Una vez implementadas las interfaces de usuario, el siguiente paso fue dotar de funcionalidad a la apli-cación. Primero se crearon las clases correspondientes al modelo de objetos (ver Figura 16). Posterior-mente, las diez clases que corresponden con la lógica de negocio, explicadas a continuación.

Se recomienda al lector ver previamente las figuras del Anexo 2 (Mockups) y el punto 2.2.2 (Diagrama de navegación) para que le sea más fácil la comprensión de las siguientes clases.

MainApplication. Esta clase, que extiende de Application, es la principal de la aplica-ción. Sirve para mantener el estado a través de todas las actividades y partes de la aplicación, implementando el patrón Singleton. A través de su única instancia, permite el acceso a las dos clases de la persistencia. Además, posee un método público para que cualquier actividad o hilo de la aplicación pueda mostrar un toast (mensaje por pantalla) a través del hilo principal.

/** * Default handler to take care of UI actions called from other threads. */ private Handler handler = new Handler() { public void handleMessage(Message msg) { switch (msg.what) { case ACTION_SHOW_TOAST: Toast.makeText(MainApplication.this,

msg.getData().getString("message"), Toast.LENGTH_LONG).show();

break; } } };

HomeActivity. Es la actividad inicial, aquella que aparece cuando la aplicación es ejecutada. Implementa el funcionamiento de los tres botones (ver Figura 12) y crea un menú para acceder al login y a la información de la empresa.


49

LoginActivity. Esta actividad es la encargada de loguear al usuario. Cuando se pulsa el bo-tón de iniciar sesión, el método handleSignPressed() verifica la autenticidad del usuario llamando al servicio web /clientIdentification, al que le pasa el hash de user:password. Si la veri-ficación es correcta, almacena el nombre del usuario en las preferencias globales y retorna a la actividad que había invocado al login; si no lo es, muestra un mensaje por pantalla.

TrackingActivity. El cometido de esta actividad es localizar el o los pedidos en curso de un cliente o un usuario no registrado en el sistema. Por ello, esta actividad cuenta con dos vis-tas: si hay un cliente en la sesión, llama al método de la persistencia getProgressOr-ders() y muestra una lista con los pedidos en curso de dicho cliente; si no lo hay, presenta un cuadro de texto donde el usuario puede introducir un número de seguimiento para ver los deta-lles de su pedido. En ambos casos se permite escanear un código QR asociado a un pedido para ver sus detalles. Cuando el usuario pulsa sobre un pedido de la lista o hace clic sobre el botón de localizar, la aplicación inicia la actividad OrderDetailsActivity.

Figura 25. Comparación de ambas vistas.

OrderDetailsActivity. Esta actividad recibe a través del intent de llamada un objeto

de la clase Order, que contiene todos los detalles del pedido seleccionado. Muestra al usuario una tabla con el tránsito del pedido, es decir, cada fila corresponde con un cambio de estado de la tarea. Además, proporciona un botón para acceder a los detalles completos de la misma.

OrderFullDetailsActivity. Una de las actividades más simples de la aplicación. Su úni-ca tarea es recoger el objeto pedido del intent y mostrar al usuario todos los detalles del mismo.

HistoryActivity. Es la actividad encargada de mostrar todos los pedidos que ha realizado un usuario. Para ello, llama al método de la persistencia getOrders(), que devuelve un obje-


50

to del tipo List<Order>. Al igual que ocurría en la actividad de tracking, cuando el usuario pulsa sobre un pedido se inicia la actividad OrderDetailsActivity. Por último, se le pro-vee al usuario de un cuadro de texto donde poder buscar o filtrar los pedidos (a través de su identificador o de su estado). A medida que el usuario escribe en el cuadro, la lista de pedidos se va actualizando. En el siguiente código se puede observar cómo está implementada esta ca-racterística:

private void initializeUI() {

… etSearch = (EditText)findViewById(R.id.etSearch); TextWatcher fieldValidatorTextWatcher = new TextWatcher() {

… @Override

public void onTextChanged(CharSequence s, int start, int before, int count) {

updateList(etSearch.getText().toString().toLowerCase()); } };

etSearch.addTextChangedListener(fieldValidatorTextWatcher); }

private void updateList(String text) { if (orders != null) { ArrayList<Order> filter = new ArrayList<Order>(); for (Order o : orders) { if (o.getIdTask().contains(text) ||

o.getStatus().getName().toLowerCase().contains(text)) filter.add(o); } ordersAdapter = new OrdersAdapter(context, R.layout.order_item,

filter, getLayoutInflater()); getListView().setAdapter(ordersAdapter); } }

NewOrderActivity. Actividad encargada de gestionar el proceso de un nuevo pedido. Co-

mo ya se comentó anteriormente, este proceso está compuesto de cuatro pasos. En el primero y segundo se presenta al usuario una serie de cuadros de texto para que introduzca los datos del emisor y receptor del paquete. Las únicas comprobaciones que se hacen en ese momento es que todos los campos excepto el teléfono estén rellenados. En el tercer paso el usuario debe elegir el tipo de servicio y método de pago. Además, puede adjuntar detalles específicos rela-cionados con el envío. Antes de cargar este paso, el sistema comprueba en base a la hora del dispositivo qué servicios están disponibles en ese momento para mostrarlos en el spinner. El cuarto y último paso sirve para que el usuario verifique que toda la información es correcta, mostrando todos los valores introducidos en los anteriores pasos. Cuando el usuario pulse so-


51

bre el botón de finalizar, el sistema llamará al método de creación de pedido de la persistencia y mostrará en un diálogo el resultado de la operación.

StoredAddressesActivity. Cada vez que un usuario realiza un nuevo pedido, interna-mente en el servidor se almacenan los datos del remitente y del receptor como “favoritos”, con el objetivo de agilizar futuros pedidos a los mismos clientes. Por ello, esta actividad obtiene esas direcciones favoritas del servidor y las muestra en una lista, permitiendo que el usuario no ten-ga que volver a escribir los datos. A esta actividad se accede a través del menú de NewOrde-rActivity. La idea de crear esta actividad surgió en pleno desarrollo del proceso de nuevos pedidos, por lo que no está contemplada en los prototipos iniciales.

AboutUsActivity. Es la actividad más simple de la aplicación y no tiene funcionalidad algu-na. Únicamente muestra información sobre la empresa y sus tipos de servicios. Estos datos es-tán almacenados en la carpeta de recursos (res/values/strings.xml) de la aplicación.

Figura 26. Vista de las direcciones almacenadas y la información de la empresa.

Por último, se crearon las dos clases de la capa de persistencia: PreferencesManager y Orders-Manager. La primera de ellas gestiona las preferencias de la aplicación (en este caso nombre de usua-rio y hash) en el almacenamiento interno de Android. Para ello, utiliza un objeto de la clase Sha-redPreferences, que proporciona métodos put y get para escribir y leer del fichero de preferen-cias.

Por otro lado, la clase OrdersManager es la encargada de realizar las peticiones web, obtener las respuestas en formato XML y parsearlas. En todas las llamadas a servicios web es necesario pasar el hash como método de validación del usuario (exceptuando en el de tracking de un único pedido).

DESARROLLO Pruebas

52

2.4. Pruebas Como se estableció en el punto 2.2.7 Diseño del plan de pruebas, se van a realizar tres tipos de pruebas: unitarias, de integración y de aceptación. Cabe destacar que, al estar utilizando una metodología de desarrollo ágil, las pruebas unitarias se fueron haciendo a medida que se iba desarrollando la aplicación.

1. Pruebas unitarias (solo se incluyen las más importantes, el resto se pueden ver en el Anexo 4,

Pruebas unitarias). Las dos primeras corresponden con la aplicación para los repartidores; las dos últimas a la aplicación para los clientes.

Prueba nº 1.1 Tarea: Envío de incidencia

Descripción Reporte de una incidencia sobre una tarea no finalizada.

Procedimiento

En la actividad de detalles de tarea, el repartidor pulsa sobre el icono de incidencia. En el diálogo que aparece selecciona una incidencia de las que se muestran en el spinner y, si desea, añade un comentario en el cuadro de texto.

Resultado CORRECTO. La incidencia es enviada correctamente y la aplicación regresa a la pantalla inicial, donde la tarea mar-cada aparece ahora como incidencia.

Prueba nº 1.2 Tarea: Ordenación de tareas por prioridad

Descripción La lista de tareas que ve el repartidor está ordenada según el estado de las mismas y su hora límite.

Procedimiento No hay ninguna acción por parte del repartidor.

Resultado CORRECTO. Las tareas, a medida que llegan a la aplicación, se van ordenando según su estado, y dentro de un mismo estado, por la hora límite de entrega.

DESARROLLO Pruebas

53

Prueba nº 2.1 Tarea: Login

Descripción Identificación en el sistema a través de la cuenta de usua-rio (nombre de usuario y contraseña).

Procedimiento

El usuario, desde la pantalla inicial de la aplicación, accede a la actividad de Login desde el menú o pulsando sobre los botones de “Mis pedidos” o “Nuevo pedido”. Después, in-troduce sus credenciales y pulsa el botón Iniciar sesión.

Resultado

CORRECTO. Si las credenciales son correctas, la aplicación loguea al usuario, guarda su nombre y hash en las prefe-rencias de la aplicación y regresa a la actividad de proce-dencia. Si no, aparece un mensaje de error.

Prueba nº 2.2 Tarea: Localización con tracking number

Descripción Localización de un pedido introduciendo su número de seguimiento.

Procedimiento El usuario, sin haber iniciado sesión, accede a la actividad de “Localizar pedido” e introduce su número de segui-miento. Por último, pulsa sobre el botón Localizar.

Resultado

CORRECTO. Si el número de seguimiento coincide con un pedido, se muestra la actividad “Detalles del pedido”, con la tabla del tránsito del pedido. Si no, muestra un mensaje avisando que no existe ningún pedido con ese código.

DESARROLLO Pruebas

54

2. Pruebas de integración.

Prueba nº 1.1 Tarea: Sincronización

Descripción Actualización en el servidor de cambios de estado de ta-reas y firmas digitalizadas cuando el terminal estaba en modo sin conexión.

Procedimiento

No hay ninguna acción por parte del usuario. La aplicación, en el momento en el que recupera la conexión a Internet, actualiza en el servidor los cambios de estado de las tareas y sube a la nube las firmas digitalizadas.

Resultado

CORRECTO. Cuando la aplicación recupera la conexión a la red: quita el icono de modo offline, sube los cambios de estado y las firmas y avisa mediante un mensaje al usuario de que el proceso ha finalizado correctamente. Si no hay ningún cambio de estado o ninguna firma, no aparece nin-gún mensaje.

Prueba nº 2.1 Tarea: Nuevo pedido

Descripción Proceso de creación de un nuevo pedido.

Procedimiento

El usuario, una vez ha iniciado sesión, accede desde el inicio a “Nuevo pedido”. En el primer paso introduce los datos del remitente del pedido; en el segundo, los del emi-sor; en el tercero debe seleccionar el tipo de servicio y el método de pago; por último, en el cuarto puede verificar los datos introducidos anteriormente. Si está conforme, pulsará sobre el botón Finalizar. Si no, sobre Cancelar.

Resultado

CORRECTO. Si hay disponibilidad de repartidores y todos los datos introducidos son correctos, aparecerá un diálogo avisando de que el proceso se ha completado correctamen-te. Si no la hay, se avisa de que el servicio no está disponi-ble. Por el contrario, si el usuario decide cancelar el pedi-do, la aplicación regresa a la actividad inicial.

DESARROLLO Pruebas

55

3. Pruebas de aceptación.

A lo largo del proyecto, la revisión del trabajo realizado por parte de la empresa ha sido constante, pues-to que cada dos semanas se convocaba una reunión para exponer los avances del mismo, que también servía para proponer cambios o mejoras en las aplicaciones.

Durante los meses de abril y mayo, ambas aplicaciones fueron presentadas en varias ocasiones a los miembros responsables de la empresa, haciendo en las últimas reuniones una demo del sistema com-pleto (aplicaciones Android y aplicaciones web). En la última, se obtuvo el visto bueno de ambas aplica-ciones, con lo que se dio por finalizado el desarrollo del proyecto.

56

Capítulo 3. Conclusiones En este último apartado se resumen las conclusiones más importantes de este proyecto. Se ha evaluado el grado de cumplimiento de los objetivos iniciales y se exponen los problemas planteados y el método de resolución, los conocimientos adquiridos por el proyectante en el desarrollo del mismo y las futuras mejoras que no se han podido implementar por falta de tiempo.

3.1. Evaluación de objetivos En la primera parte de la memoria se mencionaron los objetivos de este proyecto. Estos se dividieron en tres niveles: objetivo general, objetivos a nivel del sistema y objetivos a nivel de las aplicaciones An-droid. Se analizarán de modo inverso a lo expuesto, es decir, de los más concretos a los más abstractos.

En cuanto a las aplicaciones Android: se ha finalizado correctamente y según lo planificado la de los repartidores, modificando determinados aspectos como la interfaz de usuario, y se ha desarrollado la nueva aplicación para los clientes, con las tres funciones básicas. Además, ambas aplicaciones son intui-tivas y fáciles de usar, funcionan tanto en smartphones como en tablets y son compatibles con cualquier versión del sistema operativo superior a la 2.3.3.

Con respecto al sistema global (visto como la unión de los dos trabajos de los alumnos), se ha logrado que ambas plataformas se comuniquen, bien a través de la Device Cloud o de Google App Engine. El sistema ha sido probado por varios miembros de la empresa Digi y ha contado con el visto bueno de todos los responsables, así como el vídeo promocional, que ha causado muy buenas sensaciones.

Por último, analizando el objetivo general del proyecto (desarrollar un sistema completo y fácil de usar que se encargue de la logística necesaria para el buen funcionamiento de una empresa de paquetería a pequeña escala), se considera que se ha cumplido casi en su totalidad. Pese a que el sistema podría im-plantarse tal y como está en una empresa de esas características, quizás haya cuestiones que mejorar o añadir para poder competir con los sistemas similares presentes en el mercado.

3.2. Problemas planteados y procedimiento para su resolución A pesar de que durante la fase de desarrollo ya se fueron mencionando los problemas que surgieron, se ha decidido resumirlos aquí para un mejor análisis de los mismos.

Uno de los primeros problemas que surgió en el desarrollo fue el no funcionamiento de la aplicación para los repartidores en versiones superiores a la 3.0 de Android. Esto se debió a que no se siguieron las recomendaciones de Android, puesto que se llevaban a cabo operaciones de red en el hilo principal de la aplicación, algo que se resolvió introduciendo tareas asíncronas.

CONCLUSIONES Conocimientos adquiridos

57

El cambio ha sido un constante inconveniente a lo largo de proyecto. Como se ha comentado anterior-mente, cada dos semanas había una reunión con los responsables de la empresa, y en muchas de ellas se planteaban cambios y mejoras en las aplicaciones. En el caso de las mejoras no significaba tanto pro-blema, pero hacer efectivo un cambio significaba haber perdido horas o días de trabajo. Sin embargo, pese a todos los cambios que se han llevado a cabo, el proyecto se ha conseguido finalizar en el plazo previsto y dentro del margen de horas estimadas.

Otro problema que surgió en el mes de marzo fue el cambio de marca corporativa de la nube de disposi-tivos. Hasta entonces, la nube se llamaba iDigi Device Cloud, pero debido a la adquisición de Etherios por parte de Digi, decidieron hacer un rebranding, con lo que pasó a llamarse Etherios Device Cloud. Esto afectó al proyecto ya que hubo que cambiar y refactorizar todas las clases que dependen de la nu-be, sustituyendo también las librerías y el iDigi Connector por el Cloud Connector.

Por último, otra complicación que surgió en la parte final del proyecto fue la mala adaptación de las interfaces a pantallas con grandes resoluciones. Durante el desarrollo de las aplicaciones, los medios para probarlas fueron un tablet de 7 pulgadas y un smartphone de 4,7. En las últimas semanas, se insta-laron las aplicaciones en un tablet de gran resolución y quedó de manifiesto su mala adaptación. Esto se resolvió acudiendo a la documentación oficial de Android, que dio las claves al proyectante para corregir las interfaces y que se visualizaran de manera correcta.

3.3. Conocimientos adquiridos No cabe duda de que después de trabajar tanto tiempo sobre la plataforma Android, una de las destre-zas más importantes adquiridas ha sido esa, la programación de aplicaciones para este sistema operati-vo. Cuando el proyectante comenzó a elaborar este trabajo ya poseía cierta base en esta plataforma, ya que durante los meses de prácticas previos a este trabajo se inició la construcción del sistema, lo que implicó semanas de aprendizaje. Adentrarse en el mundo de las tecnologías móviles ha resultado una muy buena experiencia para el proyectante, pudiendo asegurar que estas solo han sido las primeras de muchas aplicaciones que desarrollará, tanto en Android como en otras plataformas.

Además, las habilidades transversales adquiridas a lo largo de este trabajo han sido muy positivas. Aprender a solucionar problemas sin la supervisión de un profesor, trabajar en equipo, guiar tu propio proyecto o desarrollar en el ámbito de una empresa son cuestiones que han ayudado al proyectante a acercarse más al mundo laboral que le espera.

El proyectante ha aprendido que quien manda puede cambiar de opinión, y lo que hace una semana había que hacerlo de una manera ahora hay que hacerlo de otra, y además hay que hacerlo ya. Es decir, hay que estar constantemente preparado para el cambio y es posible que todo el trabajo de días o se-manas no valga para nada y haya que cambiarlo.

Y, aunque no se ha mejorado demasiado el nivel, este trabajo ha hecho que el proyectante se dé cuenta de la importancia que tiene el inglés en el campo de las tecnologías. Formar parte de una multinacional

CONCLUSIONES Mejoras del proyecto

58

norteamericana ha implicado escribir (documentación, presentaciones, correos electrónicos) e incluso exponer el proyecto en inglés ante ejecutivos de la delegación estadounidense, por lo que queda de manifiesto la importancia del buen manejo de este idioma.

3.4. Mejoras del proyecto Debido a la limitación horaria y temporal de este trabajo, ha sido imposible llevar a cabo ideas que se propusieron antes de comenzar con él. Ejemplos de esas ideas son:

Comunicación mediante mensajes del dispositivo móvil a la página web. En la aplicación para los repartidores solo se permite que la empresa envíe mensajes a sus trabajadores. Una mejora se-ría que estos pudieran también responder.

Reiniciación de tareas marcadas como incidencia. En el estado actual de la aplicación, una vez que se marca una tarea como incidencia no se puede volver a iniciar. Lo ideal sería que se pudie-ra reiniciar para entregar el paquete en otro momento.

Generación de códigos QR para pegatinas. Según como está diseñado el sistema, el repartidor debe llevar pegatinas pre-impresas para pegar en los paquetes que recoge. Cada código QR de las pegatinas tiene una numeración distinta, como medio de identificación única del paquete. Podría ser mejor que el repartidor imprimiera el código en el momento de recoger el paquete.

Utilización de la localización del repartidor en el seguimiento de un pedido. Algo que podría agradar a los clientes es ver sobre un mapa dónde se encuentra su pedido. Para ello, podría uti-lizarse la localización del terminal que se utiliza para controlar a los repartidores.

Implementación de los métodos de pago. Puesto que la aplicación no está destinada, en princi-pio, a venderse a una empresa real, no se implementaron los métodos de pago. Si fuera a ser utilizada por una compañía real habría que implementar las pasarelas de pago para poder solici-tar un envío.

59

Capítulo 4. Bibliografía Ed Burnette (2010). Hello Android. Introducing Google’s Mobile Development Platform.

Pragmatic Bookshelf.

Mark L. Murphy (2009). The Busy Coder’s Guide to Advanced Android Development. CommonsWare.

Sayed Hashimi, Satya Komatineni, Dave MacLean (2010). Pro Android 2. Apress.

Project Management Institute (2008). Guía de los Fundamentos para la Dirección de Proyectos. PMI.

http://www.android.com

http://developer.android.com

http://stackoverflow.com

Trabajo de Fin de Grado Rubén Moral Miera

1

Anexos

Anexo 1. Casos de uso En este anexo se enumeran el resto de casos de uso de la aplicación para los clientes:

Caso de uso Cerrar sesión Descripción Finalizar la sesión abierta en [Iniciar sesión].

Actores Cliente.

Precondiciones La sesión del cliente debe estar abierta.

Postcondiciones La sesión del cliente queda cerrada.

Flujo básico

1. El cliente elige la opción “Cerrar sesión” en la pantalla inicial. 2. El sistema muestra un aviso pidiendo la confirmación del usuario. 3. El cliente pulsa sobre aceptar.


No hay.

Anotaciones La opción de cerrar sesión solo aparecerá en el menú inicial cuando la sesión se encuentre abierta.

Caso de uso Ver detalle pedido Descripción Mostrar los detalles del pedido seleccionado.

Actores Cliente.

Precondiciones El cliente ha tenido que pulsar en un pedido en [Localizar pedido] o en [Ver historial de pedidos].

Postcondiciones Se muestra en detalle el pedido, así como una lista con los estados por los que ha ido pasando.

Flujo básico

1. El cliente pulsa sobre el pedido. 2. El sistema muestra la información relativa a ese pedido.


No hay.

Anotaciones No hay.

ANEXOS Casos de uso

2

Caso de uso Ver historial de pedidos Descripción Mostrar una lista con los pedidos realizados de un cliente.

Actores Cliente.

Precondiciones El cliente debe estar autenticado.

Postcondiciones Se muestra una lista con todos los pedidos que ha realizado el cliente.

Flujo básico

1. El cliente elige la opción “Historial de pedidos” en la pantalla inicial. 2. El sistema comprueba si el cliente está autenticado. 3. El sistema muestra una lista con todos los pedidos realizados por el

cliente.


En el punto 2, si el cliente no ha iniciado sesión se lleva a cabo [Iniciar sesión]. Tras el punto 3, el cliente puede pulsar sobre un pedido de la lista e ir a [Ver detalle pedido].

Anotaciones No hay.

Caso de uso Escanear código QR Descripción A través de la cámara del dispositivo se escanea un código

QR que lleva implícito el número de seguimiento.

Actores Cliente.

Precondiciones El cliente ha tenido que pulsar el icono de la cámara en [Localizar pedido].

Postcondiciones El número de seguimiento implícito en el código es devuelto a [Localizar pedido].

Flujo básico

1. El cliente sitúa la cámara del dispositivo sobre el código QR, quedando alineado este con el cuadro delimitado en la pantalla.

2. El sistema escanea el código y avisa al usuario mediante un pitido. 3. El sistema lleva a cabo el punto 4 de [Localizar pedido].


Si lo que se está escaneando no es un código QR, el sistema mantendrá la pantalla de escaneo.

Anotaciones No hay.

ANEXOS Mockups

3

Anexo 2. Mockups

Figura 1. Pantalla inicial.

ANEXOS Mockups

4

Figura 2. Menú de la pantalla inicial

ANEXOS Mockups

5

Figura 3. Pantalla de información de la empresa.

ANEXOS Mockups

6

Figura 4. Pantalla de login y registro.

ANEXOS Mockups

7

Figura 5. Pantalla de inicio con usuario logueado.

ANEXOS Mockups

8

Figura 6. Menú de la pantalla inicial con usuario logueado.

ANEXOS Mockups

9

Figura 7. Pantalla de confirmación de cierre de sesión.

ANEXOS Mockups

10

Figura 8. Pantalla de inicio horizontal.

ANEXOS Mockups

11

Figura 9. Pantalla de seguimiento de pedidos.

ANEXOS Mockups

12

Figura 10. Pantalla de detalles del pedido.

ANEXOS Mockups

13

Figura 11. Pantalla de detalles completos.

ANEXOS Mockups

14

Figura 12. Pantalla de seguimiento si el usuario está logueado.

ANEXOS Mockups

15

Figura 13. Pantalla de histórico de pedidos.

ANEXOS Mockups

16

Figura 14. Pantalla del primer paso de un nuevo pedido.

ANEXOS Mockups

17

Figura 15. Pantalla del segundo paso de un nuevo pedido.

ANEXOS Mockups

18

Figura 16. Pantalla del tercer paso de un nuevo pedido.

ANEXOS Mockups

19

Figura 17. Pantalla de confirmación del pedido.

ANEXOS Mockups

20

Figura 18. Pantalla de aviso del nuevo pedido.

ANEXOS AndroidManifest.xml

21

Anexo 3. AndroidManifest.xml Aplicación para repartidores:

<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.digi.android.etherios.packaging" android:installLocation="auto" android:versionCode="1" android:versionName="1.0" > <uses-sdk android:minSdkVersion="10" /> <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" /> <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" /> <uses-permission android:name="android.permission.INTERNET" /> <uses-permission android:name="android.permission.VIBRATE" /> <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" /> <uses-permission android:name="android.permission.READ_PHONE_STATE" /> <uses-permission android:name="android.permission.CALL_PHONE" /> <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" /> <uses-permission android:name="android.permission.CAMERA" />  <uses-permission android:name="com.digi.connector.android.DATA_SERVICE" /> <uses-permission android:name="com.digi.connector.android.DEVICE_REQUEST" /> <uses-feature android:name="android.hardware.camera" android:required="false" /> <uses-feature android:name="android.hardware.camera.front" android:required="false" /> <application android:name="com.digi.android.etherios.packaging.PackagingApplication" android:allowBackup="true" android:icon="@drawable/ic_launcher_icon" android:label="@string/app_name" android:theme="@android:style/Theme.Light.NoTitleBar" > <activity android:name="com.digi.android.etherios.packaging.LoginActivity" android:label="@string/app_name" android:screenOrientation="portrait" android:theme="@android:style/Theme.Black.NoTitleBar" > <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> <activity android:name="com.digi.android.etherios.packaging.PackagingActivity" android:label="@string/app_name" android:launchMode="singleTask" android:screenOrientation="portrait" > </activity> <activity android:name="com.digi.android.etherios.packaging.HomeActivity"

22

android:label="@string/home" android:screenOrientation="portrait" > </activity> <activity android:name="com.digi.android.etherios.packaging.TasksActivity" android:label="@string/tasks" android:screenOrientation="portrait" > </activity> <activity android:name="com.digi.android.etherios.packaging.MessagesActivity" android:label="@string/messages" android:screenOrientation="portrait" > </activity> <activity android:name="com.digi.android.etherios.packaging.TaskDetailsActivity" android:label="@string/task_details" android:screenOrientation="portrait" > </activity> <activity android:name="com.digi.android.etherios.packaging.FilterActivity" android:label="@string/filter" android:screenOrientation="portrait" > </activity> <activity android:name="com.digi.android.etherios.packaging.MapActivity" android:label="@string/map" android:screenOrientation="portrait" > </activity> <activity android:name="com.digi.android.etherios.packaging.SettingsActivity" android:label="@string/settings" android:screenOrientation="portrait" > </activity> <activity android:name="com.digi.android.etherios.packaging.ProfileActivity" android:label="@string/profile" android:screenOrientation="portrait" > </activity> <activity android:name="com.digi.android.etherios.packaging.RegistrationActivity" android:label="@string/registration" android:screenOrientation="portrait" > </activity> <activity android:name="com.digi.android.etherios.packaging.SignatureActivity" android:label="@string/signature" android:screenOrientation="portrait" > </activity>  <receiver android:name="com.digi.connector.android.library.core.DeviceRequestReceiver" > <intent-filter> <action android:name="com.digi.connector.android.DEVICE_REQUEST" /> <category android:name="android.intent.category.HOME" /> </intent-filter> </receiver> <receiver android:name="com.digi.connector.android.library.core.SendFileStatusReceiver" > <intent-filter>


23

<action android:name="com.digi.connector.android.UPLOAD_FILE_STATUS" /> <category android:name="android.intent.category.HOME" /> </intent-filter> </receiver> <receiver android:name="com.digi.connector.android.library.core.DeviceIDReceiver" > <intent-filter> <action android:name="com.digi.connector.android.DEVICE_ID" /> <category android:name="android.intent.category.HOME" /> </intent-filter> </receiver> <receiver android:name="com.digi.connector.android.library.core.ServiceStatusReceiver" > <intent-filter> <action android:name="com.digi.connector.android.SERVICE_STATE" /> <category android:name="android.intent.category.HOME" /> </intent-filter> </receiver> <receiver android:name="com.digi.connector.android.library.core.ServiceStatusChangeReceiver" > <intent-filter> <action android:name="com.digi.connector.android.SERVICE_STATE_CHANGED" /> <category android:name="android.intent.category.HOME" /> </intent-filter> </receiver> <receiver android:name="com.digi.android.etherios.packaging.receivers.CloudConnectorStatusReceiver" > <intent-filter> <action android:name="com.digi.connector.android.SERVICE_STATE_CHANGED" /> <category android:name="android.intent.category.HOME" /> </intent-filter> </receiver> <service android:name="com.digi.android.etherios.packaging.location.CurrentLocationService" /> <uses-library android:name="com.google.android.maps" android:required="true" /> </application> </manifest>


24

Aplicación para clientes:

<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.digi.android.bybike" android:versionCode="1" android:versionName="1.0" > <uses-sdk android:minSdkVersion="10" android:targetSdkVersion="10" /> <uses-permission android:name="android.permission.INTERNET" /> <application android:name="com.digi.android.bybike.MainApplication" android:allowBackup="true" android:icon="@drawable/ic_launcher_icon" android:label="@string/app_name" android:theme="@android:style/Theme.Light.NoTitleBar" > <activity android:name="com.digi.android.bybike.HomeActivity" android:label="@string/app_name" > <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> <activity android:name="com.digi.android.bybike.LoginActivity" android:label="@string/title_activity_login" > </activity> <activity android:name="com.digi.android.bybike.TrackingActivity" android:label="@string/title_activity_tracking" > </activity> <activity android:name="com.digi.android.bybike.HistoryActivity" android:configChanges="keyboardHidden|orientation" android:label="@string/title_activity_history" > </activity> <activity android:name="com.digi.android.bybike.NewOrderActivity" android:configChanges="keyboardHidden|orientation" android:label="@string/title_activity_new_order" > </activity> <activity android:name="com.digi.android.bybike.OrderDetailsActivity" android:label="@string/title_activity_order_details" > </activity> <activity android:name="com.digi.android.bybike.OrderFullDetailsActivity" android:label="@string/title_activity_order_full_details" > </activity> <activity android:name="com.digi.android.bybike.AboutUsActivity" android:label="@string/title_activity_about_us" > </activity> <activity android:name="com.digi.android.bybike.StoredAddressesActivity" android:label="@string/title_activity_stored_addresses" > </activity> </application> </manifest>

ANEXOS Pruebas unitarias

25

Anexo 4. Pruebas unitarias

Prueba nº 2.3 Tarea: Localización de pedidos en curso

Descripción Localización de todos los pedidos en curso de un usuario que ha iniciado sesión anteriormente.

Procedimiento El usuario, una vez ha iniciado sesión, accede desde el inicio a “Localizar pedido”.

Resultado CORRECTO. Se muestra una lista con todos los pedidos en curso de dicho cliente. Si no tiene ninguno, la lista aparece vacía.

Prueba nº 2.4 Tarea: Histórico de pedidos

Descripción Identificación de todos los pedidos que haya realizado un usuario registrado.

Procedimiento El usuario, una vez ha iniciado sesión, accede desde el inicio a “Mis pedidos”.

Resultado CORRECTO. Se muestra una lista con todos los pedidos de dicho cliente. Si no tiene ninguno, la lista aparece vacía.

Prueba nº 2.5 Tarea: Búsqueda y filtro en “Mis pedidos”

Descripción Búsqueda y filtrado de pedidos en la actividad “Mis pedidos”

Procedimiento El usuario, una vez ha iniciado sesión, accede desde el inicio a “Mis pedidos”. Una vez allí, escribe una cadena de texto en el cuadro de búsqueda.

Resultado CORRECTO. A medida que va tecleando el usuario se van filtrando los pedidos en base a su identificador o a su estado.

ANEXOS Pruebas unitarias

26

Prueba nº 2.6 Tarea: Direcciones almacenadas

Descripción Listado de las direcciones favoritas de un usuario.

Procedimiento

El usuario, una vez ha iniciado sesión, accede desde el inicio a “Nuevo pedido”. Tanto si se encuentra en el primer paso como en el segundo, accede al menú y pulsa sobre Direcciones almacenadas.

Resultado CORRECTO. Si el usuario ha realizado un pedido anteriormente se muestra una lista con todas las direcciones empleadas. Si no, la lista aparece vacía.

Desarrollo e implementación de una solución completa … · Diagrama de estados de las tareas....

Documents

Transcript of Desarrollo e implementación de una solución completa … · Diagrama de estados de las tareas....