Aplicacion de geo-localizacion Forns IGP

iOS / Android

Raul Sanchez Delgado

11 de junio de 2012

Indice

1. Introduccion 6

1.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2. Motivaciones personales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2. Estado del Arte 9

2.1. Geolocalizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1. Metodos de georreferenciacion en dispositivos moviles . . . . . . . . 10

2.1.2. Tecnicas de geolocalizacion en redes de telefonıa movil . . . . . . . . 14

2.1.3. Herramientas de geolocalizacion . . . . . . . . . . . . . . . . . . . . . 19

2.1.4. Aplicaciones con geolocalizacion . . . . . . . . . . . . . . . . . . . . 21

2.2. Representacion de mapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2.1. Proyeccion de mapas . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2.2. Sistema de Informacion Geografica (SIG) . . . . . . . . . . . . . . . 28

2.2.3. APIs de mapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.3. iOS Vs Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.3.1. Lenguajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.3.2. Herramientas de desarrollo . . . . . . . . . . . . . . . . . . . . . . . 35

2.3.3. Plataformas de distribucion . . . . . . . . . . . . . . . . . . . . . . . 37

3. Diseno de la aplicacion 38

3.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.3. Diagrama de estados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.3.1. Inicio de la aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.3.2. Esquema general de la aplicacion . . . . . . . . . . . . . . . . . . . . 42

3.3.3. Mostrar y telefonear a un horno de la lista . . . . . . . . . . . . . . . 44

3.4. Diagramas de secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

2

3.4.1. Inicio de la aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.4.2. Mostrar Horno Seleccionado . . . . . . . . . . . . . . . . . . . . . . . 50

3.4.3. Telefonear al Horno . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.4.4. Mostrar Hornos Distancia . . . . . . . . . . . . . . . . . . . . . . . . 53

3.4.5. Mostrar Ruta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4. Implementacion 56

4.1. Implementacion en iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.1.1. Librerıas del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.1.2. Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.1.3. Capa de gestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.1.4. Capa de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.2. Implementacion en Android . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.2.1. Librerıas del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.2.2. Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.2.3. Capa de gestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.2.4. Capa de localizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.2.5. Capa de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.3. Diferencias entre iOS y Android . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.3.1. Lenguaje de programacion . . . . . . . . . . . . . . . . . . . . . . . . 82

4.3.2. Desarrollo de la interfaz . . . . . . . . . . . . . . . . . . . . . . . . . 82

4.3.3. Localizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.3.4. Uso de Mapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

4.3.5. Valoraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

4.4. Aspecto final de las pantallas . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5. Planificacion y Costes 89

6. Conclusiones y trabajo futuro 92

3

6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6.2. Valoraciones personales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6.3. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

7. Referencias 95

7.1. Geolocalizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

7.2. Representacion de Mapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

7.3. iOS vs Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

7.4. Implementacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

4

Agradecimientos

Llegados a este punto son muchas las personas que seguro merecen mi agradecimiento

durante todos estos anos de carrera, pero en esta ocasion procurare centrarme en los que

han ayudado a ponerles fin con este proyecto.

En primer lugar, como no, a mi tutor de proyecto. Gracias Jordi por pensar que serıa

capaz de llevarlo a cabo y por todo el asesoramiento y recursos que me has facilitado.

Gracias tambien a David Gaso, Ciro Alonso y Rosa Garcıa, mis responsables directos en la

empresa para la que trabajo. Gracias por toda la confianza que me habeis mostrado desde

que empece a trabajar con vosotros, gracias por vuestra comprension con respecto al rumbo

que decidı tomar y por facilitarmelo todo en forma de excedencia.

Y por ultimo gracias a toda mi familia por apoyarme y aguantarme habitualmente y sobre

todo estos ultimos meses, pues posiblemente me habre mostrado mas agitado de lo habitual.

5

Capıtulo 1

1. Introduccion

Los avances tecnologicos que los telefonos moviles han experimentado en el ultimo lustro

han permitido que el usuario tenga al alcance de la mano todo lo que puede necesitar en su

dıa a dıa. La limitada potencia de calculo o el reducido tamano de la memoria que estos dis-

positivos tenıan antano ha dejado de ser un problema para los desarrolladores que ademas

han visto como la interfaz tactil, el acceso a internet o la geolocalizacion les abrıan un nuevo

abanico de posibilidades a la hora de desarrollar aplicaciones mas utiles y accesibles para

todo el mundo.

Quizas algunas de las aplicaciones que mas hayan proliferado sean aquellas que permi-

ten al usuario ubicarse en tiempo real en un mapa y encontrar lugares de interes, ya sean

turısticos, de ocio o cualquier tipo de establecimiento. Y no es de extranar que sea ası,

ya que este tipo de aplicaciones no solo son utiles para el usuario, sino tambien para las

empresas que gracias a ellas pueden indicar a sus clientes la manera de llegar a su tienda

mas cercana. Es una manera sencilla de publicitarse y fidelizar clientes a muy bajo coste.

Con esa idea en mente nace este proyecto, cuyo objetivo principal es desarrollar una apli-

cacion que muestre nuestra posicion geografica en tiempo real y disponga de un catalogo

de establecimientos de manera que el usuario pueda navegar por el y elegir a cual desea

ir; o simplemente encontrar la manera de llegar al mas cercano. Estos establecimientos son

tiendas donde se puede adquirir pan con Indicacion Geografica Protegida (IGP) ”Pa de

Pages Catala”1.

Teniendo esto en cuenta se decidio utilizar los dispositivos moviles como plataforma pa-

ra esta aplicacion. Su tamano permite al usuario moverse con el y el GPS o el acceso a

1De ahora en adelante nos referiremos a ellos como ”hornos”

6

la red de telefonıa movil permite obtener la posicion geografica de manera mas precisa.

Los modelos escogidos han sido aquellos que funcionan sobre los sistemas operativos iOS

y Android, ya que son los que gozan de mayor implantacion en el mercado, proporcionan

facilidad para acceder a su SDK y una extensa base de conocimientos para ayudar al desa-

rrollador. Ademas las companıas que estan detras de estos sistemas operativos (Apple y

Google respectivamente) disponen de plataformas de distribucion de aplicaciones amplia-

mente aceptadas por sus usuarios (AppStore y GooglePlay, respectivamente).

1.1. Objetivos

Los objetivos para llevar a cabo este proyecto podemos desglosarlos de la siguiente manera:

Investigacion previa

En primer lugar habra que hacer un pequeno estudio sobre las diferentes tecnologıas

que permiten la localizacion geografica y determinar cual o cuales son las mas ade-

cuadas para esta aplicacion.

Posteriormente y dado que son dos lenguajes de programacion desconocidos para mı,

sera necesario estudiar tanto el entorno de desarrollo como los propios lenguajes.

Diseno preliminar de la aplicacion

Habra que determinar las acciones que podra realizar el usuario en la aplicacion y

hacer un primer diseno de la estructura de esta.

Estudio de particularidades

Una vez instalados los SDKs, asimilados los conceptos basicos de los lenguajes y

con la idea general de lo que necesitara la aplicacion, sera necesario investigar las

diferentes herramientas o APIs que tenemos disponibles para llevar a cabo las tareas

mas complejas, como son la inclusion de mapas y la geolocalizacion en ambos sistemas

operativos.

Desarrollo de la aplicacion

7

Se desarrollaran dos versiones de la aplicacion, una para dispositivos Android y otra

para iPhone.

Despliegue final

Finalmente las versiones definitivas de la aplicacion se pondran a disposicion del publi-

co en las plataformas de distribucion de Google y Apple.

1.2. Motivaciones personales

A nivel personal, la principal motivacion que encontre para realizar este proyecto fue el

deseo de iniciarme en el desarrollo para dispositivos moviles. Llevo cuatro anos ejerciendo

como programador en entornos .Net y entendıa que era el momento de probar cosas nue-

vas. En este sentido, me parecio que la programacion para iOS y Android era una buena

eleccion puesto que son dos plataformas en continuo crecimiento y permiten hacer llegar

tus aplicaciones a un amplio mercado de manera rapida y directa. Ademas este proyecto

me daba la oportunidad de trabajar con mapas y geolocalizacion, dos conceptos clave en el

desarrollo de aplicaciones moviles.

8

Capitulo 2

2. Estado del Arte

En este capıtulo introduciremos las diferentes tecnologıas que se han utilizado en este pro-

yecto, como son las tecnicas de geolocalizacion o los sistemas de representacion de mapas.

En general se procurara no entrar en demasiado detalle y mostrar una vision lo mas cercana

posible al ambito de este proyecto.

2.1. Geolocalizacion

Entendemos por geolocalizacion al conjunto de tecnicas que permiten determinar la posi-

cion geografica de un elemento (un ordenador, un telefono movil o cualquier dispositivo

capaz de ser detectado) en el mundo real y hacer uso de esa informacion. Esta tecnologıa

requiere de la perfecta sincronizacion entre hardware y software, es necesario un dispositivo

con GPS o conexion a internet y un software que permita hacer uso de ellos en esta direccion.

En los ultimos anos los smartphone se han tornado el dispositivo ideal para la geoloca-

lizacion gracias al hardware que incorporan y a que sus fabricantes han dotado sus sistemas

operativos de las herramientas necesarias para que los desarrolladores hagan uso de la geo-

localizacion con facilidad y puedan centrarse en explorar sus multiples utilidades. No es de

extranar pues la gran cantidad de aplicaciones que hay disponibles en telefonos moviles que

hacen uso de esta tecnologıa. Entre ellas podemos diferenciar tres usos comunes:

Georreferenciacion: Es el proceso mediante el que se localiza un objeto, lugar o

persona en el espacio fısico para posteriormente representarlo en un sistema de coor-

denadas o mapa. Un ejemplo habitual es la representacion de tu posicion en el mapa

de tu ciudad y actualizarla a medida que te desplazas.

Geocodificacion: Es el proceso de obtencion de coordenadas geograficas a partir

de otro tipo de datos geograficos, como la direccion o el codigo postal. Al proceso

9

contrario, la obtencion de direcciones postales a partir de coordenadas se le denomina

Geocodificacion Inversa. El ejemplo claro lo vemos en la aplicacion Google Maps, que

muestra en un mapa el punto donde quieres despues de haber indicado la direccion

postal.

Geoetiquetado: Es el proceso mediante el cual se anade informacion geografica en

forma de metadatos a otro tipo de contenido. Usualmente es un paso posterior a la

georreferenciacion. Un ejemplo de geoetiquetado serıa incluir en una fotografıa las

coordenadas del lugar donde fue tomada.

Ya que el proceso de georreferenciacion es quizas el mas importante de todos, y dado que

juega un papel importante en la mayorıa de las aplicaciones de geolocalizacion, es habitual

ver como se usan ambos terminos indistintamente [1, 2, 3, 4, 5].

2.1.1. Metodos de georreferenciacion en dispositivos moviles

Un mismo dispositivo movil dispone de diferentes vıas para determinar su posicion, siendo

algunas mucho mas precisas que otras. Sin embargo en ocasiones al dispositivo no le sera po-

sible utilizar la tecnica mas precisa y debera recurrir al metodo que tenga disponible. Esta

disponibilidad la marca el medio al que esta conectado el dispositivo, y en funcion de este

medio podemos dividir las tecnicas de georreferenciacion en tres grupos:

Redes Wi-Fi

Este metodo se basa en el uso de enormes bases de datos que contienen la informacion

y situacion de gran cantidad de redes Wi-Fi. El metodo consiste en enviar la direccion

MAC del router Wi-FI y el SSID (nombre la red) y contrastarlo con la base de datos

que devolvera la posicion geografica de la red. De esta forma es posible determinar con

una precision de entre 30 y 100 metros la ubicacion de cualquier dispositivo conectado

a una red inalambrica.

Google, por ejemplo, es propietaria de una de estas bases de datos y la utiliza en

su sistema de mapas Google Maps. Para crear la base de datos enviaron vehıculos a

10

recorrer las ciudades que registraban las redes Wi-Fi que encontraban a su paso. Hoy

dıa son los propios telefonos moviles de los usuarios los que completan estas bases de

datos enviando su ubicacion [1, 9].

Redes de telefonıa movil:

Hay un gran numero de tecnicas de georreferenciacion que permiten obtener la posicion

de un dispositivo que este conectado a una red de telefonıa movil y su precision oscila

entre los 50 y los 500 metros. Mientras que en el siguiente apartado veremos las mas

relevantes, en este nos limitaremos a clasificarlas en tres grandes grupos:

• Basadas en la red

Estas tecnicas utilizan la infraestructura del operador de telefonıa movil para

determinar la ubicacion del terminal. La principal ventaja es que no son tecnicas

intrusivas y no requieren que el dispositivo disponga de hardware o software es-

pecıfico. La precision de estas tecnicas varıa no solo en funcion de la tecnica en

sı, sino tambien en funcion de la infraestructura del operador. De estas tecnicas

destacamos la CGI (Cell Global Identity), CGI-TA, que combina las tecnicas Ti-

ming Advance junto con CGI, TDOA (Time Difference Of Arrival), AoA (Angle

of Arrival) y A-GPS (Assisted Global Positioning System)

• Basadas en el terminal

Son tecnicas que requieren dotar al terminal de un receptor de senales y de apli-

caciones especıficas que realicen las tareas necesarias para determinar la posicion

geografica, por ello estas tecnicas dependen en gran medida del fabricante del

dispositivo. La principal ventaja de estas tecnicas sobre las anteriores radica en

que no son tecnicas tan dependientes de la infraestructura del proveedor de ser-

vicios. Entre las mas conocidas, encontramos E-OTD (Enhanced Observed Time

Difference) y variaciones de CGI y TDOA.

• Hıbridas

11

Combinan las tecnicas basadas en la red y las basadas en el terminal para con-

seguir mayor precision, pero heredan los inconvenientes de ambas.

GPS

GPS son las siglas de Global Positioning System. Es un sistema de localizacion por

satelites que permite determinar la posicion de un dispositivo en cualquier lugar del

globo terrestre con una precision de entre 1 y 15 metros; en el 95 % esta precision es

de 3 metros. El sistema esta formado por 27 satelites (24 operativos y 3 de repuesto)

cuya funcion es emitir senales con informacion sobre el tiempo de emision y su posicion

para que los receptores GPS las interpreten y utilicen en el calculo de su situacion

geografica. Este calculo se basa en el concepto de trilateracion, que es un principio

geometrico que permite conocer la ubicacion de un punto conociendo su distancia a

otros puntos ya conocidos, en este caso los satelites.

Figura 1: Trilateracion

Para calcular la distancia entre el dispositivo y los satelites se mide el retraso que

marca el tiempo de la senal emitida por estos. Una vez tenemos el retraso y conocien-

12

do que la senal ha viajado a la velocidad de la luz, podemos determinar la distancia

a la que se encuentra el satelite. Para que este proceso funcione es necesario recibir la

senal de al menos otros dos satelites. Con tres satelites ubicados podemos hacer una

esfera alrededor de cada uno de ellos, con el satelite como centro, y obtendremos tres

esferas que se cortaran en dos puntos, uno de ellos es despreciable puesto que no se

