Aplicación Android para la Asistencia a Pilotos de Aviación Ligera

Transcripción

IS31
PROYECTOS INFORMÁTICOS
DE SISTEMAS
INGENIERÍA TÉCNICA EN INFORMÁTICA DE SISTEMAS
Curso 2012/13
Memoria Técnica del Proyecto
Aplicación Android para la
Asistencia a Pilotos de Aviación
Ligera
Proyecto Presentado por:
José Miguel Llorens Vera
Dirigido por:
Raúl Montoliu Colás
Castellón, a 25 de Mayo de 2013
2
Resumen
En este documento se detalla el estudio y realización de una aplicación Android
que busca suplir las necesidades que un piloto de Aviación Ligera puede tener.
En el transcurso de éste se estudia el sistema Android, se realiza una planificación
y, siguiendo ésta, se modela el sistema y finalmente se diseña e implementa una
pequeña parte de este.
La parte implementada consta de una actividad que realiza el seguimiento de
listas de chequeo de un avión. En ellas se reflejan las acciones que debe tomar un
piloto en las distintas fases de vuelo para conseguir un vuelo más seguro.
La aplicación ha sido diseñada para ser utilizada tanto desde un móvil como desde
una Tablet, aprovechando al máximo la pequeña pantalla de un Móvil y aprovechando
el espacio extra disponible de una Tablet.
3
IÍ ndice General
Índice General .................................................................................................. 3
Índice de Figuras ............................................................................................. 7
Índice de Cuadros ............................................................................................ 9
Capítulo 1: Introducción ............................................................................. 11
1.1
1.2
1.3
1.4
1.5
Motivación del Proyecto ................................................................................................11
Necesidades del Proyecto .............................................................................................11
Contexto ...............................................................................................................................13
Objetivos del Proyecto....................................................................................................14
Palabras Clave....................................................................................................................14
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
Qué es Android ..................................................................................................................15
Características Técnicas ................................................................................................16
Arquitectura del Sistema ...............................................................................................18
Almacenamiento de Datos ............................................................................................20
Estructura de una Aplicación .......................................................................................21
Ciclo de Vida de una Activity........................................................................................23
Resources ............................................................................................................................25
Android Manifest ..............................................................................................................25
Interfaz de Usuario ..........................................................................................................26
Capítulo 2: Estudio Previo - El sistema Android ................................. 15
Principios de Diseño ................................................................................................................................... 26
Patrones de Diseño ...................................................................................................................................... 27
Componentes Básicos. ............................................................................................................................... 32
2.10 Entorno de Desarrollo ....................................................................................................33
Capítulo 3: Planificación ............................................................................. 34
3.1
3.2
Estimación de Recursos Materiales...........................................................................34
Planificación Temporal ..................................................................................................36
3.3
3.4
Estimación de Costes ......................................................................................................40
Seguimiento del Proyecto .............................................................................................41
Identificación de Tareas ............................................................................................................................ 36
Estimación de Tiempos ............................................................................................................................. 38
Hitos ................................................................................................................................................................... 38
Relaciones entre Tareas ............................................................................................................................ 39
Estimación de Fechas ................................................................................................................................. 39
4
Capítulo 4: Análisis .......................................................................................43
4.1
4.2
Presentación de los Requisitos ...................................................................................43
Visión general de la Aplicación ...................................................................................45
4.3
4.4
4.5
Subsistema Papeles .........................................................................................................53
Subsistema Navegación .................................................................................................60
Subsistema Utilidades ....................................................................................................65
5.1
Interfaz Gráfica ..................................................................................................................71
5.2
Diseño de los Procesos ...................................................................................................77
Actores .............................................................................................................................................................. 46
Dependencias de Datos ............................................................................................................................. 47
Requisitos No Funcionales ....................................................................................................................... 52
Capítulo 5: Diseño .........................................................................................71
Elementos Comunes ................................................................................................................................... 71
Prototipo de la Interfaz Gráfica (Anexo C) ........................................................................................ 72
Menú Principal .............................................................................................................................................. 72
Lista de Funcionalidades .......................................................................................................................... 73
Menú Checklists ............................................................................................................................................ 74
Checklist Actual............................................................................................................................................. 75
Menú Ajustes .................................................................................................................................................. 76
Mostrar Listas y Checklist ........................................................................................................................ 77
Proceso Usar Checklists ............................................................................................................................ 78
Proceso Usar Checklists de Emergencia ............................................................................................ 79
Borrar Checklists Completadas ............................................................................................................. 80
Borrar Ítems Completados ....................................................................................................................... 80
Diagramas de Clase (Libros de Checklists) ....................................................................................... 81
Archivo XML del Avión .............................................................................................................................. 84
Capítulo 6: Implementación ...................................................................... 85
6.1
Implementación del Interfaz Gráfico ........................................................................85
6.2
Presentación de la Implementación del Sistema .................................................89
6.3
6.4
6.5
Layouts Principales ..................................................................................................................................... 86
El Spinner de Categorías ........................................................................................................................... 87
Pestañas en las Checklists ........................................................................................................................ 88
Recursos Visuales ........................................................................................................................................ 88
Paquete Principal (com.gmail.mikepilot.PilotFMS) ...................................................................... 89
Paquete Checklists (com.gmail.mikepilot.PilotFMS.Papers.Checklist) ................................ 91
Vista General del Sistema ..............................................................................................92
Elementos Comunes del Sistema................................................................................93
Métodos Comunes........................................................................................................................................ 93
Procedimientos Comunes......................................................................................................................... 95
Principales Retos y Cambios de Diseño ...................................................................98
Cambio de Diseño - Mostrar Lista y Mostrar Ítems. ..................................................................... 98
Cambio de Diseño - Borrar Checklist. ................................................................................................. 99
Cambio de Diseño – Usar Checklist de Emergencia ...................................................................... 99
Implementación de PlaneChecklists. ................................................................................................ 100
Versiones SmartPhone y Tablet – Pestañas. ................................................................................. 102
Versiones SmartPhone y Tablet – Up & Back. .............................................................................. 103
Versiones SmartPhone y Tablet – Nombre de Checklist. ........................................................ 103
5
Capítulo 7: Pruebas.................................................................................... 104
Capítulo 8: Resultado Final ..................................................................... 111
8.1
8.2
8.3
Menú Principal – Vista de Categorías. ................................................................... 111
Menú Ajustes ................................................................................................................... 114
Actividad Checklists. .................................................................................................... 115
9.1
9.2
9.3
Conclusiones Técnicas ................................................................................................. 118
Conclusiones Personales ............................................................................................ 118
Trabajo Futuro ............................................................................................................... 119
Capítulo 9: Conclusiones .......................................................................... 118
Bibliografía ................................................................................................... 120
Anexo A: Definiciones y Abreviaturas ............................................... 121
Anexo B: Manual de Usuario................................................................. 125
6
IÍ ndice de Figuras
Figura 1. Piernógrafo, Checklists y CR-3 respectivamente ................................................12
Figura 2. Esquema de la Arquitectura de Android [2].........................................................18
Figura 3. Ciclo de Vida de Activity [4] ........................................................................................24
Figura 4. Navegación en Android [3] .........................................................................................28
Figura 5. Componentes de Action Bar [3] .................................................................................29
Figura 6. Layout de una App en un móvil [3] ..........................................................................30
Figura 7. Layout de una App en una Tablet [3] ......................................................................30
Figura 8. Layout de una Notificación [3]...................................................................................31
Figura 9. Red de Actividades .........................................................................................................39
Figura 10. Diagrama de Casos de Uso - General.....................................................................45
Figura 11. Diagrama de Casos de Uso - Subsistema Papeles.............................................53
Figura 12. Diagrama de Casos de Uso - Subsistema Navegación.....................................60
Figura 13. Diagrama de Casos de Uso - Subsistema Utilidades........................................65
Figura 14. Icono de la Aplicación .................................................................................................71
Figura 15. Diseño de la Pantalla Menú Principal ...................................................................72
Figura 16. Diseño de la Pantalla Lista de Funcionalidades................................................72
Figura 17. Diseño en Tablet de Menú Principal – Lista de Funcionalidades ..............73
Figura 18. Diseño de la Pantalla Menú Checklists .................................................................74
Figura 19. Diseño de la Pantalla Checklist Actual .................................................................74
Figura 20. Diseño en Tablet de Menú Checklists - Checklist Actual ...............................75
Figura 21. Diseño de la Pantalla Ajustes ...................................................................................76
Figura 22. Diagrama de Actividad - Mostrar Listas ..............................................................77
Figura 23. Diagrama de Actividad - Mostrar Checklist........................................................77
Figura 24. Diagrama de Actividad - Usar Checklist ..............................................................78
Figura 25. Diagrama de Actividad - Usar Checklist Emergencia .....................................79
Figura 26. Diagrama de Actividad - Borrar Checklists Completadas .............................80
Figura 27. Diagrama de Actividad - Borrar Ítems Completados......................................80
Figura 28. Diagrama de Clases - Clase PlaneChecklists.......................................................81
Figura 29. Diagrama de Clases - Clase Checklist ....................................................................82
Figura 30. Diagrama de Clases - Clase CheckCompletas .....................................................83
Figura 31. Prototipo de Archivo XML de Avión ......................................................................84
Figura 32. Layout Principal main.xml ........................................................................................86
Figura 33. Layout Principal checklist_main.xml ....................................................................87
Figura 34. Código catActivity.java. onCreate() - Implementación del Spinner ..........87
Figura 35. Código CheckActivity.java. onCreate() - Implementación de Pestañas ...88
Figura 36. Icono Checklist de Emergencia ...............................................................................88
Figura 37. Relación Activities-Fragments ................................................................................92
Figura 38. Método onActivityCreated() de BookNormTab.java ......................................98
7
Figura 39. Método checkSavedItems() de CheckDetail.java .............................................99
Figura 40. Captura Móvil - Menú Principal ........................................................................... 111
Figura 41. Captura Móvil - Menú Categorías ........................................................................ 111
Figura 42. Captura Tablet - Menú Principal. ........................................................................ 112
Figura 43. Captura Móvil - Menú Categoría (Spinner Desplegado) (Portrait) ........ 112
Figura 44. Captura Móvil - Menú Principal (Landscape) ................................................. 112
Figura 45. Captura Tablet - Menú Principal (Portrait) ..................................................... 113
Figura 46. Captura Tablet - Menú Ajustes - Cambiar Avión (Portrait) ...................... 113
Figura 47. Captura Móvil - Menú Ajustes .............................................................................. 114
Figura 48. Captura Móvil - Menú Ajustes - Reiniciar Sesión .......................................... 114
Figura 49. Captura Móvil - Función Checklists - Lista de Checklists. .......................... 115
Figura 50. Captura Móvil - Función Checklists - Ítems de Checklist. .......................... 115
Figura 51. Captura Tablet - Función Checklists. ................................................................. 116
Figura 52. Captura Móvil - Función Checklists - Reiniciar Checklists ........................ 117
Figura 53. Captura Móvil - Función Checklists - Reiniciar Checklist Actual ............ 117
Figura 54. Captura Tablet - Función Checklists - Opciones de Borrado .................... 117
Figura 55. Captura Tablet - Función Checklists - Confirmación de Borrado ........... 117
8
IÍ ndice de Cuadros
Cuadro 1. Descripción de Tareas .................................................................................................36
Cuadro 2. Estimación de Horas por Tarea ...............................................................................38
Cuadro 3. Desvío de Tiempo de Tareas .....................................................................................42
Cuadro 4. Modelo de Descripción de Caso de Uso ................................................................43
Cuadro 5. Modelo de Descripción de Requisito de Datos ...................................................44
Cuadro 6. Modelo de Descripción de Requisito No Funcional .........................................44
Cuadro 7. Modelo de Descripción de Actor..............................................................................44
Cuadro 8. Actor Piloto. .....................................................................................................................46
Cuadro 9. Actor Lector PDF ...........................................................................................................46
Cuadro 10. Actor Servidor Meteo ................................................................................................46
Cuadro 11. Actor Sensores Movimiento....................................................................................46
Cuadro 12. Actor Sensor GPS ........................................................................................................46
Cuadro 13. Req.Datos DAP01 - Avión Seleccionado .............................................................47
Cuadro 14. Req.Datos DAP02 - Estaciones METAR ..............................................................47
Cuadro 15. Req.Datos DAP03 - Notas Guardadas..................................................................47
Cuadro 16. Req.Datos DAP04 - Último VOR ............................................................................47
Cuadro 17. Req.Datos DST01 - Checklists Completadas .....................................................48
Cuadro 18. Req.Datos DST02 - Ìtems Completados..............................................................48
Cuadro 19. Req.Datos DST03 - Último METAR.......................................................................48
Cuadro 20. Req.Datos DST04 - Información FPL ...................................................................48
Cuadro 21. Req.Datos DST05 - Datos Mass & Balance ........................................................49
Cuadro 22. Req.Datos DST06 - Último VOR .............................................................................49
Cuadro 23. Req.Datos DST07 - Última Nota ............................................................................49
Cuadro 24. Req.Datos DST08 - Hora Inicio Vuelo .................................................................49
Cuadro 25. Req.Datos DES01 - Archivo XML del Avión.......................................................50
Cuadro 26. Req.Datos DES02 - Checklists ................................................................................50
Cuadro 27. Req.Datos DES03 - Datos de Mass & Balance...................................................50
Cuadro 28. Req.Datos DES04 - Datos Generales del Avión ................................................50
Cuadro 29. Req.Datos DES05 - Base de Datos VOR...............................................................51
Cuadro 30. Req.Datos DES06 - Archivos XML de FPL's.......................................................51
Cuadro 31. Req.Datos DES07 - Carpeta de Fichas PDF .......................................................51
Cuadro 32. Req.No Funcional RNF01 - Sistema Operativo Mínimo ...............................52
Cuadro 33. Req.No Funcional RNF02 - Interfaz basado en Patrones Google .............52
Cuadro 34. Req.No Funcional RNF03 - Interfaz funcional en Tablets ...........................52
Cuadro 35. Req.No Funcional RNF04 - Facilidad de uso en Vuelo..................................52
Cuadro 36. Req.No Funcional RNF05 - Uso de Recursos ....................................................52
Cuadro 37. Req.No Funcional RNF06 - Código Ordenado ..................................................52
Cuadro 38. Req.No Funcional RNF07 - Cambio de Idioma ................................................53
9
Cuadro 39. Req.No Funcional RNF08 - Reinicio de la Aplcicación .................................53
Cuadro 40. Req.No Funcional RNF09 - Cambio de Avión ...................................................53
Cuadro 41. Caso de Uso PA01 - Mostrar Lista Ítems ............................................................54
Cuadro 42. Caso de Uso PA02 - Marcar Checklist Leídas ...................................................54
Cuadro 43. Caso de Uso PA03 - Usar una Checklist ..............................................................55
Cuadro 44. Caso de Uso PA04 - Ver Ficha Aeropuerto ........................................................56
Cuadro 45. Caso de Uso PA05 - Ver METAR TAF ...................................................................57
Cuadro 46. Caso de Uso PA06 - Rellenar FPL ..........................................................................58
Cuadro 47. Caso de Uso PA07 - Calcula Mass & Balance ....................................................59
Cuadro 48. Caso de Uso PA08 - Añadir Estación Aeropuerto ...........................................59
Cuadro 49. Caso de Uso NV01 - Calcular Posición VOR ......................................................61
Cuadro 50. Caso de Uso NV02 - Cambiar Frecuencia ...........................................................61
Cuadro 51. Caso de Uso NV03 - Usar HSI..................................................................................62
Cuadro 52. Caso de Uso NV04 - Calcular Espera....................................................................62
Cuadro 53. Caso de Uso NV05 - Calcular Interceptación ....................................................63
Cuadro 54. Caso de Uso NV06 - Calcular Punto a Punto .....................................................63
Cuadro 55. Caso de Uso NV07 - Calcular Arco ........................................................................64
Cuadro 56. Caso de Uso NV08 - Ver Instrumentos de Stand-By ......................................65
Cuadro 57. Caso de Uso UT01 - Mostrar Nota ........................................................................66
Cuadro 58. Caso de Uso UT02 - Crear Nota .............................................................................66
Cuadro 59. Caso de Uso UT03 - Borrar Nota ...........................................................................67
Cuadro 60. Caso de Uso UT04 - Convertir Unidades ............................................................67
Cuadro 61. Caso de Uso UT05 - Calcular Datos del Aire .....................................................68
Cuadro 62. Caso de Uso UT06 - Calcular Combustible ........................................................69
Cuadro 63. Caso de Uso UT07 - Usar Cronómetro ................................................................70
Cuadro 64. Caso de Uso UT08 - Ver Información de Vuelo ...............................................70
10
Capı́tulo 1:
Introducció n
1.1 Motivación del Proyecto
En la última década, los dispositivos móviles han sufrido un gran cambio. Han
pasado de ser meros teléfonos portátiles que apenas permitían hablar y enviar
mensajes a convertirse en auténticos ordenadores de mano, donde pueden realizarse
casi cualquier tipo de tarea computable.
Debido a estos avances, la industria del software se ha visto totalmente
desplazada hacia estos nuevos dispositivos. Gracias a las facilidades que se dan para
desarrollar en estas plataformas se ha conseguido que, sin tener un respaldo de una
compañía, un estudiante o recién titulado pueda ser capaz de desarrollar aplicaciones
que ayuden a estos a recopilar experiencia e incluso triunfar en la plataforma.
Con este panorama resulta muy atractivo realizar un proyecto basado en esta
tecnología. Aprovechando la necesidad de realizar un proyecto final de carrera hemos
buscado que éste, además de para desarrollar una aplicación que cumpla las
necesidades de un sector, pueda servirnos como aprendizaje de esta nueva plataforma
y sea el precursor de un estudio mucho más profundo que permita aprovechar todo el
potencial que esta tecnología pone a nuestro alcance.
En este caso la aplicación que queremos realizar intenta suplir las necesidades que
un piloto de aviación ligera (avionetas, ultraligeros, planeadores,…) puedan ser
cubiertas, en la medida de lo posible, por un dispositivo móvil.
1.2 Necesidades del Proyecto
Antecedentes
En el día a día de un piloto la cantidad de documentación, listas de chequeo,
reglas de cálculo, datos de aeropuertos, conocimientos de navegación y demás es
ingente. Estas hacen que la atención del piloto pueda pasar, de controlar el avión, a
basarse en la búsqueda, cálculo o anotación a papel de lo requerido en ese momento,
ya sea por necesidad propia o por petición del controlador.
Esa cantidad de información que hay que llevar encima se suele intentar llevar lo
más ordenada posible, pero la experiencia nos dice que en el transcurso del vuelo,
debido al estrés de ciertos momentos, se puede llegar a traspapelar resultando al final
en un montón de papeles sueltos y desordenados.
11
Hasta ahora, la mejor forma de evitar que esto ocurriese era mediante un
piernógrafo (kneeboard en inglés, ver Figura 1. Piernógrafo, Checklists y CR-3), que es
un archivador que se ata a la pierna y contiene departamentos para guardar
documentos y está provisto de una plancha de aluminio que permite escribir en él.
Éste, sin embargo, sigue sin conseguir que todo quede en su sitio y siempre cuesta
mucho tiempo conseguir el papel que se necesita en un momento dado.
Otra dificultad que tienen los pilotos se centra en el seguimiento de las llamadas
Checklists (listas de chequeo, ver Figura 1). Éstas son una serie de listas, basadas en las
distintas partes de un vuelo (inspección pre-vuelo, arranque, rodaje, post despegue,…)
que contienen los puntos vitales que deben realizarse. El problema que presentan
estas es que, en papel es difícil tener constancia de qué ítems se han realizado y qué
ítems no (como ejemplo, este fue uno de los eslabones que condujeron al accidente
del Spanair en el Aeropuerto de Barajas en 2008) [1]
Otro tipo de entretenimiento que puede sufrir un piloto es en el cálculo de datos,
ya sea conversiones, cálculos de velocidad, altitud, rumbos,… que requieren tiempo y
concentración para realizarlos. Hasta ahora la herramienta más útil que ha servido a
esta necesidad era el Computador de datos CR-3(ver Figura 1), que no es más que una
regla circular que permite cálculos gracias a los distintos diales milimetrados que
contiene. El problema que tiene este, es que es difícil ser preciso, pues un pequeño
desvío entre los diales produce errores significativos (es difícil usarlo en condiciones de
turbulencia, por ejemplo). Por otra parte, para la correcta realización de
procedimientos de navegación que requieren cálculo de rumbos solo existen algunas
reglas mnemotécnicas o el uso de “chuletas” en el piernógrafo.
Figura 1. Piernógrafo, Checklists y CR-3 respectivamente
También puede llegar a darse el caso, aunque extremo, de quedarse sin algún tipo
de instrumentación en el avión, ya sean indicaciones de vuelo (altitud, velocidad,
actitud y rumbo) o de navegación (posición respecto radiobalizas, distancias a
estaciones, etc.) dejando al piloto totalmente indefenso. La única baza que queda es la
experiencia propia y la limitada ayuda de los controladores.
Solución
Una vez conocemos las necesidades podemos determinar qué debería
implementar la aplicación final:
•
Un sistema que contenga de forma ordenada la documentación de vuelo,
tal como fichas de aeropuerto, planes de vuelo, Información
12
•
•
•
Meteorológica, datos recogidos por el piloto, información sobre el vuelo,
etc.
Una parte que ayude al piloto a realizar las listas de chequeo de forma
segura, que impida que se pueda saltar un ítem y que guarde una relación
de listas e ítems realizados.
Una serie de ayudas para el cálculo de velocidades, rumbos, combustible,
carga y centrado, monitorización de procedimientos de navegación, etc.
Un sistema que supla la falta de alguno de los instrumentos de vuelo y otro
que imite el funcionamiento del sistema de navegación por radiobalizas
(limitados estos a los sensores que tiene un dispositivo móvil hoy en día).
1.3 Contexto
Como hemos mencionado en la introducción, los dispositivos móviles tienen gran
acogida hoy en día. Esto ha propiciado que haya distintas opciones a la hora de elegir
el sistema en el que desarrollar.
Principalmente hay 3 sistemas distintos:
En primer lugar, iOS, propiedad de Apple. Se trata de un sistema cerrado por el
que solo se te brinda un kit de desarrollo, se te obliga a seguir ciertas pautas de
funcionamiento y ante la posibilidad de publicar la aplicación en el mercado Apple te
exige muchos requisitos. Por otra parte los usuarios de iOS tienen más probabilidades
de pagar por una aplicación, asé que si el objetivo es puramente económico esta es la
opción más segura.
En segundo lugar, está el recién salido Windows 8 de Microsoft. El principal
problema es que apenas tiene el 5% de cuota de los dispositivos móviles. Como Apple,
es un sistema cerrado y solo se te permite desarrollar usando el kit que te ofrecen. En
cuanto a la posibilidad de subir la aplicación en su mercado es más fácil que Apple. Su
interfaz gráfica es muy atractiva, por lo que podría ser un sistema que tener presente
en los próximos años.
Finalmente se encuentra Android propiedad de Google entre otras. Su principal
ventaja es que es open source casi en su totalidad, así que no solo te limitan al kit de
desarrollo que te proporcionan, sino que en teoría es posible añadir funcionalidades al
sistema operativo que te permitan realizar acciones que el kit no te ofrece. Otra
ventaja es su acogida, al ser libre se monta en infinidad de dispositivos, de distinta
marca y de distintos tipos (desde tabletas, a teléfonos, televisores e incluso relojes…).
Esto permite que existan dispositivos de todas las gamas y por tanto el número de
usuarios sea el mayor de los 3. Además, la total libertad del mercado oficial permite
que, en el caso de colocar una aplicación en él, tenga gran probabilidad de ser bajado
por los usuarios. Como inconveniente tiene que, si el interés es económico, el perfil de
usuario de Android prefiere las aplicaciones gratuitas, y también existe la posibilidad
13
de que puedan ser “crackeados” y se puedan bajar en mercados alternativos de forma
gratuita.
Como nuestra finalidad es mantener el código de nuestra aplicación abierto,
Android parece la opción más apropiada para este proyecto y por ello nuestra
aplicación será desarrollada para Android.
1.4 Objetivos del Proyecto
Dado que las necesidades del proyecto son ingentes y los créditos de la asignatura
marcan una duración de proyecto sobre las 200 horas de trabajo, no será posible
realizar una aplicación que cubra todas las necesidades antes mencionadas. Por lo
tanto, decidimos acotar el proyecto de forma que diseñaremos todo el conjunto pero
solo implementaremos el apartado de Checklists.
Así pues, los objetivos del Proyecto fin de Carrera son:
•
Aprender las bases y el funcionamiento del sistema Android con la finalidad
de poder desarrollar la aplicación deseada.
•
Realizar un Análisis del funcionamiento de una aplicación que supla las
necesidades antes mencionadas sin perjuicio de diseñar e implementar
ninguna parte. Se tendrá la prioridad de modular el sistema para reutilizar
funcionalidades similares.
•
Diseñar un Interfaz de usuario que sea fácil de usar en vuelo. Debido al
entorno en el que se encuentra un piloto se tendrá que hacer hincapié en
conseguir que la aplicación sea muy intuitiva y fácil de usar.
•
Diseñar e Implementar una aplicación Android que ayude al uso de
Checklists. Esta permitirá al piloto hacer uso de estas de una forma segura y
ordenada. Este comprenderá el objetivo principal del proyecto
1.5 Palabras Clave
Android, Dispositivo Móvil, Aviación Ligera, Checklist, XML.
14
Capı́tulo 2:
Estudio Previo: El sistema Android
En este capítulo se aborda el estudio sobre el sistema operativo Android.
Contando su historia, sus principios, arquitectura, funcionamiento y diseño de interfaz.
2.1 Qué es Android
Android es un sistema operativo basado en Linux. Está enfocado para ser utilizado
en dispositivos como smartphones, tabletas, televisiones, relojes… Lo desarrolla la
Open Handset Alliance, liderada por Google.
Tiene una gran comunidad de desarrolladores escribiendo aplicaciones. A la fecha,
se han sobrepasado las 850.000 aplicaciones disponibles (de las cuales, dos tercios son
gratuitas) en la tienda de aplicaciones oficial de Android: Google Play. Existe la
posibilidad de obtener software de terceras tiendas o bien externamente.
El desarrollo de aplicaciones se realiza en entornos IDE como Eclipse pero se
necesita un Kit de desarrollo que proporciona Google que, además del plug-in de
Eclipse y una extensa documentación, contiene también un emulador que te permite
probar tus aplicaciones sin disponer de un dispositivo físico.
Los programas se escriben en Java. No obstante, no se trata de una versión oficial
de Java ya que no incluye todos los paquetes. También existe la posibilidad de escribir
ciertas rutinas en C++, aunque se destina al desarrollo de librerías o funcionalidades
que requieran mucha potencia de computación.
Historia [2]
En julio de 2006, Google adquirió Android Inc., una pequeña compañía de
California fundada en 2003. En aquel entonces, poco se sabía de las funciones de
Android fuera de que desarrollaban software para teléfonos móviles. Esto dio pie a
rumores de que Google estaba planeando entrar en el mercado de los teléfonos
móviles.
En Google, un equipo desarrolló una plataforma para dispositivos móviles basada
en el núcleo Linux que fue promocionado a fabricantes de dispositivos y operadores
con la promesa de proveer un sistema flexible y actualizable. Se informó que Google
había alineado ya una serie de fabricantes de hardware y software y señaló a los
operadores que estaba abierto a diversos grados de cooperación por su parte.
La especulación sobre que el sistema Android de Google entraría en el mercado
de la telefonía móvil se incrementó en diciembre de 2006. Diversos medios señalaron
15
que Google quería sus servicios de búsqueda y aplicaciones en teléfonos móviles y
estaba muy empeñado en ello. Los medios pronto reportaron que Google estaba
desarrollando un teléfono con su marca.
En septiembre de 2007, se difundió un estudio de Evalueserve que reportaba que
Google había solicitado diversas patentes en el área de la telefonía móvil.
El anuncio del sistema Android se realizó el 5 de noviembre de 2007 junto con la
creación de la Open Handset Alliance, un consorcio de compañías de hardware,
software y telecomunicaciones dedicadas al desarrollo de estándares abiertos para
dispositivos móviles. Google liberó la mayoría del código de Android bajo la licencia
Apache, una licencia libre y de código abierto.
A partir de entonces Android ha ido evolucionando en versiones, a razón de una
por año como media. Ha aumentado su cuota de mercado hasta ser el sistema más
extendido a nivel mundial entre smartphones. A día de hoy la versión más reciente
publicada es 4.2 alias Jelly Bean.
Curiosidades
El nombre de Android (así como el nombre de los dispositivos Google; Nexus)
proviene de la novela Sueñan los androides con ovejas eléctricas? de Phillip K. Dick.
que fue llevada al cine como Blade Runner.
Cada versión de Android lleva un nombre en clave siguiendo un orden alfabético.
Los nombres son todos postres típicos americanos. (Cupcake, Donut, Ecclair, Frozen
Yoghurt, Ginger Bread, HoneyComb, Ice Cream Sandwich, Jelly Bean, Key Lime Pie...).
El androide verde que se usa como logotipo se llama Andy.
2.2 Características Técnicas
Datos obtenidos de Wikipedia [2]:
Diseño de dispositivo: La plataforma es adaptable a pantallas de mayor resolución,
VGA, biblioteca de gráficos 2D, biblioteca de gráficos 3D basada en las
especificaciones de la OpenGL ES 2.0 y diseño de teléfonos tradicionales.
Almacenamiento: SQLite y XML.
Conectividad: GSM/EDGE, IDEN, CDMA, EV-DO, UMTS, Bluetooth, Wi-Fi, LTE, HSDPA,
HSPA+ y WiMAX.
Mensajería: SMS, MMS y Android Cloud to Device Messaging Framework (C2DM),
parte del servicio de Push Messaging de Android.
16
Navegador web: El navegador web incluido en Android está basado en el motor de
renderizado de código abierto WebKit, emparejado con el motor JavaScript V8 de
Google Chrome.
Soporte de Java: Aunque la mayoría de las aplicaciones están escritas en Java, no hay
una máquina virtual Java en la plataforma. El soporte para J2ME puede ser
agregado mediante aplicaciones de terceros como el J2ME MIDP Runner
Soporte multimedia: WebM, H.263, H.264 (en 3GP o MP4), MPEG-4 SP, AMR, AMRWB (en un contenedor 3GP), AAC, HE-AAC (en contenedores MP4 o 3GP), MP3,
MIDI, Ogg Vorbis, WAV, JPEG, PNG, GIF y BMP.
Soporte para streaming: Streaming RTP/RTSP (3GPP PSS, ISMA), descarga progresiva
de HTML (HTML5 <video> tag), Adobe Flash Streaming (RTMP) (soportado
mediante el Adobe Flash Player).
Soporte para hardware adicional: Android soporta cámaras de fotos, de vídeo,
pantallas táctiles, GPS, acelerómetros, giroscopios, magnetómetros, sensores de
proximidad y de presión,, sensores de luz, gamepads, termómetro, aceleración
por GPU 2D y 3D.
Entorno de desarrollo: El kit de desarrollo Incluye un emulador de dispositivos,
herramientas para depuración de memoria y análisis del rendimiento del
software. El entorno de desarrollo integrado es Eclipse usando el plugin de
Herramientas de Desarrollo de Android.
Google Play: Es un catálogo de aplicaciones gratuitas o de pago en el que pueden ser
descargadas e instaladas en dispositivos Android sin la necesidad de un PC.
Multi-táctil: Soporte nativo para pantallas capacitivas con soporte multi-táctil.
Bluetooth: Soporte para A2DF y AVRCP, envío de archivos (OPP), exploración del
directorio telefónico, marcado por voz y envío de contactos entre teléfonos.
Videollamada: Soportada a través de Google Talk o Aplicaciones de terceros.
Multitarea: Multitarea real de aplicaciones está disponible, a diferencia de otros
sistemas en la que la multitarea es congelada (Como por ejemplo iOS, en el que la
multitarea se limita a servicios internos del sistema y no a aplicaciones externas).
Características basadas en voz: La búsqueda en Google a través de voz está disponible
como "Entrada de Búsqueda" desde la versión inicial del sistema.
Tethering: Soporta tethering, que permite al teléfono ser usado como un punto de
acceso alámbrico o inalámbrico.
17
2.3 Arquitectura del Sistema
La estructura del sistema operativo Android se compone de aplicaciones que
utilizan un framework a través de APIs. En este existen una serie de librerías Java que
se ejecutan en una máquina virtual (Dalvik) en traducción dinámica (JiT).
Tanto la Maquina Dalvik como algunos componentes del Framework acceden a las
librerías nativas, escritas en C o C++, mediante un interfaz llamado JNI (Java Native
Interface).
Estas librerías nativas acceden al kernel de Linux a través de una capa de abstracción
Hardware (HAL) para usar las funcionalidades de los drivers de los dispositivos
necesarios.
En la siguiente figura (Figura 2) se puede ver la estructura de Android.
Figura 2. Esquema de la Arquitectura de Android [3]
Podemos resaltar:
Aplicaciones: Las aplicaciones base incluyen un cliente de email, programa de SMS,
calendario, mapas, navegador, contactos, etc. Es aquí donde se colocan las
aplicaciones desarrolladas por terceros. Todas las aplicaciones están escritas en
Java y tienen la misma prioridad unas sobre otras.
18
Framework de aplicaciones: Los desarrolladores tienen acceso completo a las API’s del
framework usado por las aplicaciones. La arquitectura está diseñada para
simplificar la reutilización de componentes; cualquier aplicación puede publicar
sus capacidades y cualquier otra aplicación puede luego hacer uso de ellas (sujeto
a reglas de seguridad). Éste mismo mecanismo permite que los componentes sean
remplazados por el usuario. Este framework está formado, entre muchas otras,
por:
•
•
•
•
•
•
Un extenso conjunto de Vistas tales como listas, cajas de texto, botones…
Content Providers: Permiten a las aplicaciones acceder a información de
otras aplicaciones o compartir su propia información.
Resource Manager: Proporciona acceso a recursos que no son código
como pueden ser gráficos, cadenas de texto, imágenes…
Notification Manager: Permite a las aplicaciones mostrar alarmas
personalizadas en la barra de estado.
Activity Manager: Gestiona el ciclo de vida de las aplicaciones.
…
Librerías Nativas: Android incluye un set de librerías C/C++ usadas por varios
componentes del sistema. Éstas se exponen a través del framework de
aplicaciones de Android. También el Runtime de Android interactúa con las
librerías mediante el JNI (Java Native Interface). Algunas son: System C library
(implementación librería C estándar), librerías de medios, librerías de gráficos,
OpenGL ES, SQLite, entre otras.
Runtime de Android: Android incluye un set de librerías base que proveen la mayor
parte de las funcionalidades disponibles en Java. Cada aplicación Android corre su
propio proceso, con su propia instancia de la máquina virtual Dalvik.
Dalvik es una Máquina Virtual Java específicamente diseñada para Android y
dispositivos móviles. Su objetivo, aparte de ejecutar la aplicación Java, es
tener en cuenta el uso de recursos, memoria y batería; cosas que en un
dispositivo móvil son limitadas. Ha sido escrito de forma que un dispositivo
pueda correr múltiples máquinas virtuales de forma eficiente.
HAL (Hardware Abstraction Layer): Aunque su traducción es capa de Abstracción de
Hardware no es una capa estanca en sí. Esta está integrada en parte en las
librerías nativas y parte en el kernel. Facilita la comunicación entre los
componentes y las librerías. La desarrolla Google para un dispositivo inicial y luego
cada fabricante la modifica para hacerla compatible con sus dispositivos. En las
últimas versiones de Android se ha mejorado este apartado.
Kernel Linux: Android depende del núcleo Linux 2.6 para los servicios básicos del
sistema como: seguridad, gestión de memoria, gestión de procesos, pila de red y
modelo de drivers.
19
2.4 Almacenamiento de Datos
En aplicaciones de escritorio, el sistema operativo ofrece el sistema de ficheros
para guardar o compartir datos entre aplicaciones. En Android, los ficheros son
privados por aplicación, es decir, solo la aplicación que crea estos datos o para la cual
existen pueden usarlos. Esto soluciona las dependencias que cualquier aplicación en
Android pueda tener con otra pero tiene como inconveniente que no hay compartición
de datos de forma inmediata. Para evitar este inconveniente se provee (desde el
framework de aplicaciones) el llamado Content Provider (ver más adelante).
Android tiene 3 tipos de almacenamiento de datos:
Preferences: Es la forma más rápida y sencilla de guardar datos simples. Estos se
guardan en pares (llave/valor) y se almacenan en la memoria interna del
dispositivo hasta que son modificadas por el usuario. Quiere decir que ante el
cierre de una aplicación estos no se perderán.
Entre los datos que se pueden guardar tenemos: Boolean, Float, Strings, etc.
Local Files: Esta forma es similar al almacenamiento de datos de un escritorio Linux
estándar, con la salvedad de que solo la aplicación en desarrollo tendrá acceso a
estos. Para acceder o crear los archivos se usan Streams como en Java y, aunque
por defecto se guardan en la memoria interna existe la posibilidad de hacerlo en
la externa (Tarjeta SD). Aquí, por supuesto puede haber cualquier tipo de archivo;
Texto llano, XML, HTML, propios...
Database: Consiste en una implementación de bases de datos SQL llamada SQLite. Es
soportada nativamente por Android y tiene como ventaja que es ligera y no
requiere recursos excesivos. La forma de compartir estas es a través de Content
Providers.
20
2.5 Estructura de una Aplicación
Una aplicación en Android se puede definir como un programa escrito en Java que
utiliza el framework de aplicaciones a través del SDK (Software Development Kit) para
satisfacer las necesidades de un usuario mediante el uso de una interfaz gráfica que se
puede componer de distintas vistas y sub programas.
Cada aplicación tiene:
• Una instancia propia de la máquina virtual Dalvik
• Por tanto, su propio espacio de memoria.
• Un proceso de Linux asociado exclusivamente a ella.
• Un ID de usuario de Linux asignado (el cual es el único que tiene
permisos para acceder a los datos de esta)
• Una aplicación puede tener 2 threads (el principal (donde se gestiona la
UI y otro opcional para operaciones más costosas)
Google ha optado por una modularización de las aplicaciones, por lo que estas se
dividen en distintos componentes que, según el ámbito del objetivo de la aplicación a
desarrollar, hará uso de ellos o no. A continuación se nombran los más importantes:
Activity
Es el elemento constituyente de Android más común. Básicamente define
una pantalla (su UI) en el dispositivo y le da funcionalidad. Para implementarla se
utiliza una extensión de la clase Activity (una por cada Actividad). Cada clase
mostrará una interfaz de usuario, compuesta por Views (los distintos tipos de
componentes de un interfaz gráfico). Cada vez que se cambia de pantalla (Vista),
se cambia de Actividad. Cuando cambiamos de Vista, la anterior queda pausada y
puesta dentro de una pila de actividades para poder retornar en caso necesario.
Para pasar de vista en vista, Android utiliza los Intents.
En las últimas versiones de Android (a partir de 4.0 Ice Cream Sandwich) se ha
añadido otro componente llamado Fragment que vive dentro de una Activity. Se
comporta igual que una actividad (en el sentido de tener una View,
comportamiento y ciclo de vida propios), pero al estar anidada dentro de una
Activity consigue que el número de Activities de la aplicación sea menor y se usa
para tener distintas Interfaces gráficas en una misma pantalla (pensando en las
tablets).Para más información sobre este componente ver Android Developers [4].
Intent
Es un mecanismo para el paso de mensajes. Declara la intención de realizar
una acción. Se utilizan para iniciar Activities o para comunicarse entre ellas. Las
dos partes más importantes de un Intent son la acción que se quiere realizar y la
información necesaria que se proporciona para poder realizarla ya sea en formato
URI o mediante extras (pueden contener cualquier tipo de variable o una clase
que implemente Parcelable [4]).
21
Intent Filter
Es una descripción de qué Intents puede gestionar una Actividad. Mediante
los Intent Filters, el sistema puede resolver Intents que una aplicación pide,
buscando cuales posee cada actividad y escogiendo aquel que mejor se ajuste a
sus necesidades. El proceso de resolver Intents se realiza en tiempo real, lo cual
ofrece dos beneficios:
•
•
Las actividades pueden reutilizar funcionalidades de otros
componentes haciendo peticiones mediante un Intent.
Las actividades pueden ser remplazadas por nuevas actividades con
los mismos Intent Filters (siguiendo el principio de igualdad entre
aplicaciones).
Service
Es un componente que se ejecuta durante un largo periodo y que no tiene UI,
por lo que se ejecuta de forma transparente. Por ejemplo un reproductor de
música que reproduce una canción sin que el usuario, por el hecho de abrir una
nueva vista, el reproductor se interrumpa.
Content Provider
Como hemos mencionado antes, Android tiene la capacidad de manejar
Bases de datos con SQLite pero las aplicaciones externas no pueden acceder a
estas BBDD. En caso de querer compartir dicha información con otras aplicaciones
se utiliza un Content Provider. Un Content Provider es, por tanto, un componente
que permite a otras aplicaciones guardar y obtener la información que maneja
dicho Content Provider.
Broadcast Receiver
Es otro componente que se puede implementar en una aplicación. Realiza
una acción ante un mensaje de difusión del sistema (Intent Broadcast). Carece de
UI aunque puede mostrarse a través de la barra de estado (Notification Manager).
Atiende a las señales que se hayan especificado en su Intent Filter. Ejemplos de
Intent Broadcasts son: Recepción de una llamada, aviso de batería baja,
activación/desactivación del Wifi/Bluetooth,…
22
2.6 Ciclo de Vida de una Activity
Como anteriormente hemos nombrado (Punto 2.5), cada aplicación de Android
corre en su propio proceso que se crea cuando se ejecuta por primera vez y
permanece en memoria hasta que la aplicación deja de trabajar o el sistema necesita
memoria para otras aplicaciones.
Una característica peculiar en Android es que el ciclo de vida de una Activity no lo
controla la aplicación sino que lo determina el sistema, mediante el Activity Manager,
a partir de una serie de condiciones como son: aplicaciones que están funcionando en
ese momento, prioridad que tienen para el usuario y memoria disponible en el
sistema. Así Android sitúa cada proceso en distintos estados basándose en las
condiciones anteriores.
Dentro del proceso de una aplicación pueden existir varias Activities, pero el
estado del proceso depende de la que esté activa, de forma que, podemos relacionar
el estado de la Activity (Starting, Running, Paused, Stopped y Destroyed) con el estado
del proceso (Foreground, Visible, Background y Empty).
Los estados posibles Activity (Proceso) son:
Running (Foreground Process): El estado que tiene la Activity cuando está en primer
plano, es decir, se muestra su UI en la pantalla y el usuario puede interactuar con
ella. El sistema deja como última opción a eliminar en caso de falta de memoria.
Paused (Visible Process): En este estado la aplicación está visible pero alguna instancia
ha aparecido delante de ella requiriendo la atención del usuario y dejando
congelada la UI de la aplicación principal. Un ejemplo típico es la ventana de
diálogo (pidiendo una confirmación), esta pasa a estar en Running y la aplicación
principal pasa a Paused.
El sistema solo eliminaría un Visible Process si no tuviera recursos suficientes para
mantener el proceso activo en ese momento.
Stopped (Background Process): Estado en el que se encuentra una aplicación cuando
deja de estar visible al usuario. Ocurre cuando se cambia entre distintas
aplicaciones; la aplicación se para y se guarda en una pila para poder volver a ella
posteriormente. El sistema ante la necesidad de recursos elimina en primera
instancia las Activities que se hallan dentro en esta cola.
Starting/Destroyed (Empty Process): Es un proceso que no aloja ningún componente.
La razón de existir de este proceso es tener una cache disponible de la aplicación
para su próxima activación. Se crea la primera vez que se ejecuta la aplicación. Es
común que el sistema elimine este tipo de procesos con frecuencia para obtener
recursos.
23
Para el desarrollador, la forma de saber en qué estado se encuentra una Activity
se realiza mediante la sobrecarga de una serie de métodos que el sistema llama
cuando cambia entre estados.
Figura 3. Ciclo de Vida de Activity [5]
En esta figura (Figura 3) podemos diferenciar 3 periodos (lifetime) en la vida de
una Activity:
•
•
•
Entire Lifetime: Es la vida completa de la aplicación desde que se crea
hasta que se destruye. La determinan onCreate() y onDestroy().
Visible Lifetime: Es el periodo de vida de una Activity donde la aplicación
es visible pero no activa. Determinada por onStart() y onStop()
Foreground Lifetime: La parte de vida en la que la Activity es visible y
activa. Lo determina onResume() y onPause().
24
2.7 Resources
Los recursos (Resources) en Android son archivos externos que no son código y que
son usados e incluidos dentro de la aplicación. Android soporta distintos tipos de
recursos como imágenes, textos, layouts, audio, videos…
Estos recursos se organizan por carpetas según el tipo de recurso que representan.
Entre los más importantes se encuentran:
•
•
•
•
•
•
Drawable: Imágenes, Iconos…
Layout: Organización de los interfaces gráficos de usuario (en XML)
Values: Textos, colores, dimensiones, estilos, ... (en XML)
Menú: Menús y diálogo (en XML)
XML: Resto de archivos XML que no soporta nativamente Android.
Raw: Recursos que se copian en la aplicación sin un proceso previo
Los ficheros XML se compilan dentro un archivo binario por razones de eficiencia y
los strings se comprimen en una forma más eficiente de almacenamiento. Es por esta
razón que hay diferentes tipos de recursos en Android.
2.8 Android Manifest
El Android Manifest es un archivo XML (AndroidManifest.xml) que forma parte de
una aplicación Android y que contiene aspectos principales de la aplicación, como:
•
•
•
•
•
•
Identificación (Nombre, versión, icono, paquete Java asociado,…)
Componentes (Activities, Servicios, Clases, Intent Filters…)
Permisos que necesita la aplicación para su ejecución.
Lista de librerías necesarias.
Requisitos mínimos del dispositivo.
…
25
2.9 Interfaz de Usuario
En este apartado se muestra la filosofía de diseño de Interfaces gráficos en
Android [4] y vemos los componentes más destacados.
Principios de Diseño
Durante los primeros años de Android, los desarrolladores siempre han tenido la
libertad de diseñar sus interfaces gráficos. Esto tiene el inconveniente de que cada
aplicación funciona de una manera y no existían unos patrones oficiales que seguir.
Desde el lanzamiento de Android 4.0 Ice Cream Sandwich, Google ha empezado a
promover unos patrones de diseño, que si bien no son obligatorios, sí se recomiendan
con el fin de facilitar el uso de los usuarios.
Estos patrones se basan en 3 principios dirigidos al usuario:
Enchant Me (Haz que me Encante): La aplicación debe ser atractiva, sencilla y
personalizable. Para ello recomiendan:
•
•
•
•
Dejar que el usuario pueda personalizarla.
Usar iconos en vez de botones y menus.
Usar efectos sutiles que ayuden a entender el funcionamiento
Aprender del usuario
Simplify My Life (Simplifica mi Vida): El principal objetivo de una aplicación es facilitar
al usuario una tarea. Tiene que ser intuitiva y fácil de usar. Tareas sencillas no
deben de requerir pasos complicados y las complicadas deben automatizarse
teniendo en cuenta el usuario. Se debe evitar añadir demasiadas opciones o
alertas. Estos objetivos se consiguen siguiendo:
•
•
•
•
•
•
•
•
Uso de frases cortas y directas.
Usar fotos en vez de palabras.
Evitar demasiadas preguntas. Decidir por el usuario pero dejar que tenga la
última palabra.
Mostrar sólo lo necesario y sólo cuando lo necesite.
Ayudar al usuario a saber en qué parte de la aplicación se encuentra.
Guardar opciones y recordar preferencias.
Evitar que componentes parecidos se comporten de distinta forma (If it
looks the same, it should act the same).
Sólo interrumpir al usuario si es importante.
26
Make me Amazing (Hazme increíble): Además de ser fácil de usar, debe animar al
usuario a aprender y probar nuevas formas de usar sus aplicaciones. Debe de
posibilitar al usuario el acceso a las nuevas tecnologías con claridad y elegancia.
Conceptos que pueden ayudar a este objetivo serían:
•
•
•
•
Hacer la aplicación más fácil de aprender aprovechando patrones visuales y
el comportamiento de otras aplicaciones de Android.
Evitar abrumar al usuario con palabras técnicas y no echarle la culpa cuando
hay problemas; en vez de eso indicarle instrucciones.
Permitir al usuario hacer acciones avanzadas simplificando y automatizando
el proceso.
Decidir lo más importante de cada aplicación y conseguir que sea fácil de
encontrar, fácil de usar y rápido de hacer.
Patrones de Diseño
Para conseguir los objetivos se han diseñado una serie de patrones que facilitan al
desarrollador la tarea de tener que pensar en cómo conseguirlos.
Gestos: Los gestos táctiles disponibles son:
•
•
•
•
•
•
Toque:
Toque Largo:
Deslizar:
Arrastrar:
Doble toque:
Pinzar:
Para activar la funcionalidad normal.
Activar el modo selección de datos.
Para navegar en componentes de la misma jerarquía.
Para mover componentes.
Para activar una funcionalidad secundaria.
Para hacer zoom.
Estructura del Interfaz: El interfaz debe tener 3 jerarquías:
•
•
•
Nivel Principal: En él se deben mostrar las funcionalidades que tiene la
aplicación
Vistas de Categoría: Aquí deben estar los elementos de una misma
categoría del nivel superior.
Vista Detalle: Aquí es donde se realiza la acción y el usuario consigue lo
que quiere.
Navegación: Para moverse por los menús existen (asumiendo el toque) dos botones; el
botón Back y el botón Up.
•
•
Back (Rojo): Vuelve una ventana atrás en la pila de Activities, de forma
muy parecida al botón Atrás de un navegador de Internet (Figura 4).
Up (Nanranja): Sube un nivel en la jerarquía de la aplicación. Parecido al
botón subir del Explorador de Windows (Figura 4).
27
Figura 4. Navegación en Android [4]
28
Action Bar: Es un patrón de diseño colocado en la parte de arriba de una aplicación, y
que normalmente es persistente (no desaparece en las distintas vistas):
•
•
•
Muestra la localización del usuario dentro de la aplicación y permite el
movimiento en esta.
Permite el uso de funcionalidades frecuentes de forma accesible.
Permite agrupar funciones menos frecuentes en un Action Overflow (menú
donde se agrupan funcionalidades)
Tiene una organización de elementos definida (Figura 5):
Figura 5. Componentes de Action Bar [4]
1. App Icon (Botón Up): Muestra el icono de la aplicación y sirve (aparte de
personalizar la aplicación) para indicar si el usuario se encuentra en el nivel
más alto o no de la jerarquía de la aplicación. Para ello muestra un “<”
cuando no lo está. Presionar el botón produce que el usuario suba en la
jerarquía.
2. View Control: Sirve para nombrar la Activity actual y/o para permitir
moverse por la aplicación dándole distintas funcionalidades (Spinner [lista
desplegable], Tabs [Pestañas], o Drawer [Menú Deslizable]).
3. Action Buttons: Debe mostrar las acciones más importantes para la
aplicación. El número de estos dependerá del tamaño de la pantalla del
dispositivo.
4. Action Overflow: Al presionar sobre él se muestra una lista desplegable de
elementos que no se usan tan a menudo.
El Action Bar también puede partirse en dos, con la parte superior y una en el
inferior de la pantalla para permitir más botones y para soportar distintos tipos de
dispositivos.
Multi-Pane Layout: Una de las cosas a tener en cuenta es que, debido a la gran gama
de dispositivos que existen, el interfaz se debe ajustar a multitud de tamaños y
resoluciones. Para ello se usa un DPI (Dots per Inch) base y usando dp’s (Density
Independent Pixels) se puede escalar sobre él.
Google sugiere que hay que aprovechar las pantallas grandes añadiendo
nuevas vistas en vez de solo agrandar el interfaz. Para ello existe el Multi-Pane
Layout. Es la utilización de distintos tipos de GUI dependiendo de las
características del dispositivo en el que se ejecuta la aplicación.
29
En terminales pequeños solo se mostrará una vista por pantalla, y en el caso
de disponer de una pantalla grande, las distintas vistas se colocarían una al lado
de otra:
Un móvil tendría este Layout (Figura 6):
Figura 6. Layout de una App en un móvil [4]
Una Tablet las juntaría en una sola pantalla (Figura 7):
Figura 7. Layout de una App en una Tablet [4]
También hay que tener en cuenta el cambio de orientación del dispositivo
que permite un tipo de distribución distinto. En Android te recomiendan 4 tipos
de recomposición de la pantalla:
•
Show/Hide: Sería seguir el mismo patrón que cuando se dispone de móvil
o tablet (se mostraría en apaisado ambas vistas (como la Figura 7), pero en
vertical solo se vería una (Figura 6)).
30
•
•
•
Stretch/Compress: Sencillamente estrechar o ensanchar los componentes
que existen (esto ocurre de manera automática en la mayoría de los casos)
Stack: Los componentes se redistribuyen para optimizar el cambio de
orientación.
Expand/Collapse: La vista de la izquierda mostraría solo los datos
importantes (en la Figura 7 mostraría los nombres ocultando las
imágenes).
Menú Selección: En versiones anteriores de Android (<3.0 Honeycomb) se utilizaba un
modo de selección similar al de un escritorio (mediante un menú contextual). Esto
se cambia por un menú de selección.
Al mantener presionado un ítem en una lista, el ActionBar cambia a Contextual
Action Bar (CAB) y este permite realizar acciones contextuales sobre uno o varios
ítems de la vista; como puede ser seleccionar, copiar, cortar, pegar, borrar,…
Confirmación y Acuses: Google es muy explícito en cuanto a cuándo debe ser avisado
o “molestado” el usuario durante el funcionamiento de la aplicación. Existen dos
formas de avisar a un usuario: Mediante una confirmación (Dialog), donde el
usuario debe tomar una decisión; o un acuse (Toast), donde el usuario es avisado
sobre una acción que la aplicación ha realizado.
Los patrones señalan que hay que pedir confirmación solo en casos como
(pérdida irrecuperable de datos, cargos en tarjetas, uso intensivo de Internet,
largas esperas,…)
Los casos donde hay que evitar informar al usuario son aquellos que no
aportan nada al usuario o donde existe otro tipo de feedback.
Notificaciones: El sistema de notificaciones permite a una aplicación mantener
informado al usuario sobre eventos como mensajes nuevos, citas de calendario,
etc.
Las notificaciones se muestran en la barra de estado del teléfono y se
acceden arrastrando ésta hacia abajo. Como mínimo una notificación debe
contener lo señalado en la Figura 8:
Figura 8. Layout de una Notificación [4]
31
En la última versión de Android (4.2 Jelly Bean) se han añadido
funcionalidades a las notificaciones como: Vistas Expandidas (se puede ampliar el
espacio de una notificación para que muestre más información), acciones (se le
pueden añadir botones para realizar distintas acciones) y se añade un sistema de
Prioridades (se les da a las notificaciones una prioridad en función de su
importancia).
Widgets: Son mini aplicaciones que se muestran en la pantalla principal del sistema
(Home). Se pueden implementar para cualquier aplicación, pero solo se
recomienda usar para aquellas que requieran un uso intensivo por parte de los
usuarios.
Settings (Preferencias): Es un lugar de la aplicación donde los usuarios indican sus
preferencias y cómo quieren que la aplicación se comporte.
El menú de Settings se debe encontrar dentro del Action Overflow.
Los principios de Android aconsejan evitar meter dentro de Settings
información o acciones. También ajustes que la mayoría de los usuarios no vayan
a modificar siempre y cuando esto no repercuta negativamente a las minorías que
sí lo usarán.
Si las opciones son muchas se pueden agrupar mediante divisores o mediante sub
menús. Google recomienda usar un lenguaje llano y directo, sin entrar en
tecnicismos.
Componentes Básicos
Android ofrece una serie de componentes (Views) para diseñar las Interfaces de
Usuario. Entre las más comunes están:
•
•
•
•
•
•
•
•
•
•
•
Tabs: Es una pestaña. Se alojan en la Action Bar Permite cambiar de Vistas
rápidamente. Existen dos tipos: Scrollable y Fixed.
Lists: Consiste en una lista de ítems de puestos verticalmente.
Scroll Indicator: Permite mover y saber la posición del usuario en una
interfaz cuando ésta es más grande (verticalmente) que la pantalla.
Spinners: Es una lista desplegable igual que en otros sistemas.
Buttons: Botones que realizarán una acción al ser pulsados
Text Fields: Espacio donde se permite al usuario escribir en él.
Seek Bars & Sliders: Se utilizan para seleccionar un valor contínuo o
discreto de una forma más gráfica que escribiendo el valor.
Progress Bar & Activity Circle: Muestran al usuario que el sistema está
haciendo algo que requiere tiempo en completarse.
Switches, Checkbox & RadioButton: Controles que activan o desactivan
una función, un valor individual, o un valor entre varias opciones.
Dialogs: Ventana que se muestra para solicitar algo al usuario.
Pickers: Ruleta que permite seleccionar un valor dentro de un conjunto.
Para más información sobre el UI se puede acceder a Android Developers [4]
32
2.10 Entorno de Desarrollo
Google, desde antes incluso del lanzamiento de Android, ofreció a los
desarrolladores un kit de desarrollo para facilitarles la programación. En este punto se
describe esta herramienta.
Componentes
El Entorno de desarrollo se ha diseñado para usarse utilizando IDE’s. El IDE en el
que Google recomienda programar es Eclipse por su filosofía Open Source, como por
su amplio reconocimiento entre los desarrolladores. La versión de Eclipse más
adecuada para Android es Eclipse for Mobile Developers, ya que contiene paquetes
para Java, y C/C++ en caso de necesitar programar en lenguaje nativo (se puede
descargar desde www.eclipse.org).
El siguiente componente necesario es el kit de desarrollo de Java, el Java
Development Kit que se descarga de la página oficial de Oracle (www.oracle.com). Este
contiene las librerías y API’s necesarios para programar en Java.
Por parte de Google se nos ofrece el antes mencionado Kit de desarrollo (Android
Software Development Kit) disponible desde la página de Android Developers [4].
Se compone de varias partes:
•
•
•
•
•
Paquete con todas las librerías específicas de Android, API’s y demás
archivos necesarios para poder programar una Aplicación.
SDK Manager: Un programa que ayuda a mantener las distribuciones del
Kit actualizadas.
AVD Manager: Una Máquina Virtual que simula un dispositivo Android
según los requerimientos del desarrollador.
Software para la depuración de las aplicaciones(en línea de comandos).
Drivers y software para la comunicación con dispositivos reales. (en línea
de comandos).
Por último un plug-in de Eclipse (u otras IDE’s alternativas) que ayuda en la
comunicación entre el IDE y el SDK de Android. Ayuda al desarrollador en el trabajo:
•
•
•
•
•
•
Facilitando la compilación de los proyectos.
Ofreciendo ayuda en el editor de texto rellenando campos y creando
código prefabricado.
Mostrando documentación de Android para el recurso seleccionado
Dotando de interfaces gráficas para el software de depuración.
Facilitando el uso de dispositivos físicos.
…
33
Capı́tulo 3:
Planificació n
En este capítulo realizamos una estimación de recursos materiales y humanos,
costes y una planificación temporal del proyecto para, una vez se ha finalizado el
proyecto, contrastar las diferencias con los costes y tiempos reales.
En el Anexo E se describe una planificación de todo el proyecto si se tuviese
intención de implementar todas las funcionalidades de la aplicación.
3.1 Estimación de Recursos Materiales
En este apartado consideramos recurso material a todo objeto, dispositivo,
ordenador y software necesario para la realización del proyecto.
Recursos Físicos
Ordenador de Sobremesa del alumno: Donde se realiza casi la totalidad del
proyecto exceptuando pruebas reales. Adquirido en el año 2006. Sus
características más destacables son:
•
•
•
•
•
Procesador AMD Athon 64 X2 4200+
Placa Base Asus A8RN32
2 GB de RAM DDR
1TB de Disco Duro SATA2
Tarjeta Gráfica ATI Radeon HD3870 (512 MB VRAM)
Dispositivo móvil del alumno: Será necesario para la etapa de pruebas. Su
sistema operativo está modificado tal que puede hacerse pasar por Tablet
y mostrar el contenido de las aplicaciones de igual forma que lo haría con
una Tablet real. Adquirido en 2010, sus características son:
•
•
•
•
•
•
Marca y modelo : HTC Desire (HTC Bravo/G7)
System on Chip Qualcomm Snapdragon S1 (QSD8250)
Procesador ARM7 1Ghz (del SoC)
Acelerómetro (3 ejes) y Brújula (3 Ejes)
Pantalla AMOLED de 3.7’’ (480x800) 250dpi
Android 4.2 Jelly Bean (Modificación por Paranoid Android)
34
Segundo Dispositivo Móvil: Adquirido en 2012
•
•
•
•
•
Marca y modelo : Sony Xperia S (LT26i)
System on Chip Qualcomm Snapdragon S3 (MSM8260)
Procesador ARM7 1.5Ghz DualCore
Acelerómetro (3 ejes), Giróscopo y Brújula (3 Ejes)
Pantalla SLCD de 4.3’’ (720x1280) 340dpi
•
Android 4.0 Ice Cream Sandwich
Tablet: Disponible bajo pedido, será de utilidad en el testeo final para
confirmar el buen comportamiento que presenta la aplicación en la HTC en
modo Tablet.
•
•
•
•
•
•
Marca y modelo : ASUS Transformer (TF101)
System on Chip NVIDIA Tegra 2 (T20)
Procesador ARM7 1Ghz DualCore (Cortex-A9)
Acelerómetro (3 ejes), Giróscopo y Brújula (3 Ejes)
Pantalla IPS LCD de 10.1’’ (1280x800) 150dpi
Android 4.0 Ice Cream Sandwich
Avioneta en régimen de alquiler: En caso de que se estimase necesario, y si las
pruebas realizadas con simulador no se vieran suficientes, existe la
posibilidad de probar la aplicación en un entorno real.
Recursos de Software
Sistema Operativo Windows 7 Home Premium: Sistema Operativo instalado en el
Ordenador de Sobremesa. Licencia de 2010.
Eclipse IDE for Mobile Developers + Android Plug-in: Utilizado para la
implementación de la aplicación
Eclipse Modeling Tools: Separado del IDE del proyecto, se utiliza para la creación
de Diagramas UML durante la fase de Diseño.
Java Development Kit 7: Necesario para la utilización del IDE.
Android SDK: Software proporcionado por Google para el desarrollo de
aplicaciones Android y posterior testeo.
Microsoft Office 2010: Adquirido en 2010. Se utiliza para la redacción de la
memoria y sus anexos.
PDF Creator: Herramienta gratuita para convertir archivos a PDF.
Chrome: Explorador de Internet utilizado para la búsqueda de información.
35
Servicio Google Drive: Para mantener la memoria actualizada y disponible al
alumno y al tutor en cualquier momento.
X-Plane X: Simulador de vuelo utilizado para la prueba del dispositivo en
condiciones simuladas.
Open Workbench: Planificador de Tareas. Utilizado para la planificación temporal.
Balsamik Mockups: Programa para la creación de bocetos de interfaces gráficos.
3.2 Planificación Temporal
Identificación de Tareas
Conocidos los objetivos de nuestro proyecto podemos determinar la serie de
tareas de la que se compondrá el proyecto final enumerados en el siguiente Cuadro 1:
Fase
Estudio Previo
Planificación
Análisis
Diseño
Implementación
Pruebas
Documentación
Tarea a Desempeñar
Repaso de conceptos de Programación OO y Java
Documentación General sobre Android
Estudio de Manuales para Desarrolladores Android
Instalación del Entorno (Java JDK, Eclipse y Android SDK)
Familiarización del Entorno Eclipse-Android
Estudio de Necesidades del Piloto
Planificación del Proyecto
Definición de Funcionalidades
Estudio de Conceptos Aeronáuticos Necesarios
Elaboración del Modelo de Casos de Uso
Realización de los Casos de Uso
Diseño de la Interfaz de Usuario
Diseño funcional y de datos de las Checklist
Implementación de la Interfaz de Usuario
Implementación de la funcionalidad de Checklists
Pruebas de Funcionamiento
Prueba en Simulador o Real
Realización de la Memoria
Redacción del Manual de Usuario
Cuadro 1. Descripción de Tareas
A continuación pasamos a detallar algunas de las tareas:
Repaso de conceptos de Programación OO y Java: Dado el tiempo de inactividad por
parte del alumno en el campo de la informática es necesario un repaso sobre los
conceptos básicos de Programación Orientada a Objetos así como un recordatorio
sobre la sintaxis y particularidades del lenguaje Java, ya conocido por el alumno.
36
Documentación General sobre Android: Consiste en la recopilación de información
sobre el sistema Android, funcionamiento en dispositivos, datos sobre sus
posibilidades, etc.
Estudio de Manuales para Desarrolladores Android: Lectura y ejecución de ejercicios
de libros sobre el desarrollo en la plataforma Android donde se aprende la forma
de programar, recursos disponibles para el desarrollo, pautas de diseño, etc.
Estudio de Necesidades del Piloto: Antes de poder definir las funcionalidades de la
aplicación hay que conocer las tareas que realiza un piloto a bordo de un avión.
Para ello se cuenta con la experiencia propia del alumno así como con la
aportación de otros profesionales del campo.
Definición de Funcionalidades: En base a las necesidades, se acotan las necesidades
que van a ser una futura funcionalidad de la aplicación.
Estudio de Conceptos Aeronáuticos Necesarios: Conocidas las funcionalidades que
tendrá el sistema se pasa al estudio de la teoría necesaria para poder diseñar
dichas funcionalidades. Dado que el alumno conoce la mayoría de la teoría a
aplicar no supondrá un coste temporal alto como sí lo sería para cualquier otro
programador.
Elaboración del Modelo de Casos de Uso: Creación del esquema principal de la
aplicación vista desde el modelo de Casos de uso.
Realización de los Casos de Uso: Se toman los casos de uso especificados en el modelo
y se detallan uno a uno indicando dependencias, precondiciones, pasos,
postcondiciones, etc.
Diseño de la Interfaz de Usuario: Diseño del Interfaz mediante Mock-ups (dibujos) de
toda la aplicación.
Diseño funcional y de datos de las Checklists: Diseño Funcional de la aplicación
principal y la parte de Checklists incluyendo dependencias de datos.
Implementación de la Interfaz de Usuario: Implementación de la Activity Principal y
del apartado de Checklists.
Prueba en Simulador o Real: Pruebas usando el simulador de vuelo. Si en ese
momento se estimase oportuno también se realizaría una prueba en un vuelo
real.
37
Estimación de Tiempos
Para cada tarea se ha calculado un tiempo de duración siguiendo el algoritmo
PERT [6], que calcula en base a una estimación probable, una optimista y otra
pesimista. Calculadas estas nos quedaría una relación de horas tal que (Cuadro 2):
Tarea a Desempeñar
Tiempo
Estimado
4 Horas
6 Horas
33 Horas
Instalación del Entorno
3 Horas
3 Horas
4 Horas
14 Horas
8 Horas
8 Horas
5 Horas
27 Horas
19 Horas
Diseño funcional y de datos de las Checklist
24 Horas
21 Horas
Implementación de Checklists
33 Horas
8 Horas
4 Horas
32 Horas
8 Horas
Total Horas Estimadas 264 Horas
Cuadro 2. Estimación de Horas por Tarea
Hitos
Los hitos son objetivos intermedios durante la ejecución de un proyecto. Sirven
para poder evaluar el desarrollo del mismo. En este caso se han tomado como hitos los
siguientes puntos:
•
•
•
•
•
•
H1: Fin del estudio Previo.
H2: Fin del Análisis del Proyecto.
H3: Fin del Diseño del Proyecto.
H4: Fin de la implementación.
H5: Fin de la Fase de Pruebas.
H6: Fin de la Redacción de Documentación.
38
Relaciones entre Tareas
Una vez definidas tareas e hitos podemos relacionarlos de forma que se pueda ver
gráficamente las dependencias que tienen unos sobre otros. Para ello hemos utilizado
una red de Actividades (Figura 9). Las actividades son nodos rectangulares, y la relación
de precedencia entre ellas se representa mediante una flecha. Los hitos son dibujados
como círculos.
Figura 9. Red de Actividades
Estimación de Fechas
Para la realización del proyecto se ha tenido en cuenta un calendario adecuado a
la actividad del alumno. Se ha establecido una jornada de 3 horas diarias, 4 días a la
semana. Esto supone 48 horas al mes.
Para tener mejor exactitud en el cálculo, se han tenido en cuenta los festivos
nacionales y los de la localidad de Castellón de la Plana desde Noviembre a Junio
(Todos los santos, Puente de la Constitución, Navidad, Nochevieja, Epifanía,
Magdalena, San José, Pascua y Día del Trabajador).
Suponiendo una fecha de inicio de Proyecto el 01 de Octubre de 2012 la fecha de
finalización debería acercarse al 13 de Abril de 2013, siendo el número total de días
transcurridos de 244.
39
Debido a que solo existe un desarrollador (el alumno) se descarta una impresión
del diagrama de Gantt. En este caso solo representa una sucesión de tareas y se
considera información superflua. Tampoco se considera un cálculo del camino crítico
por la misma razón pues cualquier tarea que se retrase implica un retraso sobre el
proyecto.
3.3 Estimación de Costes
Aunque el coste económico del proyecto sea nulo debido a que se trata de un
proyecto académico y que ya se dispone del software y hardware necesario, sí se va a
considerar para tener un conocimiento del coste que supone un proyecto de estas
características.
Recursos Materiales:
•
•
•
•
•
•
Ordenador de Sobremesa:
800€
Dispositivos Móviles:
HTC Desire:
150€
Sony Xperia S:
300€
Asus Transformer:
400€
Electricidad (0.3kWh * 0.1457€/kWh *264horas + 20€*7meses): 151.54€
Internet (39.90€/mes * 7 meses):
279.30€
Alquiler Avión (150€/hora *1 horas): 150€
Software:
Microsoft Windows 7
95€
Microsoft Office 2010
250€
X-Plane 10:
80€
Balsamiq Mockups
60€
Total Recursos Materiales: 2715.84€
Recursos Humanos:
•
Alumno: 264 horas * 30€/hora = 7.920€
Coste Total del Proyecto (2715.84€ + 7.920€) = 10.635,84€
40
3.4 Seguimiento del Proyecto
Aunque una planificación se haga de la forma más realista y usando los métodos
más exactos siempre se produce un desfase entre la planificación y el desarrollo real.
Este proyecto no es una excepción y, aunque en la mayor parte de él se ha cumplido el
cálculo de tiempo (con una holgura aceptable) sí ha habido una serie de
acontecimientos que han modificado el calendario estimado de una forma tangible:
•
•
•
•
•
•
El Estudio de Manuales para Desarrolladores Android ha resultado mucho
mayor de lo esperado. Las diferencias con Java a la hora de programar son
superiores a lo esperado. Esto ha requerido un estudio más a fondo de la
plataforma Android con el tiempo extra que conlleva.
La Planificación del proyecto también ha sufrido un incremento de
tiempo. Tras realizarla con el uso de la aplicación OpenProj se descubre
que está no es capaz de distribuir las tareas sobre un máximo de trabajo
diario, por lo que el alumno tenía una sobreexplotación del 700%. La
solución tomada es el uso de Open Workbench en el que, tras realizar la
tarea por segunda vez sí se consigue una planificación correcta.
La Realización de casos de uso aumenta su duración respecto de la
estimada por dos razones. La primera es que se subestiman las
funcionalidades del sistema, por lo que cuesta un trabajo extra modelizar
el comportamiento de cada una de ellas. La segunda razón deriva en las
fiestas de Navidad. No se consigue el objetivo de horas durante estas
fechas, por lo cual la duración del proyecto se ve desplazada 2 semanas.
Durante el Diseño Funcional y de Datos aumenta el número de horas
estimado debido a que el alumno debe aprender el entorno de desarrollo
de diagramas UML y en repasar los conceptos de los diagramas utilizados.
También incrementa la duración al pasar los diagramas a la memoria ya
que eclipse exporta a imagen con mala calidad, por lo que se tiene que
exportar a PDF (que mantiene el dibujo vectorial) para pasarlo luego a PNG
y editarlo posteriormente con un editor de imágenes.
El Diseño del Interfaz de usuario se realiza utilizando el programa
Balsamiq Mockups. Debido a que el alumno tiene que aprender el uso del
programa y la realización de prototipos es más lenta que si se hiciese a
mano, se produce un aumento de trabajo y por tanto, un aumento de la
duración de esta tarea.
Tanto la Implementación de la Interfaz de Usuario como la
Implementación de Checklists sufren una serie de cambios y
contratiempos que se exponen en el Capítulo 6 Punto 6.5 Principales
Retos y Cambios de Diseño
41
Con todos estos acontecimientos las tareas han sufrido un desvío respecto a la
estimación que se muestran en el Cuadro 3:
Tarea a Desempeñar
Instalación del Entorno
Diseño funcional y de datos de las Checklists
Implementación de Checklists
Total Horas
Cuadro 3. Desvío de Tiempo de Tareas
T.
T.
Desv.
Estim.
Real
4 H.
3h
-1h
6 H.
6h
0h
33 H.
50h +17h
3 H.
2h
-1h
3 H.
2h
-1h
4 H.
2h
-2h
14 H.
18h
+4h
8 H.
5h
-3h
8 H.
6h
-2h
5 H.
7h
+2h
27 H.
35h
+8h
19 H.
28h
+9h
24 H.
32h
+8h
21 H.
27h
+6h
33 H.
52h +19h
8 H.
4h
-4h
4 H.
1h
-3h
32 H.
40h
+8h
8 H.
8h
0h
264H 328h +64h
El incremento son 64 horas, que siguiendo el ritmo calculado supone un retraso
de la finalización del proyecto de 5-6 semanas, lo que sitúa el final del proyecto en la
semana del 20 al 27 de Mayo. Podemos afirmar que la planificación ha sido correcta
pues la fecha real de finalización se encuentra en ese periodo.
42
Capı́tulo 4:
Aná lisis
En este capítulo se aborda el análisis de la aplicación a desarrollar. En él se
estudian los requisitos de su sistema, tanto funcionales como datos, así como
requisitos que, no siendo de ninguno de estos anteriores, deben tener una repercusión
sobre la aplicación. Todos estos requisitos serán descritos individualmente y su
cumplimiento permitirá que la aplicación tenga todas las funcionalidades y diseños
para que sea satisfactoria.
4.1 Presentación de los Requisitos
Para analizar los requisitos que debe cumplir el sistema se van a utilizar los
diagramas y tablas de Casos de Uso. En este proyecto se definen 3 tipos de requisitos:
•
•
•
Requisitos Funcionales: Los casos de uso. Funcionalidades para el usuario.
Requisitos de Datos: Información necesaria para el usuario y Req. Funcionales.
Req. No Funcionales: Filosofías de diseño, objetivos generales y restricciones.
Los requisitos funcionales se definirán utilizando una tabla como en el Cuadro 4.
Caso de Uso : Código
Descripción
Precondición
Flujo Normal
Flujo Alternativo
Postcondición
Nombre del Caso de Uso
Breve descripción del requisito que debe cumplir el sistema.
Condiciones necesarias ante la ejecución del caso de uso.
Paso Acción
1
Acción 1.
2
Acción 2.
3
Acción 3.
…
Acción ...
Paso Acción
2a.1 Acción Alternativa A al Paso 2 – Paso 1.
2a.2 Acción Alternativa A al Paso 2– Paso 2.
2b.1 Acción Alternativa B al Paso 2 – Paso 1.
2b.2 Acción Alternativa B al Paso 2 –Paso 2.
3C
Acción Alternativa C al Paso 3 (Única Acción).
D
Accion Alternativa D en todo el Caso de Uso.
Condiciones que se cumplen al terminar la ejecución de la
funcionalidad del caso de uso.
Cuadro 4. Modelo de Descripción de Caso de Uso
Para requisitos que no sean casos de uso se utilizarán tablas más sencillas. Para
requisitos de datos (Cuadro 5) y para requisitos no funcionales (Cuadro 6).
43
Req. de Datos : Código
Descripción
Casos de uso Asociados
Requisitos Asociados
Comentarios
Nombre del Requisito
Casos de Uso donde se utiliza este futuro recurso.
Lista de relación con otros requisitos de datos.
Notas y comentarios sobre el requisito.
Cuadro 5. Modelo de Descripción de Requisito de Datos
Req. no Funcional : Código
Descripción
Comentarios
Nombre del Requisito
Notas y comentarios sobre el requisito.
Cuadro 6. Modelo de Descripción de Requisito No Funcional
Para definir a los actores del sistema se utilizará la siguiente tabla (Cuadro 7)
Actor :
Casos de Uso
Asociados:
Tipo
Descripción:
Nombre del Actor
Casos de uso en los que está implicado.
Primario o Secundario.
Descripción del Actor.
Cuadro 7. Modelo de Descripción de Actor
Los códigos que se utilizan en el modelado siguen los patrones que se indican a
continuación (los xx se sustituyen por el número de caso de uso):
•
•
•
•
•
•
•
PAxx (PApers): Casos de uso centrados en el apartado de papeles
(documentación e información de vuelo)
NVxx (NaVigation): Casos de uso centrados en la navegación, instrumentos
y ayuda a la navegación.
UTxx (UTilities): Casos de uso referentes a utilidades del sistema
(conversores, cálculos, notas, cronometro…).
DAPxx (Data-APplication): Requisitos de datos almacenados
permanentemente en la aplicación.
DSTxx (Data-Status): Requisitos de datos almacenados temporalmente
durante la ejecución de la aplicación.
DESxx (Data-External Storage) Requisitos de datos que se refieren a
archivos localizados en la memoria externa del dispositivo (Tarjeta SD o
Memoria adicional).
RNFxx: Requisitos No funcionales.
44
4.2 Visión general de la Aplicación
Antes de describir cada caso de uso, para tener una visión global del futuro
sistema y para comprenderlos mejor se muestra un diagrama de Caso de Uso general
(Figura 10). En él se distinguen 3 subsistemas, que realmente es el mismo, solo que
para una mejor comprensión se separan los casos de uso en 3 bloques.
Figura 10. Diagrama de Casos de Uso - General
45
Actores
Los Actores del sistema son aquellas personas o sistemas externos que
interactúan con nuestra aplicación. Ahora detallamos los Actores del sistema en
estudio (Cuadros 8 al 12):
Actor :
Casos de Uso
Asociados:
Tipo:
Descripción:
Piloto
PA01, PA03, PA04, PA05, PA06, PA07,PA08, NV01, NV03, NV04, NV05, NV06,
NV07, NV08, UT02, UT03, UT04, UT05, UT06,UT07, UT08
Primario
Se trata del usuario principal de la aplicación. Representa a cualquier
persona que esté usando el dispositivo.
Cuadro 8. Actor Piloto.
Actor :
Casos de Uso
Asociados:
Tipo
Descripción:
Lector PDF
PA04
Secundario
Representa una aplicación instalada en Android que permite abrir y
visualizar archivos PDF.
Cuadro 9. Actor Lector PDF
Actor :
Casos de Uso
Asociados:
Tipo:
Descripción:
Servidor Meteo
PA05
Secundario
Se trata de un Servidor externo o página web alojado en Internet que ofrece
información meteorológica de un aeropuerto en formato METAR y TAFOR
(Texto Llano).
Cuadro 10. Actor Servidor Meteo
Actor :
Casos de Uso
Asociados:
Tipo:
Descripción:
Sensores Movimiento
NV08, UT05
Secundario
Son los sensores disponibles del dispositivo encargados del movimiento y
conocimiento del medio en el que se rodea (acelerómetros, giróscopo,
brújula y barómetro).
Cuadro 11. Actor Sensores Movimiento
Actor :
Casos de Uso
Asociados:
Tipo:
Descripción:
Sensor GPS
NV01, NV08, UT05, UT06
Secundario
Sensor del dispositivo encargado de traducir las señales de los satélites GPS
en una posición en el Elipsoide WGS84 que representa la Tierra. También
ofrece velocidad sobre el suelo, Track y Altitud.
Cuadro 12. Actor Sensor GPS
46
Dependencias de Datos
El sistema, para su correcto funcionamiento necesita de una serie de información.
Esta puede provenir de 3 lugares: de la memoria externa, la memoria de la aplicación y
del estado de la aplicación.
Según esta clasificación en nuestra aplicación tenemos las siguientes
dependencias de datos:
Memoria de la Aplicación: Datos que se guardan en la aplicación de forma
permanente para su uso por parte del sistema. Solo pueden ser modificados
desde dentro de la aplicación. (Cuadros 13 al 16)
Req. de Datos : DAP01
Descripción:
Avión Seleccionado
Nombre del Avión y ruta del archivo XML del avión que se utilizará
en la aplicación.
Casos de uso Asociados PA03, PA07, UT06, UT08
DST01
Comentarios
Ruta del archivo localizada en la memoria Externa.
Cuadro 13. Req.Datos DAP01 - Avión Seleccionado
Descripción:
Estaciones METAR Buscados
Nombre y código OACI de las estaciones meteorológicas buscadas
por el Piloto con anterioridad.
Casos de uso Asociados PA05
Comentarios
Se trata de una lista con dos componentes en cada nodo. Un
nombre de estación y un código OACI.
Cuadro 14. Req.Datos DAP02 - Estaciones METAR
Descripción:
Comentarios
Notas Guardadas
Notas escritas por el Piloto y guardadas en el sistema.
UT01, UT02, UT03
Lista de notas. Solo se almacenan caracteres alfanuméricos.
Cuadro 15. Req.Datos DAP03 - Notas Guardadas
Descripción:
Último VOR
Identificación y posición del último VOR utilizado por el Piloto en
sesiones anteriores.
Casos de uso Asociados NV01, NV02
DES05
Comentarios
Componente que almacena un código de 3 caracteres como
identificación y un número decimal como frecuencia.
Cuadro 16. Req.Datos DAP04 - Último VOR
47
Estado de la Aplicación: Son los datos que se guardan durante la ejecución de la
aplicación y que son borrados tras cerrarla o tras un tiempo sin utilizar la
aplicación (tiempo que depende del sistema y del dispositivo) (Cuadros 17 al 24).
Req. de Datos : DST01
Descripción
Checklists Completadas
Lista de Checklists que ya han sido completadas por el Piloto en la
sesión actual.
DES02
Comentarios
Listado de las Checklist en las que el Piloto ha seleccionado todos
sus ítems. Se guarda como lista de un solo elemento por nodo (la
identificación de la lista).
Cuadro 17. Req.Datos DST01 - Checklists Completadas
Descripción
Ítems Completados
Relación de ítems completados dentro de una Checklist en la sesión
actual.
Comentarios
Número entero de ítems completados.
Cuadro 18. Req.Datos DST02 - Ìtems Completados
Descripción
Último METAR
Información del último METAR consultado por el usuario durante la
ejecución de la sesión actual.
Casos de uso Asociados PA05, UT08
DES03
Comentarios
Cadena de caracteres alfanuméricos que componen el texto
normalizado de un METAR.
Cuadro 19. Req.Datos DST03 - Último METAR
Descripción
Comentarios
Información FPL
Guarda información del plan de vuelo de la sesión actual.
PA06, UT08
DES06
Estructura de distintos campos alfanuméricos. Guarda la
información de:
• Nombre del Plan de Vuelo
• Tipo de Vuelo: (General, Escuela,…)
• Código de Aeropuerto de Salida
• Hora de salida
• Velocidad de crucero
• Códigos de aeropuertos alternativos
• Código de aeropuerto de Destino
• Tiempo estimado de Duración
• Número de Pasajeros
• Autonomía en horas
• Piloto al Mando
• Día del Vuelo
• Otra información (cadena de caracteres)
Cuadro 20. Req.Datos DST04 - Información FPL
48
Descripción
Datos Mass & Balance
Información del cálculo de peso y centro de gravedad del avión en
la sesión actual.
Casos de uso Asociados PA07, UT06, UT08
DES03
Comentarios
Datos numéricos sobre:
• Combustible a bordo
• Peso de las personas a bordo
• Peso del Equipaje
• Peso Actual del avión
• Posición del Centro de Gravedad del avión
• Capacidad de los depósitos de Combustible
Cuadro 21. Req.Datos DST05 - Datos Mass & Balance
Descripción
Último VOR
Identificación y posición del último VOR utilizado por el Piloto en la
sesión actual.
Casos de uso Asociados NV01, NV02, NV03, NV04, NV05, NV06, UT08
DES05
Comentarios
Componente que almacena un código de 3 caracteres como
identificación, un número decimal como frecuencia, una
coordenada N-S, una coordenada E-O (ambos con 4 decimales) y
una elevación.
Cuadro 22. Req.Datos DST06 - Último VOR
Descripción
Última Nota abierta
Información escrita por el Piloto la última vez que utilizó la
funcionalidad de crear Nota.
Casos de uso Asociados UT02
Comentarios
Cadena de caracteres que contienen la nota escrita por el piloto en
el caso de que se salga de la aplicación sin guardar la nota.
Cuadro 23. Req.Datos DST07 - Última Nota
Descripción
Comentarios
Hora Inicio Vuelo
Hora en la que se inicia el vuelo en la sesión actual.
UT06, UT08
Hora que se utiliza para calcular el tiempo de vuelo. Se graba a
partir de superar cierta velocidad GPS.
Cuadro 24. Req.Datos DST08 - Hora Inicio Vuelo
49
Memoria Externa: Datos accesibles desde la memoria externa del dispositivo (ya sea
una memoria interna o una tarjeta SD). Es modificable por el usuario (u otras
aplicaciones) debido a que pueden acceder a los archivos que residen en ella
(Cuadros 25 al 31).
Req. de Datos : DES01
Descripción
Archivo XML de Avión.
Guarda toda la información referida al avión que representa en la
memoria externa.
Casos de uso Asociados PA03, PA07, UT06
DAP01, DES02,DES03,DES04
Comentarios
Archivo XML que guarda la información General (DES04), Checklist
de Vuelo (DES02) y los Datos de Mass & Balance (DES03).
Cuadro 25. Req.Datos DES01 - Archivo XML del Avión
Descripción
Checklists
Serie de Listas de chequeo, cada una con sus ítems propios. Forma
parte de DES01.
DES01, DST01
Comentarios
Checklists distribuidas en dos grandes Grupos: Normales y
Emergencia. Dentro de cada Grupo existe una serie de Listas (para
cada parte del vuelo) y dentro de ellas una sucesión de ítems a
realizar.
Cuadro 26. Req.Datos DES02 - Checklists
Descripción
Datos de Mass & Balance
Datos propios del avión necesarios para el cálculo de la carga y
centrado . Forma parte de DES01.
DES01, DST05
Comentarios
Los Datos que almacena son:
• Peso Básico del Avión
• Peso Máximo al despegue
• Capacidad de los depósitos
• Número máximo de pasajeros
• Peso máximo del compartimento de carga
• Gráfica de la envolvente de vuelo (Peso/ Centro Gravedad)
Cuadro 27. Req.Datos DES03 - Datos de Mass & Balance
Descripción
Comentarios
Datos Generales del Avión
Datos generales del avión. Forma parte de DES01.
UT06
DES01, DAP01
• Nombre del Avión
• Código OACI del Avión
• Velocidad de Crucero
• Consumo Medio
• Velocidad óptima de planeo
• Fineza
Cuadro 28. Req.Datos DES04 - Datos Generales del Avión
50
Descripción
Comentarios
Base de Datos VOR
Base de datos SQLite que contiene todos los VOR del mundo.
Alojada en la memoria externa.
NV02
DAP04, DST06
• Identificación VOR (3 Caracteres)
• Frecuencia VOR (Numero Decimal)
• Coordenada Latitud (4 Decimales)
• Coordenada Longitud (4 Decimales)
• Elevación del Terreno (en pies)
Cuadro 29. Req.Datos DES05 - Base de Datos VOR
Descripción
Archivos XML de FPL’s
Contiene la información de un plan de vuelo guardado en la
memoria externa por el Piloto.
DST04
Comentarios
Estructura de distintos campos alfanuméricos. Guarda la
información de:
• Nombre del Plan de Vuelo
• Tipo de Vuelo: (General, Escuela,..)
• Código de Aeropuerto de Salida
• Hora de salida
• Velocidad de crucero
• Códigos de aeropuertos alternativos
• Código de aeropuerto de Destino
• Tiempo estimado de Duración
• Número de Pasajeros
• Autonomía en horas
• Piloto al Mando
• Día del Vuelo
• Otra información (cadena de caracteres)
Cuadro 30. Req.Datos DES06 - Archivos XML de FPL's
Descripción
Comentarios
Carpeta de Fichas PDF
Carpeta que aloja las fichas de aeropuertos que el Piloto utiliza en
la memoria externa.
PA04
La estructura es tal que: Dentro de una carpeta general (Fichas)
existen subcarpetas (Código - Aeropuerto) que contienen todas las
fichas PDF de cada aeropuerto.
Cuadro 31. Req.Datos DES07 - Carpeta de Fichas PDF
51
Requisitos No Funcionales
Aquí se nombran aquellos requisitos que condicionan la función global de la
aplicación, restricciones y requisitos que no son funcionalidades por sí mismas.
Req. no Funcional : RNF01
Descripción
Comentarios
Sistema Operativo Mínimo
La aplicación debe soportar como mínimo Android 4.0 (Ice
Cream Sandwich).
Debe aprovechar las mejoras que se introducen a partir de 4.0.
Cuadro 32. Req.No Funcional RNF01 - Sistema Operativo Mínimo
Descripción
Interfaz basado en Patrones de Google
La interfaz gráfica debe estar diseñada siguiendo los patrones
estudiados anteriormente (Interfaz de Usuario) para mejorar
la experiencia del usuario.
Cuadro 33. Req.No Funcional RNF02 - Interfaz basado en Patrones Google
Descripción
Comentarios
Interfaz funcional en Tablets
La aplicación debe soportar y adaptarse a los distintos tipos de
pantallas de los diferentes dispositivos, aprovechando el espacio
extra de las tablets para mostrar más información que en un
Smartphone.
Debe hacer uso de los Fragments que dispone Android 4.0 así
como aprovechar las distintas configuraciones según densidad
de píxels.
Cuadro 34. Req.No Funcional RNF03 - Interfaz funcional en Tablets
Descripción
Comentarios
Facilidad de uso en Vuelo
La aplicación se debe diseñar para que al Piloto le resulte fácil e
intuitivo utilizar sus funcionalidades en el transcurso de un
vuelo.
Debe hacerse hincapié en evitar introducir datos y letras. Hay
aprovechar la introducción de datos visualmente, mostrar solo lo
estrictamente necesario y simplificar la interacción con el Piloto.
Cuadro 35. Req.No Funcional RNF04 - Facilidad de uso en Vuelo
Descripción
Uso de Recursos
La aplicación debe utilizar, en la medida de lo posible, la mínima
cantidad de recursos (memoria, CPU, batería) sin que ello
perjudique al Piloto.
Cuadro 36. Req.No Funcional RNF05 - Uso de Recursos
Descripción
Código Ordenado
El código de la aplicación debe estar documentado, escrita de
forma coherente y de fácil lectura. Debe tener en cuenta la
reutilización de código, la escalabilidad y debe facilitar la
localización de bugs.
Cuadro 37. Req.No Funcional RNF06 - Código Ordenado
52
Descripción
Comentarios
Cambio de Idioma
La aplicación debe de tener la opción de cambiar el idioma del
interfaz gráfico.
Se intentará utilizar las recomendaciones de Google para reducir
al mínimo el coste de añadir idiomas nuevos.
Cuadro 38. Req.No Funcional RNF07 - Cambio de Idioma
Descripción
Comentarios
Reinicio de la aplicación
La aplicación debe de tener la opción de reiniciar la aplicación,
haciendo que todas los datos temporales se borren.
Borrará todos los datos del estado de la aplicación (DSTxx)
dejando la aplicación lista para un vuelo nuevo.
Cuadro 39. Req.No Funcional RNF08 - Reinicio de la Aplcicación
Descripción
Comentarios
Cambio de Avión
La aplicación debe de tener la opción cambiar el avión
seleccionado para el vuelo.
Se buscará el XML de todos los aviones disponibles en la
memoria externa del dispositivo.
Cuadro 40. Req.No Funcional RNF09 - Cambio de Avión
4.3 Subsistema Papeles
En esta parte de la aplicación se agrupan todas las funcionalidades referidas al uso
de documentación del avión (Checklists, Fichas, Carga y centrado, Meteorología y
Planes de Vuelo). Este es el único subsistema que contiene casos de uso que van a ser
diseñados e implementados; en concreto se trata de PA01 – Mostrar Lista Ítems, PA02
– Marcar Checklist Leídas y PA03 – Usar Checklist.
El diagrama de Casos de uso para este subsistema es el siguiente (Figura 11):
Figura 11. Diagrama de Casos de Uso - Subsistema Papeles
53
El Detalle de cada Caso de Uso se indica en los siguientes Cuadros (del Cuadro 41
al Cuadro 48):
Caso de Uso : PA01 Mostrar Lista Ítems
Descripción
El Sistema muestra en pantalla una lista de ítems cargados desde el
conjunto de datos correspondiente a fin de que el piloto seleccionar uno
de ellos.
Precondición
Se le debe indicar el conjunto de datos donde debe buscar la
información ya sea una estructura de datos personalizada, un archivo
XML, o una lista de archivos externos.
Flujo Normal
Paso Acción
1
El sistema carga la ListView donde se añadirán los ítems.
2
Se carga el conjunto de datos correspondiente en la Pantalla.
3
El Piloto selecciona el ítem deseado.
4
Se devuelve el Ítem seleccionado al sistema.
Flujo Alternativo
Paso Acción
3A En caso de mostrar Checklists (Provenir de PA03) se ejecuta el
caso de uso PA02 – Marcar Checklist Leídas. Se vuelve al Flujo
Normal en el Punto 3.
3B
En caso de mostrar Estaciones Meteorológicas (Provenir de PA05)
se Ejecuta el caso de Uso PA08 – Añadir Estación Aeropuerto. Se
vuelve al Flujo Normal en el Punto 3.
Postcondición
Se ha seleccionado un Ítem.
Cuadro 41. Caso de Uso PA01 - Mostrar Lista Ítems
Caso de Uso : PA02 Marcar Checklist Leídas
Descripción
El Sistema comprueba las Checklists completadas o parcialmente
cargadas y las marca para que el usuario tenga constancia de ello.
Precondición
Este Caso de Uso es llamado por PA01 - Mostrar Lista Ítems sólo en el
caso de haber sido llamada por PA03 -Usar una Checklist.
Flujo Normal
Paso Acción
1
Se comprueba desde el estado de la aplicación las Checkist
completadas (DST01).
2
El sistema Añade un Stick a la derecha del nombre de las Checklist
que ya han sido completadas.
3
Se devuelve el Flujo al caso de uso PA01 - Mostrar Lista Ítems.
Flujo Alternativo
Paso Acción
A.1 El Piloto Accede a las opciones y selecciona Reiniciar Listas
A.2 El Sistema borra todas las listas completadas del estado de la
aplicación (DST01) y borra los sticks.
Postcondición
Se han marcado las Checklists completadas.
Cuadro 42. Caso de Uso PA02 - Marcar Checklist Leídas
54
Caso de Uso : PA03 Usar una Checklist
Descripción
El Sistema muestra en pantalla una Lista de Checklists del avión
seleccionado (provenientes del fichero XML del avión) a fin de que el
piloto seleccione una de ellas.
Precondición
Existe un avión cargado en el sistema (Archivo XML) DAP01.
Flujo Normal
Paso Acción
1
El sistema llama al caso de uso PA01 - Mostrar Lista Ítems
indicando el archivo XML del avión seleccionado ubicado en la
memoria externa del Dispositivo (DES01).
2
Es sistema según el Ítem (Checklist) seleccionado abre una nueva
ventana y muestra una lista de los puntos de la Checklist cargados
desde el XML del Avión (DES02).
3
El Sistema Comprueba si existen puntos ya realizados en el estado
de la aplicación (DST02). De ser así se les añade un stick a la
derecha (para indicar que ya han sido realizados).
4
El Piloto selecciona los distintos puntos en orden (el sistema no
permite saltarse un punto). Al realizarlo se añade un stick a la
derecha indicando su estado completado.
5
Al terminar seleccionar todos los puntos el sistema mostrará en
pantalla “Checklist Completed”. Se añade la Checklist al estado de
la aplicación para indicar que ya ha sido completada.
Flujo Alternativo
Paso Acción
5A La lista cargada es de Emergencia. El sistema muestra en pantalla
“Checklist Completed”. (No se añade la lista a completadas).
A
En caso que la Actividad sea parada se guarda la relación de ítems
que han sido completados en el estado de la aplicación (DST02).
B.1 El Piloto Accede a las opciones y Selecciona Reiniciar Lista.
B.2 El Sistema borra todos los Ítems completados y lista completada
del estado de la aplicación (DST02) y borra los sticks.
Postcondición
El piloto ha usado la Checklist deseada.
Cuadro 43. Caso de Uso PA03 - Usar una Checklist
55
Caso de Uso : PA04 Ver Ficha de Aeropuerto
Descripción
El Sistema muestra en pantalla una Ficha de un aeropuerto con el uso de
un visor PDF externo. Para ello primero muestra una Lista de
Aeropuertos (provenientes de la cantidad de Ficheros de aeropuertos
que existan en la Memoria Externa) y luego otra de las Fichas disponibles
en cada directorio a fin de que el piloto seleccione una de ellas.
Precondición
Existen al menos un fichero de Aeropuerto en la memoria Externa y una
ficha PDF dentro de él.
Flujo Normal
Paso Acción
1
indicando la ruta del fichero donde se encuentran los aeropuertos
en la memoria externa del Dispositivo (DES07).
2
Es sistema según el Ítem (Aeropuerto) vuelve a llamar al caso de
uso PA01 - Mostrar Lista Ítems indicando la ruta del fichero del
aeropuerto donde se encuentran las Fichas PDF en la memoria
externa del Dispositivo (DES07).
3
Según el Ítem seleccionado (Ficha) se manda su ruta al Visor PDF
para que abra dicho documento.
Flujo Alternativo
Paso Acción
3A No se encuentra Visor de PDF en el dispositivo. El Sistema le
muestra al usuario la posibilidad de descargar uno desde Google
Play.
Postcondición
El sistema ha abierto el visor PDF con la ficha seleccionada.
Cuadro 44. Caso de Uso PA04 - Ver Ficha Aeropuerto
56
Caso de Uso : PA05 Ver METAR TAF
Descripción
El Sistema muestra en pantalla el METAR y el TAFOR en texto llano de un
aeropuerto. Para ello primero muestra una Lista de Aeropuertos
estándar y los que el usuario ha introducido anteriormente.
Precondición
Existe una conexión a Internet
Flujo Normal
Paso Acción
1
indicando el archivo de memoria de la aplicación (DAP02) donde
se encuentran los aeropuertos estándar y los buscados con
anterioridad.
2
El sistema según el Ítem seleccionado (Código OACI del
Aeropuerto) pide al servidor de meteorología la información de
ese aeropuerto.
3
El servidor devuelve en texto llano el METAR y el TAFOR.
4
El Sistema muestra en pantalla el texto en grande para facilitar la
lectura y lo guarda en el estado de la aplicación (DST03).
5
Se añade el aeropuerto consultado en la lista de “buscados con
anterioridad” (alojada en el estado de la aplicación) si no lo está
ya.
Flujo Alternativo
Paso Acción
3a.1 El servidor no responde.
3a.2 El sistema muestra al piloto que no puede contactar con el
servidor. FIN del Caso de Uso.
3b.1 El servidor no encuentra el aeropuerto y envía al sistema un error.
3b.2 El Sistema muestra al piloto que el Aeropuerto no se ha
encontrado. FIN del Caso de Uso.
Postcondición
El sistema muestra un texto que contiene el METAR y TAFOR del
aeropuerto requerido.
Cuadro 45. Caso de Uso PA05 - Ver METAR TAF
57
Caso de Uso : PA06 Rellenar FPL
Descripción
El Sistema muestra en pantalla los distintos campos de un Plan de Vuelo
OACI y el usuario puede rellenarlos sin ningún tipo de restricción. El
usuario puede guardar o cargar FPL’s desde la Memoria Externa.
Precondición
Ninguna.
Flujo Normal
Paso Acción
1
El sistema muestra en pantalla los distintos campos vacíos a
rellenar.
2
El piloto rellena los datos según su plan de Vuelo aprobado o
supervisa los existentes.
3
Al salir de la Actividad el sistema guarda los datos temporalmente
en el estado de la aplicación (DST04).
Flujo Alternativo
Paso Acción
1A El Sistema carga los datos anteriormente introducidos en vez de
mostrar campos vacíos. Continúa el Flujo Normal en el Punto 2
(DST04).
2a.1 El usuario pulsa en Cargar FPL anterior.
2a.2 El sistema abre una ventana nueva y llama al caso de uso PA01 Mostrar Lista Ítems indicando la ruta del fichero donde se
encuentran los FPL (en formato XML) en la memoria externa del
Dispositivo (DES06).
2a.3 Según el Ítem seleccionado (Archivo FPL) el sistema abre dicho
archivo y carga los datos en los campos de la actividad (DES06).
Continúa el Flujo Normal en el Punto 2.
3a.1 El Usuario presiona Guardar FPL.
3a.2 El sistema genera y guarda un archivo con nombre normalizado
(Fecha–Hora TO-ID) en la memoria externa (DES06) con todos los
datos introducidos. FIN del Caso de Uso.
Postcondición
El sistema muestra una serie de campos con información sobre el Plan
de Vuelo.
Cuadro 46. Caso de Uso PA06 - Rellenar FPL
58
Caso de Uso : PA07 Calcular Mass & Balance
Descripción
El Sistema muestra en pantalla 3 parámetros numéricos (Personas a
bordo, Kg de Equipaje y US Galones de Combustible) que el piloto debe
seleccionar correctamente a fin de que el sistema calcule si el avión
seleccionado se encuentra dentro de la envolvente de vuelo (que
asegura que no se excede el peso máximo ni los límites del Centro de
Gravedad).
Precondición
Existe un avión cargado en el sistema (Archivo XML) (DAP01).
Flujo Normal
Paso Acción
1
El sistema muestra 3 Pickers con los valores que se pueden
modificar.
2
El usuario cambia los valores según el vuelo que realice.
3
El sistema carga los datos de Carga y Centrado del XML del avión
(DES01, DES03).
3
El sistema calcula y muestra en la parte inferior en verde “M&B
OK” si se encuentra dentro de la envolvente.
4
Al salir de la actividad se guardan los datos en el estado de la
aplicación (DST05).
Flujo Alternativo
Paso Acción
3A Los datos introducidos no entran en la envolvente. El sistema
muestra en la parte inferior en ROJO “NO GO!!” e indica la razón
por la que se sale de ella (por exceso de peso o por límites del
CdG). Se vuelve el flujo Normal en el paso 2.
B.1 El usuario pulsa ver gráfico.
B.2 El Sistema muestra un gráfico 2D definido en el XML del Avión
(DES03) donde se señala la posición del avión en la envolvente
según los datos introducidos.
Postcondición
El sistema ha calculado la carga y centrado del avión.
Cuadro 47. Caso de Uso PA07 - Calcula Mass & Balance
Caso de Uso : PA08 Añadir Estación Aeropuerto
Descripción
El Sistema añade una estación meteorológica nueva en la lista
disponible.
Precondición
Existe una conexión a Internet
Este Caso de Uso es llamado por PA01 - Mostrar Lista Ítems sólo en el
caso de haber sido llamada por PA05 – Ver METAR TAF
Flujo Normal
Paso Acción
1
El sistema muestra un campo de entrada de texto y un botón de
añadir Estación.
2
El Piloto introduce el código OACI del aeropuerto que desea
conocer y Pulsa el botón de añadir.
3
El sistema Añade la opción a la Lista.
4
Se devuelve el Flujo al caso de uso PA01 - Mostrar Lista Ítems.
Flujo Alternativo
Paso Acción
2A El piloto no realiza ninguna acción. Se Devuelve el Flujo a PA01 Mostrar Lista Ítems.
Postcondición
El sistema ha añadido una estación meteorológica en la lista de ítems
disponibles.
Cuadro 48. Caso de Uso PA08 - Añadir Estación Aeropuerto
59
4.4 Subsistema Navegación
En esta parte de la aplicación se agrupan los casos de uso referentes a sistemas y
ayudas a la navegación como son: Instrumentos de Stand-By, HSI, y procedimientos
IFR. El diagrama de Casos de Uso es el siguiente (Figura 12):
Figura 12. Diagrama de Casos de Uso - Subsistema Navegación
Los detalles de cada caso de uso se muestran en los siguientes cuadros (del
Cuadro 49 al Cuadro 56):
Caso de Uso : NV01 Calcular Posición VOR
Descripción
El sistema calcula la posición relativa a un VOR predefinido (Radial y
Distancia) a partir de los datos del sensor GPS del dispositivo.
Precondición
Debe ser llamado por otro caso de uso que utilice la posición VOR.
Hay un VOR seleccionado.
El dispositivo dispone de Antena GPS y/o GLONASS.
Flujo Normal
Paso Acción
1
El piloto mantiene el VOR que ya está seleccionado (DAP04).
2
El sistema pide los datos de posición al sensor.
3
El sensor responde con la posición, altitud, track y velocidad.
4
El sistema calcula la posición en referencia al VOR actual desde
el estado de la aplicación donde se conoce la posición del VOR.
5
El resultado del cálculo se compone de un Radial, una Distancia
DME, una Distancia sobre el Suelo y una velocidad hacia la
estación.
6
El sistema escribe en el estado de la aplicación el resultado del
cálculo más el Track, velocidad y Altitud (DST06).
Flujo Alternativo
Paso Acción
1A
El Piloto selecciona cambiar de estación VOR. Se llama al caso de
uso NV02 - Cambiar Frecuencia
3a.1 No hay respuesta del sensor. El Sistema avisa al usuario
indicando que no hay cobertura.
3a.2 Se devuelve el flujo al punto 3 hasta que haya cobertura.
60
3b.1
Postcondición
La recepción GPS está apagada. El Sistema propone al usuario la
opción de conectarla.
3b.2 Se devuelve el flujo al punto 3 hasta que haya cobertura.
El sistema ha calculado la posición VOR del avión para ser usada por
otros casos de uso.
Cuadro 49. Caso de Uso NV01 - Calcular Posición VOR
Caso de Uso : NV02 Cambiar Frecuencia
Descripción
El sistema permite al usuario cambiar de frecuencia VOR para utilizar
otra estación VOR para la navegación o para la ayuda a la navegación.
Precondición
Es llamado por el Caso de Uso NV01 - Calcular Posición VOR
Flujo Normal
Paso Acción
1
modificar (MHz en uno y Centésimas de MHz en otro), y también
muestra una entrada de texto donde escribir 3 caracteres
(identificación VOR).
2
El usuario modifica los valores y acepta el cambio.
3
El sistema busca en la base de datos de VOR en la Memoria
Externa (DES05) la frecuencia introducida la estación
correspondiente.
4
El sistema escribe en el estado de la aplicación la nueva estación
VOR (frecuencia, identificación, posición GPS) (DST06), reescribe
en la memoria el nuevo VOR utilizado (DAP04) y cambia los
pickers o la entrada de texto con los valores de la estación elegida.
5
Se Devuelve el flujo a NV01 - Calcular Posición VOR.
Flujo Alternativo
Paso Acción
3a.1 El sistema encuentra varias posibilidades (misma frecuencia para
distintas estaciones o misma id para distintas frecuencias).
3a.2 El sistema selecciona mediante una estimación de distancia la más
cercana. Continúa el flujo en el punto 4.
3b.1 El sistema no encuentra ningún resultado en la base de datos.
3b.2 El sistema informa al usuario de que no encuentra resultados y no
permite que la ejecución termine. Continúa el flujo en el punto 2.
C
El usuario cancela el cambio. Se pasa al punto 5.
Postcondición
El sistema ha cambiado la estación VOR de referencia.
Cuadro 50. Caso de Uso NV02 - Cambiar Frecuencia
61
Caso de Uso : NV03 Usar HSI
Descripción
El Sistema muestra en pantalla una representación de un HSI, Horizontal
Situation Indicator ,y de un DME, Distance Measuring Equipment. El
Piloto puede utilizarlo como radioayuda usando la información que
ofrece, cambiando el radial y la pínula.
Precondición
Flujo Normal
Paso Acción
1
El sistema muestra un HSI, un DME e información sobre la
estación seleccionada (Identificación y frecuencia).
2
El sistema llama al caso de uso NV01 - Calcular Posición VOR.
3
Con los datos devueltos el sistema muestra la posición del avión
en el CDI siguiendo los principios de funcionamiento del HSI según
la posición del Course (DST06).
4
El sistema muestra en el DME la Distancia DME, velocidad a la
estación y calcula el tiempo a ella para mostrarla (DST06).
5
El piloto navega con los valores actuales.
6
El flujo vuelve al punto 2 hasta que el usuario salga de la actividad.
Flujo Alternativo
Paso Acción
5A El usuario cambia los valores del Course. Continúa el Flujo en el
punto 6.
Postcondición
El usuario ha utilizado el HSI como medio de navegación.
Cuadro 51. Caso de Uso NV03 - Usar HSI
Caso de Uso : NV04 Calcular Espera
Descripción
El usuario introduce las propiedades de la espera, el sistema calcula el
tipo de entrada a la espera según la posición del avión e indica al piloto
los pasos que debe realizar para entrar correctamente.
Precondición
Flujo Normal
Paso Acción
1
El sistema muestra 3 campos a rellenar (outbound, espera no
estándar y espera por encima de FL140) y la opción de cambiar de
estación.
2
El piloto rellena el campo Outbound, y si procede marca que la
espera no es estándar y/o está por encima de FL140.
3
4
El sistema con la información que se devuelve del paso anterior
(DST06) y con la que proporciona el piloto calcula el tipo de
entrada.
5
El sistema muestra en pantalla el tipo de entrada (DIRECTA, GOTA
o PARALELA) y los pasos que debe seguir.
6
El Piloto sigue los pasos.
7
En el momento de pasar por encima de la estación el sistema
muestra en pantalla un cronometro en cuenta atrás. Al llegar a 0
emite un sonido y parpadea el cronometro.
Flujo Alternativo
Paso Acción
6a.1 El piloto cambia parámetros de la espera tras mostrarse los pasos.
6a.2 El sistema vuelve al punto 3.
Postcondición
El piloto ha conseguido entrar en la espera.
Cuadro 52. Caso de Uso NV04 - Calcular Espera
62
Caso de Uso : NV05 Calcular Interceptación
Descripción
El usuario introduce la interceptación deseada, el sistema calcula el tipo
de interceptación según la posición del avión e indica al piloto los pasos
que debe hacer para realizarla correctamente.
Precondición
Flujo Normal
Paso Acción
1
El sistema muestra 1 campo a rellenar (ruta deseada), una
selección de alejamiento o acercamiento y la opción de cambiar
de estación.
2
El piloto rellena el campo “deseada” con el radial deseado y si se
trata de acercamiento o alejamiento.
3
4
(DST06) y con la que proporciona el piloto calcula el tipo de
interceptación.
5
El sistema muestra en pantalla el tipo de interceptación (DIRECTO
o PASADO) y los pasos que debe seguir.
6
Flujo Alternativo
Paso Acción
5A En el caso de ser acercamiento pasado, al pasar abeam de la
estación el sistema muestra en pantalla un cronometro de un
minuto en cuenta atrás. Al llegar a 0 emite un sonido y parpadea
el cronometro.
Postcondición
El piloto ha conseguido realizar la interceptación correctamente.
Cuadro 53. Caso de Uso NV05 - Calcular Interceptación
Caso de Uso : NV06 Calcular Punto a Punto
Descripción
El piloto introduce el punto deseado referenciado al VOR actual, el
sistema según la posición del avión calcula el rumbo al punto y lo
muestra al piloto.
Precondición
Flujo Normal
Paso Acción
1
El sistema muestra 2 pickers (Radial y Distancia DME) además de
la opción de cambio de frecuencia.
2
El piloto selecciona los valores del punto al que quiere ir.
3
4
(DST06) y con la que proporciona el piloto calcula el rumbo a
seguir.
5
El sistema muestra en pantalla el rumbo.
6
Flujo Alternativo
Paso Acción
6a.1 El piloto cambia parámetros del punto tras mostrarse el rumbo.
Postcondición
El piloto ha conseguido ir de un punto a otro.
Cuadro 54. Caso de Uso NV06 - Calcular Punto a Punto
63
Caso de Uso : NV07 Calcular Arco
Descripción
El usuario introduce las propiedades del arco, el sistema según la
posición del avión calcula el rumbo a marcar para entrar en dicho arco y
el error que tiene el piloto.
Precondición
Flujo Normal
Paso Acción
1
El sistema muestra 2 campos a rellenar (Distancia DME y sentido
de giro) y la opción de cambiar de estación.
2
El piloto rellena el campo con la distancia requerida y el sentido
de giro establecido.
3
4
(DST06) y con la que proporciona el piloto calcula el rumbo y el
error.
5
El sistema muestra en pantalla rumbo y el error (Izquierda o
derecha y error en NM)
6
Flujo Alternativo
Paso Acción
Postcondición
El piloto ha seguido el arco deseado.
Cuadro 55. Caso de Uso NV07 - Calcular Arco
Caso de Uso : NV08 Ver Instrumentos de Stand-By
Descripción
El Sistema muestra en pantalla una serie de relojes que imitan el tablero
de un avión. El piloto solo puede visualizar la información (excepto el
Altímetro).
Precondición
El dispositivo dispone de Sensor GPS y sensores de Movimiento.
Flujo Normal
Paso Acción
1
El sistema muestra los relojes: Se muestran:
• Velocidad (etiqueta GPS)
• Posición respecto el horizonte
• Altitud (etiqueta GPS)
• Régimen y coordinación de viraje
• Rumbo
• Cambio de altitud
2
El sistema pide información a Sensores de Movimiento y a Sensor
GPS.
3
Con los datos de los sensores el sistema calcula y muestra en cada
reloj su dato correspondiente.
Flujo Alternativo
Paso Acción
2a.1 El dispositivo dispone de Giróscopo.
2a.2 El Sistema pone la etiqueta GYRO en el Horizonte.
3a.1 El Dispositivo dispone de barómetro.
3a.2 El Sistema elimina la etiqueta GPS del altímetro.
3a.3 El piloto cambia la Capsula de Kollsman presionando el altímetro.
3a.4 El sistema muestra un Picker con los valores en milibares para
poner en la capsula.
3a.5 El sistema calcula la altitud mediante el barómetro y el valor de la
cápsula de Kollsman.
3a.6 El Flujo vuelve al punto 3.
64
Postcondición
3b.1 No hay respuesta del Sensor GPS y se avisa al usuario indicando
que no hay cobertura.
3b.2 Se marcan con aspas rojas los instrumentos implicados (Velocidad
y/o Altitud). Se devuelve el flujo al punto 2.
3c.1 La recepción GPS está apagada y se propone al usuario la opción
de conectarla.
3c.2 Se marcan con aspas rojas los instrumentos implicados (Velocidad
y/o Altitud). Se devuelve el flujo al punto 2.
El usuario ha utilizado los instrumentos de emergencia.
Cuadro 56. Caso de Uso NV08 - Ver Instrumentos de Stand-By
4.5 Subsistema Utilidades
En esta última parte están aquellos casos de uso que están relacionados con
herramientas para el piloto, como pueden ser: cálculo de equivalencias de unidades,
cálculo de combustible, cálculo de Viento y Velocidad Real, Cronometro, Notas e
Información de vuelo.
El Diagrama de Casos de Uso de este subsistema es el siguiente (Figura 13):
Figura 13. Diagrama de Casos de Uso - Subsistema Utilidades
65
64):
El detalle de cada caso de uso se nombra a continuación (del Cuadro 57 al Cuadro
Caso de Uso : UT01 Mostrar Nota
Descripción
El Sistema muestra en pantalla una lista de Notas escritas por el Piloto
anteriormente y este accede a una de ellas para ver su contenido.
Precondición
Ninguna.
Flujo Normal
Paso Acción
1
indicando la lista de notas guardadas ubicada en la memoria de la
aplicación. (DAP03).
2
Es sistema según el Ítem (Nota) seleccionado abre una nueva
ventana y muestra el texto anteriormente introducido por el
Piloto.
Flujo Alternativo
Paso Acción
1A No hay ninguna nota en la lista. El sistema llama al caso de uso
PA01 - Mostrar Lista Ítems pero al no haber ítems se muestra una
lista vacía y por consiguiente el piloto no elige ninguno.
1b.1 El Piloto desea crear una Nota.
1b.2 El sistema llama al caso de uso UT02 – Crear Nota.
1c.1 El Piloto desea borrar una de las Notas.
1c.2 El sistema llama al caso de uso UT03 – Borrar Nota.
Postcondición
El usuario ha consultado una nota.
Cuadro 57. Caso de Uso UT01 - Mostrar Nota
Caso de Uso : UT02
Descripción
Precondición
Flujo Normal
Flujo Alternativo
Postcondición
Crear Nota
El piloto desea crear una nueva nota y el sistema la crea y la guarda
Este caso de uso es llamado por Mostrar Notas – UT01.
Paso Acción
1
El sistema muestra una ventana con un campo de texto para
rellenar.
2
El piloto rellena la nota con la información que desea guardar.
3
El piloto selecciona guardar nota.
4
El sistema le pone de nombre la fecha y el inicio de la nota, y la
guarda en la memoria de la aplicación (DAP03).
5
El sistema muestra al usuario que se ha guardado correctamente.
Paso Acción
1a.1 El usuario sale de la aplicación tras iniciar la nota nueva.
1a.2 El sistema guarda la nota en el estado de la aplicación hasta que
se vuelva a la aplicación (DST07).
3a.1 El piloto descarta la nota.
3a.2 El sistema borra la nota. Fin del caso de uso.
4A El sistema no puede guardar la nota y se lo comunica al usuario.
Continúa el flujo en el punto 5.
El usuario ha creado una nota nueva y se ha guardado.
Cuadro 58. Caso de Uso UT02 - Crear Nota
66
Caso de Uso : UT03 Borrar Nota
Descripción
El piloto desea borrar una nota ya creada.
Precondición
Este caso de uso es llamado por UT01 - Mostrar Nota.
Existe al menos una nota en la memoria de la aplicación.
Flujo Normal
Paso Acción
1
El Piloto accede al menú de selección de Android.
2
El piloto selecciona las notas que desea borrar.
3
El piloto pulsa la opción de borrar.
4
El sistema borra de la lista las notas seleccionadas.
5
El sistema muestra al usuario que se han borrado las notas y
muestra una opción de deshacer.
6
El sistema borra las notas de la memoria de la aplicación (DAP03).
7
Se devuelve el flujo a UT01 - Mostrar Notas.
Flujo Alternativo
Paso Acción
3A El usuario cancela el borrado y sale del menú de selección de
Android. Se pasa al punto 7.
6a.1 El usuario presiona el botón deshacer.
6a.2 El sistema vuelve a mostrar en la lista las notas borradas.
Postcondición
El usuario ha borrado una nota.
Cuadro 59. Caso de Uso UT03 - Borrar Nota
Caso de Uso : UT04
Descripción
Precondición
Flujo Normal
Flujo Alternativo
Postcondición
Convertir Unidades
El piloto desea consultar una equivalencia entre dos unidades distintas.
Ninguna.
Paso Acción
1
El sistema muestra una pantalla con distintas pestañas disponibles
en función del tipo de unidades que desea buscar (U. Geográficas,
U. Físicas o U. Medioambientales).
2
El Piloto selecciona el grupo al que pertenecen las unidades
deseadas.
3
El Piloto selecciona entre las distintas unidades la unidad de
origen y la unidad de destino.
4
El Piloto introduce mediante el teclado el valor deseado
5
El sistema calcula, en función de las dos unidades seleccionadas y
el valor introducido, la equivalencia en la unidad de destino.
6
El sistema muestra en un campo el resultado del cálculo.
Paso Acción
5a.1 El usuario presiona el botón de intercambio de unidades.
5a.2 El sistema cambia la unidad de origen por la de destino y
viceversa.
5a.3 Se vuelve al flujo normal en el punto 5.
El usuario ha consultado una equivalencia de unidades.
Cuadro 60. Caso de Uso UT04 - Convertir Unidades
67
Caso de Uso : UT05 Calcular Datos del Aire
Descripción
El Sistema muestra en pantalla 2 parámetros numéricos (Temperatura e
IAS) que el piloto debe seleccionar correctamente a fin de que el sistema
calcule la velocidad Real (TAS) y el viento que está afectando la aeronave
(Rumbo/Intensidad).
Precondición
El dispositivo dispone de Antena GPS/GLONASS y sensores de
movimiento.
Flujo Normal
Paso Acción
1
modificar y un aviso para recordar al usuario que oriente el
dispositivo perpendicularmente al rumbo del avión.
2
El Piloto coloca correctamente el dispositivo (a 90º del morro del
avión, con la pantalla mirando al Piloto).
3
El Piloto selecciona los valores deseados de temperatura y
velocidad indicada.
4
El sistema pide información al sensor GPS y a los sensores de
Movimiento.
5
El sistema calcula en función de los datos del piloto y los de los
sensores la TAS, la dirección del viento y su intensidad.
6
El sistema muestra en pantalla la TAS y el Viento.
Flujo Alternativo
Paso Acción
5a.1 No hay respuesta del sensor. Se avisa al usuario indicando que no
hay cobertura.
5b.1 La recepción GPS está apagada. Se propone al Piloto la opción de
conectarla.
C
El dispositivo no dispone de Giróscopo. El sistema muestra en
pantalla un aviso de que la información solo es válida en vuelo
recto y nivelado.
Postcondición
El sistema ha calculado los datos del aire.
Cuadro 61. Caso de Uso UT05 - Calcular Datos del Aire
68
Caso de Uso : UT06 Calcular Combustible
Descripción
El Sistema muestra en pantalla un campo que el piloto debe rellenar con
el combustible que contiene la aeronave antes del despegue. Cuando la
aeronave se encuentra en vuelo el sistema calcula el combustible
remanente, el tiempo de funcionamiento del motor y la distancia
aproximada que puede alcanzar con dicho combustible en función de la
aeronave seleccionada.
Precondición
El dispositivo dispone de Antena GPS/GLONASS.
Existe un avión cargado en el sistema (DAP01).
Flujo Normal
Paso Acción
1
El sistema muestra 1 campo de texto donde indicar el combustible
a bordo, un botón de validación y los datos a mostrar
(combustible remanente, tiempo de vuelo y distancia alcanzable).
2
El Sistema saca del estado de la aplicación la cantidad de
combustible (DST05)(anteriormente calculada del caso de uso
PA07 - Calcular Mass & Balance) y la valida automáticamente.
3
El sistema accede al XML del avión seleccionado para conocer su
velocidad de crucero, capacidad del depósito y consumo medio
(DES04).
4
El sistema pide información al sensor GPS.
5
El sistema detecta que el avión está en vuelo (el dispositivo se
mueve a una velocidad mínima determinada) y empieza a contar
el tiempo de vuelo.
6
El sistema calcula en función de los datos suministrados y del
tiempo de vuelo la cantidad remanente, tiempo hasta agotar
combustible y distancia alcanzable.
7
El sistema muestra en pantalla los datos calculados y los guarda
en el estado de la aplicación (DST05).
Flujo Alternativo
Paso Acción
2a.1 El sistema no encuentra el dato de combustible en el estado de la
aplicación (DST05).
2a.2 El Piloto introduce la cantidad de combustible en los tanques y
valida el dato con el botón.
2a.3 Se devuelve el flujo normal en el punto 3.
5a.1 No hay respuesta del sensor. Se avisa al usuario indicando que no
hay cobertura.
5b.1 La recepción GPS está apagada. Se propone al Piloto la opción de
conectarla.
7a.1 El Piloto cambia la cantidad de combustible y presiona el botón
validar.
7a.2 El sistema pone a cero el tiempo de vuelo y recalcula los datos con
la nueva información guardando los correspondientes en el estado
de la aplicación(DST05).
Postcondición
El sistema ha calculado el combustible remanente.
Cuadro 62. Caso de Uso UT06 - Calcular Combustible
69
Caso de Uso : UT07 Usar Cronómetro
Descripción
El piloto desea cronometrar un tiempo y el sistema le proporciona un
cronómetro que cuenta desde/hasta que el piloto decide o suena una
alarma si se trata de una cuenta atrás.
Precondición
Ninguna.
Flujo Normal
Paso Acción
1
El sistema muestra los dígitos de un cronómetro, un botón de
Inicio/Parada, un botón de Restablecer y una opción de cuenta
atrás de 1m y 1m30s.
2
El piloto selecciona no tener una cuenta atrás.
3
El piloto pulsa el botón de Inicio/Parada
4
El sistema Inicia el cronómetro en un servicio independiente de la
actividad y muestra el tiempo correr en la actividad.
5
El piloto presiona el botón Inicio/Parada.
6
El sistema muestra el tiempo total.
7
El piloto presiona Borrar.
8
El sistema borra el tiempo y pone el contador a 0.
Flujo Alternativo
Paso Acción
2a.1 El piloto selecciona tener una cuenta atrás de 1m o 1m30s.
2a.2 El usuario presiona el botón Inicio/Parada.
2a.3 El sistema Inicia el cronómetro en un servicio independiente de la
actividad y muestra el tiempo correr en la actividad.
2a.4 El tiempo se agota. El sistema emite un sonido y parpadea la
pantalla dentro de la aplicación. Fuera de ella envía un mensaje a
la barra de Notificaciones.
2a.5 Se vuelve al flujo normal en el punto 8.
Postcondición
El usuario ha utilizado el cronómetro.
Cuadro 63. Caso de Uso UT07 - Usar Cronómetro
Caso de Uso : UT08
Descripción
Precondición
Flujo Normal
Flujo Alternativo
Postcondición
Ver Información de Vuelo
El piloto desea ver la información del vuelo actual.
Ninguna.
Paso Acción
1
El sistema busca todos los datos que existen en el estado de la
aplicación así como algunos de la memoria de la aplicación (avión
actual, datos del Mass&Balance, tiempo de vuelo del cálculo de
combustible, ultimo METAR consultado, información del FPL,…)
(DAP01, DST03, DST04, DST05, DST06, DST08).
2
El sistema muestra dichos datos en la pantalla en modo texto.
3
El piloto consulta dicha información.
Paso Acción
El usuario ha consultado la información de vuelo.
Cuadro 64. Caso de Uso UT08 - Ver Información de Vuelo
70
Capı́tulo 5:
Diseñ o
En este capítulo se muestra todo el desarrollo del diseño de la aplicación. En una
parte se diseña el interfaz gráfico y en la segunda parte se diseña el comportamiento
básico de la aplicación y la funcionalidad de Checklists.
5.1 Interfaz Gráfica
En esta parte se expone el diseño de la interfaz gráfica de toda la aplicación, y más
profundamente la interfaz de la funcionalidad del uso de Checklists. Se explica, para la
funcionalidad de Checklists, las posibilidades que tiene el usuario dentro de ella y sus
consecuencias en la aplicación.
Durante el diseño de esta, se ha seguido los principios de Google (ver 2.9 Interfaz
de Usuario) y se ha perseguido conseguir una interfaz que sea fácilmente usable por el
piloto (ver Cuadro 35. Req.No Funcional RNF04 - Facilidad de uso en Vuelo).
Otro de los objetivos de esta interfaz es tener compatibilidad con dispositivos con
pantallas grandes (ver Cuadro 34. Req.No Funcional RNF03 - Interfaz funcional en
Tablets), debido a eso se necesitan 2 diseños distintos; uno para móviles y otro para
Tablets. Como después se comprueba durante la implementación, Android provee a
los desarrolladores de herramientas que permiten evitar hacer el trabajo dos veces.
Elementos Comunes
En la totalidad de la aplicación existe un elemento que es común en todas las
pantallas, la barra Action Bar (ver 2.9 Interfaz de Usuario - Patrones de Diseño).
El icono de la aplicación se ha obtenido partiendo de SVG’s de dominio
público y modificados a gusto del alumno. Se trata de un HSI (de la FAA
americana) y una avioneta por delante (obtenido de la Open Clip Art Library).
Indica de forma gráfica el uso objetivo y la funcionalidad más atractiva.
Figura 14. Icono de la Aplicación
71
Prototipo de la Interfaz Gráfica (Anexo C)
Debido a la ingente cantidad de pantallas que contiene la aplicación se hace
inviable mostrarlas todas en esta memoria. Decidimos exportar la lista de
pantallas a un Anexo (Anexo C). En éste se le ha añadido la posibilidad de
interactuar entre los distintos botones de la aplicación haciendo más fácil el
visualizado de la interfaz.
Las Interfaces que finalmente se implementan, y por tanto, las que se detallan en
esta memoria son las siguientes:
Menú Principal
En el menú principal se muestran 4 botones asociados a 4 categorías. Cada
uno de ellos contiene funcionalidades asociadas a esa categoría. De esta forma el
Piloto no pierde tiempo buscando la actividad deseada en una larga lista, pues
conociendo dicha actividad sin dudas averiguará la categoría a la que pertenece
(ver Figura 15).
Al hacer clic el piloto en una de las categorías se muestra una lista con las
funcionalidades que ésta contiene.
En el caso de tener un dispositivo móvil la lista se mostrará en una ventana
nueva ocultando el menú principal. En caso de usar una Tablet se mostrará a la
izquierda el menú principal y a la derecha la Lista de Funcionalidades (ver Figura
17).
Figura 15. Diseño de la Pantalla Menú Principal
Figura 16. Diseño de la Pantalla Lista de Funcionalidades
72
En la versión móvil, en la Action Bar se muestra como nombre un Spinner con
las 4 Categorías permitiendo así la posibilidad de entrar en otra con menos pasos.
A la derecha del Spinner se muestra un botón que accede a las Checklists de
emergencia.
Lista de Funcionalidades
El contenido de estas dependerá de la categoría a la que se haya accedido. En
este caso se estudia el funcionamiento de la categoría Papeles por ser la que
contiene la funcionalidad de Checklists (Ver Figura 16 y Figura 17).
En ella se muestran en una lista simple las funcionalidades. Al hacer clic sobre
Checklists la aplicación iniciará la actividad de Checklists.
La Action Bar se mantiene igual que en el menú principal.
Como se ha mencionado antes, en caso de disponer de una Tablet el menú
principal y la lista de funcionalidades se muestran como una única interfaz (Figura
17).
Figura 17. Diseño en Tablet de Menú Principal – Lista de Funcionalidades
73
Menú Checklists
Al pulsar en Checklists en la lista de funcionalidades de Papeles se abre una
nueva Actividad. En ella se muestran 2 pestañas; una llamada Normales (por
defecto) y la otra Emergencia. Estas contienen una lista de las Checklists que han
encontrado en el XML del Avión (ver Cuadro 26. Req.Datos DES02 - Checklists),
cada una en su grupo.
En el caso de ser Emergencia solo se trata de una lista de las diferentes
Checklists. En el caso de ser Normales cada celda (cada Checklist) a su derecha
puede llevar una imagen de un stick para indicar al piloto que esa Checklist ya ha
sido utilizada y completada (ver Figura 18).
El Piloto, en el caso de tener un dispositivo móvil, al hacer clic en una de las
Checklist se abre (en una nueva ventana) la Checklist Actual ocultando la lista. En
caso de usar una Tablet se mostrará a la izquierda el menú de Checklists y a la
derecha la Checklist Actual (ver Figura 20).
En la Action Bar ahora en el nombre pone Checklists (sin Spinner) y
desaparece el botón de Checklists. Se mantiene el Action Overflow que añade la
opción de reiniciar todas las Checklists (borrar las que se hayan completado).
Figura 18. Diseño de la Pantalla Menú Checklists
Figura 19. Diseño de la Pantalla Checklist Actual
74
Checklist Actual
En esta pantalla se muestra una lista de ítems con formato (Objeto -- Acción)
y a la derecha de cada uno una imagen que, dependiendo del Piloto, será o vacía o
un stick. Cuando el piloto hace clic en el ítem correspondiente, este pasará de
inicialmente vacío a mostrar un stick indicando que la acción ha sido realizada.
La interfaz no permite que se puedan añadir sticks a ítems que no están
inmediatamente debajo del anteriormente pulsado, por lo que obliga al piloto a
realizar todos los pasos en secuencia).
Al terminar todos los ítems se muestra un texto indicando “Checklist
Completed” y marca con un stick la Checklist actual (ver Figura 19).
Como se menciona en el punto anterior, en caso de ser una Tablet7 el Menú
Checklists y Checklist Actual es una misma interfaz (Figura 20).
Figura 20. Diseño en Tablet de Menú Checklists - Checklist Actual
En la ActionBar se le añade al Action Overflow la opción de borrar la Checklist
actual (elimina los ítems completados anteriormente).
75
Menú Ajustes
Desde el Menú Principal se puede acceder, a través del Action Overflow, a los
ajustes de la aplicación (Figura 21). Este menú da las opciones de:
•
•
•
Cambiar de avión: Al pulsar se abre una nueva ventana con una lista
de los XML de aviones encontrados (ver Cuadro 25. Req.Datos DES01 Archivo XML del Avión).
Reiniciar la aplicación: Borra todos los datos temporales del vuelo
que estaba en curso.
Cambiar el idioma: Permite cambiar el idioma de la interfaz (sin tener
en cuenta las Checklists que provienen del XML y por lo tanto no son
traducidas).
Figura 21. Diseño de la Pantalla Ajustes
Se descarta el diseño de una pantalla de ajustes para Tablet diferenciada
porque el extra de espacio no aporta ninguna ventaja en este caso. Se mostrará
la lista utilizando toda la pantalla disponible.
76
5.2 Diseño de los Procesos
En este punto pasamos a mostrar el diseño principal de la aplicación desde el
punto de vista funcional. Para una mejor comprensión se utilizan diagramas UML
(actividad y clases).
Para el diseño de este se ha tenido muy en cuenta el uso de recursos tal y como
marca uno de los requisitos del proyecto (ver Cuadro 36. Req.No Funcional RNF05 Uso de Recursos). Otro de los puntos que se ha tenido en cuenta es seguir las
recomendaciones de Google para el desarrollo de aplicaciones (evitando el uso de
funcionalidades y librerías no estándar o no optimizadas para Android).
Los diseños funcionales se centran en lo relacionado con los interfaces gráficos
Menú Checklists y Checklist Actual.
Mostrar Listas y Checklist
En Menú Checklist se muestra una lista de Checklists que se carga desde un
XML. Debido a que esta debe recordar qué Checklists han sido completadas no se
trata solo de mostrarlas sino también de comprobar su estado (completado o no
completado) y marcarlo con un stick para que el Piloto sea consciente de ello.
Lo mismo ocurre con Checklist Actual, pero en vez de Checklists muestra los Ítems.
En las siguientes figuras se ve el funcionamiento (Figura 22 y Figura 23).
Figura 22. Diagrama de Actividad - Mostrar Listas
Figura 23. Diagrama de Actividad - Mostrar Checklist
En las acciones Mostrar Ítem Checklist de XML y Mostrar Ítem XML se carga la
información desde un XML pero para mejorar el uso de recursos se crea una
estructura de datos (que se ve más adelante) que lee al principio todo el XML y
guarda la información dentro de forma que no haya que acceder al XML cada vez
que se necesite información y así evitar el coste de memoria y procesador
asociado a dicha lectura.
77
Proceso Usar Checklists
Trata la funcionalidad asociada al interfaz Menú Checklists. En él se muestra
la lista de Checklists generada por la actividad Mostrar Listas (ver Figura 22) y
luego el Mostrar Ítems (ver Figura 23). A partir de aquí, el piloto va seleccionando
cada uno de los ítems para confirmar su ejecución. Según va pulsando ítems estos
se marcan con sticks y se añaden como ítems completados en la estructura de
datos. Al final cuando todos están completados se añade la Checklist actual como
completada y se informa al usuario que la lista ha sido completada.
En la siguiente figura (Figura 24) se puede ver su funcionamiento:
Figura 24. Diagrama de Actividad - Usar Checklist
Se considera Ítem correcto a seleccionar el ítem inmediatamente inferior al último
marcado. Con ello se asegura la ejecución de las tareas secuencialmente.
78
Proceso Usar Checklists de Emergencia
Este proceso es similar a Ver Checklist con la diferencia de que no se guarda
una relación de ítems y listas completadas, ya que una emergencia puede surgir
varias veces y no son listas que se deban ejecutar todas.
Figura 25. Diagrama de Actividad - Usar Checklist Emergencia
En este caso (Figura 25) se muestran simplemente las listas disponibles sin
verificar completadas y como en el caso anterior se comprueba que la ejecución
sea secuencial y se marca con un stick (visualmente) indicando que se ha
completado.
En el caso de salir de la aplicación sí se guardará una relación de ítems
completados, pero la gestión será desde el punto de vista de la interfaz.
Al completar la lista se lo indica al Piloto y al salir no se guarda ningún ítem.
79
Borrar Checklists Completadas
Dentro del interfaz Menú Checklists está (como se ha visto anteriormente) la
opción de borrar toda las listas que se han completado o medio completado. El
diagrama de actividad asociado sería el siguiente.
Figura 26. Diagrama de Actividad - Borrar Checklists Completadas
Borrar Ítems Completados
Esta función está disponible cuando se muestra una Checklist (Interfaz
Checklist Actual). Permite borrar los Ítems completados en ella hasta entonces y si
la Checklist estaba completa permite también borrarla de la lista de completadas.
Figura 27. Diagrama de Actividad - Borrar Ítems Completados
80
Diagramas de Clase (Libros de Checklists)
Las Checklists se guardan en el archivo XML del avión en cuestión en la
memoria externa (como ya se ha indicado anteriormente). Debido a que el acceso
a un archivo XML es caro desde el punto de vista de recursos, se opta por leer una
vez y guardar las Checklist en objetos dentro de la aplicación.
Dichos objetos serán instancias de la clase PlaneChecklists (Figura 28).
Se instanciarán 2 objetos; uno para Checklist Normales y la otra para las
Checklist de Emergencia. La razón de no contenerlas todas en la misma clase es
por su separación física en la interfaz y porque las Checklist de emergencia no
necesitan guardar su estado.
Todas las clases diseñadas para esta aplicación se incluyen dentro de un
mismo paquete (package). Las 3 clases que se van a implementar son:
PlaneChecklists, Checklist y CheckCompletas.
PlaneChecklists: Es la clase principal y desde la que se opera para gestionar todo
aquello relacionado con las Checklists. El encapsulado garantizará que el
acceso a estas sea mediante sus métodos.
Figura 28. Diagrama de Clases - Clase PlaneChecklists
Teniendo en cuenta la Figura 28 tenemos:
•
•
•
ChecklistsBook (libro): Un Array de Objetos Checklist. Cada uno de estos
objetos es una Checklist distinta.
Completed: Objeto CheckCompletas que gestiona qué Checklists e
Ítems internos están completados y cuáles no.
numChecklists: Indica el número de Checklists que contiene el objeto.
Útil para la implementación Android.
81
Por la parte de métodos públicos tenemos:
•
•
•
•
•
•
•
addChecklist(~): Añade una Checklist vacía al libro.
addItem(~): Añade un ítem a una Checklist determinada.
isCheckCompleted(~): Indica si la lista indicada está completada.
getChecklistItems(~): Devuelve un array de Strings con todos los ítems
de una Checklist concreta para ser listada en el interfaz mediante un
adaptador Android.
getAllChecklist(): Devuelve el array de Checklist para listar las Checklist
en el interfaz mediante un adaptador Android.
resetPlaneChecklists(): Borra todas las Checklists completadas y sus
ítems.
resetOneChecklist(~): Borra los ítems realizados de una Checklist en
particular y si está completada también la desmarca.
Checklist: Esta clase guarda la toda información de una Checklist en concreto.
Solo se puede instanciar desde dentro del package.
Figura 29. Diagrama de Clases - Clase Checklist
Según vemos en la Figura 29 consta de:
•
•
•
•
•
•
•
•
Nombre: El nombre de la Checklist (Before Take-off).
NumItems: Número de Ítems de la Checklist.
Ítems: Array de Strings con todos los Ítems con formato Objeto Acción.
Los métodos que tiene son:
Constructor.
addItem(~): Se le indica el Ítem en forma Objeto - Acción y lo añade a la
Checklist.
toString(): Necesario para el uso de adaptadores Android.
getAllItems(): Devuelve el Array de ítems para ser mostrados por un
adaptador Android.
getNumItems(): Devuelve el número de ítems que tiene la Checklist.
82
CheckCompletas: Esta clase es la encargada de guardar el estado de las
Checklists y sus ítems (completado o no completado). Como la anterior
sólo se puede instanciar desde dentro del package.
Figura 30. Diagrama de Clases - Clase CheckCompletas
Como se ve en la Figura 30, esta se compone de dos Arrays de
Integers. La existencia de esta clase se basa en la optimización del uso de
recursos. El funcionamiento es el siguiente:
Inicialmente a la hora de extraer los datos del XML se crean estas
listas de Integers. Según se va leyendo en esta se colocan el número de
Ítems de cada Checklist. Cada vez que el usuario selecciona un ítem para
marcar que está completado se resta uno al Integer de la lista
correspondiente en listaCheck de forma que:
•
•
•
Si el Integer = número de Ítems
 Lista sin Iniciar.