encuentra en la superficie de la tierra y el otro sera el que indique donde se encuentra

el receptor GPS.

No obstante, debido a que la senal no viaja realmente a la velocidad de la luz (por

retrasos en la ionosfera y estratosfera y otro tipo de obstaculos), hay errores que se

ven reflejados en la precision del resultad y para compensarlos es necesario involucrar

mas satelites y calcular sus distancias. Es por ello que el sistema GPS garantiza que

las orbitas de los satelites permiten que desde cualquier punto de la tierra sean visibles

simultaneamente no menos de cinco satelites.

Figura 2: Funcionamiento GPS

Hoy dıa hay un considerable numero de telefonos moviles que disponen de receptor

13

GPS y es la primera opcion que utilizan las aplicaciones de geolocalizacion cuando

se prioriza la precision, pero es requisito indispensable que el dispositivo se encuentre

en cielo abierto y despejado, de lo contrario no puede recibir la senal de los satelites.

Otro de sus inconvenientes es que es un sistema considerablemente lento. El resultado

puede tardar en obtenerse en torno a unos 20 - 45 segundos [1, 7, 10].

2.1.2. Tecnicas de geolocalizacion en redes de telefonıa movil

A continuacion describiremos brevemente algunas de las tecnicas de georreferenciacion que

es posible efectuar sobre dispositivos conectados a redes de telefonıa movil.

Cell Global Identity (CGI)

Para entender el funcionamiento de esta tecnica es necesario comprender primero como

estan disenadas las redes de telefonıa movil. A estas redes tambien se las conoce como redes

celulares ya que estan formadas por un conjunto de celulas que emiten a un determinada

distancia las unas de las otras. Cuando un telefono movil quiere realizar una llamada loca-

liza las senales de las antenas de estas celulas y se conecta a la que recibe con mas fuerza.

Este tipo de red esta disenado a modo de panal, de manera que cada celula esta rodeada de

otras seis, formando hexagonos, y cada una de las antenas emite en una frecuencia diferente,

por lo que tenemos siete frecuencias por hexagono (seis en las antenas de los vertices y una

en el centro).

14

Figura 3: Redes celulares

Teniendo esto claro, es facil entender el funcionamiento de esta tecnica, ya que unicamente

consiste en determinar a que antena del hexagono esta conectado el terminal, que sera la

que tenga mas cercana puesto que es cuya senal recibe con mas fuerza. Ası pues sabremos

que el terminal esta situado en el radio de alcance de esta antena.

Esta tecnica tiene la ventaja de que no necesita ningun tipo de modificacion en el dispositivo

movil (es una tecnica basada en la red), pero la precision del resultado esta ıntimamente

ligada a la densidad de antenas que tenga el operador de telefonıa movil en la zona en la que

nos encontremos. En ciudades, donde el numero de antenas es mayor, obtenemos mejores

resultados que en zonas rurales, donde el margen de error puede llegar a ser kilometrico [7, 8].

Cell Global Identity + Timing Advance (CGI-TA)

Es una mejora de la tecnica anterior haciendo uso del Timing Advance. Timing Advance

es un tecnica que permite calcular (con baja precision) la distancia entre una antena y el

dispositivo movil. Para ello se miden los retardos en la propagacion de la senal y, asumiendo

que viaja a un velocidad cercana a la de la luz, es posible determinar la distancia.

15

Figura 4: Timing Advance

Esta tecnica esta directamente vinculada a la cobertura de la celula, por lo que en entornos

rurales el margen de error puede llegar a ser tan alto como el de la tecnica CGI simple pero

en ciudad puede alcanzar una precision de hasta 10 metros [8].

Time Difference of Arrival (TDOA)

Esta tecnica consiste en medir los tiempos que tarda una misma senal en llegar desde el

terminal movil a un conjunto de antenas y ver la diferencia. A partir de ahı podemos cal-

cular la distancia a la que se encuentra de cada antena y averiguar su ubicacion exacta

gracias a la trilateracion, al igual que ocurre en el calculo de posicion mediante GPS pero

esta vez en un plano bidimensional. Cabe destacar que el calculo de la ubicacion en funcion

de los parametros de tiempo obtenidos los lleva a cabo el operador de la red, el terminal no

interviene en ningun momento, por lo que esta tecnica, al igual que CGI, es posible llevarla

a cabo en cualquier telefono movil [7, 8].

16

Figura 5: Trilateracion aplicada en TDOA

Angle of Arrival (AOA)

Es una tecnica que mide el angulo con el que inciden sobre un conjunto de antenas las senales

que emite el dispositivo movil. Para calcular estos angulos es necesario utilizar la tecnica

TDOA, y una vez se obtenien podemos calcular la posicion geografica por triangulacion.

Figura 6: Angle of Arrival

Esta es una tecnica costosa ya que requiere de un determinado tipo de antena y que pierde

eficacia en entornos urbanos, donde los edificios interrumpen las senales [7, 8].

Enhanced Obeserved Time Difference (E-OTD)

Esta tecnica se basa en el mismo principio que TDOA: a partir de la diferencia de tiem-

pos en las senales establece la posicion del terminal movil. La gran diferencia es que en

17

este caso quien lleva a cabo el calculo a partir de los parametros obtenidos es el propio

dispositivo. Ello significa que para poder hacer uso de este metodo se requieren terminales

convenientemente adaptados.

Figura 7: Esquema E-OTD

La precision de esta tecnica fluctua entre lo 50 y los 100 metros [8].

Assisted Global Positioning System (A-GPS)

Es una tecnica hıbrida que mezcla las tecnicas de geolocacilacion por redes moviles con el

sistema GPS. Para ello el operador de la red distribuye cada 200-400 kilometros de cober-

tura bajo estaciones base unos dispositivos de asistencia GPS que unicamente podran usar

aquellos terminales dotados de un receptor GPS. Estos terminales se podran conectar con

los dispositivos mediante una senal wireless o de telefonıa y ası combinar el uso del GPS con

algunas de las tecnicas vistas anteriormente. De esta manera se salvan los problemas que

tenıa el GPS para posicionar en espacios cerrados o con condiciones climatologicas adversas

y se mejoran los tiempos de obtencion del resultado, que pasan a ser de 1-8 segundos. Tam-

bien tiene un modo de funcionamiento off-line, que consiste en descargase de los dispositivos

distribuidos un fichero con los datos de los satelites y hacer uso de el cuando junto con los

resultados que de el GPS cuando se solicite el geoposicionamiento [7, 8, 11].

18

2.1.3. Herramientas de geolocalizacion

Location API for J2ME (JSR 179)

Location API for J2ME es una conjunto de APIs genericas para dispositivos moviles que

permite obtener todo tipo de informacion relacionada con la ubicacion del terminal que

utiliza el servicio. Fue desarrollada bajo el ambito del Java Community Process (JSP) en

el ano 2003 con el nombre de JSR 179, siendo Nokia el principal desarrollador y encargado

de su mantenimiento.

Es posible utilizarla mediante el paquete Javax.microedition.location pero requiere del fra-

mework Connected Device Configuration (CDC) o del Connected Limited Device Configura-

tion (CLDC) pero no en su primera version (1.0), ya que esta no soporta numeros de coma

flotante y la API los necesita para representar las coordenadas. Esta API puede usarse como

librerıa en cualquier aplicacion, ya sea de codigo abierto o cerrado, ya que se encuentra bajo

licencia GNU Lesser General Public License (LGPL).

El objetivo principal que se tenıa con esta API era proporcionar una herramienta de geolo-

caclizacion al mayor numero de dispositivos posible, sin importar sus caracterısticas, por lo

que se programo con la capacidad de hacer uso de un gran numero de tecnicas de georrefe-

renciacion. Sin embargo sı que seran las caracterısticas del dispositivo las que determinen

que tecnica puede utilizarse en ultima instancia y la precision en el resultado sera resultado

directo de esto. Haciendo uso de los metodos de localizacion a traves de redes moviles,

obtendremos mediciones con un margen de error de entre 50 y 500 metros (puede que mas

en zonas rurales), mientras que si el dispositivo tiene receptor GPS el precision se vera in-

crementada hasta los 4 - 40 metros.

Esta API funciona tanto en espacios abiertos como cerrados y permite obtener latitud,

longitud, velocidad, altura e incluso la orientacion del dispositivo (siempre que este dispon-

ga de brujula). Tiene la capacidad de asignar nombres y valores textuales (como direcciones

19

postales) a las posiciones obtenidas y almacenarlas como marcadores. Otra de sus carac-

terısticas es que permite elegir entre velocidad y precision a la hora de obtener un resultado,

siempre y cuando las caracterısticas del dispositivo den la posibilidad de usar mas de una

tecnica de geolocalizacion [12, 13].

Android Location Services

Es una API desarrollada por Google que podemos descargar gratuitamente junto con el en-

torno de desarrollo para Android y que encontramos dentro del paquete Android.Location.

Al igual que la API anterior, permite conocer todos los parametros necesarios para determi-

nar una posicion (latitud, longitud, altura, velocidad y direccion) y la actualiza en tiempo

real. Ademas tiene la opcion de consultar la ultima ubicacion obtenida, por si en un mo-

mento dado no tenemos la posibilidad de calcularla de nuevo. Otra de sus prestaciones es la

posibilidad de suscribirse a un intent o evento que lanzara cualquier aplicacion que elijamos

al llegar a una ubicacion previamente marcada.

Como es comun en estas APIs, permite utilizar las tecnicas de geoposicionamiento mediante

redes Wi-Fi locales, redes de telefonıa movil y GPS (siempre que el terminal este prepara-

do). La principal ventaja de esta API es que al ser de Google esta pensada para funcionar

con su API de mapas Google Maps y su integracion es muy sencilla [14].

Core Location

Este paquete ha sido desarrollado por Apple y solo es posible obtenerlo con su SDK y uti-

lizarlo en aplicaciones que funcionen sobre el sistema operativo iOS. Funciona empleando

las tecnicas de geolocalizacion en redes Wi-Fi, moviles o GPS que hemos visto y permite

elegir entre dos servicios diferentes a la hora solicitar la posicion del terminal [15].

Standard location service

Es un servicio configurable para un uso general y que soportan todas las versiones de

iOS. Permite solicitar la posicion del terminal en un momento determinado pero no

20

subscribirse para ser avisado en caso de cambios en esa posicion. Ademas tiene un

alto consumo energetico y es conveniente utilizarlo con mesura para ahorrar baterıa.

Significant-change location service

Es un servicio de bajo coste energetico que ademas permite recibir alertas sobre los

cambios de posicion del terminal, incluso si la aplicacion se encuentra en estado suspen-

dido o apagada. Estas alertas tambien informan del cruce entre fronteras. Unicamente

esta disponible en iOS 4.0 y posteriores.

2.1.4. Aplicaciones con geolocalizacion

Actualmente son muchas las aplicaciones que hacen uso de la ubicacion del usuario en uno

u otro sentido. A continuacion vamos a ver alguna de ellas:

Figura 8: Brujula

Brujula para iPhone

Esta aplicacion viene por defecto en todos los

telefonos iPhone. Haciendo gala del minimalismo

con el que Apple dota a todos sus productos, la

aplicacion consta de una unica pantalla que na-

da mas mostrarse ya indica la ubicacion en for-

ma de coordenadas geograficas (grados, minutos

y segundos), como podemos ver en la figura 8.

Ademas, como su nombre indica, hace las veces de

brujula indicando el norte (podemos elegir entre

el norte real y el norte magnetico) y hacia donde

esta orientado el dispositivo. Finalmente nos da la

opcion de llamar a una aplicacion de mapas y mos-

trarnos el punto geograficos donde estamos ubica-

dos.

21

Star Walk

Star Walk es una aplicacion pensada para los aficionados a la astronomıa. Se hace valer de

la ubicacion geografica para mostrar el cielo tal y como lo estamos viendo en la realidad y

lo va actualizando en tiempo real.

Figura 9: Star Walk

Ademas utiliza la el calculo de la orientacion del dispositivo para poder usarlo como si de

un cristal transparente se tratase, de forma que si lo ponemos delante de nuestros ojos y

miramos al cielo, veremos indicados en la pantalla nombre de todos los objetos celestes

(estrellas, planetas, catalogo Messier...) hacia los que estamos mirando. Es una aplicacion

disponible para dispositivos con sistema operativo iOS.

TomTom

TomTom es una aplicacion para dispositivos iOS que hace las veces de sistema GPS de

carretera. Utiliza la ubicacion del usuario para mostrarla en un mapa de carretera y guiar-

le durante el trayecto mediante voz. Tambien calcula la velocidad a la que se desplaza el

vehıculo e indica los lugares de interes a los que se va acercando (estaciones de servicio,

22

radares, accidentes... ). Sin embargo debido a la alta precision que requiere la conduccion

en carretera, solo soporta la tecnica de geoposicionamiento por GPS, por lo que es obligado

que los dispositivos que ejecuten a aplicacion tengan un receptor de senal GPS.

Figura 10: Around Me

Around Me

Esta aplicacion, disponible tanto para dispositi-

vos Android como iOS, utiliza nuestra ubicacion

geografica para indicarnos los lugares de nuestro

interes que tenemos proximos. El usuario en pri-

mer lugar indica que lugares le interesa encontrar

y la aplicacion le muestra una lista con los resul-

tados que ha obtenido, mostrando en primer lugar

los mas cercanos e indicando la distancia hasta ellos

y como llegar. Entre los lugares que podemos bus-

car tenemos disponibles bancos, gasolineras, hospi-

tales, bares, cines y muchos mas. Si lo deseamos

Around Me tambien puede mostrarnos un mapa

con nuestra ubicacion y la de los lugares selecciona-

dos.

Aplicaciones de Mapas

Tanto Android como iOS vienen instalados por defecto con una aplicacion de mapas, que

aunque son diferentes ambas tienen caracterısticas muy parecidas puesto que las dos funcio-

nan con la API de mapas Google Maps. Estas aplicaciones nos muestran nuestra posicion

en un mapa y senalizan todo lo que tenemos alrededor: el nombre de las calles, los portales,

estaciones de metro, paradas de autobus... Tambien permiten escribir una direccion postal

23

para que la aplicacion la localice y nos la muestre en el mapa con un marcador. Podemos

ver las diferentes rutas que tenemos para llegar allı desde nuestra ubicacion actual o desde

otro punto que le indiquemos. A medida que nos movemos vemos como nuestra posicion en

el mapa se desplaza de la misma forma y podemos pedir que nos muestre la direccion hacia

la que estamos mirando.

Figura 11: Mapas para iOS

2.2. Representacion de mapas

Cuando tratamos de representar una superficie esferica sobre un plano nos encontramos con

el problema de que es imposible hacerlo sin deformarlo o distorsionarlo de alguna manera,

ası que las distancias en determinados puntos no se ajustaran a las reales. Esto hace que

fijar un sistema de coordenadas en ese plano sea una tarea complicada. Ademas si lo que

queremos representar es la corteza terrestre nos encontramos con que la superficie de la

24

Tierra (al igual que la el resto de cuerpos celestes) no es perfectamente esferica, mas bien

es un esferoide ligeramente aplanado por los polos y con multitud de irregularidades en su

superficie. Ası pues la unica manera posible de representar sin ningun tipo de imprecision

la superficie de nuestro planeta es utilizar una esfera de verdad (como un globo terraqueo),

pero no es comodo trabajar con este tipo de formas en una pantalla, es por ello que para

representar mapas digitales se utilizan otros metodos [16, 17].

2.2.1. Proyeccion de mapas

Una proyeccion es un metodo matematico que permite representar un cuerpo esferico, o

cualquier cuerpo tridimensional, en un plano bidimensional. Existen varios tipos de pro-

yecciones y todas y cada una de ellas deforman algun aspecto del objeto original, ya sea

la forma, el area, la distancia o la direccion. Sin embargo segun cual sea nuestro proposito

algunas deformaciones son aceptables, por lo que podemos escoger el tipo de proyeccion que

mas se ajusta a nuestras necesidades.

La forma tıpica de clasificar los tipos de proyecciones de mapas es segun la forma del

objeto sobre el que se proyectara la esfera terrestre, dando lugar a tres grandes grupos:

cilındricas, conicas y planas

Proyecciones cilındricas

Se basan en proyectar la superfıcie de la Tierra en un cilindro. Este cilindro puede ser

tangente a la esfera terrestre en una lınea seleccionada o bien secante y cortarla por dos

lıneas. Una vez se proyecte la esfera sobre la superficie del cilindro los puntos donde la este

es tangente o secante seran los que menos distorsion tengan. Una caracterıstica interesante

de estas proyecciones es que si el cilindro es tangente o secante por los paralelos terrestres,

obtendremos mapa con todos los paralelos y meridianos rectos y paralelos entre sı.

25

Figura 12: Proyeccion cilındrica tangente y secante

Entre las proyecciones cilındricas mas famosas se encuentra la proyeccion Mercator, adop-

tada por ejemplo en aplicaciones de mapas como Google Maps. Su uso esta muy extendido

en la navegacion y, al ser tangente por el Ecuador, es comun verla en los paıses cercanos a

este. Como contrapartida pierde precision a medida que nos acercamos a los polos, dando

la falsa impresion de que Groenlandia y la antigua Union Sovietica son mas extensas que

Sudamerica y Africa.

Otras proyecciones cilındricas o pseudocilındricas muy conocidas son la Mollweide, que

dibuja la tierra dentro de un ovalo, o la discontinua de Goode, que representa como si fue-

sen gajos, de forma que aunque consigue mucha precision es muy difıcil de leer.

Proyecciones conicas

En este tipo de proyeccion la superficie de la tierra se proyecta sobre un cono imaginario.

Este cono puede ser tangente a alguno de los paralelos terrestres o secante en dos de ellos,

tal y como podemos apreciar en la figura 13.

26

Figura 13: Proyeccion conica tangente y secante

Este tipo de proyeccion no presenta deformidades allı donde el cono es tangente o secante,

por lo que es recomendable para regiones poco extensas de latitudes medias, pero presenta

grandes deformaciones regiones mayores. Como representantes de esta categorıa tenemos

la proyeccion Lambert, utilizada a menudo en aeronautica, y la proyeccion Albers, que es

secante por dos paralelos y aunque no conserva la escala y forma del original, consigue una

distorsion mınima entre los dos paralelos secantes.

Proyecciones planas

Tambien conocidas como proyecciones acimutales, en este tipo de proyeccion es un plano

bidimensional quien es tangente a la esfera terrestre por un punto o bien secante por toda

una circunferencia. Tambien es posible que el plano sea totalmente exterior a la esfera, como

en el caso de la proyeccion ortografica.

27

Figura 14: Proyeccion planar tangente y secante

Estas proyecciones tienen la particularidad de que apenas presentan deformidades en las

zonas centrales del plano, pero sı en los extremos.

Entre sus ejemplos, podemos destacar la ya mencionada proyeccion ortografica, que tiene la

apariencia de una foto del planeta Tierra tomada por un astronauta, y la proyeccion azimutal

equidistante, que tiene como principal ventaja que todas las distancias y direcciones medidas

desde el centro del mapa son verdaderas, es decir, que si trazamos una circunferencia desde

el centro, todos los puntos de ese circulo seran equidistantes respecto al origen [16, 17].

2.2.2. Sistema de Informacion Geografica (SIG)

Un Sistema de Informacion Geografica es un sistema de mapas digitalizados cuyo fin es

capturar, almacenar, manipular, analizar y desplegar la informacion geografica almacena-

da para poder ejecutar cualquier tipo de operacion relacionada con mapas de una manera

sencilla para el usuario. Entre las operaciones mas comunes se encuentra la busqueda de

direcciones, el trazado de rutas, calculo de distancias, etc.

Podemos pensar en un SIG como si de una base de datos se tratase, una base de datos

donde se almacena todo tipo de informacion geografica cuyo identificador es un objeto

grafico representado en mapa en unas determinadas coordenadas. De esta manera senalan-

28

do este objeto en el mapa podemos obtener todos los datos asociados a el que hay en la

base de datos y viceversa, si introducimos alguno de estos datos como criterio de busqueda

podemos ser trasladados a su posicion en el mapa.

Los SIG funcionan agrupando su informacion por capas que se situan la una sobre la otra

y compartiendo un mismo sistema de coordenadas. Tal y como vemos en la figura 15, una

capa puede tener la informacion fluvial, otra los mapas de carteras, otra los nombres de los

lugares de interes, etc. De esta manera es posible acceder a la informacion deseada de una

manera mas directa y podemos discriminar los datos que no deseamos ver.

Figura 15: Sistema de capas

Representacion de los datos

El leitmotiv de todo SIG es poder representar en una pantalla la realidad y sus objetos.

Estos objetos podemos dividirlos de dos grupos: discretos y continuos. Entendemos por

objetos discretos aquellos cuyos lımites estan bien delimitados, como puede ser un edificio o

una carretera. En cambio los continuos son aquellos fenomenos con lımites mas imprecisos,

como puede ser la lluvia caıda, la contaminacion o la temperatura en una zona determinada.

Para ambos objetos tenemos una forma de almacenar datos: vectorial para los discretos y

raster para los contınuos.

Raster

29

El tipo de datos raster se centra mas en las propiedades del espacio que en la precision

de las localizaciones. Consiste en dividir el espacio en celdas regulares, a modo de

malla, y asignarles un valor. Es el mismo funcionamiento que una imagen, donde a

cada pixel se le asigna un color y la union de todos acaba definiendo la imagen en

su totalidad. De hecho una forma de almacenar datos raster es como si de imagen

se tratarse, con formatos TIFF, JPEG... o tambien puden almacenarse en grandes

ficheros binarios llamados BLOB.

Vectorial

Los datos vectoriales se utilizan cuando se quiere dar prioridad a la precision de los

elementos geograficos en el espacio. Por ello, a fin de mantener sus caracterısticas

geometricas y delimitarlos adecuadamente se definen mediante vectores. Utilizan tres

tipos de figuras para modelar los elementos geograficos: el punto, la lınea y el polıgono.

El punto se utiliza para representar los elementos del mundo real que pueden ser

definidos mediante un punto concreto, como puede ser el pico de una montana u otros

puntos de interes. A escalas pequenas tambien sirven para representar poblaciones. La

lınea se utiliza para medir todo aquello que se caracteriza por su longitud, como pueden

ser carreteras, rıos, caminos, vıas, ferrocarriles, fronteras, etc. Los datos representados

por lıneas permiten medir distancias. Por ultimo el polıgono sirve para representar

elementos del mundo real que abarcan cierta extension sobre la superficie terrestre:

lagos, provincias, ciudades, parques naturales... Permiten calcular el area que abarcan.

Renderizado

Una vez tenemos los datos en la base de datos y tenemos claro como representarlos, lo unico

que falta es la fase de renderizado. Esta fase es la encargada de reunir toda la informacion

de la base de datos, unir las capas y generar la imagen final con la que trabajara el usuario.

Hay servicios de mapas que unicamente centran su trabajo en esta fase: obtienen los datos

de alguna otra fuente (por ejemplo OpenStreetMap) y se encargan de ofrecer al usuario un

renderizado y unas funcionalidades especıficas [18].

30

2.2.3. APIs de mapas

En los ultimos tiempos la creciente demanda por las aplicaciones de geolocalizacion y mapas

ha dado lugar una gran oferta de APIs disponibles entre las que poder elegir segun nuestras

necesidades. Las funciones que ofrecen todas ellas son muy similares, en general encontramos

geocodificacion, geocodificacion inversa, soporte para marcadores, calculo de distancias,

lugares de interes, etc. A continuacion veremos un pequeno listado con algunas de ellas:

OpenStreetMap: Es una base de datos geograficos de libre uso cuya popularidad

va en aumento. Desarrollada por la OpenStreetMap Foundation, permite a cualquier

tipo de desarrollador, ya sea aficionado, autonomo o una empresa, usar sus mapas sin

ningun tipo de restriccion. Su principal caracterıstica es que da acceso a la base de da-

tos subyacente y no unicamente a los datos renderizados, por lo que los desarrolladores

tienen muchısima mas libertad a la hora de crear sus aplicaciones [19].

Google Maps: Esta API desarrollada por Google es la API cuyo uso esta mas exten-

dido. Su version movil viene incluida en el paquete com.google.android.maps del SDK

de Android. Aunque hasta hace relativamente poco su uso era gratuito, recientemente

Google anadio unos lımites para su uso: 25000 cargas de mapas diarias y 2500 cargas

de mapas modificados. Si nuestra aplicacion sobrepasa ese lımite Google da la opcion

de pagar por la sobrecarga o adquirir una licencia premium. Es debido a este movi-

miento que algunas empresas se estan replanteando su uso (como Apple, que con la

ultima version de iPhoto ha cambiado Google Maps por OpenStreetMap) [20].

Bing Maps: Bing Maps es una API desarrollada por Microsoft con el objetivo de

ser el sistema principal de mapas en Windows Phone 7, aunque tambien disponen de

SDK para hacer uso de ellos en Android e iOS. Es una API de acceso gratuito pero

tiene diferentes planes de uso segun el tipo de usuario y muchas restricciones [21].

CloudMade: Esta API esta disponible para varios sistemas operativos, entre ellos iOS

y RIM BlackBerry, y presenta como principal atractivo la posibilidad de customizar los

31

mapas. No tienen una base de datos geograficos propia, sino que utilizan los mapas de

OpenStreetMap. Es una API que obliga a tener publicidad en la aplicacion (de cuyas

ganancias se benefician) o bien, para eliminarla, hacen pagar 0.30 dolares por cada

usuario que la descargue [22].

Nutiteq Map: Nutiteq Map API esta pensada para plataformas java: Android, J2ME

y RIM BlackBerry. Tiene como base los mapas de OpenStreetMap pero tambien da

la opcion de usar otros mapas, como CloudMade o Binq. Para poder utilizarla debe

comprarse una licencia que cuesta 2000 euros en su version basica. Una vez pagada la

licencia no hay cargos extra por numero de usuarios o cantidad de llamadas a la API

[23].

Map Kit Framework: Esta librerıa desarrollada por Apple funciona sobre los servi-

cios de Google Maps y es la manera mas simple que tienen los desarrolladores de

introducir mapas en las aplicaciones para iOS. Se encuentra en el paquete Map-

Kit.framework del SDK de iOS y se basa en el uso de la clase MKMapView, que

ademas de mostrar el mapa te da gran variedad de opciones interesantes, como por

ejemplo visualizar en tiempo real la posicion del dispositivo dentro del mapa sin ne-

cesidad de codigo extra [15].

2.3. iOS Vs Android

En esta seccion vamos a analizar los dos sistemas operativos para los que se ha decido rea-

lizar la aplicacion.

Cuando hablamos de iOS y de Android estamos hablando de los dos sistemas operati-

vos con mas base de usuarios y aplicaciones de todo el panorama smartphones. Desde que

fueron lanzados en 2007 y 2008 respectivamente, sus ventas no han hecho mas que crecer

en detrimento de sus competidores.

32

Figura 16: Grafico de ventas de dispositivos moviles segun su SO

Como podemos apreciar en la figura 16 el crecimiento de Android ha sido mucho mas pro-

nunciado que el iOS. Esto se debe fundamentalmente que Android es un sistema operativo

instalado en mas de 200 dispositivos, mientras que iOS nacio por y para iPhone, aunque

mas adelante su uso se ha portado al iPad, iPod Touch y Apple TV.

Las companıas que encontramos detras de ambos sistemas operativos son dos de las em-

presas mas poderosas en el mundo de la tecnologıa. Lo son y lo eran antes de semejante

exito con los smartphone. Hablamos de Apple en el caso de iOS y Google en el de Android.

Que si bien coinciden en el exito, ambas tienen filosofıas muy diferentes. Google diseno An-

droid para que fuera un sistema operativo abierto, querıa que cualquier companıa pudiese

instalarlo en su telefono movil y se sintiese libre de modificarlo segun sus necesidades. Por

contra Apple desarrollo iOS pensando exclusivamente en su nuevo dispositivo, el iPhone,

que estaba destinado a revolucionar el mundo de la telefonıa movil. Y como viene siendo

33

tradicional con todos los productos Apple, cuya polıtica consiste en crear un ecosistema

propio, cerrado, basado en la eficiencia, el diseno y la facilidad de uso, su nuevo sistema

operativo serıa exclusivo y no podrıa ser modificado por nadie.

2.3.1. Lenguajes

Los lenguajes de programacion con los que por defecto se trabaja en estos sistemas operati-

vos siguen las filosofıas de las que hablabamos antes. Por un lado Objective-C para iOS, que

es un superconjunto de C creado a principios de los anos ochenta y que Apple utiliza tanto

en el desarrollo de iOS como en el de Mac OS X. Por el otro tenemos Java, que aparecio a

mediados de los noventa con la idea clara de ser un lenguaje multiplataforma, es decir, que

un mismo programa pudiese ejecutarse en cualquier tipo de hardware. Como vemos esto

casa perfectamente con la idea de Android de ser un SO operativo que pueda funcionar en

cualquier dispositivo.

De cara al programador, aunque Java y Objective-C son dos lenguajes orientados a ob-

jetos cuya sintaxis se inspira en C, no es en absoluto lo mismo trabajar con ellos. Para

empezar la sintaxis, aun teniendo la misma base, es mucho mas legible en el caso de Java.

Objective-C obliga a emplear largas lıneas de codigo con caracteres que no son habituales

en la mayorıa de lenguajes de programacion. Si el programador tiene experiencia previa,

debido a la naturaleza multiplataforma de Java, es probable que alguna vez haya trabajado

con el o al menos este familiarizado con sintaxis parecidas. Por contra si el programador

no tiene experiencia previa en iOS o Mac OS X, Objective-C sera un completo desconocido

para el y debera emplear tiempo en familiarizarse. Ademas, como Java es un lenguaje muy

conocido, resulta mas sencillo encontrar documentacion extra o consultar dudas con otros

programadores puesto que la comunidad Java es mayor y hay mas bibliografıa disponible.