Si el Integer [1 - número de Ítems)  Lista parcialmente completada.
Si el Integer = 0
 Lista completada.
De la misma forma se puede conocer el número de ítems completados
gracias al segundo array (starList) que siempre contiene el número de
ítems totales de cada Checklist. También sirve para borrar las listas
completadas y sus ítems.
Así pues los métodos que contiene son:
•
•
•
•
•
addCheck(~): añade una nueva lista (Integer) a los arrays indicando su
número de ítems.
setCheck(~): Marca como completados el número de ítems que se
indique en la lista correspondiente.
resetAllCheck(): Vuelve a inicializar listaCheck con los valores iniciales
(de startList)
isCheckCompleted(~): Indica si la lista indicada está completada.
resetOneCheck(~): Inicializa la lista marcada con el valor de startList
asociado.
83
Archivo XML del Avión
Como en apartados anteriores se ha mencionado, se utiliza un archivo XML
ubicado en la memoria externa para guardar los datos del avión tal como:
nombre, pesos, Checklist, etc. La razón de usar XML es poder facilitar a un usuario
con un nivel medio de informática la realización de perfiles de avión nuevos. Cada
XML comprende un modelo avión.
El XML se dividirá en 3 grandes grupos (como se ve en el Cuadro 25). Estos
son: Datos Generales, Checklists y Mass & Balance.
Como en este proyecto solo se diseña e implementa el apartado de Checklists el
XML no tendrá información de los otros 2 apartados (salvo la imprescindible).
Así pues cualquier XML de avión seguirá el siguiente patrón:
Figura 31. Prototipo de Archivo XML de Avión
84
Capı́tulo 6:
Implementació n
En este capítulo se muestran los aspectos más significativos de la implementación
de la aplicación. Debido a la gran cantidad de trabajo que se sucede en este apartado
no se nombrarán todos los procesos, problemas y decisiones que se toman a lo largo
de la implementación. El objeto de este capítulo se centra en una visión general del
trabajo realizado, los sucesos más importantes y los que han supuesto un cambio en el
diseño propuesto.
Aunque en la implementación van fuertemente unidos, se puede hacer una
distinción desde el interfaz puramente gráfico (colocación de vistas) y la
implementación de su funcionamiento.
6.1 Implementación del Interfaz Gráfico
El Interfaz tal y como hemos visto en el diseño (5.1
dos versiones; una para móviles y otra para Tablets.
Interfaz Gráfica) se divide en
El interfaz en Android se especifica mediante archivos XML. Estos se guardan en
una carpeta llamada layout dentro del proyecto. Cada archivo XML representa una
vista individual, que puede contener dentro elementos visuales u otras vistas XML.
Aprovechando esta cualidad se puede reusar las vistas y así se ha intentado durante la
implementación.
Como dependiendo de la configuración del dispositivo (vista normal o en
apaisado) o del tipo de dispositivo (móvil o Tablet) se debe mostrar distintos interfaces
el SDK y sus normas proporcionan una serie de modificadores que indican que ciertas
vistas solo serán utilizadas en las condiciones que el modificador indique. Los
modificadores se señalan en el nombre de la carpeta en la que se colocarán las vistas
que tengan que activarse en esa configuración. Por ello tenemos:
•
•
•
layout: Todas las vistas que se encuentren aquí se cargarán por defecto, es
decir, si no se encuentra una vista que coincida con la configuración actual.
layout-land: El Sistema usa estas vistas cuando el dispositivo se encuentra
en apaisado (Landscape)
layout-sw***dp: El sistema usará estas vistas en el caso que el lado más
pequeño de la pantalla disponible sea igual o superior a la cifra marcada
(smallest width). Esto a la práctica permite diferenciar un dispositivo móvil
de una Tablet. En el proyecto se usa un dp de 600 que suele ser el estándar
utilizado para tablets pequeñas(6-7’’).
85
Además se permite la concatenación de modificadores, como es el caso de layoutsw600dp-land, de forma que la vista se utilizaría en el caso de que las 2 condiciones se
cumplan. Para el correcto funcionamiento de este sistema los nombres de los archivos
deben ser el mismo en cada una de las carpetas que existan modificaciones para que el
sistema luego las utilice según la configuración.
Para conseguir distintos idiomas se utilizan también modificadores en la carpeta
de valores (values). Así tenemos los valores en ingles values–en, español values–es,
francés values–fr, etc. Gracias a esta funcionalidad no se necesita una configuración de
idioma, pues Android carga el idioma que se corresponda con el que está usando el
usuario en el sistema. Si este no existe carga por defecto values (sin modificador).
Layouts Principales
Dicho esto en el proyecto tenemos los siguientes layouts principales:
•
main.xml: Determina el layout dependiendo de la configuración.
Tiene 2 configuraciones; móvil y Tablet (con dos pequeñas variaciones de
normal y apaisado)
- En la versión móvil sólo se muestran los botones. Las categorías son
mostradas por otra actividad distinta.
- En la versión Tablet se muestran los botones en un lado y las listas en
catFragment.
Figura 32. Layout Principal main.xml
•
•
category_list.xml: Contiene los botones del menú principal.
Existen 2 versiones; normal y apaisado. Para el modo Tablet apaisado
existe una pequeña modificación que permite ver bien los nombres.
checklist_main.xml: Determina el layout del apartado Checklist (Figura
33).
Contiene 2 versiones (móvil y Tablet):
- En la versión móvil solo existe un apartado llamado frameChecklist y
todas las vistas se cargan en ese contenedor (Listas e Ítems).
- En la versión Tablet hay 2 apartados; bookChecklist que muestra las
listas e itemsChecklist que muestra los ítems.
86
Figura 33. Layout Principal checklist_main.xml
El código fuente de estos layouts se encuentran en el Anexo D.
El Spinner de Categorías
En la versión móvil al acceder a una de las categorías (presionando uno de los 4
Botones del Menú Principal) se muestra una lista con las funciones de dicha categoría.
Al no tener disponible los botones (como ocurriría en la versión Tablet) se hace más
complejo al usuario cambiar entre categorías por lo que se decide añadir un Spinner
(Lista Desplegable) en la Action Bar tal y como recomienda Google.
Para ello se utiliza el modo de la Action Bar NAVIGATION_MODE_LIST. Este
permite añadir dentro del Action Bar una lista desplegable. Esto se consigue mediante
un Adaptador con las opciones que debe mostrar, unos layouts de cómo visualmente
van a mostrar los elementos y finalmente se debe implementar el Listener que será
llamado cuando se seleccione una categoría desde el Spinner. Ver Figura 34.
//Set the Action Bar
ActionBar actionbar = getActionBar();
actionbar.setDisplayShowTitleEnabled(false);
actionbar.setDisplayHomeAsUpEnabled(true);
actionbar.setNavigationMode(ActionBar.NAVIGATION_MODE_LIST);
//Set the Spinner Adapter
ArrayAdapter<CharSequence> adapter = ArrayAdapter.createFromResource(this,
R.array.catActivity_spinner,
R.layout.simple_spinner_item);
adapter.setDropDownViewResource(android.R.layout.simple_spinner_dropdown_item);
//Set the Callback Listener
actionbar.setListNavigationCallbacks(adapter, new OnNavigationListener() {
@Override //When the user Changes the Category through the Spinner
public boolean onNavigationItemSelected(int itemPosition, long itemId) {
spinPos=itemPosition;
//Set the Fragment Transaction with the new Fragment
catFragment catDetail = catFragment.newInstance(spinPos);
getFragmentManager().beginTransaction()
.replace(android.R.id.content, catDetail)
.setTransition(FragmentTransaction.TRANSIT_FRAGMENT_OPEN)
.commit();
return true;
}
});
Figura 34. Código catActivity.java. onCreate() - Implementación del Spinner
87
Pestañas en las Checklists
Para mostrar la lista de Checklists Normales o Emergencia se buscaba el uso de
pestañas. A partir de Android 4 las pestañas forman parte de la Action Bar y no son
una vista que se nombra en los XML de los GUI. Son implementadas desde el código
Java y son el otro modo (junto al Spinner) de Navegación Lateral que proporciona
Android.
Para implementarlas el modo a utilizar debe ser NAVIGATION_MODE_TABS. Este
modo necesita que se creen las pestañas necesarias con un nombre a mostrar (que en
nuestro caso depende del idioma). A cada pestaña se le asocia una clase implementa el
Listener de dicha pestaña (BookTabListener<T>) que indica el comportamiento de las
pestañas al cambiar entre ellas. En este caso a dicho Listener se le proporciona una
clase heredada de Fragment (bookNormTab y bookEmergTab) que indica el
comportamiento y las vistas que tiene que mostrar.
//Initiate ActionBar with tabs and up Button
actionbar = getActionBar();
actionbar.setDisplayHomeAsUpEnabled(true);
actionbar.setNavigationMode(ActionBar.NAVIGATION_MODE_TABS);
//Add the Two Tabs
Tab NormalChk = actionbar.newTab().setText(R.string.checklist_tab_normal);
Tab EmergeChk = actionbar.newTab().setText(R.string.checklist_tab_emergency);
//Set the Listeners
NormalChk.setTabListener(new
BookTabListener<bookNormTab>(this,PFStat.cFTAG_NORMAL,bookNormTab.class));
EmergeChk.setTabListener(new
BookTabListener<bookEmergTab>(this,PFStat.cFTAG_EMERGENCY,bookEmergTab.class));
<MORE CODE>
//Add the Tabs to the ActionBar and set Selected Tab through isEmergency
actionbar.addTab(NormalChk, !isEmergency);
actionbar.addTab(EmergeChk, isEmergency);
Figura 35. Código CheckActivity.java. onCreate() - Implementación de Pestañas
Recursos Visuales
Para mejorar el interfaz y hacerlo más atractivo se han utilizado una serie de
imágenes e iconos creados por el alumno.
El primer recurso es el icono de Checklist de Emergencia. Un icono que muestra
una Checklist y una señal de atención o peligro. Para un piloto la relación imagenacción es inmediata ya que tiene similitudes con la forma de una Checklist real.
Figura 36. Icono Checklist de Emergencia
El segundo recurso es un PNG-9-Pach (escalable dinámicamente) que consiste en
una sombra con transparencia que, añadida en las pestañas, ofrece un efecto en 3D en
el modo Tablet.
88
El tercer recurso a nombrar es una imagen de un avión simplificado usado en las
opciones de la aplicación para elegir el avión actual. También se utiliza un recurso de
Android (Iconos Estandarizados) para la opción de Reiniciar la Aplicación.
Otros recursos son imágenes con transparencia en el modo Tablet que tienen un
carácter puramente ornamental. En el Menú Principal se muestra el logo de la
aplicación en grande y en las Checklists se muestra un dibujo de una Checklist.
6.2 Presentación de la Implementación del Sistema
Antes de ahondar en los retos de la implementación del sistema vamos a mostrar
una visión global de cómo está implementado el sistema.
La aplicación puede dividirse en dos grandes grupos (separados además, en 2
paquetes Java distintos):
Paquete Principal (com.gmail.mikepilot.PilotFMS)
Este Paquete se encarga de la funcionalidad básica de la aplicación. Sus
principales funciones y principales componentes son:
•
•
•
•
•
•
•
•
•
•
•
Mostrar el Menú Inicial al ejecutar la Aplicación.
Contiene los Menús Principales.
Comprobar que todos los recursos necesarios para el correcto
funcionamiento están disponibles (incluso solucionar la falta de algunos).
Realizar correctamente el comportamiento de las distintas vistas y menús
cambiando entre unas y otras. También reubicar las vistas ante un cambio
de la orientación del dispositivo.
Contiene la implementación de la estructura de datos que guarda las
Checklists en tiempo de ejecución (PlaneChecklists, ver 5.2 - Diagramas de
Clase).
Realizar la traducción de XML a dichas estructuras de datos.
Encargarse de cambiar su funcionamiento según el tipo de dispositivo que
lo ejecuta (Tablet o Smartphone).
Contiene el apartado de Ajustes generales que se encarga de cambiar de
avión seleccionado y de reiniciar la aplicación.
Recuperar las estructuras de datos actualizadas que devuelven otras
actividades.
Mostrar una demostración (imagen estática) de las funcionalidades no
implementadas en este proyecto.
Contiene la implementación de los diálogos de alerta que se muestran en
toda la aplicación.
89
A continuación se muestra una lista de las clases que están contenidas
(Clase (clase que extiende)) y una breve descripción de su cometido:
MainMenu (Activity): Actividad que se encarga mostrar la pantalla Principal y
los menús, controla los recursos e inicializa estructuras de datos.
MainFragment (Fragment): Muestra la pantalla inicial con los 4 Botones. Es
gestionada por MainMenu.
CatFragment (ListFragment): Muestra las distintas funcionalidades de cada
categoría dependiendo de qué categoría en cuestión se haya pulsado.
También es la encargada de iniciar la funcionalidad que desee el usuario y
mandar los datos necesarios, así como recibirlos al volver de dicha
funcionalidad. Es gestionado por MainMenu o por CatActivity (si se trata
de un Smartphone).
CatActivity (Activity): Actividad puente que se utiliza en el caso de usar un
Smartphone para mostrar las categorías (CatFragment) en una sola vista.
Añade una funcionalidad que es el Spinner (Lista Desplegable) que permite
cambiar entre categorías desde la misma vista (sin volver Atrás).
PilotAlertDialog (DialogFragment): Pequeño Fragment que muestra una
ventana de alerta en los casos que la memoria no esté disponible y cierra
la actividad.
AppPreferences (Activity): Actividad que aloja el Fragment de las preferencias.
AppPreferencesFrag (PreferenceFragment): Fragment que se encarga de las
preferencias del sistema. Carga la vista, se encarga de buscar archivos XML
de aviones para ofrecérselos al usuario en caso de que quiera cambiar de
avión y permite, en su caso también, que se reinicie la aplicación.
PFStat: (PilotFMS Statics) Contiene todas las constantes estáticas (Strings y
Enteros) que se usan en toda la aplicación para evitar el uso de hardcode.
PlaneParser: Clase que se encarga de la operación de leer un archivo XML y
pasarlo a estructuras de datos que entiende la aplicación.
PlaneChecklists, Checklist y CheckCompletas: Implementación de la estructura
de datos que contiene las Checklists (ver más atrás).
DemoView (Activity): Actividad que muestra una imagen (demostración) de las
funciones que aún no han sido implementadas a fin de poder tener, de un
modo gráfico, una visión general del futuro sistema completo.
TwoOptionAlertDialog(DialogFragment): Fragment que se encarga de mostrar
alertas genéricas con dos opciones.
TOAlertDialogListener(Interface):
Interface
que
debe
indicar
comportamiento que tienen los 2 botones de TwoOptionAlertDIalog.
90
el
Paquete Checklists (com.gmail.mikepilot.PilotFMS.Papers.Checklist)
Este Paquete se encarga exclusivamente de todo lo relacionado con la
funcionalidad de Checklists. Sus principales funciones son:
•
•
•
•
•
•
Muestra la pantalla de Checklists (que dependiendo del dispositivo serán
distintas) y carga la información del avión.
Crea 2 Pestañas en la Action Bar (una con las Checklists de Emergencia y
otra con las Normales) en las que se muestra una lista de checklists.
Muestra las listas de ítems que debe realizar el Piloto en una Checklist
previamente seleccionada.
Permite al usuario hacer uso de las Checklist haciendo clic en los ítems.
Gestiona el funcionamiento de todas las ventanas y menús dentro de la
funcionalidad Checklist (moverse hacia una Checklist, volver atrás, Arriba,
cambiar orientación, etc.).
Devuelve a la aplicación principal las Checklists actualizadas.
Estas Funcionalidades están implementadas en las siguientes clases:
CheckActivity (Activity): Es la Actividad principal en Checklists. Es la encargada
de mostrar las vistas, de crear las pestañas e iniciarlas, de activar las
Checklist de emergencia en caso de que el usuario use el Botón
Emergencia, controlar las vistas (mostrar las vistas según el dispositivo,
entrar en una Checklist determinada, subir o volver atrás, cambiar la
orientación), borrar las checklists completadas, etc.
BookTab (ListFragment): Fragment abstracto que determina las
funcionalidades en común que tienen las pestañas (emergencia y normal).
Entre ellas están el mostrar las vistas (dependiendo del dispositivo),
marcar la Checklist seleccionada en el modo Tablet,…
BookNormTab (BookTab): Especificación de BookTab para las listas normales.
Llama al Interface onChecklistSelectedListener (que implementa
CheckActivity) para mostrar la Checklist Normal seleccionada.
BookEmergTab (BookTab): Especificación de BookTab para las listas de
emergencia. Llama al Interface onChecklistSelectedListener (que
implementa CheckActivity) para mostrar la Checklist de Emergencia
seleccionada.
BookTabListener (TabListener): Se encarga de gestionar las pestañas
(BookNormTab y BookEmergTab). Las Inicializa y controla cuando se
cambian entre ellas o se pulsa sobre la que está activa. Según el caso,
realiza un cambio de vista (en la pantalla que ocupan), o también realizan
alguna tarea de borrado de datos o ajuste de parámetros.
ChecklistDetails (ListFragment): Se encarga de mostrar los ítems de una
Checklist determinada por CheckActivity, y de guardar las listas
91
completadas y los ítems de cada una de ellas que estén completados.
También añade la opción de borrar sólo la Checklist actual.
OnChecklistSelectedListener (Interface): Interface implementado en la práctica
por CheckActivity que determina el método onChecklistSelected(), que se
encarga de hacer que el dispositivo muestre una Checklist elegida por el
usuario (es decir, muestre sus ítems).
6.3 Vista General del Sistema
Para desarrollar aplicaciones con distintas versiones, dependiendo del dispositivo
(a partir de Ice Cream Sandwich), se han encontrado dos posibilidades:
•
•
Usar varias Actividades para mostrar los distintos Fragments que muestran
las vistas de forma que el control de la aplicación se distribuye entre ellas.
Usar una única actividad que va mostrando todos los Fragments según se
vayan necesitando y por tanto se encarga de todo el control de la
aplicación.
Dado que ambas son válidas y depende del tipo de aplicación y del desarrollador,
para enriquecer más los conocimientos de Android decidimos realizar cada paquete de
una forma distinta; el paquete principal contiene 4 actividades que se reparten las
tareas y el paquete Checklists utiliza una única Activity que gestiona todo el trabajo.
Figura 37. Relación Activities-Fragments
En el cuadro anterior (Figura 37) se muestra la relación entre las distintas
Activities y los Fragments que gestionan en cada paquete por separado. El movimiento
92
entre Activities se realiza mediante Intents (ver Intent). Las actividades pueden reusar
un mismo Fragment de forma que se aprovecha el código y la funcionalidad para varios
apartados. El caso de CatActivity solo ocurre si se utiliza un SmartPhone porque se crea
una segunda vista para ver el contenido de la categoría. Si se usa una Tablet todo se
muestra en la misma pantalla y CatActivity nunca se crea.
6.4 Elementos Comunes del Sistema
Aunque cada clase tenga su propio cometido, todas contienen una serie de
elementos comunes que se explican a continuación y que ayudan a entender mejor la
implementación de una aplicación Android. Los dividimos en dos apartados Métodos
(de una clase o clases) y Procedimientos (entendiendo como formas de proceder).
Métodos Comunes
Como ya se explica en 2.6 - Ciclo de Vida de una Activity, utilizamos las
llamadas que son realizadas por el sistema según cambian el estado de la
actividad. De todas esas posibilidades, en la práctica se usan unas pocas
(onCreate, onStart y onCreateView). Sin embargo sí existen otras llamadas que
realiza el sistema para muchos otros casos, y son, junto con las antes nombradas,
las que dan autentica movilidad al sistema. En nuestro caso los métodos que más
utilizamos son:
onCreate(Bundle estadoGuardado): Lo utilizamos para comprobar que los
recursos están disponibles, inicializar variables, cargar valores enviados por
otra aplicación, indicar el comportamiento de elementos como la ActionBar y
establecer su layout XML.
También es la encargada de recuperar los datos de un estado anterior. Esto
ocurre porque al cambiar la orientación Android re-crea la actividad completa
para mostrar su nueva vista.
onCreateView(Bundle
estadoGuardado):
Se
ejecuta
cuando
la
Actividad/Fragment va a ser mostrado en pantalla. Tiene más sentido usarlo
en los Fragments ya que puede darse el caso de crear un Fragment pero no
mostrarlo inmediatamente en pantalla. También contiene el Bundle que te
permite recuperar datos de un estado anterior.
onStart(): Se ejecuta cuando se va a iniciar la actividad, ya sea por primera vez , al
volver de otra actividad o de otra aplicación del teléfono. En este proyecto se
utiliza para modificar o actualizar valores que han podido ser cambiados por
otras aplicaciones.
onActivityCreated(Bundle estadoGuardado): Esta es exclusiva de los Fragments y
se ejecuta una vez la actividad asociada a ese Fragment (en ese momento)
termina la ejecución de su onCreate(). En este caso lo usamos porque dentro
de este método nos aseguramos que podemos acceder a cualquier elemento
de la Activity con el convencimiento de que está todo inicializado y es
93
funcional (por ejemplo el acceso a los Books de Checklists que se crean en la
actividad). Por ello, en este método realizamos todo lo que hace onCreate()
del Fragment por lo que normalmente, si existe onActivityCreated() no existe
un onCreate(), y si existe tiene poca carga.
onSaveInstanceState(Bundle estadoSalida): Este método es el que se tiene que
encargar de guardar todos los datos que sean necesarios ante una
destrucción del Fragment/Activity. Se ejecuta automáticamente al destruir
una Activity/Fragment. Principalmente lo usamos para guardar posiciones del
cursor, vista cargada y también guarda los Books de Checklist para no tener
que volver a buscarlos en el XML.
onCreateOptionsMenu(Menu menu): Este se utiliza para añadir opciones en el
ActionBar, ya sean iconos u opciones de texto. Las carga de un XML (alojado
en la carpeta menú) o también se puede crear en el código a través de la
clase Menu. En nuestro caso utilizamos los 2 métodos a lo largo de la
aplicación. Hay que tener en cuenta que este método sólo crea la vista
(icono, nombre, etc.) y no le da funcionalidad ninguna.
onOptionsItemSelected(MenuItem menu): Este método se ejecuta cuando un
ítem de la ActionBar es pulsado. El Ítem pulsado se reconoce por el
MenuItem que se le pasa. En nuestra aplicación usamos el método
menu.getItemId() para obtener su identificador y hacer un switch a fin de
discriminar qué opción se ha pulsado y, en consecuencia, qué acción se debe
tomar. Por ejemplo, aquí es donde se da funcionalidad al botón Arriba, al
botón de Checklist de Emergencia, opción de borrar Checklist…
onBackPressed(): Se ejecuta cuando se pulsa el botón volver del dispositivo.
Como regla general funciona de forma autónoma volviendo a la pantalla
anterior, pero en algunos casos hay que sobrescribirla y guardar datos o
mostrar vistas que por defecto no mostrarían. En nuestro caso tenemos que
implementarla porque según sea un Smartphone o una Tablet el
comportamiento es distinto. Además se encarga también de devolver los
Books actualizados a la actividad superior ya que sino se perderían.
onItemListClick(Listview lista, View ítem, int posición, int id): Es propio de los
ListFragments (subclase de Fragments que contiene una Lista). Se ejecuta
cuando el usuario hace clic en un Ítem en particular. Es donde se le da
funcionalidad. Para ello se puede conocer el ítem por la posición en la lista
(Int) o por alguna propiedad (View). En nuestro caso utilizamos la posición y
lo hacemos en muchos lugares: elegir categoría, elegir función, elegir lista,
seleccionar ítem completado…
94
Procedimientos Comunes
Iniciar Actividades y devolver Elementos: Ya hemos hablado de pasar datos a una
Activity mediante Intent y devolver datos, pero no hemos concretado cómo
se hace:
•
Primero hay que crear una instancia y meter los datos dentro como
pares llave-valor usando un método universal para todo tipo de datos:
intent.putExtra(“nombre”, variable). También existe la posibilidad de
crear un Intent pasándole al constructor un Bundle, por lo que
automáticamente metería todo lo que hay en él dentro del Intent.
•
Segundo hay que indicarle al Intent quien es el Destinatario. En
nuestro caso utilizamos el método intent.setClass(contexto,
clase.java) donde le añadimos la clase que implementa la Activity que
queremos que se ejecute. Existen otros métodos de mandar un
destinatario de forma no explicita (lo elige Android), pero que no se
utilizan en este proyecto.
•
Entonces se ejecuta el método startActivityForResult(Intent, Código
de Respuesta). A este se le indica el Intent creado y un código que
servirá para identificar luego el retorno de la aplicación. Este método
hace que se cree la actividad y se muestre en pantalla.
•
Dentro de la nueva Actividad se accede al intent mediante
intent=getIntent() y una vez tenemos la instancia de éste accedemos
a
sus
extras
guardados
usando
variable=intent.get___Extra(“nombre”), que varía según el tipo
devuelto.
•
Cuando se pulsa atrás o Arriba dentro de la nueva actividad estos
deben ser programados para que recojan los datos necesarios,
marquen la actividad como correcta y la finalicen. Para ello se utiliza
setResult(resultado, Intent) de igual forma se le añaden los datos al
Intent, se ejecuta esta orden y finalmente la orden finish().
•
Cuando se finaliza la actividad el flujo vuelve a la actividad que había
llamado y se ejecuta el método
onActivityResult(código de Respuesta, Resultado, Intent). Dentro de
este se debe realizar la comprobación de que sea correcto y que se
trate de la actividad deseada.
Una vez realizada la comprobación se accede al Intent y se recogen los
datos mediante variable=intent.get___Extra(“nombre”).
95
Guardar/Recuperar el Estado Anterior: Como hemos mencionado
anteriormente existe una llamada onSaveInstanceState() que usamos para
guardar datos necesarios. El procedimiento que se lleva a cabo es el
siguiente:
•
Se sobrescribe el método onSaveInstanceState(Bundle bdle) de la
siguiente forma: Se usa el Bundle para introducir los valores dentro
de él mediante pares llave-valor usando los métodos
bdle.put___(llave, variable) según el tipo de variable.
•
Al cerrarse la Actividad/Fragment el sistema llama a este método y
guarda los datos.
•
Al crearse de nuevo en el método de inicialización (ya sea
onCreate(), onActivityCreated() u onCreateView()) se hace una
condicional al Bundle aportado. Si es NULL significa que no hay
estado guardado y no hay nada que recuperar. Si por el contrario
tiene información se recupera usando variable=bdle.get____(llave)
para cada uno de los datos guardados.
Transacción de Fragments: Android llama Transacción en este contexto a
cambiar la vista actual definida por un Fragment por otro distinto dentro
de la misma Actividad. Para realizar estas transacciones se utiliza el
FragmentManager, que es la clase que gestiona los cambios de Fragments.
Estos cambios se denominan FragmentTransaction y se realizan de la
siguiente forma:
•
Se consigue el Fragment Manager y se le pide una nueva transacción
mediante
el
método
de
la
Actividad
transaction=getFragmentManager().beginTransaction().
•
Se le añade un tipo de animación que se usará al cambiar el Fragment
con transaction.setTransition(tipo de animación).
•
En algunas ocasiones interesa que la vista que se queda detrás se
guarde para luego acceder a ella al volver atrás o subir arriba, para ello
se usa la opción transaction.addToBackState(true). Esto produce que la
vista quede guardada en una pila de Fragments que crea Android.
•
Se le indica el cambio de pantalla donde se aporta el nuevo Fragment a
mostrar. Para ello se usa:
transaction.replace(contenedor, Fragment, Tag identidicativo)
El contenedor es donde la vista es mostrada, que dependiendo del
dispositivo puede ser distinta; el Fragment es el nuevo a mostrar, y el
Tag identificativo sirve para luego poder rescatar la vista de la pila de
fragments.
•
Finalmente y para que la transacción se lleve a cabo hay que ejecutar el
método transaction.commit(). En algunos casos (volver atrás o arriba)
96
puede ser interesante borrar la pila de Fragments (o parte de ella) ya
que los guardados ya no tienen sentido en la posición actual, el método
que permite eso es getFragmentManager().popBackStack() o su
variante con la opción de introducir el Tag hasta el cual borra.
Muestra de Diálogos: Los diálogos son ventanas que se muestran al usuario
tapando parcialmente la vista del programa. Como comentamos
anteriormente (ver 2.9 - Patrones de Diseño) sólo se deben mostrar al
usuario cuando hay un cambio o suceso importante en la aplicación que
repercute directamente al usuario. En nuestro caso lo utilizamos en los
casos siguientes: Falta de acceso a la memoria externa (por la que se nutre
de los datos de checklists), cambios de configuración y reinicio de todas las
checklists.
Para ello se crea una nueva clase que extiende a DialogFragment. Dicha
clase tiene:
•
Constructor estático newInstance(título, mensaje, ok, cancel): En él
se le indican los recursos String que contienen el título, el mensaje,
el mensaje en el botón ok y el mensaje en el botón cancelar. Este
crea una instancia de la clase y le añade todos los strings como
extras (Bundle).
•
Método obligado onCreateDialog(bundle estadoGuardado). Este
método se ejecuta al mostrarse el diálogo. Este crea el diálogo
usando los argumentos anteriores y también debe definir un
comportamiento para los botones OK y CANCEL mediante
builder.setPositiveButton() y builder.setNegativeButton(). Cada
uno de estos métodos se define mediante una clase anónima que
implementa las acciones que realizan cada uno de ellos.
En nuestro caso ejecuta los métodos (para cada caso) de un
Interface (el Listener TOAlertDialogListener) que la Activity que
quiere mostrarlo debe implementar.
Finalmente debe instanciarse el diálogo de la siguiente forma:
•
Se llama al constructor estático y se le pasan los parámetros
antes mencionados. myAlertDialog.newInstance(__,__,__,__).
•
Se le indica al dialogo que debe ser mostrado medante:
myAlertDialog.show(Gestor de Fragments, Tag Identificativo).
97
6.5 Principales Retos y Cambios de Diseño
En este apartado se exponen los hechos más destacables de la implementación de
la aplicación; los que han significado un cambio en el planteamiento inicial y aquellos
que han supuesto un esfuerzo para superarlos.
En primer lugar los cambios de diseño:
Cambio de Diseño - Mostrar Lista y Mostrar Ítems
En el diseño inicial (ver punto 5.2 Diseño de los Procesos) se contemplan dos
procesos: uno para mostrar las lista de checklists y otro para mostrar los ítems de
una checklist. Durante la implementación se realizan una serie de cambios
respecto a lo diseñado.
Mostrar Lista: En el caso de Mostrar Lista, decidimos eliminar la característica de
mostrar si una lista ha sido completa por 2 razones: primero, porque no
supone una funcionalidad importante (un piloto conoce en qué parte de un
vuelo se encuentra); y segundo, por simplificar la complejidad el proyecto. En
consecuencia el diagrama de Actividad se modifica y termina por resultar una
sola acción, que es “Mostrar Ítem Checklist de PlaneChecklsits” hasta que se
muestren todas las Checklists.
Dicha acción se realiza automáticamente con la utilización del Adaptador
de Listas que proporciona Android de la siguiente manera (ver Figura 38).
public void onActivityCreated(Bundle savedInstanceState) {
super.onActivityCreated(savedInstanceState);
//Set the adapter with the Checklist information from CheckActivity
CheckActivity parentAct = (CheckActivity) getActivity();
setListAdapter( new ArrayAdapter<Checklist>(
getActivity(),
android.R.layout.simple_list_item_activated_1,
parentAct.normalbook.getAllChecklists() ) );
}
Figura 38. Método onActivityCreated() de BookNormTab.java
En este ejemplo (de las listas Normales) se puede ver como se llama al
método SetListAdapter() que espera un Adaptador con la lista a mostrar. Este
Adaptador se crea de forma anónima ya que no va a ser utilizado por nadie
más. Se realiza de la siguiente manera:
new ArrayAdapter<Tipo de elemento a mostrar>( contexto, formato visual de
la celda, lugar donde se encuentran los objetos);.
El tipo de elemento debe tener definido el método toString() para que
pueda ser impreso en el ítem correspondiente. El lugar de los elementos en
este caso es la estructura de datos PlaneChecklist (una instancia suya llamada
normalBook que contiene las checklists normales).
98
Mostrar Checklist:
En el caso de mostrar una checklist el cambio es más bien puntual. En vez
de realizar el marcado de ítems al mostrar (tal y como se plasma en el
diagrama, ver Figura 23), éste se produce en un segundo pase ya que la
muestra de ítems es gestionada internamente por Android. Para ello utilizamos
un método llamado checkSavedItems() (ver Figura 39).
void checkSavedItems(){
// Get the number of completed items for the current Checklist.
completedItems =
actualBook.getCheckNumItems(currentChecklist) actualBook.getRemainingItems(currentChecklist);
// Mark (with a stick) that number of items that are already done.
for(int i=0;i< completedItems;i++){
getListView().setItemChecked(i, true); }
}
Figura 39. Método checkSavedItems() de CheckDetail.java
En este código primero se calcula el número de ítems que hay que marcar
(aprovechando la particularidad de que se completan de forma secuencial) y, una
vez conocido el número, se marcan.
Cambio de Diseño - Borrar Checklist
En el diseño de la aplicación (ver punto 5.2 Diseño de los Procesos - Borrar
Ítems Completados) se muestra un diálogo de confirmación del usuario, pero
consideramos que para el borrado de una checklist no queda suficientemente
justificado su existencia debido a que si se pulsa por error no supone un gran esfuerzo
repetir la checklist. Por lo cual se decide eliminar el diálogo.
Cambio de Diseño – Usar Checklist de Emergencia
El proceso Usar Checklist de Emergencia (ver punto 5.2
Diseño
de
los
Procesos) también sufre cambios en la implementación. Debido a que Android
destruye la actividad cuando se cambia la configuración (cambio de orientación) se
deben guardar los ítems para que se vuelvan a cargar.
Ese cambio hace que el proceso de usar las checklist de emergencia sea igual que
el de checklists normales, con una diferencia; al salir del proceso se borran todos los
cambios realizados usando el método de PlaneChecklists resetPlaneChecklists().
Este cambio resulta un poco problemático debido a que existen varias formas de
salir del proceso (botón atrás, botón arriba, pulsar pestaña,…) y debe de realizarse
dicho borrado en esos eventos.
99
Implementación de PlaneChecklists
Tal y como se describe en el capítulo 5.2 Diseño de los Procesos - Diagramas
de Clase, las checklists se guardan en una estructura de datos que evita el tener
que acceder al XML cada vez y soluciona el problema de guardar las checklists e
ítems completados.
La implementación en un primer momento se realiza siguiendo el diseño,
pero, con la experiencia ganada de haber programado parte de la aplicación, nos
damos cuenta de que se pueden eliminar algunas variables y se necesitan nuevos
métodos. Los cambios que se realizan se nombran a continuación:
Checklist.java: En esta clase los cambios son:
•
Se elimina la variable int numitems, debido a que el ListArray contiene
el método listArray.size() que ya lo proporciona.
•
El método toString() que devuelve un String con el nombre de la
Checklist se debe declarar como público para que el Adaptador de las
Listas de checklists puedan llamarla y conseguir el nombre.
CheckCompletas.java: En esta clase las modificaciones son:
•
Se añade una variable nueva llamada modified de tipo Boolean. Esta
indica si las checklists (Array de enteros) han sido modificadas, es decir,
si no se ha realizado ningún ítem en ninguna lista. Esta variable se
utiliza para mejorar el rendimiento evitando realizar operaciones
sobre los Arrays cuando no es necesario realizarlas.
•
Se añade el método int getRemainingItems(int iden). Este devuelve,
para una Checklist dada, el número de ítems que queda por realizar. La
razón por la que se crea este método es que, a la hora de redibujar los
Ítems que ya han sido realizados necesitamos conocer los que quedan
por realizar (que es lo que realmente se almacena).
PlaneChecklists.java: Esta clase es la que gestiona todo y por la cual se accede
al resto. Por ello es la que más varía:
•
En primer lugar se realiza un cambio en la forma en la que se inicia.
Debido a que al inicializar no se conocen el número de checklists e
ítems ya que son añadidas secuencialmente por el lector de XML hay
que esperar a tener toda la información para inicializar el
CheckCompletas.
Por
ello
se
crea
el
método
void
enableChecklistStatus() que se debe ejecutar una vez se han cargado
todos los datos (Checklist e ítems) del XML en el libro.
•
Se añade un Boolean saveStatus que indica si el libro ya ha sido
inicializado con enableChecklistStatus().
100
•
Eliminamos la variable int numChecklist ya que el ArrayList de Checklist
nos proporciona ese dato con su método size().
•
Se añade el método int getReamainingItems(int iden) que responde al
método de CheckCompletas.
•
Nos percatamos de que no se había declarado un método en esta clase
que redujera el número de ítems que se han completado, por lo que
desde la aplicación no se podía reducir el número de ítems
remanentes. A este nuevo método se le nombra void
setNewCheckedItems(int iden, int numOk) y responde al método de
CheckCompletas llamado setCheck(int iden, int numOk).
•
Finalmente
se
añade
otro
nuevo
método:
Checklist
getOneChecklist(int iden). Este devuelve el objeto Checklist elegido. La
necesidad de este método se debe a que en modo Smartphone el
nombre de la Checklist se pone en la ActionBar y por lo tanto se
necesita acceder individualmente a dicho Checklist para luego usar su
toString() y cargar ese String en el subtítulo de la ActionBar.
Definidos los cambios del diseño de cada clase hay que añadir otro cambio
que afecta a todos, que no es más que definir los constructores de la clase
como públicos en vez de package porque son instanciados desde fuera del
paquete en la aplicación.
El último cambio a esta clase es la implementación del interface Parcelable
(buscar Parcelable en [4]). Resumiendo, este interface consigue algo parecido a
Serializable de Java, es decir, permite que esta estructura de datos se pueda
pasar entre distintas actividades-programas, pero de una forma mucho más
eficiente y preparada específicamente para Android.
La razón por la cual implementamos este interface es porque los Libros de
Checklists se van pasando entre aplicaciones y no se pueden guardar tal cual en
un Bundle.
Dicha implementación se realiza siguiendo las pautas de Android
Developers [4]. De modo esquematizado se realiza tal que así:
•
•
•
Se escribe la función writeToParcel(Parcel save, int flag) que
permite guardar en el Parcel tipos básicos de variables y
también otros objetos Parcelables (se pueden anidar).
Se sobrecarga el constructor para que se inicialice con un
parámetro Parcel. En dicho Parcel se puede acceder a los
valores guardados por writeToParcel().
Se crea una variable estática Parcelable.Creator que es la
que inicializa una instancia de la clase principal usando el
constructor sobrecargado.
101
• Se escribe la función describeContents() y que devuelve
0. Su función no es necesaria en este proyecto.
Finalmente mostramos los retos que ha supuesto el añadirle dos versiones
distintas según si la aplicación se ejecuta desde un móvil o una Tablet.
Versiones SmartPhone y Tablet – Pestañas
Las pestañas han sido uno de los elementos que más problemas han causado
debido a los cambios que Android ha realizado en las últimas versiones.
En un principio las pestañas de las Checklists (Normales o Emergencia) eran
independientes y estaban ligadas a la ventana en la que se abría (una nueva
ventana en versión Smartphone y la ventana de la izquierda en versión Tablet). Así
en principio, el tipo de dispositivo era inherente al comportamiento de estas.
Pero las nuevas directrices de Android cambian el ámbito de las pestañas al
de la Actividad, por lo que no se pueden implementar de forma aislada y deben
tener en cuenta el resto de elementos de la vista.
En una primera versión se implementaban dentro de la clase de la actividad
de checklists, CheckActivity; pero el código se volvía muy confuso y se hacía difícil
el depurado de errores. La solución más limpia y elegante que se encuentra es la
de crear 2 Listeners (BookTabListener.java; una instancia para cada pestaña) que
responden a los cambios que se realizan en cada una ellas por separado.
La declaración en la clase principal se muestra en el Punto 6.1
Implementación del Interfaz Gráfico – Pestañas en las Checklists (ver más atrás).
En el Listener, los 3 métodos que se implementan son:
•
•
•
onTabSelected() (al ser seleccionada): Realiza en la ventana correcta
(dependiendo de la versión) la transacción del Fragment (pone
delante el Fragment que contiene dicho Listener, ya sean las listas
Normales o las listas de Emergencia).
onTabReselected() (al seleccionar la pestaña ya activa): En este caso
sólo tiene función si es un smartPhone; vuelve a las listas (volviendo
atrás en la pila de Fragments), borra el nombre de Checklist del título
y si además son emergencia borra los ítems realizados.
onTabUnselected() (al ser seleccionada otra pestaña): Dependiendo
de la versión, o vuelve atrás en los Fragments(Smartphone) o crea una
vista vacía(Tablet), borra los índices que muestran la Checklist elegida
anteriormente y, si es el caso, borra los ítems de las Checklist de
Emergencia.
102
Hasta llegar a este modelo hubo que realizar muchos cambios debido a
problemas como: realizar el trabajo 2 veces, superponer dos vistas, no
mostrar un elemento antes marcado…
Versiones SmartPhone y Tablet – Up & Back
Como se ve en 2.9 Interfaz de Usuario - Patrones de Diseño, los botones
Arriba y Atrás tienen comportamientos distintos, pero dependiendo del
dispositivo también cambia.
En el caso de Tablet el botón atrás responde casi siempre a volver a la
Actividad anterior, pero en el caso de Smartphone no es así, ya que dentro de una
misma actividad hay varias vistas, es por ello que se ha tenido muy en cuenta
estos comportamientos.
El botón arriba es parecido, pero así como el botón atrás funciona de forma
más o menos autónoma, en este hay que programar todo su comportamiento.
La diferencia en este proyecto entre ambos botones radica en la posibilidad
de iniciar las checklists de emergencia desde cualquier punto de la aplicación, por
lo que Atrás deberá volver a la función anterior (donde se pulso el botón
Emergencia) y Arriba debe siempre volver a la categoría Papeles.
La dificultad de estas funcionalidades en este proyecto está en la actividad de
las Checklist, CheckActivity, ya que es la que se debe encargar de luego volver
donde debe, devolviendo además los libros de Checklist actualizados.
Durante la implementación surgieron problemas en los que no se volvía
donde debía, o las listas no se devolvían actualizadas.
Versiones SmartPhone y Tablet – Nombre de Checklist
Aunque a la práctica pueda parecer una nimiedad, en la versión Smartphone
dentro de una Checklist concreta se debe notificar al usuario de alguna forma en
qué Checklist está.
En un principio se pensó en un texto justo encima de los ítems tal que el
nombre del avión en las listas. Supuestamente con la declaración de un TextView
debería ser suficiente, pero debido a la forma en la cual se definen las vistas de los
ítems en la actividad ocurría un error; no se mostraban los ítems. Se estuvo
buscando el origen del problema, pero el código estaba correcto y no se pudo
solucionar. La razón reside en el funcionamiento interno de Android, así que
tuvimos que replantear el problema. La solución ha sido añadir este nombre de la
checklist en el título de la aplicación como subtítulo.
Con este cambio se soluciona por completo e incluso deja la vista más limpia
y aprovecha el espacio limitado de un móvil.
103
Capı́tulo 7:
Pruebas
En este pequeño capítulo se detallan las pruebas realizadas con la aplicación
final. Dado que son muchas las pruebas, se han dividido en distintos ámbitos para
una mejor lectura y comprensión de estas.
Hay que puntualizar que una ventaja que ofrece Eclipse y el plug-in de
Android es el de poder ir probando la aplicación sin terminarla según se va
implementando, por lo que la mayoría de las pruebas realizadas al finalizar ya se
habían comprobado durante la implementación.
Para todas estas pruebas se tiene en cuenta las dos versiones de la aplicación
(Smartphone y Tablet), así pues siempre que no se puntualice sobre ninguna en
concreto se supone que la prueba se refiere a las 2 versiones, es decir, se realiza la
prueba 2 veces, una para cada versión.
7.1 Pruebas Visuales
En este apartado se tienen en cuenta los aspectos visuales como son, posición y
tamaño de botones, tamaño de Texto, colores, imágenes, etc.
•
•
•
•
•
•
Icono: El icono se muestra correctamente tanto en la aplicación como en
el Launcher del móvil.
Menú Principal – Posición, tamaño y color de los Botones: Correcto en
todas las configuraciones (tiene 3 versiones; normal, móvil apaisado y
Tablet). Muestra correctamente la transparencia del logo de la aplicación
en modo Tablet.
Menú Categorías – Pruebas visuales: Se muestran las listas correctamente
con según la elegida y un tamaño adecuado. Se muestra correctamente el
Spinner (versión móvil) y permite cambio entre ellas a través de él.
Menú Ajustes – Pruebas visuales: Muestra correctamente las 2 opciones
con las imágenes correctas y los subtítulos que corresponden.
Proceso Checklists – Pruebas visuales: Se muestra correctamente las
pestañas. En modo Tablet se muestra la transparencia con una Checklist
dibujada.
Proceso Checklists – Lista de Checklists: Se muestran correctamente las
listas con un tono más oscuro. En modo Tablet se muestra el sombreado
3D correctamente.
104
•
Menú Checklists – Lista de Ítems: Muestra los Ítems correctamente con su
Stick adosado con el color que la versión de Android lleva por defecto. Se
ha comprobado que en dispositivos Sony el stick no resalta demasiado,
pero es un problema inherente a la aplicación.
7.2 Pruebas de Versiones
En este apartado se prueba que la aplicación cambia su forma de mostrarse según
si se trata de un smartphone o de una Tablet.
•
•
•
•
Menú Principal: Se comprueba satisfactoriamente que en la versión móvil
se muestra correctamente el menú de botones y luego el de categorías y
en la versión Tablet se cargan ambos a la vez.
Menú Categoría: En la versión móvil se muestra correctamente el Spinner
y en la Tablet no se muestra.
Proceso Checklists: Se comprueba satisfactoriamente que en la versión
móvil se muestra correctamente la lista de Checklists y luego la de ítems, y
en la versión Tablet se cargan ambas a la vez.
Proceso Checklists – Checklist Actual: Se comprueba que en la versión
móvil se muestra el nombre de la checklist actual en el título y en la
versión Tablet se queda marcada la checklist actual.
7.3 Pruebas de Orientación
Debido a que Android re-crea las actividades al cambiar la orientación del
dispositivo (normal-portrait y apaisado-landscape) hay que tener en cuenta que
funcione todo correctamente al realizar el cambio.
•
•
•
•
Menú Principal: Se comprueba el en el cambio se guardan todos los
elementos (libros y la categoría en Tablet) y se redibuja correctamente.
Menú Categoría: En la versión móvil, al cambiar la orientación se muestra
correctamente la lista de funciones que estaba mostrada anteriormente. El
Spinner también muestra correctamente la categoría actual.
Proceso Checklists: Se comprueba satisfactoriamente que al cambiar la
orientación se guarda la pestaña elegida y los libros. En la versión Tablet se
selecciona y se carga también la checklist si había sido elegida.
Proceso Checklists – Checklist Actual: Se comprueba que al cambiar
orientación se cargan de nuevo los ítems con los sticks tal y como estaban
antes del cambio.
105
•
•
Menú Ajustes: En el cambio de orientación se muestra correctamente la
vista y se seleccionan correctamente los ajustes que estaban elegidos.
Vista Demo: Al pulsar cualquier función no implementada se comprueba
que muestra una imagen de demostración que no cambia aunque se
cambie la orientación (no responde al cambio).
7.4 Pruebas sobre el Guardado de Datos
Aunque en el apartado anterior ya se tiene en cuenta el guardado que ocurre al
cambiar la orientación, también existen otras razones por las que se puede perder
algún dato.
•
•
•
•
•
•
Menú Principal: Se escriben correctamente los Libros de Checklist desde el
XML. Al entrar en una categoría o al pulsar el botón emergencia estos se
pasan correctamente.
Menú Categoría: En versión móvil recibe y carga correctamente los libros y
la categoría a mostrar. Al seleccionar la función deseada envía los datos
correctamente a la actividad asociada.
Proceso Checklists: Recibe y carga correctamente los libros y si proviene
del botón emergencia activa automáticamente la pestaña Emergencias. Al
volver devuelve correctamente los libros actualizados.
Proceso Checklists – Checklist Actual: Se comprueba que guarda los ítems
pulsados.
Menú Ajustes – Cambio de Avión: Al cambiar un ajuste se guarda
correctamente.
Cambiar de Aplicación: Se comprueba que si se pulsa el botón Home; o se
atiende a una, llamada, mensaje; o se accede a alguna aplicación mediante
una notificación, al volver a la aplicación recupera su estado y datos
exactamente como estaban. El tiempo por el que permanecen intactos
depende del dispositivo.
106
7.5 Pruebas sobre la Disponibilidad de Recursos
Esta serie de pruebas se encargan de asegurar que la aplicación gestiona bien los
recursos del dispositivo.
•
•
•
•
•
•
•
Menú Principal – Sin Almacenamiento Externo: Se comprueba que la
aplicación avisa que no se tiene acceso a la memoria externa y se cierra la
aplicación.
Menú Principal – Almacenamiento USB conectado: Se comprueba que la
aplicación avisa cuando el almacenamiento está conectado y cierra la
aplicación.
Menú Principal – Archivos en la memoria Externa: Se comprueba que la
aplicación crea los directorios y archivos necesarios básicos cuando estos
no existen en la memoria externa.
Menú Principal – Avión Cargado: Se comprueba que la aplicación carga
correctamente el avión del archivo XML seleccionado.
Menú Principal – Avión Cargado Borrado: Se comprueba que la aplicación
cambia al avión básico cuando se ha borrado el archivo XML del avión que
estaba elegido en ese momento.
Menú Ajustes – Almacenamiento externo Disponible Al elegir otro avión
comprobamos en el caso de que no se pueda acceder a la memoria
externa (por USB conectado en modo compartir o por falta del mismo), la
aplicación avisa con un Diálogo y cancela el cambio de avión.
Menú Ajustes - Archivos: Al elegir otro avión comprobamos que se han
cargado todos los XML que se encuentran en la carpeta Planes.
107
7.6 Pruebas de Navegación
En este apartado se realizan pruebas sobre la navegación entre los distintos
menús y usando todas las posibilidades que existe para moverse entre ellos.
•
•
•
•
•
•
•
•
•
De Menú Principal a Categoría: Se prueba que la aplicación accede
correctamente a la categoría elegida. En versión móvil también se
comprueba que el cambio entre categorías usando el Spinner funciona
correctamente y que pulsando Atrás y Arriba se vuelve al menú principal.
De Categoría a Checklists: Se comprueba que desde categoría se accede a
Checklists correctamente. En versión móvil Atrás y Arriba devuelven al
mismo sitio (Categoría).
De Cualquier sitio a Emergencia: Se comprueba que al pulsar el botón
“Checklist de Emergencia” se abre directamente las Checklists con la
pestaña emergencia. Al pulsar Atrás vuelve correctamente al sitio de
antes. Al pulsar Arriba vuelve al Menú Principal (o categoría si es móvil).
De Checklists a Lista de Ítems: Al pulsar una lista concreta se accede
correctamente a los Ítems. Al pulsar Atrás o Arriba se comprueba que
vuelve a la lista de checklists (o al menú principal si es Tablet).
En la Lista de Ítems: En la versión móvil, dentro de la lista de ítems se
comprueba que al pulsar una pestaña muestra la lista de checklist
seleccionada.
De Menú Principal a Ajustes: al pulsar el Action Overflow y seleccionar
ajustes se abre una nueva vista con los ajustes de forma correcta. Al pulsar
Atrás o Arriba se devuelve correctamente al menú principal.
De menú Principal a cualquier Vista Demo: Se abre correctamente una
ventana con una imagen de demostración de la futura función. Al pulsar
Atrás o Arriba devuelve correctamente al Menú Principal (o categoría si es
Móvil).
Cambiar de Aplicación: Se comprueba que si se pulsa el botón Home; o se
atiende a una, llamada, mensaje; o se accede a alguna aplicación mediante
una notificación, al volver a la aplicación se abre en la ventana que se
había dejado.
Cerrar la Aplicación: Se comprueba que si se pulsa el botón Atrás en menú
principal se cierra la aplicación olvidando todos los datos temporales.
108
7.7 Pruebas de Funcionamiento de Checklists
Las siguientes pruebas se encargan de ver el correcto funcionamiento de las
Checklists.
•
•
•
•
•
•
Muestra de Avión: Se comprueba que en la lista de Checklist aparece el
nombre correcto del Avión seleccionado.
Cambio de Pestañas: Al cambiar la pestaña se carga correctamente la lista
de Checklists correspondiente.
Elegir Checklist: Al elegir una Checklist se muestra correctamente sus
ítems cargando además los que ya están completados. Al cambiar a otra
también los carga sin problema.
Muestra de checklist: Al estar en una checklist (móvil) se comprueba que
el nombre del título de la aplicación cambia a tener el nombre de dicha
checklist y que cambia según se cambie de checklist o desaparece al salir.
Si se tiene seleccionada una checklist (Tablet) se comprueba que siempre
se queda marcada la checklist que se está viendo en ese momento.
Seleccionar Ítems: Se comprueba que al seleccionar un Ítem solo lo marca
si es el secuencialmente correcto.
Checklist Completada: Al completar una Checklist se comprueba que avisa
al usuario mediante un Toast.
7.8 Pruebas de Borrado de Datos
En este apartado se comprueba que el borrado de datos en los distintos apartados
de la aplicación se efectúa correctamente.
•
•
•
Borrado de Checklist Actual: Dentro de una checklist se pulsa la opción de
borrar la checklist y se comprueba que los sticks desaparecen.
Borrado de todas las Checklists: En la lista de Checklists (o en la actividad
de Checklists si es Tablet) se pulsa la opción de borrar las checklists y se
comprueba que aparece un diálogo pidiendo confirmación, y en el caso de
aceptarlo todos los sticks de todas las listas desaparecen. Además en
modo Móvil se comprueba que dentro de una checklist la opción de borrar
todas las checklists desaparece.
Ajustes - Reinicio de la Aplicación. Se comprueba que al pulsar reiniciar
aplicación aparece un diálogo y al aceptar se borran los sticks de todas las
listas informando al usuario de ello.
109
7.9 Pruebas de Cambio de Idioma
En este apartado se comprueba que al cambiar de idioma el sistema Android la
aplicación cambia también de forma autónoma el idioma. Existen 3 versiones, inglés,
español y catalán-valenciano.
•
•
•
•
Idioma del sistema Español: Se comprueba que todos los menús y textos
(excepto las Checklists) están en español.
Idioma del sistema Catalán-Valenciano: Se comprueba que todos los
menús y textos (excepto las Checklists) están en catalán.
Idioma del sistema Ingles: Se comprueba que todos los menús y textos
(excepto las Checklists) están en inglés.
Cualquier otro Idioma: Se comprueba que todos los menús y textos
(excepto las Checklists) están en inglés, que es el idioma por defecto.
7.10 Pruebas en distintos Dispositivos
Se han realizado pruebas satisfactorias en los siguientes dispositivos:
•
•
•
•
•
•
•
•
•
HTC Desire (4.2 Jelly Bean). Custom ROM.
Sony Xperia S (4.0 Ice Cream Sandwich).Dispone de Botón Menú.
Sony Xperia U (4.0 Ice Cream Sandwich). Dispone de Botón Menú.
Sony Xperia T (4.0 Ice Cream Sandwich). Sin botones físicos.
LG Optimus Black (4.0 Ice Cream Sandwich).
Samsung Galaxy Tab (4.0 Ice Cream Sandwich). Tablet.
Asus Transformer (4.0 Ice Cream Sandwich). Tablet.
Asus Transformer (4.2 Jelly Bean). Tablet. Custom ROM.
Airis Kira 10’’ (4.0 Ice Cream Sandwich). NetBook. Touch Screen.
110
Capı́tulo 8:
Resultado Final
En este capítulo se presenta el resultado final de la aplicación y sus
funcionalidades. Para ello, se dispone de capturas de dispositivos reales y una breve
explicación sobre ellas. Se mostrarán agrupadas siguiendo un orden de navegación,
mostrando en cada apartado el resultado con Móvil y Tablet.
8.1 Menú Principal – Vista de Categorías
En la versión Móvil se compone de dos ventanas distintas. La primera ventana es
el Menú Principal. A través de los 4 botones de categorías accedemos al contenido de
estas en una nueva ventana (en este caso la categoría Papeles) (ver Figura 40 y Figura
41).
Figura 40. Captura Móvil - Menú Principal
Figura 41. Captura Móvil - Menú Categorías
En ambas pantallas se puede acceder a un botón situado en el Action Bar que
lleva directamente a las checklist de emergencia. En la pantalla Menú Categorías se
dispone de un Spinner que te permite cambiar entre categorías sin volver al menú
principal (ver Figura 43).
En la versión Tablet ambas pantallas están integradas en una sola. En un primer
instante la parte de la derecha permanece en blanco (con la imagen del logotipo como
111
fondo) hasta que se presiona un botón de la izquierda que muestra las categorías
(como se ve en la Figura 42).
Figura 42. Captura Tablet - Menú Principal.
Estas pantallas también tienen en cuenta el cambio de orientación:
Figura 44. Captura Móvil - Menú Principal (Landscape)
Figura 43. Captura Móvil - Menú Categoría
(Spinner Desplegado) (Portrait)
112
Figura 45. Captura Tablet - Menú Principal (Portrait)
Figura 46. Captura Tablet - Menú Ajustes Cambiar Avión (Portrait)
En la Figura 44 se puede ver que, al cambiar la orientación los botones se
redistribuyen para ser mostrados todos correctamente sin necesidad de hacer scroll.
En la Figura 45, en modo Tablet, cambia la proporción de espacio que ocupa cada uno
de los 2 layouts. También se aprecia como al mantener pulsado el botón aparece su
texto indicando qué significa éste.
113
8.2 Menú Ajustes
Al menú Ajustes se accede haciendo clic en el Action Overflow (icono de 3 puntos
en el Action Bar) o usando el botón físico del dispositivo si dispone de él (en cuyo caso
no se mostrará el Action Overflow). Tiene la misma presentación tanto en móvil como
en Tablet.
A través de él (Figura 47) se puede cambiar de avión o reiniciar la sesión. En el
caso de cambiar de avión se muestra una lista para elegir el deseado (Figura 46). En el
caso de Reiniciar sesión muestra un diálogo de confirmación para borrar la sesión
actual y empezar un nuevo vuelo (Figura 48).
Figura 47. Captura Móvil - Menú Ajustes
Figura 48. Captura Móvil - Menú Ajustes Reiniciar Sesión
114
8.3 Actividad Checklists
Esta es la única funcionalidad implementada en la aplicación. Las demás solo
muestran una imagen estática de demostración.
Para acceder a ella hay que acceder a la categoría Papeles y seleccionar Checklists
(Figura 41 y Figura 42).
La versión Móvil contiene 2 pantallas separadas. Al principio muestra una lista de
Checklists (Figura 49), y según la pestaña seleccionada muestra las normales o las de
emergencia.
Al pulsar sobre una checklist se abre una ventana que muestra los ítems de ésta
marcando, si los hay, aquellos que ya han sido completados anteriormente (ver Figura
50). En ésta se nombra la checklist actual para conocimiento del piloto.
Figura 49. Captura Móvil - Función Checklists Lista de Checklists.
Figura 50. Captura Móvil - Función Checklists Ítems de Checklist.
En la versión Tablet, ver Figura 51, ambas vistas se combinan en una sola. Para conocer
qué checklist está usando el piloto en ese momento, su nombre queda marcado en la
lista de forma permanente (siempre que se encuentre en dicha lista).
115
Figura 51. Captura Tablet - Función Checklists.
Finalmente para borrar las listas se dispone de dos opciones en el Action Overflow:
Una borra la lista que está abierta en ese momento y la otra borra todas las checklists.
Esta última abre un diálogo de confirmación antes de borrarlas (Figura 55). En la
versión Móvil se ve la opción de borrar todas las checklists sólo en la lista de checklists
(Figura 52), y la opción de borrar la checklist actual solo es visible si se está dentro de
una checklist (Figura 53). En la versión Tablet ambas opciones son visibles (ver Figura
54).
116
Figura 52. Captura Móvil - Función Checklists - Reiniciar Checklists
Figura 53. Captura Móvil - Función
Checklists - Reiniciar Checklist Actual
Figura 54. Captura Tablet - Función Checklists Opciones de Borrado
Figura 55. Captura Tablet - Función Checklists Confirmación de Borrado
117
Capı́tulo 9:
Conclusiones
En este último capítulo se exponen las conclusiones técnicas y personales, y se
hace una valoración sobre los trabajos futuros que se deben realizar a partir de este
proyecto.
9.1 Conclusiones Técnicas
Desde un punto de vista técnico y funcional se ha conseguido:
•
•
•
•
•
Diseñar toda una aplicación que suple las necesidades de un piloto de
aviación general.
Crear la base de dicha aplicación móvil, haciéndola mínimamente
funcional.
Implementar además, una de las funcionalidades de esta, que es el
seguimiento de Checklists.
Que ésta aplicación se pueda utilizar en distintos dispositivos con distinto
tamaño.
Que ésta sea fácil de usar para un piloto mientras vuela.
Estos hechos consiguen superar con creces los objetivos del proyecto, por lo que
podemos concluir que el trabajo realizado en este es satisfactorio.
9.2 Conclusiones Personales
Este proyecto ha sido una experiencia muy enriquecedora. Tras muchas horas de
estudio, trabajo y resolución retos nos ha permitido:
•
•
•
•
Aprender a gestionar proyectos de una forma que la teoría no puede
enseñar.
Ahondar en la filosofía de diseño de aplicaciones para el sistema Android,
que a día de hoy es el sistema más extendido a nivel mundial.
Aprender a programar Java y Android de forma ordenada y eficiente.
Practicar el modelado de sistemas informáticos con ayuda de estándares
como UML que nos ha facilitado la tarea de diseño e implementación.
118
•
•
Hemos aprendido a ser flexibles con nuestro diseño principal y cambiarlo y
mejorarlo sobre la marcha ante un problema no planteado.
Hemos puesto en práctica muchos de los conocimientos adquiridos
durante la carrera como Programación, Sistemas Operativos, Estructuras
de Datos, Programación distribuida o Multimedia, entre muchas otras.
A nivel personal, este proyecto ha sentado las bases para una dedicación
profesional en este campo que nos brinda la posibilidad de conseguir una
remuneración económica sin depender de una empresa en estos tiempos en la
que la contratación es tan escasa.
9.3 Trabajo Futuro
En el contexto de este proyecto, el trabajo futuro es más que evidente debido a
las particularidades de este. Como la implementación sólo se ha llevado a cabo en una
pequeña parte de la aplicación se sobreentiende que el trabajo subsiguiente es
implementar el resto de la aplicación tal y como se modela y diseña en este proyecto.
Aun así, del trabajo realizado se pueden realizar otra serie de trabajos como son:
•
•
•
•
•
•
Añadir una guía de usuario dentro de la aplicación que sea interactiva.
Añadir nuevos idiomas a la aplicación.
Mejorar el rendimiento de la aplicación usando programación con varios
hilos.
Realizar un análisis para reutilizar funcionalidades y código.
Personalizar la aplicación y dotarla de un interfaz más gráfico y atractivo.
Crear una aplicación en PC que permita a los pilotos crear Checklists de
Avión propias.
119
Bibliografı́a
[1] Wikimedia, «Wikimedia - Accidente del vuelo JK5022,» 10 Marzo 2013. [En línea].
Available: http://es.wikipedia.org/wiki/Vuelo_5022_de_Spanair.
[2] Wikimedia, «Wikipedia - Android,» 2 Mayo 2013. [En línea]. Available:
http://es.wikipedia.org/wiki/Android.
[3] A. Lee, "Android Goes Beyond Google," RTC Magazine, p.
http://www.rtcmagazine.com/articles/view/102586, 2012.
[4] Google Inc., "Android Developers," 2012. [Online]. Available:
http://developer.android.com/.
[5] Pragmatic Programers, LLC, Hello, Android, Ed. Brunette, 2010.
[6] Wikimedia, «Wikipedia - Técnica de revisión y evaluación de programas,» 5 Abril
2013. [En línea]. Available: http://es.wikipedia.org/wiki/PERT.
[7] G. Allen, Beginning Android 4, Apress, 2012.
[8] S. Komatineni and D. MacLean, Pro Android 4, Apress, 2012.
[9] R. C. Palomino, «Desarrollo en Android v1.0,» 2010.
[10] E. Avilés, «TechMi,» 14 11 2010. [En línea]. Available:
http://techmi.es/blog/cursos/curso-android-avanzado/. [Último acceso: 20 11
2012].
[11] H. @s0ulbuzz, «Android HAL and Graphics,» Watching The v0ld, p.
http://soulbuzz.net/?p=175, 2010.
[12] D. Felker, Android Application Development for Dummies, Hoboken: Wiley
Publishing, Inc., 2011.
[13] M. Gargenta, Learning Android, Sebastopol: O'Really, 2011.
120
Anexo A
Definiciones y Abreviaturas
ADF: Ver NDB.
API (Application Programming Interface): Interfaz de programación de aplicaciones es
el conjunto de funciones y métodos que ofrece cierta librería para ser utilizado
por otro software como una capa de abstracción.
Arco: Procedimiento Instrumental por el cual, tomando como centro una estación
VOR/DME y determinando una distancia DME, se realiza una trayectoria que
dibuja un circulo con radio la distancia DME.
Aviación Ligera: Se refiere a todo lo relacionado con aviones de Pistón de menos de
5700kg (Procedimientos, aviones, Licencias, infraestructuras).
Avioneta: Aeroplano ligero de menos de 5700kg con motor de combustión interna.
Carga y Centrado: Ver Mass & Balance.
Checklist: Lista de acciones que deben realizarse para un momento determinado del
vuelo. Estas tienen el nombre del momento específico para el cual están
diseñadas. Las acciones en ellas escritas buscan la seguridad del vuelo y son de
obligatorio seguimiento. En aviación ligera se disponen todas las acciones a
realizar, pero en aviones más grandes solo se muestran los ítems que afectan
directamente la seguridad del vuelo.
Todas las Checklist tienen por ley un mismo formato, en el que se escribe a la
izquierda el objeto y a la derecha la acción o valor que se le debe aplicar.
Declinación Magnética: Diferencia en grados entre el Norte Magnético y el Norte
Geográfico.
Deriva: Desvío del rumbo al que apunta el avión respecto a la trayectoria que sigue
debido al viento.
DME: Equipo dentro de un avión que, si la estación sintonizada tiene tal sistema, es
capaz de mostrar la distancia lineal desde el avión a la estación y la velocidad a la
que se acerca/aleja de esta. A esa distancia se le llama Distancia DME.
Espera: Ver Hold.
Estación: Infraestructura fija en el suelo que emite señales electromagnéticas en una
frecuencia dada y cuya posición es conocida.
121
Ficha (de aeropuerto): Papel de tamaño A5 que contiene información sobre un
aeropuerto. Su función es la de ayudar a los pilotos a seguir los procedimientos,
normativas y mostrarles de forma gráfica las rutas y calles de rodaje.
Existen principalmente 5 tipos de fichas:
Info/Briefing: Muestra datos sobre el aeropuerto y planos de este.
VFR (Visual Flight Rules): Fichas que muestran como llegar a un aeropuerto
basándose en referencias visuales. Son las más utilizadas en aviación ligera.
SID (Standard Instrumental Departure): Son fichas que muestran por donde debe ir
un avión para salir del aeropuerto usando radioayudas.
STAR (Standard Arrival): Muestran cómo llegar al aeropuerto y colocarse en un
punto específico cerca de él con el uso de radioayudas.
APP (Approach): Muestran cómo llegar a una pista específica para aterrizar en ella.
Su inicio es el punto específico donde te lleva una STAR. Existen distintos
subtipos dependiendo de la radioayuda que se use para aterrizar.
Flight Plan: Formulario estandarizado que se debe enviar a las autoridades
aeronáuticas (a los controladores) para los vuelos que se realicen dentro de un
espacio aéreo controlado o para cualquier vuelo que tenga distinto aeropuerto de
salida que de llegada.
Su cometido es informar a los controladores y equipos de emergencia de los
datos de un vuelo en particular (horas de salida y llegada, tipo de avión, ruta,
equipamiento, número de ocupantes, piloto al mando…).
GS (Ground Speed): Velocidad del avión respecto el suelo.
GUI (Graphic User Interface): Ver UI.
Hold: Consiste en una serie de circuito ovalado encima de una estación con el fin de
que los aviones en vuelo entren en éste y permanezcan en él mientras esperan a
ser atendidos/autorizados por los controladores para continuar su vuelo. Existen
dos tipos; Estándar (giros a derechas) y No Estándar (giros a izquierdas).
HSI (Horizontal Situation Indicator): Instrumento de Navegación por radiobalizas que
es capaz de indicar mediante un giróscopo el rumbo actual y además también es
capaz de informarte sobre qué radial de la estación VOR que tengas sintonizada te
encuentras.
IAS (Indicated Airspeed): Velocidad indicada por el anemómetro del avión. Se calcula
con la diferencia de presión de impacto respecto la presión estática.
IDE (Integrated Development Environment): Un entorno de desarrollo integrado es un
programa informático compuesto por una serie de herramientas de programación
122
(editor de código, compilador, depurador, constructor de interfaz gráfica) que
funcionan de manera conjunta.
Interceptación: Es el procedimiento para cambiarse de radial en un NDB (no da ayuda
para seguir encima de un radial como sí lo hace un VOR).
IFR (Instrumental Flight Rules): Normativa referente al vuelo usando instrumentos de
navegación basado en radiobalizas.
Libros (de Checklists): En el contexto de este proyecto son las estructuras de datos que
contienen una serie de checklists con sus ítems y que guardan una relación de los
ítems completados.
Lista de Chequeo: Ver Checklist.
Mass & Balance: Cálculo del peso y de la posición del centro de gravedad del avión.
Estos deben estar comprendidos entre unos valores (la envolvente de vuelo) para
que sea segura su operación. Se suelen calcular mediante tablas y gráficos.
METAR: Previsión meteorológica descrita en texto siguiendo un código estandarizado
para un aeropuerto.
MTOW (Maximum Take-off Weight): Peso máximo al despegue certificado que un
avión puede soportar.
NDB (Non Directional Beacon): Estación que emite en una frecuencia dada a fin de
que un avión equipado con un ADF (Automatic Direcion Finder) pueda establecer
la dirección que debe tomar para llegar a esta.
Plan de Vuelo: Ver Flight Plan.
Punto a Punto: Procedimiento Instrumental por el cual, desde la posición actual del
avión respecto a una estación VOR/DME que es conocida, se procede a otro punto
respecto a la misma estación (punto determinado por un radial y una distancia
DME).
QDM: Es el ángulo medido entre el Norte magnético por donde pasa el avión y la línea
imaginaria que une a éste con la estación NDB, es decir,el rumbo que tendría que
poner el piloto para dirigirse a dicha estación.
QDR: Es el ángulo medido en sentido horario entre el Norte Magnético en la estación y
la línea imaginaria que une a ésta con el avión. QDR es el ángulo opuesto al QDM.
QNH: Presión atmosférica a nivel del mar que se calcula, para un aeropuerto dado,
tomando como base la presión local en ese aeropuerto y una corrección de la
elevación de este.
Radial: Posición relativa de un avión (en grados) respecto a una estación tomando
como referencia el Norte Magnético en la estación. Existen 360 radiales, uno por
grado.
123
TAS (True Airspeed): Velocidad del avión respecto al aire compensando los errores de
posición del instrumento, de compresibilidad y de densidad del aire.
TOW (Take-off Weight): Peso del avión al despegue.
UI (User Interface): Interfaz de Usuario, serie de vistas, botones textos que contiene
una pantalla de un dispositivo con cuya función es facilitar al usuario el uso de una
aplicación o programa.
URI (Uniform Resource Identifier): Es una cadena de caracteres que identifica
inequívocamente un recurso dentro de un sistema (archivo, contacto, cita de
calendario…)
VFR (Visual Flight Rules): Normativa referente al vuelo usando referencias visuales
(carreteras, ríos, pueblos,…) para orientarse y navegar.
VOR (VHF Omnidirectional Range): Estación que, mediante diferencia de fase, es
capaz de mostrar al piloto en qué radial de esta se encuentra un avión o,
seleccionado un radial especifico, hacia donde tiene que virar para montarse
sobre él.
VOR/DME: Estación que contiene un VOR y un DME que emiten en la misma
frecuencia.
124
Anexo B
Manual de Usuario
Este Anexo contiene el manual de usuario de la aplicación implementada.
Contenido
La Aplicación ................................................................................................ 126
Menú Principal ............................................................................................ 127
Menú Ajustes................................................................................................ 128
Categorías ..................................................................................................... 129
Checklists ...................................................................................................... 130
Idioma ............................................................................................................ 132
Almacenamiento Externo ........................................................................ 132
Creación de Nuevas Checklists .............................................................. 133
125
La Aplicación
Esta aplicación se inicia desde el Launcher de tu dispositivo móvil (Tablet o
Smartphone). Para ello hay que tocar el icono de la aplicación.
Tras ello se abre la aplicación principal donde podemos destacar:
Ilustración 1. Disposición Móvil
Ilustración 2. Disposición Tablet
La Action Bar
Se utiliza para conocer la actividad actual, navegar por la aplicación y acceder
a funciones especiales como los ajustes, el botón de Emergencia y el borrado de
checklists mediante el Action Overflow, que es el icono con 3 puntos situado a la
derecha de la Action Bar.
Si quieres subir en el orden jerárquico de la aplicación usa el icono de la
aplicación (que contendrá una flecha a la izquierda cuando se pueda subir).
Para volver a pantallas anteriores en las que has estado usa el botón Atrás de
tu dispositivo.
Layout Principal
Muestra el apartado Actual. Donde el usuario debe realizar la acción que
requiere. Al pulsar sobre algún apartado el layout cambia y muestra la siguiente
pantalla (en la versión Móvil).
Layout Secundario
Solo visible desde una Tablet. Muestra la vista detalle de la acción realizada
en el Layout Principal. Se puede interactuar con ella como si de una pantalla
individual se tratara.
126
Menú Principal
En el menú principal encontramos 4 Botones que nos permiten ir a cada una de
las 4 Categorías. En nuestro caso pulsa la categoría Papeles.
Ilustración 3. Móvil Pulsa Papeles
Ilustración 4. Tablet - Pulsa Papeles
También se puede acceder a las checklist de emergencia pulsando el Botón
“Checklist de Emergencia”, que es el botón de una checklist y una señal de aviso.
Ilustración 5. Móvil Botón Emergencia
Ilustración 6. Tablet - Botón Emergencia
127
Finalmente se puede acceder a los ajustes pulsando el Action Overflow y eligiendo
Ajustes.
Ilustración 7. Móvil Accede a Ajustes
Ilustración 8. Tablet - Accede a Ajustes
Menú Ajustes
En este menú se puede cambiar de avión actual para cargar las listas de uno
distinto. Para ello pulsa sobre Cambiar Avión Actual y luego elige uno de la lista:
Ilustración 9. Tablet - Pulsa Cambiar Avión Actual.
128
Ilustración 10. Móvil Elige Avión Nuevo.
También se puede reiniciar la aplicación para iniciar un nuevo vuelo. Para ello
pulsa sobre Reiniciar Sesión y luego confirma la ventana que aparece. Finalmente
vuelve al menú Principal pulsando Arriba:
Ilustración 11. Móvil Pulsa para Reiniciar la Sesión.
Ilustración 12. Tablet - Vuelve al menú Principal pulsando Arriba
Categorías
Cuando se pulsa un botón se accede a una de las categorías donde se ven todas
las funciones disponibles para esa categoría actual. Si es una Tablet esta se muestra en
el layout Secundario.
Para cambiar de categoría pulsa sobre el nombre de la categoría para abrir una
lista desplegable (móvil) o pulsa otro botón en el layout principal (Tablet).
Para acceder a las Checklists haz clic en el nombre Checklist.
Ilustración 13. Móvil Accede Checklists
Ilustración 14. Tablet - Accede a Checklists.
129
Checklists
En la funcionalidad checklists se muestran dos pestañas; una Normal y otra
Emergencia. Estas muestran una lista de Checklists (según cual) en el layout Principal.
Pulsa la pestaña Normal para acceder a las Checklist Normales o pulsa la pestaña
Emergencia para las Checklists de Emergencia. Luego selecciona la Checklist deseada:
Ilustración 15. Móvil Pulsa la Checklist deseada.
Ilustración 16. Tablet - Pulsa la Checklist deseada.
Se mostrará en el layout Principal (Móvil) o en el Layout Secundario (Tablet) la
lista de ítems de la Checklist elegida con aquellos realizados ya marcados:
Ilustración 17. Móvil Lista de Ítems
Ilustración 18. Tablet - Lista de Ítems.
130
Para marcar los Ítems tan solo haz clic en cada uno de ellos, pero recuerda que
deben realizarse de forma Secuencial, por lo que si no seleccionas el ítem correcto no
marcará nada.
Ilustración 19. Móvil Marca un Ítem Realizado.
Ilustración 20. Tablet - Marca un Ítem Realizado.
Cuando la Checklist sea completada el móvil avisará con un mensaje.
Borrar Listas
Para borrar las marcas de los ítems de una Checklist hay que tener mostrada
aquella lista que se desea borrar.
Una vez mostrada pulsa el Action Overflow y selecciona Borrar Checklist Actual.
La aplicación avisa con un mensaje cuando se haya borrado:
Ilustración 21. Móvil Reiniciar Checklist Actual
Ilustración 22. Tablet - Reiniciar Checklist Actual y Reiniciar Checklists.
131
Para borrar todos los ítems de todas las Checklists hay que estar en la lista de
Checklists (móvil). Para ello solo tienes que pulsar el Action Overflow y seleccionar
Reiniciar Checklists.
Se mostrará entonces una ventana pidiendo la confirmación. Una vez Confirmes
quedarán todas borradas.
Ilustración 23- Móvil Reiniciar Checklists.
Ilustración 24. Tablet - Confirmación de Reiniciar Checklists.
Idioma
Para cambiar el idioma cambia el idioma general de Android desde los Ajustes
Generales del Sistema. Hay 3 idiomas: Español, Catalán-Valenciano e Inglés (por
defecto). Eso quiere decir que cualquier otro idioma seleccionado en el dispositivo
hará que se muestre en inglés.
Almacenamiento Externo
Esta aplicación necesita de un almacenamiento externo (Tarjeta SD o memoria
Externa del dispositivo). Si este no está disponible o se encuentra compartido por USB
(Almacenamiento Masivo) la aplicación avisa de ello con una ventana y cierra la
aplicación. Hasta que no se encuentre disponible no será posible utilizar PilotFMS.
132
Creación de Nuevas Checklists
Si deseas, puedes crear una checklists para un avión nuevo siguiendo estas reglas:
•
•
•
Coloca el archivo resultante en la carpeta del Almacenamiento Externo:
<MemoriaSD>/PilotFMS/Planes.
El nombre del archivo debe ser <nombre del avión>.xml
El XML debe seguir el siguiente patrón (para que resulte más fácil se puede
crear una copia de “Cessna 150L.xml” y modificarla para ahorrar trabajo):
Ilustración 25. Prototipo de XML de Avión
133

Aplicación Android para la Asistencia a Pilotos de Aviación Ligera

Transcripción

Documentos relacionados

¿Cuánto de nuevo es nuevo? Pues… ¡nuevo! Y ¿cuánto de bueno

Sistema de Guiado para Peatones, Ciclistas y

Rootear una tableta Android

Menú

Gestión de documentos en entornos colaborativos mediante un

Descargar libro completo - FYDE