Una de las diferencias fundamentales entre ambos lenguajes es que, mientras que Java se

desarrollo con la idea de resultar mas sencillo de cara al programador ahorrandole las tareas

34

de bajo nivel que tenıa C, Objective-C, al ser un superconjunto de este, las conserva todas.

La mas importante sin duda es el manejo de memoria. Mientras Java se olvida de punteros,

de reservar memoria y liberar espacio, dejando todo el trabajo al recolector de basura de

turno (el de Android en este caso), Objective-C, puesto que iOS no dispone de el, debe

lidiar con ello. O debıa, ya que la salida del reciente iOS 5 ha supuesto un gran cambio en

este sentido. Sigue sin tener implementado un recolector de basura propiamente dicho, pero

tiene un Automatic Reference Counting (ARC). Mientras un recolector de basura pierde

recursos del hardware durante el proceso de liberar memoria, el ARC lo que hace es insertar

la logica de la gestion de memoria dentro del codigo durante el proceso de compilado. De

esta manera logramos tener la eficiencia que da la gestion manual de memoria, sin perder

tiempo pensando en ella ni la seguridad que da un recolector de basura, pero sin sacrificar

rendimiento por el camino.

Como apunte final, hablando de rendimiento, en general podemos decir que la dupla iOS y

Objective-C consigue mejores resultados que Android y Java. Esto de nuevo tiene que ver

con sus filosofıas. Objective-C es un lenguaje cuyas aplicaciones se compilan directamente

en codigo ejecutable para el procesador. Esto es posible porque Apple tiene una filosofıa

cerrada y toda aplicacion se ejecutara unicamente en las CPU que ellos decidan ensamblar

en sus dispositivos. Por otro lado, como Android es un SO abierto destinado a multitud de

dispositivos diferentes con procesadores igual de diversos, y no es recomendable un sistema

que obligue a compilar una aplicacion para cada tipo de procesador, decidieron disenar una

maquina virtual intermedia sobre la cual funcionarıan sus aplicaciones. Esto claro tiene un

coste en cuanto a rendimiento [24, 25].

2.3.2. Herramientas de desarrollo

Tanto Apple como Google tienen a disposicion de los futuros desarrolladores un completo

SDK y toda la documentacion necesaria para configurarlos y empezar de cero. Ambos son

accesibles de manera gratuita, pero en el caso de Apple hay una serie de consideraciones

35

que pueden hacer que esa afirmacion no sea del todo cierta. En primer lugar, Xcode, que es

como se llama el IDE para desarrollar tanto para iOS como para Mac OS X, solo funciona

en un ordenador Mac. Ası pues, si no se dispone de uno, es necesario efectuar un desembolso

inicial de al menos 699 euros para comprar uno. Si ya se dispone de un Mac, el siguiente

paso es hacerse una cuenta de desarrollador. La version gratuita de esta cuenta permite

descargar el SDK y empezar a programar, pero no permite distribuir tus aplicaciones ni

testearlas en dispositivos iOS fısicos, unicamente en el simulador que viene con el kit de

desarrollo. La version de pago no tiene estas restricciones y cuesta 99 dolares al ano. Ademas

para poder trabajar con la ultima version del SDK y desarrollar ası para la ultima version

de iOS, es necesario tener instalado en el Mac la ultima version de Mac OS X. En caso

contrario habra que comprarlo e instalarlo. Por ultimo tambien hay que tener en cuenta

que para testear tus aplicaciones iOS es necesario disponer en un iPhone, iPad o un iPod

Touch, que no son dispositivos baratos, en cambio en Android tienes una gran variedad de

dispositivos donde para elegir.

En cuanto al IDE, programar para iOS unicamente es posible con Xcode. En cambio Google

permite instalar el kit de desarrollo en tu IDE habitual, como por ejemplo Eclipse, NetBeans

o IntelliJ IDEA. Ademas el SDK de Android puede instalarse en Linux, Windows o Mac

OS X.

Una vez se esta listo para desarrollar, cabe decir que Xcode supera en eficiencia y ren-

dimiento a cualquier IDE que escojamos para desarrollar en Android. Esto sin duda es

debido de nuevo al ecosistema cerrado que envuelve a Apple. Xcode esta pensado unica-

mente para Mac OS X que esta pensado unicamente para funcionar sobre un Mac. Esto

permite aprovechar mejor el hardware de la maquina. La diferencia se vuelve mas que no-

toria cuando se quiere ejecutar tu aplicacion sobre el simulador: mientras que el de Android

puede tardar cerca de dos minutos en arrancar, el de iOS es mucho mas inmediato.

36

Finalmente, una vez tenemos la aplicacion lista, siempre es recomendable testearla en varios

de los dispositivos sobre los que podra funcionar. En el caso de iOS esto se reduce a menos

de una decena. En cambio en Android, al estar mucho mas fragmentado, directamente es

imposible hacerlo. Esto puede provocar que en alguno de los dispositivos el rendimiento

no sea el esperado o que la interfaz grafica se vea desajustada en una pantalla de menor

tamano que la utilizada durante el testeo.

2.3.3. Plataformas de distribucion

Apple y Google disponen de su propia plataforma de distribucion: App Store y Google Play

respectivamente. Como ya se ha comentado, para poder subir aplicaciones a la App Sto-

re debers tener una cuenta de desarrollador de Apple que cuesta 99 dolares anuales. Para

Google Play tambien se precisa un perfil de desarrollador y pagar una cuota de registro de

25 dolares.

Los requisitos solicitados durante el proceso de subir aplicaciones es similar en ambas

plataformas. Siempre se solicita adjuntar los iconos de la aplicacion en una resoluciones

determinadas, indicar los idiomas que soporta la aplicacion, el nombre de la misma y una

breve descripcion, etc. La diferencia principal es el proceso de validacion por el que Apple

hace pasar a todas las aplicaciones. Mientras que con Android puedes tener tu aplicacion

disponible para descargar en cuestion de minutos, el proceso de Apple se puede hacer te-

diosamente largo. El objetivo de este es comprobar que las aplicaciones cumplen una serie

de requisitos de calidad y que no pondran en uso practicas que comprometan la eficiencia

y el buen funcionamiento de iOS [26, 27].

37

Capitulo 3

3. Diseno de la aplicacion

En este capıtulo veremos la informacion relacionada con el analisis funcional y la especifica-

cion de la aplicacion, es decir, las tareas mas relacionadas con la arquitectura del software.

3.1. Requisitos funcionales

A continuacion describiremos las funcionalidades de la aplicacion desarrollada:

Mostrar en el mapa la posicion geografica del usuario

La aplicacion debera mostrar en un mapa, siempre que disponga de alguna conexion

de red, la posicion geografica del usuario y actualizarla en tiempo real. El usuario

podra manipular el mapa mediante zooms y desplazamientos y volver a centrarse en

la posicion del usuario apretando a un boton.

Ubicar en el mapa hornos cercanos

La aplicacion debera mostrar en el mapa, nada mas cargar la aplicacion, todos los

hornos que estan proximos al usuario en un radio de 2 kilometros.

Ubicar en el mapa hornos por distancia

Existira una pantalla donde se podra seleccionar en cualquier momento una distancia

no mayor de 100 kilometros y, al presionar un boton, se mostraran en el mapa todos

los hornos que esten a una distancia del usuario igual o menor a la seleccionada.

Mostrar ruta hasta el horno seleccionado

El usuario podra seleccionar cualquiera de los hornos mostrados en el mapa y ver la

ruta a seguir para llegar hasta a el. El punto de inicio de la ruta podra ser la ubicacion

actual del usuario o una direccion postal introducida por el.

Mostrar lista de hornos

38

La aplicacion debera mostrar en una pantalla el listado de hornos organizado por

provincias, comarcas y poblaciones.

Ubicar en el mapa un horno de la lista

El usuario podra mostrar en el mapa cualquiera de los hornos de la lista de manera

independiente.

Mostrar datos de interes de cualquier horno

El usuario debera poder consultar en una misma pantalla todos los datos disponibles

del horno que seleccione.

Telefonear a cualquier horno de la lista

El usuario debera poder telefonear al horno que seleccione sin marcar su numero de

telefono, unicamente presionando un boton.

3.2. Requisitos no funcionales

Siguiendo el esquema del apartado anterior, en este punto detallaremos los requisitos no

funcionales.

Version del sistema operativo

La aplicacion debera funcionar en todos los dispositivos Android que tengan instalada

la version 2.3.3 (o superior) del sistema operativo. En dispositivos iPhone, la aplicacion

debera funcionar en todos aquellos que tengan la version 5.0 de iOS, o superior.

Acceso a la aplicacion

La aplicacion debera poder descargarse gratuitamente desde las plataformas de dis-

tribucion oficiales de Google y Apple: Google Play y App Store respectivamente.

Idioma

La aplicacion debera estar disponible al menos en catalan.

Lenguaje de programacion

39

La aplicacion Android estara desarrollada en Java, mientras que la version para iOS

estara desarrollada en objective-C.

Tiempos de carga

Con el fin de hacer que la aplicacion sea los mas agil posible, se minimizaran los

tiempos de carga. Esto implica reducir sobre todo los accesos a la base de datos y al

fichero pList que contiene la informacion de los hornos.

Aplicacion de mapas

Para poder indicar las rutas, el dispositivo movil debera tener instalada la aplicacion

de mapas que viene por defecto en el sistema operativo.

Tarjeta SIM

Para poder hacer uso de la funcion de telefonear a los hornos, el dispositivo movil

debera tener insertada una tarjeta SIM operativa.

3.3. Diagrama de estados

En este apartado vamos a mostrar una serie de diagramas de estado que se han hecho para

detallar el comportamiento de las funcionalidades basicas, de las diferentes pantallas y la

navegacion entre ellas.

3.3.1. Inicio de la aplicacion

A continuacion detallamos los procesos que la aplicacion lleva a cabo cuando empieza a

ejecutarse.

40

Inicializar aplicación

[Si es la

primera vez]

Cargar BBDD

Pantalla Mapa

Error

Mostrar Posición

Mostrar Hornos Cercanos

[Si localización

no disponible]

[Si localización

disponible]

[Si no es la

primera vez]

Figura 17: Diagrama de estados de inicio de la aplicacion

Cargar BBDD

Todos los datos de los hornos de los que dispone la aplicacion se encuentran en un

fichero formato pList que fue proporcionado por el grupo de hornos. Acceder a estos

datos directamente es un proceso lento, por lo que se ha optado por almacenarlos

durante la primera ejecucion en una base de datos y leerlos desde ahı en el futuro.

Inicializar Aplicacion

En esta fase se ponen en marcha los servicios de localizacion del dispositivo movil y

se inicializan los objetos necesarios para poder leer la base de datos.

Mostrar Posicion

Este proceso es el encargado de determinar las coordenadas actuales del dispositivo y

representarlas en el mapa.

Mostrar Hornos Cercanos

Una vez obtenida la posicion del dispositivo se accede a la base de datos en busca

de todos aquellos hornos que estan cerca del usuario, concretamente a una distancia

41

no superior a 2 kilometros. Una vez se obtiene la lista de hornos que cumplen con el

requisito se muestra un marcador para cada uno de ellos en la pantalla del mapa.

3.3.2. Esquema general de la aplicacion

A continuacion se muestra un par de esquemas para entender la navegacion en funciona-

miento general de la aplicacion. En la figura 18 se muestra la navegacion entre pantallas.

Pantalla Mapa

Pantalla Lista

Hornos

Pantalla Hornos

Distancia

Pantalla Vista

Horno

Figura 18: Navegacion entre pantallas desde el menu

Al ejecutarse la aplicacion en primer lugar aparecera la pantalla Mapa. Haciendo uso del

menu podremos desplazarnos libremente por tres pantallas: Mapa, Lista Hornos y Hornos

Distancia. Ademas desde lista podremos ver la pantalla Vista Horno, que al mostrarse ocu-

para el lugar de Lista Hornos en el menu. Esto significa que podremos movernos libremente

entre Mapa, Vista Horno y Hornos Distancia. Para volver a la lista habra que situarse en

Vista Horno y retroceder a la lista. En la proxima seccion veremos en detalle el funciona-

miento de la pantalla Lista Horno para entenderlo mejor.

42

El siguiente esquema muestra la ubicacion de las funcionalidades en las distintas panta-

llas y como nos desplazamos por la aplicacion a traves de ellas.

Mostrar Ruta

Pantalla Mapa

Mostrar PosiciónMostrar Hornos

Cercanos

Seleccionar

marcador

Mostrar Datos Horno

Pantalla Lista Hornos

Pantalla Vista HornoPantalla Hornos

Distancia

Mostrar Horno Seleccionado

Telefonear al Horno

Mostrar Hornos por Distancia

Seleccionar

distancia

Seleccionar

horno

Figura 19: Esquema general de la aplicacion

Pantalla Mapa

Esta es la primera pantalla que cargara la aplicacion. Ademas al hacerlo se mostrara un

marcador indicando la posicion de cada uno de los hornos que hay cerca de la posicion

geografica del dispositivo. Esa posicion sera visible en todo momento (siempre que sea

posible calcularla) y se podra centrar el mapa en ella pulsando un boton. Por ultimo

podremos ver la ruta a alguno de los hornos que este mostrandose en ese momento.

Esta ultima funcion dejara la aplicacion ejecutandose en segundo plano y mostrara la

aplicacion de mapas del sistema operativo con la ruta trazada.

43

Pantalla Lista Hornos

La unica funcion de esta pantalla sera navegar por la lista de hornos y seleccionar

uno, que se mostrara en la Pantalla Vista Horno

Pantalla Vista Horno

Esta pantalla se abrira despues de seleccionar un horno de la lista. Contendra toda

la informacion del horno y permitira pulsar un boton para mostrarlo en el mapa (en

cuyo caso cargara la Pantalla Mapa con un marcador indicando la posicion del horno).

Tambien existira otro boton para telefonear al horno, lo que dejara la aplicacion en

segundo plano y marcara el numero de telefono con la aplicacion predeterminada del

sistema operativo.

Pantalla Hornos Distancia

Esta pantalla permitira indicar una distancia y pulsar un boton para mostrar todos

los hornos de la lista que haya a una distancia igual o menor a la seleccionada. Al

pulsar el boton se abrira la Pantalla Mapa con un marcador para cada uno de los

hornos que han cumplido el requisito de la distancia.

3.3.3. Mostrar y telefonear a un horno de la lista

Ahora vamos a detallar la manera de seleccionar un horno de la lista. Al seleccionarlo

iremos a la pantalla Vista Horno y habran dos botones para mostrar el horno en el mapa

o telefonearlo.

Antes de empezar a describir esta funcionalidad es necesario entender como esta disenada la

lista de hornos. Como ya hemos comentado, cuando ejecutamos por primera vez la aplicacion

se lanza un proceso que lee los datos de los hornos de un fichero pList y los introduce en la

base de datos. Ası pues antes de llegar a la Pantalla Lista Hornos disponemos de una base de

datos con los atributos de cada horno. Para facilitar la localizacion del horno deseado dentro

de la lista se han utilizado algunos de estos atributos para agrupar los hornos, concretamente

los relacionados con su ubicacion: provincia, comarca y poblacion. Ahora debemos imaginar

44

la lista como si de un arbol se tratase, de forma que seleccionando uno de los nodos de cada

nivel pasamos a ver el siguiente, tal y como se muestra en la figura 20 :

Provincia 1 Provincia 2 Provincia n

Comarca 1.1

Población 1.1.1

Horno 1.1.1.1

Nivel 1

Nivel 2

Nivel 3

Nivel 4

Comarca 1.2 Comarca 1.n

Población 1.1.2 Población 1.1.n

Horno 1.1.1.2 Horno 1.1.1.n

Pantalla Vista

Horno

Pantalla Lista Hornos

Figura 20: Esquema de la Pantalla Lista Hornos

Ası pues en esta pantalla el objetivo es ir nivel a nivel hasta llegar a un subconjunto de

hornos elegido en funcion del nodo seleccionado en cada nivel. Una vez pulsamos sobre un

horno del subconjunto cambiaremos a la Pantalla Vista Horno y allı habra dos botones: uno

para telefonear al horno y el otro para mostrar su marcador en el mapa. El funcionamiento

se resume con el diagrama de la figura 21 :

45

Pantalla Lista

Hornos

Pantalla Lista

Hornos

Pantalla Lista

Hornos

Pantalla Lista

Hornos

Pantalla Vista

Horno

Pantalla Mapa

Mostrar Horno Seleccionado

Telefonear al Horno

Provincia Comarca Población Horno

Atrás Atrás Atrás Atrás

Figura 21: Diagrama de estados mostrar y telefonear horno

3.4. Diagramas de secuencia

En esta seccion vamos a disenar los diagramas de secuencia de las funcionalidades mas

importantes de la aplicacion. Mostraremos las relaciones entre las clases y los metodos que

se ejecutan en cada momento. Es necesario tener en cuenta que las dos aplicaciones de este

proyecto (iOS y Android) no tienen las mismas clases. Esto es debido a que las librerıas del

SDK de una y otra tecnologıa permiten hacer las cosas de manera diferente. Una misma

funcionalidad puede resultar mas sencilla de implementar gracias al uso de estas librerıas y

requerir menos lıneas de codigo, dando como resultado una organizacion diferente de clases.

Es importante destacar que estas diferencias en ningun momento han perjudicado ni a la

claridad del codigo ni a la posible reusabilidad del mismo. En el siguiente capıtulo veremos la

implementacion con mas detalle, ahora unicamente nos interesa conocer esto para entender

los diagramas de secuencia que vienen a continuacion.

La siguiente figura muestra la equivalencia entre los nombres de las clases que vamos a

utilizar en los diagramas y las clases que aparecen en las aplicaciones.

46

Capa Nombre genérico iOS Android

CtrlMapa

CtrlLista

CtrlHorno

CtrlProximos

VistaMapaController FornsIGPActivity

LlistatFornController

VistaFornController

FornsProximsController

LlistatActivity

VistaFornActivity

FornsProximsActivity

Capa de presentación

Capa de negocio Horno

GestorAplicación

GestorLocalización

Forn

AppDelegate

CoreLocation.framework

Forn

GestorAplicacion

GestorLocalizacion

ProcesadorUbicacion

Localizador

LocationWaiter

Capa de datos DBObject

CoreDataDelegate

FornDAO

XMLPListParser

DataBaseCreator

DataBaseInit

Marcador DisplayMap BalloonMap

GestorBBDD GestorBBDD

CoreData.framework

Figura 22: Equivalencia de clases

El nombre generico de las clases que vemos en la figura 21 sera el utilizado el los diagramas.

Las clases que aparecen agrupadas lo estan porque su funcionamiento es totalmente equi-

valente. Por eso es posible asignarles un unico nombre generico para los diagramas y ganar

ası claridad en estos. Senalar tambien que las clases escritas en azul son librerıas del SDK.

47

3.4.1. Inicio de la aplicacion

loop

GestorBBDD

loop

GestorLocalización

opt

Usuario<<Actor>>

:CtrlMapa

inicio

GestorAplicación

inicializarAplicacion()inicializarBBDD()

:DBObject

new()

leerPList()

insertarHornos()

inicializarLocalizacion()

[ 1ª vez ]

getLocation()

locdraw(loc)

[ TRUE ]

obtenerHornosDistancia(2)

listaHornos

m:Marcador

new(h) [ ! h ∈ listaHornos ]

draw(m)

Figura 23: Diagrama de inicio de la aplicacion

48

Cuando el usuario inicia la aplicacion se carga automaticamente la Pantalla Mapa como

pantalla de inicio y su clase responsable es CtrlMapa. Automaticamente se llama al metodo

inicializarAplicacion() de la clase estatica GestorAplicacion. Este metodo realiza las tareas

que son necesarias para poner a punto el programa. En primer lugar se inician los objetos

de la base de datos mediante el metodo inicializarBBDD() de la clase GestorBBDD. Este

crea un nuevo objeto DBObject, que ademas de poner a punto la BBDD lee el fichero

pList y guarda los datos de los hornos en la base de datos si es la primera vez que se

ejecuta la aplicacion. Acto seguido GestorAplicacion inicializara los objetos que se encargan

de obtener la localizacion geografica con el metodo inicializarLocalizacion() de la clase

GestorLocalizacion. Acto seguido CtrlMapa lanza un proceso asıncrono que ira solicitando la

posicion a GestorLocacion con el metodo getLocation() y la indicara en el mapa. Finalmente

llamara al metodo obtenerHornosDistancia() de GestorBBDD con el valor 2 para obtener

la lista de hornos que estan a menos de 2 kilometros de distancia y creara un marcador

para cada uno de ellos que dibujara en el mapa. La aplicacion restara a la espera de que el

usuario ejecute nuevas acciones.

49

3.4.2. Mostrar Horno Seleccionado

:CtrlHorno

loop

Usuario<<Actor>>

:CtrlLista

ir a la listanivel := 1

alt

[ nivel < 5 ]

GestorBBDD

obtenerProvincias()

lista

obtenerComarcas(s)

obtenerPoblaciones(s)

obtenerHornos(s)

[ nivel = 1 ]

[ nivel = 2 ]

[ nivel = 3 ]

[ nivel = 4 ]

mostrar(lista)

elegir ítem snivel ++

h:Horno

new(s)

new(h)

presionar "Mostrar en mapa"

:CtrlMapa

dibujarHorno(h)

m:Marcador

new(h)

draw(m)

Figura 24: Diagrama mostrar horno seleccionado

En primer lugar el usuario debe dirigirse a la Pantalla Lista Hornos a traves del menu de

la aplicacion. Como se vio en el capıtulo anterior, esta pantalla funciona como un arbol y

cada vez que avanzamos por los niveles del arbol los nodos cambian, cosa que se ve reflejada

en los ıtems que muestra la lista. Nada mas cargar la pantalla se establece el valor de

50

la variable nivel a 1. Cada vez que el usuario selecciona un ıtem incrementa este nivel y

cambian los valores de la lista. Estos valores se solicitan a la clase GestorBBDD con los

diferentes metodos que vemos en el diagrama. Cuando el valor de nivel es igual a 4 los

ıtems de la lista seran los nombres de los hornos. Si el usuario selecciona uno creara un

objeto de la clase Horno con el valor que ha seleccionado y se llamara al controlador de la

Pantalla Vista Horno, CtrlHorno, para cargar la pantalla con los valores del objeto Horno.

Acto seguido, cuando el usuario presione un boton, invocara el metodo dibujarHorno() de

CtrlMapa pasando como valor el objeto Horno. En ese instante se mostrara esta pantalla en

primer plano, creara un objeto Marcador con los valores del objeto Horno y lo dibujara en

el mapa.

3.4.3. Telefonear al Horno

El proximo diagrama comparte codigo con el diagrama de la figura 24 hasta la marca de

color amarillo, ası que para no repetir informacion vamos a considerar que este diagrama

comienza desde la citada marca.

:CtrlHornoUsuario

<<Actor>>:CtrlLista

new(h)

presionar "Telefonear"

Sistema Operativo

apiTelefonear(h.telf)

AppTelefono

marcar

Figura 25: Diagrama telefonear a un horno

Como ya se ha comentado, este diagrama comparte la misma logica que el diagrama de

51

la figura 24 hasta el momento en el que el usuario debe pulsar uno de los dos botones

de la Pantalla Vista Horno. En este caso, si el usuario presiona el boton encargado de

ejecutar la funcion para telefonear, el CtrlHorno recoge la accion y lanza una llamada

al sistema operativo para que ejecute la aplicacion que por defecto se encarga de realizar

llamadas telefonicas. Una vez finalizada la llamada telefonica el control lo recupera el sistema

operativo y el usuario sera libre de realizar cualquier otra accion. Nuestra aplicacion no se

habra cerrado, seguira ejecutandose en segundo plano a la espera de que el usuario vuelva

a necesitarla.

52

3.4.4. Mostrar Hornos Distancia

loop [ ! h ∈ lista ]

loop

alt

Usuario<<Actor>>

:CtrlProximos

ir a la pantalla

elegir distancia

<< d := distancia >>pulsar botón

:DBObjectGestorBBDD

obtenerHornosDistancia(d)obtenerTodos()

listaTodos

GestorLocalización

getLocation()

loc

lista := null

[ ! h ∈ listaTodos ]

dH := distancia entre loc y h

[ "#$≤$" ]lista.add(h)

lista

:CtrlMapa

dibujarHornos(lista)

dibujarHorno(h)

Figura 26: Diagrama mostrar hornos segun distancia

Para realizar esta funcionalidad el usuario debe ir a traves del menu a la Pantalla Hornos

Distancia. Allı debera seleccionar una distancia y darle a un boton. En ese momento CtrlPro-

ximos capturara la accion y lanzara el metodo obtenerHornosDistancia del GestorBBDD,

pasandole como parametro la distancia seleccionada. Para discernir que hornos estan a una

distancia igual o menor a la seleccionada, en primer lugar obtendra todos los hornos existen-

tes en la base de datos mediante el metodo obtenerTodos() de la clase DBObject. Tambien

53

necesitara la localizacion actual del dispositivo, que la obtendra del GestorLocalizacion.

Cuando tenga las dos cosas entrara en un bucle y comparara, para cada horno, la distancia

que hay entre el dispositivo movil y el horno con la distancia que ha seleccionado usuario.

Todos los hornos que esten a una distancia igual o menor los anadira a una lista. Finalmente

se pasara esa lista a CtrlMapa y allı se ejecutara el metodo dibujarHorno() para cada horno,

cuyo funcionamiento ya hemos visto en el diagrama de la figura 24.

3.4.5. Mostrar Ruta

El siguiente diagrama parte del estado en el cual hay marcadores de hornos en el mapa. A

esta situacion se puede llegar despues de los diagramas de las figuras 23, 24 o 26.

alt

GestorLocalizaciónUsuario

<<Actor>>:CtrlMapa

inicio

indicar dirección inicio (addr)

indicar posición actual como inicio getLocation()

inicio := null

inicio := addr

locinicio := loc

:Marcardor

getCoordenadas()

destino

URL := << formar URL con inicio y destino >>

Sistema Operativo

llamadaSO(URL)

Aplicación de mapas

abrirApp(URL)

presionar botón

elegir marcador

mostrarPanelRuta()

Figura 27: Diagrama mostrar ruta

54

La primera accion que debe realizar el usuario es seleccionar el marcador que senala al

horno donde desea ir. En ese instante el CtrlMapa mostrara un panel donde podra indicarse

el origen de la ruta y un boton para ejecutar la funcionalidad. El usuario podra indicar

cualquier direccion postal como inicio de la ruta o bien dejar por defecto la ubicacion

actual del dispositivo. Si elige esta segunda opcion CtrlMapa pedira a GestorLocalizacion

la ubicacion mediante el metodo getLocation(). Si por contra prefiere indicar una direccion

la aplicacion la transformara en coordenadas que usara como inicio de la ruta. Cuando el

usuario presione el boton para ver la ruta, CtrlMapa obtendra del marcador las coordenadas

del horno y las usara como destino. Despues compondra una direccion URL con el inicio y

el destino y se la lanzara al sistema operativo, que traducira la URL y abrira la aplicacion

de mapas que tenga por defecto (Google Maps en Android y Maps en iOS) y dibujara la

ruta. Al igual que ocurrıa en la funcionalidad Telefonear al Horno, la aplicacion quedara en

segundo plano a la espera de que el usuario vuelva a necesitarla.

55

Capitulo 4

4. Implementacion

En este capıtulo dejamos atras todas aquellas tareas que son responsabilidad del arquitecto

de software y vamos a entrar en el detalle de la estructura de clases, su diseno y las funciones

de cada una de ellas, es decir, lo que ha sido el trabajo del programador.

En primer lugar es importante diferenciar la implementacion de la aplicacion iOS de la

implementacion de la aplicacion Android, puesto que ambas tienen diferencias importantes

en su codigo, mas alla de lo que serıan las diferencias vinculadas al propio lenguaje de pro-

gramacion. Por ello primero describiremos la implementacion en iOS, luego en Android y

finalmente senalaremos las diferencias mas notorias entre ambas y analizaremos cuanto han

ayudado los respectivos SDKs a la hora de implementar.

4.1. Implementacion en iOS

Esta implementacion se ha llevado a cabo en el entorno Xcode y el lenguaje utilizado para

el desarrollo ha sido Objective-C.

Si observamos la figura 28, podemos ver las diferentes capas que componen la aplicacion y

como quedan emplazadas dentro de ellas las clases desarrolladas. Tambien incluiremos las

librerıas del SDK de iOS que han sido necesarias para el desarrollo de esta aplicacion.

56

Capa Clase/Objeto

VistaMapaController

LlistaFornController

VistaFornController

FornsProximsController

Capa de gestión

Forn

AppDelegate

CoreLocation.framework

Capa de datos

CoreDataDelegate

Marcador

CoreData.framework

Origen

Interfaz MainStoryboard.storyboard Desarrollado

Desarrollado

Desarrollado

Desarrollado

Desarrollado

Desarrollado

Desarrollado

Desarrollado

iOS SDK

Desarrollado

Librerías del sistema UIKit.framework iOS SDK

iOS SDK

CoreGraphics.framework iOS SDK

Foundation.framework iOS SDK

ModeloDeDatos.xcdatamodeld Desarrollado

MapKit.framework iOS SDK

Figura 28: Clases aplicacion iOS

4.1.1. Librerıas del sistema

Estas tres librerıas contienen las clases y las funcionalidades mas basicas de un proyecto

iOS. Componen el nucleo de cualquier aplicacion.

CoreGraphics.framework

Es una librerıa desarrollada en C basada en el motor de graficos Quartz, que proporciona

mecanismos para el renderizado a bajo nivel de graficos en 2D. Se encarga entre otras co-

sas del dibujo de los graficos, transformaciones, coloreado, paletas, degradados y matices,

muestra de imagenes e incluso de archivos PDF.

Foundation.framework

57

Esta librerıa define la capa base sobre la que se sustentan las clases de Objective-C. Propor-

ciona un conjunto de objetos primitivos e introduce paradigmas no cubiertos originariamente

por el propio lenguaje con el objetivo de facilitar el desarrollo en Objective-C y favorecer

la portabilidad.

Foundation.framework incluye los objetos raız de la jerarquıa de clases y aquellas clases que

representan los tipos de datos basicos, como los strings, los arrays de bytes o las colecciones

de objetos.

De entre las clases que han servido para desarrollar esta aplicacion, podemos destacar las

siguientes:

NSObject: Es la clase raız de la mayorıa de clases en Objective-C. A traves de esta

clase se heredan los mecanismos necesarios para convertirse en un objeto de Objective-

C y ser tratado como tal en tiempo de ejecucion. Entre sus metodos podemos destacar

alloc, que reserva espacio en memoria para el objeto; init, que lo inicializa y finalize,

que prepara el objeto para ser liberado en memoria.

NSString: En Objective-C NSString es la clase que se utiliza para definir cadenas

de texto Unicode. Proporciona los metodos habituales para trabajar con este tipo

de objetos pero no permite modificar su valor una vez le ha sido asignado. Para ello

deberıamos usar su subclase NSMutableString.

NSException: Esta clase se usa para el control de excepciones y contiene toda la

informacion del error que se ha producido.

NSArray: Es la clase que permite manejar colecciones de objetos. NSArray solo

permite colecciones estaticas, es necesario definir su tamano antes de utilizarlas. Para

poder modificar la longitud de la coleccion se requiere el uso de su subclase NSMuta-

bleArray.

UIKit.framework

Esta librerıa proporciona las clases necesarias para la construccion y el manejo de la interfaz

58

grafica de la aplicacion. Se encarga de facilitar los mecanismos que controlan la aplicacion,

el manejo de eventos, la estructura de ventanas, los objetos basicos para el uso de interfaces

tactiles, etc.

La interfaz de esta aplicacion usa varias de estas clases. A continuacion se destacan las mas

importantes:

UIEvent / UIResponder: Un objeto UIEvent representa un evento del sistema iOS.

Estos eventos pueden ser de tres tipos: tactiles (aquellos que se producen al tocar la

pantalla), de control remoto (aquellos producidos por accesorios externos al terminal)

o de movimiento (los producidos por el movimiento del dispositivo, por ejemplo por un

acelerometro). Estos objetos envıan toda la informacion a los objetos UIResponder

que esten a la escucha, que trataran el evento e informaran a la aplicacion que se

ha producido. En realidad UIResponder no es un objeto, es una interfaz que deben

heredar e implementar aquellos objetos que quieran reaccionar a eventos, como los

que veremos a continuacion.

UIView: Todas las pantallas de la aplicacion desarrollada contienen un UIView o

algun objeto que lo hereda. Esta clase define un area rectangular en la pantalla y los

mecanismos para manejar los objetos que puede contener. Se encarga de renderizar

cualquier contenido que haya en este area y de manejar sus eventos. De entre las

clases que la heredan podemos destacar UILabel, que es un rectangulo con texto,

UIImageView, que contiene una imagen o UIControl, que veremos ahora.

UIControl: La clase UIControl es aquella de la que heredan todos los controles con los

que podemos interactuar en una interfaz tactil iOS. No es posible instanciar objetos

UIControl puesto que se trata de una interfaz, por lo que es necesario crear clases

que la implementen. Esta librerıa ya nos proporciona los controles basicos que puede

necesitar una aplicacion, como los botones, sliders, campos de texto, etc.

UIViewController: Esta clase proporciona los mecanismos para manejar vistas o

conjuntos de vistas (tambien conjuntos de UIViewController). Funciona por detras

59

de los objetos UIView y se encarga entre otras cosas de recoger la interaccion del

usuario, redimensionar o reorientar las vistas y redistribuir los controles que contienen.

Todo UIView requiere de un UIViewController. En nuestra aplicacion ademas de

UIViewController se usan objetos que lo heredan. En primera lugar, para darle al

conjunto de la aplicacion una distribucion de pantallas accesibles por pestanas se ha

utilizado un objeto UITabBarController que se encarga de toda la logica relacionada

con esta funcion, ası que es el objeto del que dependen el resto de pantallas. Tambien

se ha utilizado un UINavigationController para el movimiento a traves de los niveles

de la Pantalla Lista Hornos y un UITableViewController para mostrar e interactuar

con la propia lista.

4.1.2. Interfaz

La implementacion de la interfaz en iOS 5 esta basada en ficheros .storyboard. Este fichero

no es mas que un fichero XML pero que mediante el Interface Builder de Xcode se permite

su diseno de una manera grafica. Los .storyboard son especialmente utiles en aplicaciones

multipantalla, puesto que no unicamente especifican las pantallas de la aplicacion y los ob-

jetos que contienen, tambien incluyen las relaciones entre pantallas e indican de que manera

se realizan las transiciones. Por poner un ejemplo, podemos arrastrar un boton dentro de

una pantalla y crear una relacion con otra pantalla. La relacion hara que al presionar el

boton de la primera pantalla se muestre la segunda sin necesidad de codigo extra. Esto

simplifica mucho el diseno de este tipo de interfaces y reduce el codigo de la aplicacion.

A continuacion, en la figura 29, podemos ver un ejemplo de transicion en el storyboard

de nuestra aplicacion, concretamente la relacion que existe entre el objeto que controla las

pestanas y la Pantalla Mapa.

60

Figura 29: Ejemplo de transicion en storyboard

Al disponer de una herramienta tan potente para el desarrollo de interfaces, la aplicacion

no ha requerido ni clases ni metodos extra para controlar el flujo de la aplicacion y todo lo

necesario esta contenido en el fichero MainStoryboard.storyboard.

MapKit.framework

Esta librerıa contiene los objetos necesarios para trabajar con mapas. El mas importante, y

el que ha sido utilizado en la Pantalla Mapa, es el MKMapView, que es un tipo de UIView

que situa en la pantalla un mapa que funciona gracias a la API de GoogleMaps. Tambien

proporciona metodos y propiedades para hacer zoom sobre el mapa, situar marcadores,

cambiar el tipo de vista e incluso para mostrar la localizadion geografica dentro del mapa

(siempre que sea posible obtenerla).

61

4.1.3. Capa de gestion

En esta capa encontramos todos las clases necesarias para tratar los eventos producidos en

la interfaz, tratarlos, hacer los calculos necesarios y devolver la informacion que el usuario

necesita.

VistaMapaController

Esta clase es la encargada del funcionamiento de la Pantalla Mapa. Se encarga principal-

mente de representar el mapa y permitir que el usuario interactue con el de una forma

sencilla y comoda. Tambien se encarga de tratar los eventos producidos en los botones,

en el mapa y sus marcadores. A continuacion se muestra un listado con sus metodos mas

importantes.

Metodo Descripcion

mostrarUbicacion() Este metodo recibe las coordenadas, el nombre y la direccion

del horno y coloca un marcador en el mapa indicando su

ubicacion.

findme() Centra el mapa en la posicion geografica del dispositivo.

borrarAnotaciones() Borra del mapa todos los marcadores de los hornos y deja

visible unicamente el indicador de la posicion geografica del

dispositivo.

mostrarRuta() Muestra la ruta has a el horno que haya seleccionado.

addressToCoordinate() Transforma una direccion postal en coordenadas geograficas.

62

mostrarHornosDistancia() Dibuja en el mapa los marcadores de los hornos situados a una

distancia igual o menor a la seleccionada.

Marcador

Esta clase hereda de la clase MKAnnotation de la librerıa MapKit.framework. Sirve para

representar un objeto marcador y poder situarlo en el mapa. No tiene metodos, tan solo

tres atributos para indicar las coordenadas del horno, su nombre y direccion.

LlistaFornController

Esta clase se encarga del funcionamiento de la Pantalla Lista Hornos. Se encarga de mostrar

los datos que corresponden en cada nivel de la lista y de gestionar los eventos tactiles que

produce. Estos son sus principales metodos:

Metodo Descripcion

initWithDepth() Este metodo inicializa la lista indicando el nivel en el que se

encuentra y cargando los datos que corresponden a ese nivel.

didSelectRowAtIndexPath() Es necesario sobreescribir este metodo de la clase UITableView

para capturar el evento que se lanza cuando el usuario pulsa

una celda de la lista. En nuestra aplicacion su funcion es cargar

una nueva lista aumentando el nivel siempre y cuando no nos

encontremos en el nivel maximo, de ser ası, abre la Pantalla

Vista Horno.

VistaFornController

Es la clase encargada del funcionamiento de la Pantalla Vista Horno. Su funcion es mostrar

los datos del horno y capturar los eventos de los botones. Sus metodos principales son:

63

Metodo Descripcion

initWithForn() Sirve para iniciar el objeto con los datos del horno.

mostrarAlMapa() Este metodo pasa los atributos del horno al objeto VistaMapa-

Controller para que coloque un marcador y cierra la Pantalla

Vista Horno para mostrar el mapa.

llamarPorTelefono() Se encarga de realizar la llamada al sistema operativo para que

el telefono marque el numero del horno. En la siguiente figura se

muestra su codigo como ejemplo de interaccion directa con iOS:

FornsProximsController

Es la clase que se encarga del funcionamiento de la Pantalla Hornos Distancia. Gestiona los

eventos del objeto tipo slider que sirve para seleccionar una distancia y de un boton. Sus

metodos mas importantes son:

64

Metodo Descripcion

seleccionarKM() Es el metodo que captura el evento del slider. Actualiza los

kilometros en pantalla y los guarda en una variable.

mostrarHornosDistancia() Es el metodo que captura la pulsacion del boton. Le pasa al

objeto VistaMapaController la distancia seleccionada para que

dibuje los marcadores de los hornos.

Forn

Esta clase es la que representa a un horno. Contiene todos los atributos necesarios para

trabajar con ellos en esta aplicacion: nombre, direccion, telefono, coordenadas... Es una

subclase de NSManagedObject, que es una clase generica que aporta todo el comportamien-

to necesario para facilitar el almacenamiento de estos objetos en base de datos. Necesita

que en el modelo de datos, que veremos en la capa de datos, exista una entidad asociada

con el mismo nombre.

CoreDataDelegate

Es la clase estatica encargada de inicializar y realizar los accesos a la base de datos. Su fun-

cionamiento esta basado en los metodos que proporciona la librerıa CoreData.framework y

requiere del modelo de datos. Sus metodos mas destacados son los siguientes:

65

Metodo Descripcion

initCoreData() Inicializa la base de datos y, si no existe por ser la primera eje-

cucion, crea una base de datos .sqlite.

leerPList() Es el encargado de leer el fichero pList que contiene la informa-

cion de los hornos y de insertarlos en la base de datos.

obtenerProvincias() Devuelve las diferentes provincias que hay en la base de datos.

obtenerComarcas() Devuelve las diferentes comarcas dada una provincia determina-

da.

obtenerPoblaciones() Devuelve las diferentes poblaciones dada una comarca determi-

nada.

obtenerForns() Devuelve los hornos de una poblacion determinada.

obtenerTodos() Devuelve todos los hornos que hay en la base de datos.

Los metodos que devuelven datos de la bbdd tienen todos el mismos esquema. En la figura

30 podemos ver el codigo del metodo obtenerComarcas().

66

Figura 30: Metodo obtenerComarcas

AppDelegate

Esta es una clase que se genera automaticamente al iniciar un proyecto iOS y que contiene

los metodos que capturan los eventos relacionados con el ciclo de vida y los estados de

la aplicacion. Para la aplicacion desarrollada unicamente ha sido necesario implementar el

metodo que se lanza cuando el sistema operativo ha terminado de lanzar la aplicacion. En

ese momento llamamos al metodo initCoreData() de la clase CoreDataDelegate.

CoreLocation.framework

Esta librerıa contiene los metodos necesarios para trabajar con coordenadas y obtener la

posicion geografica del dispositivo en un momento determinado. De entre sus clases, las que

han sido necesarias en este proyecto han sido las siguientes:

CLLocation

Representa un conjunto de coordenadas geograficas.

67

CLLocationManager

Permite obtener la localizacion actual del dispositivo, comprobar si el hardware para

obtenerla esta disponible y establecer los criterios de obtencion de la misma (frecuencia

de actualizacion, metodo de obtencion, precison...)

4.1.4. Capa de datos

En esta capa vemos los objetos mas basicos relacionados con el almacenamiento de datos.

CoreData.framework

Esta librerıa proporciona los mecanismos necesarios para el manejo y la persistencia de

datos en iOS. Aunque soporta varios formatos de archivos para su almacenamiento, para

nuestra aplicacion se ha optado por el uso de una base de datos SQLite. Las clases mas

importantes que se han utilizado han sido las siguientes:

NSFetchRequest

Se utiliza para establecer los criterios de obtencion de los datos. Serıa el equivalente

a construir una consulta SQL.

NSManagedObject

Su funcion es crear un objeto en el modelo logico equivalente a una tabla de la base

de datos. De esta manera podemos trabajar directamente con dicho objeto y luego

guardar los cambios que en el se han producido.

NSFetchedResultsController

Es un contenedor de datos en el que se guardan los resultados obtenidos despues de

realizar una consulta a la base de datos.

ModeloDeDatos.xcdatamodeld

Este fichero representa el esquema de la base de datos. En el se especifican las tablas, sus

68

atributos y relaciones. Para la aplicacion desarrollada tan solo ha sido necesaria una tabla

para representar a los hornos:

Figura 31: Esquema Forn en ModeloDeDatos

Como podemos ver se han definido ocho atributos, todos ellos de tipo texto.

Atributo Funcion

nom Es el nombre comercial del horno.

adreca Direccion postal del horno.

telefon Telefono del horno. Necesario para la funcion Telefonear al Horno.

provincia Provincia del horno. Consultado en el primer nivel de la lista.

comarca Comarca del horno. Consultado en el segundo nivel de la lista.

poblacio Municipio al que pertenece el horno. Consultado en el tercer nivel

de la lista.

latitud / longitud Coordenadas del horno. Utilizadas para situar su marcador en el

mapa.

4.2. Implementacion en Android

La implementacion de la aplicacion en su version Android se ha llevado a cabo en java. Al

igual que hicimos en el apartado anterior, vamos a ver un esquema con las clases que han

sido necesarias organizadas por capas, incluyendo tambien las librerıas externas.

69

Capa Clase/Objeto

FornsIGPActivity

LlistatActivity

VistaFornActivity

FornsProximsActivity

Capa de gestión

Forn

GestorAplicacion

Capa de datos

GestorBBDD

BalloonMap

Origen

Interfaz Archivos XML Desarrollado

Desarrollado

Desarrollado

Desarrollado

Desarrollado

Desarrollado

Desarrollado

Desarrollado

Desarrollado

Librerías del sistema android.jar Android SDK

DataBaseInit Desarrollado

CapaPosicion Desarrollado

XMLPListParser Desarrollado

DataBaseCreator Desarrollado

Capa de localización GestorLocalizacion

Localizador

Desarrollado

Desarrollado

ProcesadorUbicacion

LocationWaiter

Desarrollado

Desarrollado

maps.jar Android SDK

FornDAO Desarrollado

Figura 32: Clases aplicacion Android

4.2.1. Librerıas del sistema

android.jar

Esta librerıa es la liberıa base de todo proyecto Android. Contiene las clases y objetos

principales del entorno Android y las funciones basicas para la gestion de la aplicacion, de

memoria, de datos, de la interfaz grafica, interaccion con el sistema operativo, accesos a los

recursos del telefono movil, etc. Sus clases mas importantes son las siguientes:

Activity

70

Las Activity son el elemento principal de la interfaz grafica en un programa Android.

Son el equivalente a las ventanas en Windows.

View

Representan los controles que pueden colocarse dentro de los Activity. Esta librerıa

nos proporciona un gran numero de views basicos (botones, cuadros de texto, listas...)

pero tambien podemos heredar la clase y crearlos nosotros.

Service

Son componentes sin representacion grafica que se ejecutan en segundo plano. Cum-

plen las mismas funciones que los servicios de otros sistemas operativos: pueden uti-

lizarse para actualizar datos, lanzar notificaciones, mostrar activities, etc.

Content Provider

Es el mecanismo de Android que permite compartir datos entre dos aplicaciones.

Broadcast Receiver

La funcion de estos objetos es detectar eventos producidos por el sistema operativo

(baterıa baja, sms entrante, localizacion actualizada...) o por otras aplicaciones.

Intent

Son mensajes que envıan las aplicaciones Android para comunicarse entre ellas o

incluso para comunicarse entre componentes de una misma aplicacion. Con los intent

es posible ejecutar una aplicacion desde cualquier otra, iniciar un service, enviar un

mensaje broadcast para que lo detecten los broadcast receiver que haya a la escucha,

mostrar un activity desde otro, etc.

4.2.2. Interfaz

La interfaz en Android se disena mediante archivos XML. En ellos se definen los objetos

que se mostraran en pantalla y sus atributos: estilo, posicion, texto, etc...

Segun el IDE con el que se este trabajando tienes la opcion disenar las pantallas con una

71

interfaz grafica.

Los archivos XML que han sido necesarios para el desarrollo de esta aplicacion han sido los

siguientes:

main.xml

Representa el xml principal, el que se lanza en primer lugar y en nuestro caso es la

Pantalla Mapa.

llistat forns.xml

Es el xml que contiene el diseno de la Pantalla Lista Hornos.

vista forn.xml

Contiene el diseno de la Pantalla Vista Horno.

forns proxims.xml

Es el xml de la Pantalla Hornos Distancia.

Otros

Se han necesitado otros xml para definir el menu de pestanas, el aspecto personalizado

de algunos botones o el globo que aparece al presionar un marcador.

4.2.3. Capa de gestion

maps.jar

Esta liberıa contiene los elementos necesarios para trabajar con mapas. Su clase principal es

MapView, que es una pantalla que es un control que contiene un mapa para colocarlo sobre

un activity. Permite establecer el zoom del mapa, colocar algunos botones preestablecidos

sobre el y anadir capas con informacion visual. Tambien es necesario destacar la clase Geo-

Point, que sirve para senalar un punto en el mapa previa transformacion a numeros enteros

de las coordenadas geograficas.

72

FornsIGPActivity

Esta clase es el equivalente a la clase VistaMapaController de iOS. Representa la pantalla

mapa y controla toda interaccion que el usuario realice con ella. Sus metodo mas importantes

son:

Metodo Descripcion

pintarLocalizacion() Este metodo recibe un objeto Forn y coloca su marcador

correspondiente en el mapa.

centrarLocalizacionActual() Centra el mapa y ajusta el zoom sobre la posicion geografi-

ca actual del dispositivo.

reiniciarCapas() Borra del mapa los marcadores.

mostrarRuta() Lanza un intent a la aplicacion de Google Maps para que

dibuje la ruta al horno seleccionado.

obtenerLatitud() / obte-

nerLongitud()

Obtiene la latitud o la longitud de la direccion postal que

se le pase por parametro.

pintarHornosDistancia Recibe una distancia y pinta sobre el mapa los marcado-

res de los hornos que se encuentra a esa distancia como

maximo.

Dada la importancia de los objetos intent en el sistema Android, vamos a ver en la figura 33

el fragmento del codigo del metodo mostrarRuta() donde se lanza el Intent para comunicarse

con la aplicacion Google Maps.

73

Figura 33: Ejemplo de uso de un Intent

LlistatActivity

Esta clase es la encargada de controlar la Pantalla Lista Hornos. Su cometido es el mismo

que la clase LlistaFornController en iOS. Sus metodos a destacar son:

Metodo Descripcion

cargarLista() Este metodo es el responsable de solicitar y mostrar los datos

que deben mostrarse en la lista segun el nivel en el que este.

onItemClick() Este metodo se lanza automaticamente cuando el usuario ha

presionado un elemento de la lista. Su funcion es incrementar

la variable que indica el nivel de la lista y solicitar el cambio

de los datos que se muestran. Si la lista esta en el ultimo

nivel, lanza un intent para que se muestre la Pantalla Vista

Horno.

VistaFornActivity

Es la clase que controla la Pantalla Vista Horno. Sus metodos mas importantes son:

74

Metodo Descripcion

informarValores() Muestra por pantalla los valores del objeto Forn que le han

pasado.

mostrarHorno() Indica a la Pantalla Mapa que debe colocar un marcador del

horno que estamos mostrando.

llamarTelefono() Lanza un intent al sistema operativo con el numero de

telefono del horno para que lo marque en la aplicacion que

realiza las llamadas.

FornsProximsActivity

Es la clase que controla la Pantalla Hornos Distancia. Sus unicos metodos a destacar son:

Metodo Descripcion

onProgressChanged() Es el metodo que se lanza cuando se ha producido el evento

que indica un cambio de valor en el slider de la pantalla. Su

funcion es guardar la distancia en una variable y mostrar la

distancia seleccionada por pantalla.

mostrarHornos() Indica a la Pantalla Mapa que debe colocar un marcador

para cada uno de los hornos que cumplen el requisito de la

distancia seleccionada.

BalloonMap

Esta clase representa los marcadores en la aplicacion Android. Ha sido necesario crear le

marcador desde cero, tanto su apariencia como la deteccion de los eventos que se producen

sobre el. Hereda de la clase abstracta ItemizedOverlay de maps.jar, que son objetos capaces

75

de anadirse como capa a un objeto MapView y ver su representacion grafica en el punto

senalado y tambien detectar cuando el usuario lo presiona. Su metodo mas imporante por

lo tanto es el evento onTap(). Cuando se produce el marcador muestra los datos del horno

en un bocadillo sobre el y lanza un evento que recoge FornsIGPActivity para que muestre

los controles que permiten solicitar una ruta hasta el horno.

CapaPosicion

Esta clase hereda de la clase Overlay de la librerıa maps.jar. Los objetos Overlay permi-

ten dibujar sobre ellos cualquier cosa y luego colocarlos sobre el mapa, de manera que lo

dibujado en ellos se vea superpuesto. En este caso lo utilizamos para mostrar la posicion

geografica del usuario. En su metodo draw obtenemos la localizacion geografica, si es que

ha cambiado desde la ultima vez, y dibujamos un circulo sobre la posicion indicada.

Forn

Es la representacion logica de los hornos. Contiene todos los atributos que conforman un

horno y sus metodos para obtenerlos y editarlos. Tambien contiene un metodo save() para

guardar el objeto Forn en base de datos.

GestorAplicacion

Es una clase estatica encargada de llevar a cabo la funciones basicas de la aplicacion y

contiene los metodos necesarios para controlar las transiciones entre las diferentes pantallas.

Sus metodos mas importantes son:

76

Metodo Descripcion

myOnOptionItemSelected() Es el metodo encargado de dibujar el menu de pestanas

en cada pantalla.

onOptionsItemSelected() Este metodo detecta cuando se ha pulsado un ıtem del

menu de pestanas y lanza un intent para mostrar la pan-

talla que corresponda.

inicializarAplicacion() Se encarga de inicializar la base de datos y tambien el ges-

tor de localizacion (para empezar a detectar la posicion

geografica).

GestorBBDD

Esta clase estatica recoge las peticiones de acceso a base de datos de los objetos de la capa

de gestion y los traslada la clase FornDAO de la capa de datos. Tambien se encarga del

resto de tareas relacionadas con la base de datos. Sus metodos a destacar son los siguientes:

Metodo Descripcion

leerLista() Es el metodo encargado leer los hornos del fichero pList

e insertarlos en la base de datos.

inicializarBBDD() Inicializa los objetos que se encargan de atacar a la base

de datos.

77

obtenerProvincias() Devuelve las diferentes provincias a las que pertenecen

los hornos de la base de datos.

obtenerComcarcas() Devuelve las diferentes comarcas a las que pertenecen los

hornos de una determinada provincia.

obtenerPoblaciones() Devuelve las diferentes poblaciones a las que pertenecen

los hornos de una determinada comarca.

obtenerHornos() Devuelve la lista de hornos que pertenecen a una deter-

minada poblacion

obtenerHornosDistancia() Devuelve la lista de hornos que estan a una determinada

distancia del terminal

XMLPListParser

Es la clase encargada de leer directamente del fichero pList. Su cometido es leerlo como el

fichero xml que es en realidad y colocar las cadenas de texto en una serie de hashtables anida-

das. El objetivo es que la informacion quede bien estructurada para que el GestorBBDD

acceda a ella facilmente.

4.2.4. Capa de localizacion

Esta capa contiene las clases relacionadas con la obtencion de la posicion geograficas del

dispositivo.

GestorLocalizacion

Esta clase estatica se encarga de iniciar el proceso de localizacion. Para ello debe crear un

78

objeto de la clase LocationWaiter y esperar a que este le envıe eventos. Su metodo mas

importante es getLocalizacion(), que devuelve a quien lo llame la ubicacion actual del dis-

positivo.

LocationWaiter

Esta clase se encarga de arrancar un Thread que continuamente consultara las coordena-

das obtenidas por el objeto de la clase Localizador. Si ese objeto pasado un tiempo no ha

obtenido ningunas coordenadas, LocationWaiter enviara un evento al GestorLocalizacion

indicando que no ha sido posible obtener la localizacion actual. Por contra, si devuelve

coordenadas y son diferentes a las que habıa devuelto en algun momento previo, lanzara un

evento indicando que el dispositivo ha cambiado de ubicacion.

Localizador

Esta clase crea los objetos que se utilizan en Android para obtener la localizacion geografica.

Estos objetos son el LocationListener y el LocationManager. Una vez creados, crea tam-

bien un objeto de la clase ProcesadorUbicacion y le pasa por parametro los dos objetos

proveedores. En ese momento iniciara un thread para gestionar los eventos que recoge el

LocationListener, entre los que se encuentra el evento onLocationChanged, que se produce

cuando hay un cambio en la posicion del dispositivo.

ProcesadorUbicacion

Se encarga de inicializar los objetos proveedores de localizacion que le ha suministrado la

clase Localizador y tratar sus eventos para dejar definido el metodo de obtencion de la

ubicacion geografica. En primer lugar establece la busqueda en modo GPS. Si despues de

un tiempo determinado el dispositivo es incapaz de localizar el numero de satelites adecuado

79

para obtener una localizacion GPS, pasa a intentar obtener su posicion con tecnicas a traves

de la red movil.

4.2.5. Capa de datos

En esta capa se encuentran las clases mas ıntimamente ligadas con el manejo de la base de

datos.

DataBaseCreator

Es clase hereda de la clase SQLiteOpenHelper. Su funcion es crear o actualizar la base de

datos. Tiene dos atributos: DATABASE NAME y DATABASE VERSION. En primer lugar

busca un objeto en el sistema de archivos con el nombre DATABASE NAME, si no existe

lo crea y lanza un evento onCreate que recogera la clase DataBaseInit. Si existe y su version

es inferior a DATABASE VERSION, lanza un evento onUpgrade.

DataBaseInit

Esta clase recoge los eventos producidos en DataBaseCreator. Si recibe un evento onCreate,

ejecuta la query que crea la tabla para guardar los datos de los hornos. Si recibe un evento

onUpgrade borra los datos de la tabla para que se vuelvan a leer los datos del archivo pList.

FornDAO

Esta clase es la encargada de lanzar los accesos a la base de datos. Sus metodos mas im-

portantes son:

80

Metodo Descripcion

open() / close() Son los metodos encargados de abrir y cerrar la base de

datos.

insertForn() Crea una lınea en la tabla donde se guardan los hornos

con los datos pasados por parametro.

obtenerProvincias() Realiza una consulta a la tabla hornos para obtener las

diferentes provincias.

obtenerComarcas() Realiza una consulta a la tabla hornos para obtener las

diferentes comarcas de una provincia determinada.

obtenerPoblaciones() Realiza una consulta a la tabla hornos para obtener las

diferentes poblaciones de una comarca determinada.

obtenerHornos() Realiza una consulta a la tabla hornos para obtener los

hornos de una poblacion determinada.

obtenerTodos() Realiza una consulta para obtener todos los hornos de la

tabla.

4.3. Diferencias entre iOS y Android

En esta seccion vamos analizar las diferencias que han habido durante el proceso de imple-

mentacion de las dos aplicaciones.

81

4.3.1. Lenguaje de programacion

Puestos a analizar las diferencias entre ambas implementaciones, el primer punto donde

detenerse debe ser el propio lenguaje. El uso de Java para Android ha resultado ser mucho

mas amigable que Objetctive-C. En primer lugar el tiempo de adaptacion al lenguaje fue

nulo. Java es uno de los lenguajes que mas extendido esta hoy dıa y ademas su sintaxis es

bastante comun, por lo que de no haberlo conocido previamente, igualmente habrıa sido

sencilla la adaptacion.

Por contra Objective-C requirio de varias horas dedicadas exclusivamente al aprendizaje

del lenguaje. Una vez conocidas las bases, el uso de Objective-C no difiere mucho del uso de

Java puesto que ambos son lenguajes orientados a objetos, pero termina por dar resultados

menos legibles de cara al programador. La sintaxis del lenguaje es poco intuitiva y repasar

el funcionamiento de cualquier metodo acaba requiriendo mas tiempo que en Java.

4.3.2. Desarrollo de la interfaz

Como ya hemos visto ambas interfaces se disenan sobre ficheros xml. Android propone el

uso de un fichero por cada pantalla que tenga la aplicacion, para iOS en cambio solo ha

sido necesario un unico fichero.

A la hora de disenar cada pantalla, la interfaz grafica de Xcode ha resultado mucho mas

eficiente que la de Eclipse, hasta el punto que en Android se acabo por disenar la interfaz

directamente en codigo xml. Mientras que la interfaz de Xcode es agil e intuitiva, en Eclipse

nos encontramos con algo mucho mas rudimentario. Colocar los controles donde uno desea

no resulta todo lo sencillo que deberıa ser y no existe una paleta de colores para pintar

los objetos desde la interfaz grafica (debe indicarse su codigo RGB). Ello comporta que la

tarea mas estrictamente vinculada con el diseno se vuelve muy incomoda. Ademas, si como

ha sido el caso las pantallas se han disenado directamente en xml, al cambiar a la interfaz

grafica para comprobar el resultado, podemos encontrarnos con que la pantalla que vemos

no es del todo fiel con la pantalla que el usuario vera cuando ejecute la aplicacion.

Otra diferencia muy importante entre el diseno en Android e iOS es la posibilidad que

82

brinda este ultimo para determinar en el propio fichero xml las transiciones entre pantallas.

En iOS existen una serie de controles destinados exclusivamente a este cometido, ası que

unicamente anadiendolos a tu interfaz y definiendo una serie de relaciones entre las pantallas

ya tenemos el comportamiento deseado. En Android en cambio ha sido necesario controlar

todo este proceso mediante programacion. Como consecuencia tenemos que en iOS esta

tarea tuvo un coste en tiempo muy reducido y nulo en cuanto a lineas de codigo, mientras

que en Android llevo mas tiempo y fue necesario programar varios metodos.

4.3.3. Localizacion

Mostrar la ubicacion geografica del dispositivo ha sido mucho mas sencillo en iOS que en

Android. Por un lado, en iOS, esta opcion la tenemos totalmente integrada en el control

MKMapView. El mismo control que muestra un mapa por pantalla, tiene un atributo boo-

leano llamado showsUserLocation, ası que simplemente asignandole como valor CIERTO ya

dibuja en el mapa un completo marcador que no solo indica la posicion, tambien la precision

con la que se ha obtenido. El mismo objeto se encarga de elegir el mejor metodo para ob-

tener la localizacion segun las circunstancias. Si mas tarde necesitamos obtener el valor de

las coordenadas para por ejemplo utilizarlas como punto de inicio de una ruta, simplemente

debemos acceder a otro atributo de la clase MKMapView llamado userLocation.

En Android, en cambio, el proceso es algo mas costoso. En primer lugar obtener la loca-

lizacion y dibujarla en el mapa son dos tareas separadas. Para obtener la localizacion es

necesario crear una clase LocationListener que gestione los eventos relacionados con la lo-

calizacion que puedan producirse. Para que estos tengan lugar, antes hay que inicializar

un objeto LocationManager y pedirle que empiece a buscar la posicion. Si indicamos que

empiece a buscarla como GPS y no encuentra ningun satelite, debemos crear un sistema

capaz de detectarlo y pedirle que entonces la busque a traves de la red movil. Ası pues, una

vez montado todo este sistema, podremos recibir las coordenadas de nuestra posicion, pero

claro, ya nos habra llevado algo de tiempo y unas cuantas clases. Llegados a este punto hay

que senalar las coordenadas obtenidas en el mapa. Para ello es necesario crear una clase tipo

83

Overlay o un ItemazedOverlay, que son dos tipos de objeto que permiten dibujar encima de

un MapView. Ası pues hay que escoger una imagen como marcador, o simplemente dibujar

un punto, colocarlo en el Overlay y despues colocar este sobre el MapView como si fuera

una capa. Ademas hay que asegurarse de que la posicion se va actualizando regularmente,

por lo que es necesario crear todo esto en algun tipo de thread.

4.3.4. Uso de Mapas

El uso de la API de mapas tanto en iOS como en Android es bastante comodo. Ambas

librerıas proporcionan un control que al colocarlo en una pantalla muestra un mapa. Es al

colocar marcadores cuando encontramos algunas diferencias. En Android, como ya hemos

comentado, es necesario crear una clase y asignarsela como capa al mapa. El principal

problema es que esta clase esta totalmente vacıa de contenido, no tiene ninguna imagen

que dibujar como marcador, ni lanza ningun evento cuando el marcador es presionado ni

tampoco dispone de algun globo de texto con informacion personalizable. Todo esto ha

sido necesario crearlo de cero. En iOS, en cambio, solo es necesario crear una clase con

el protocolo MKAnnotation y sin necesidad de anadirle ningun metodo ya tendremos un

marcador con imagen predeterminada que podremos presionar y que mostrara un bocadillo

con la informacion que le asignemos. Si deseamos realizar alguna modificacion sobre el

marcador predeterminado, como cambiar su apariencia o anadir algun boton al globo de

texto, habra que sobreescribir un metodo de la clase MKMapView.

Otro punto a destacar sobre el uso de mapas es que el mapa en Android requiere una

clave de licencia de Google Maps para funcionar. En la pagina web para desarrolladores de

Android encontramos instrucciones para conseguir la clave y como utilizarla. Ademas esta

clave es diferente si el mapa se va a utilizar en un entorno de desarrollo o si se va a utilizar

en el producto final, por lo que durante el desarrollo de esta aplicacion ha sido necesario

obtener dos claves: una cuando empezo el desarrollo para poder testear y otra cuando se

compilo la aplicacion para subirla a Google Play.

84

4.3.5. Valoraciones

A nivel general las diferencias entre ambas implementaciones han hecho que el desarrollo

para iOS haya sido bastante mas rapido y sencillo. Si bien es cierto que el proceso de

aprendizaje de Objective-C fue un punto desfavorable, la gran cantidad de recursos que

proporcionan las librerıas del SDK de iOS han hecho el desarrollo mas satisfactorio.

4.4. Aspecto final de las pantallas

Para terminar con el capıtulo de la implementacion vamos a mostrar a modo comparativo

como han quedado las pantallas en una y otra aplicacion. Las pantallas de la izquierda

corresponden a la aplicacion iOS y las de la derecha a la aplicacion Android.

Figura 34: Pantalla Mapa

85

Figura 35: Pantalla Mapa con controles para trazar ruta

Figura 36: Pantalla Mapa con hornos cercanos

86

Figura 37: Pantalla Lista Hornos (nivel comarcas)

Figura 38: Pantalla Hornos Distancia

87

Figura 39: Pantalla Vista Horno

88

Capitulo 5

5. Planificacion y Costes

El objetivo de este capıtulo es ver la planificacion en tiempo de trabajo que se habıa

realizado para este proyecto y compararla con el tiempo real que ha sido empleado.

Tambien se pretende hacer una estimacion de los costes que tendrıa un proyecto como este

en un entorno empresarial.

La siguiente tabla nos muestra por un lado las horas estimadas en un principio y las que

finalmente han sido necesarias.

Tarea Horas estimadas Horas reales

Estudio previo de tecnologıas 40 37

Analisis de requisitos 30 25

Especificacion 16 16

Diseno 40 38

Implementacion Android 160 176

Implementacion iOS 176 152

Testeo 30 29

Documentacion 140 127

Total 632 horas 600 horas

En el desarrollo de la aplicacion han intervenido tres figuras: el jefe de proyecto, el analista

programador y el becario.

Jefe de proyecto: El jefe de proyecto ha sido el responsable de la planificacion del

proyecto y la gestion de recursos. Le imputaremos las horas de las reuniones para el

analisis funcional, las reuniones de seguimiento (una por semana) y aproximadamente

89

una decima parte de las horas empleadas en la documentacion.

Analista programador: Le corresponden las horas del estudio previo, tambien del

analisis funcional, la especificacion, el diseno, ambas implementaciones y la documen-

tacion.

Becario: Para la fase de testeo fue contratado un becario que se encargo del testeo

de la aplicacion.

Para analizar los costes de la aplicacion, vamos a ver en primer lugar el salario por horas

de las tres figuras implicadas:

Cargo Salario por hora

Jefe de proyecto 60 e

Analista programador 30 e

Becario 0 e

Una vez conocidos los salarios, vamos calcular segun las horas trabajadas de cada uno el

coste que han supuesto para el proyecto.

Cargo Dedicacion Coste

Jefe de proyecto 55 horas 3300 e

Analista programador 571 horas 17130 e

Becario 29 horas 0 e

Total 20430 e

Ademas de los costes en recursos humanos hay que anadir los relativos al hardware, software

y licencias. Si bien algunos de ellos no han supuesto un desembolso real por haber sido

facilitados por la universidad o por disponer de ellos previamente, para que este apartado

sea lo mas fidedigno posible con los costes que habrıa supuesto el proyecto en un entorno

laboral, vamos a suponer que fue necesario comprar todo para su realizacion

90

Gasto Coste

MacBook Pro 1745 e

iPhone 599 e

Telefono Movil Android 300 e

Cuota anual de desarrollador Apple 80 e

Cuota de desarrollador Google 20 e

Total 2744 e

Una vez calculados todos los costes, el gasto real del proyecto habrıa sido el siguiente:

Costes Cantidad

Recursos humanos 20430 e

Otros Recursos 2744 e

Total 23174 e

91

Capitulo 6

6. Conclusiones y trabajo futuro

En este capıtulo, finalmente, vamos a valorar el estado final del proyecto, lo que ha supuesto

para el autor y las mejoras que se pueden anadir en futuros proyectos.

6.1. Conclusiones

En general podemos decir que el desarrollo del proyecto ha sido satisfactorio. Todos los

objetivos marcados se han alcanzado y ambas aplicaciones estan disponibles para descargar

en Google Play y AppStore.

Aunque la planificacion se habıa hecho partiendo de un escenario pesimista, hay que senalar

que se ha reducido la estimacion de tiempo prevista. En este sentido la implementacion de

ambas aplicaciones ha jugado un papel sorprendente en ambos casos. En un principio se

habıa estimado que llevarıa menos tiempo desarrollar la aplicacion de Android que la de iOS

porque el programador ya conocıa el lenguaje Java y el entorno de desarrollo, mientras que

en iOS todo era nuevo. Despues la realidad fue diferente. El SDK y las librerıa disponibles

jugaron un papel vital. Por un lado en Android se dio la necesidad de desarrollar casi desde

cero partes cruciales, por el otro nos encontramos mas facilidades de las esperadas en este

sentido y finalmente se vio reflejado en los tiempos de desarrollo.

6.2. Valoraciones personales

A nivel personal me gustarıa senalar que he cumplido mis objetivos. Lo que me llevo a

presentarme voluntario para realizar este proyecto, y no otro, fue la oportunidad que me

brindaba para romper con todo lo que tenıa aprendido despues de cuatro anos trabajando

como programador y empezar a realizar aplicaciones para estos dispositivos que veo y uso

cada dıa.

Hoy mis conocimientos como programador Android e iOS, aun lejos de ser sobresalientes,

92

son lo suficientemente amplios como para sentirme animado a realizar mis propios proyectos

y distribuirlos en las correspondientes plataformas. Y he de decir que ese animo es algo que

no sentıa desde hace mucho tiempo.

Trabajar en un consultorıa, realizando proyectos clonicos en tiempo record para otras em-

presas cuyos intereses estan lejos de ser los mıos es algo que me ha ido desgastando y que

convertıa algo tan vocacional, como lo es para mı el desarrollo de software, en un simple

trabajo que hacıa por obligacion. Este proyecto ha cambiado eso y vuelvo a sentir las ganas

de programar lo que a mı verdaderamente me nace, y creo que las plataformas moviles son

un lugar idoneo para ello.

6.3. Trabajo futuro

Una vez finalizada la aplicacion nos gustarıa mejorarla en futuras versiones partiendo de

las siguientes consideraciones:

Actualizacion de la lista de hornos

Durante el desarrollo actual, por temas de eficiencia, se decidio leer el archivo pList

unicamente la primera vez que se ejecuta la aplicacion y guardar los datos en una

base de datos. El resultado ha sido muy satisfactorio pero nos da problemas si quere-

mos actualizar dicha lista en futuras versiones, puesto que ahora mismo no hay nada

implementado que permita leer de nuevo la lista sin desinstalar la aplicacion. Veo

prioritario desarrollar un sistema de actualizacion de versiones independiente del que

facilitan las plataformas de distribucion que permita leer el archivo pList de nuevo

cuando haya algun cambio. Incluso serıa interesante considerar la opcion de disponer

de un servicio Web que facilitara la lista de hornos, ası no serıa necesario un cambio

de version cada vez que se anadiesen nuevos hornos.

Implementacion en iPad y tablets Android

Si bien el desarrollo efectuado permitirıa ejecutar ambas aplicaciones en los tablet

disponibles con su sistema operativo, es necesario desarrollar una interfaz que se ajuste

93

al cambio de tamano de la pantalla y si puede ser saque mas partido de una pantalla

tan grande.

Soporte para otros idiomas

Dado el caracter comercial y publicitario de esta aplicacion, serıa bueno que pudiese

llegar a mas gente, sobre todo a turistas que pueden encontrar interesante comprar un

producto tan autoctono como el pa de pages catala. Por ello es necesario considerar la

posibilidad de anadir mas idiomas, como el ingles y el castellano.

94

Capitulo 7

7. Referencias

7.1. Geolocalizacion

[1] http://www.inteco.es/Seguridad/Observatorio/guias/Guia_Geolocalizacion

[2] http://en.wikipedia.org/wiki/Georeference

[3] http://en.wikipedia.org/wiki/Geocoding

[4] http://en.wikipedia.org/wiki/Geotagging

[5] http://en.wikipedia.org/wiki/Geolocation

[6] http://en.wikipedia.org/wiki/Mobile_phone_tracking

[7] http://www.gisdevelopment.net/technology/lbs/techlbs006.htm

[8] http://www.kriptopolis.org/geoposicionamiento-gsm-1

[9] http://www.rtve.es/noticias/20111115/como-borrar-tu-red-wifi-base-datos-google/

475608.shtml

[10] http://es.wikipedia.org/wiki/Sistema_de_posicionamiento_global

[11] http://es.wikipedia.org/wiki/GPS_Asistido

[12] http://en.wikipedia.org/wiki/Location_API_for_Java_ME

[13] http://developers.sun.com/mobility/apis/articles/location

[14] http://developer.android.com/guide/topics/location/index.html

[15] http://developer.apple.com/library/ios/#documentation/UserExperience/

Conceptual/LocationAwarenessPG/Introduction/Introduction.html

95

7.2. Representacion de Mapas

[16] http://en.wikipedia.org/wiki/Map_projection

[17] http://www.nationalatlas.gov/articles/mapping/a_projections.html

[18] http://es.wikipedia.org/wiki/Sistema_de_Informacion_Geografica

[19] http://www.openstreetmap.es/

[20] https://developers.google.com/maps/faq?hl=es-ES

[21] http://www.microsoft.com/maps/product/licensing_for_mobile.aspx

[22] http://cloudmade.com/about

[23] http://www.nutiteq.com/map-api

7.3. iOS vs Android

[24] http://gallir.wordpress.com/2011/12/07/android-ios-tiempos-de-respuestas-y-por-que-nada-es-gratis-en-sistemas-informaticos/

[25] http://www.sozpic.com/desarrollo-ios-vs-android-por-donde-empiezo/

[26] https://support.google.com/googleplay/android-developer/bin/answer.

py?hl=es&answer=113469

[27] https://developer.apple.com/programs/mac/distribution.html

7.4. Implementacion

[28] http://www.sgoliver.net/blog/?p=1313

[29] http://developer.android.com/index.html

[30] https://developer.apple.com

[31] The iPhone Developer’s Cookbook - Erica Sadun - Addison Wesley

96