Aplicacion de geo-localizacion Forns IGP

iOS / Android

Ra
ul Sanchez Delgado

11 de junio de 2012
Indice

1. Introducci
on 6
1.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. Motivaciones personales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2. Estado del Arte 9

2.1. Geolocalizaci
on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1. Metodos de georreferenciacion en dispositivos moviles . . . . . . . . 10
2.1.2. Tecnicas de geolocalizacion en redes de telefona movil . . . . . . . . 14
2.1.3. Herramientas de geolocalizacion . . . . . . . . . . . . . . . . . . . . . 19
2.1.4. Aplicaciones con geolocalizacion . . . . . . . . . . . . . . . . . . . . 21
2.2. Representaci
on de mapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.1. Proyecci
on 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. Dise
no de la aplicaci
on 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. Implementaci
on 56
4.1. Implementaci
on en iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.1.1. Libreras del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.1.2. Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.1.3. Capa de gesti
on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.1.4. Capa de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.2. Implementaci
on en Android . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.2.1. Libreras del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.2.2. Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.2.3. Capa de gesti
on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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. Localizaci
on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.3.4. Uso de Mapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.3.5. Valoraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.4. Aspecto final de las pantallas . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5. Planificaci
on 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. Geolocalizaci
on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.2. Representaci
on de Mapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.3. iOS vs Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.4. Implementaci
on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

4
 Agradecimientos
Llegados a este punto son muchas las personas que seguro merecen mi agradecimiento
durante todos estos a
nos 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 sera
capaz de llevarlo a cabo y por todo el asesoramiento y recursos que me has facilitado.

Gracias tambien a David Gas

o, Ciro Alonso y Rosa Garca, 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 facilit
armelo todo en forma de excedencia.

Y por u
ltimo gracias a toda mi familia por apoyarme y aguantarme habitualmente y sobre
todo estos u
ltimos meses, pues posiblemente me habre mostrado mas agitado de lo habitual.

5
 Captulo 1

1. Introducci
on

Los avances tecnol

ogicos que los telefonos moviles han experimentado en el u
ltimo lustro
han permitido que el usuario tenga al alcance de la mano todo lo que puede necesitar en su
da a da. La limitada potencia de calculo o el reducido tama
no de la memoria que estos dis-
positivos tenan anta
no ha dejado de ser un problema para los desarrolladores que adem
as
han visto como la interfaz t
actil, el acceso a internet o la geolocalizacion les abran un nuevo
abanico de posibilidades a la hora de desarrollar aplicaciones mas u
tiles 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
tursticos, de ocio o cualquier tipo de establecimiento. Y no es de extra
nar que sea as,
ya que este tipo de aplicaciones no solo son u
tiles 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
a1 .
Pages Catal`

Teniendo esto en cuenta se decidio utilizar los dispositivos moviles como plataforma pa-
ra esta aplicaci
on. Su tama
no permite al usuario moverse con el y el GPS o el acceso a
1
De ahora en adelante nos referiremos a ellos como hornos

6
la red de telefona m
ovil 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. Adem
as las compa
nas 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:

Investigaci
on previa
En primer lugar habr
a que hacer un peque
no estudio sobre las diferentes tecnologas
que permiten la localizaci
on geografica y determinar cual o cuales son las mas ade-
cuadas para esta aplicaci
on.
Posteriormente y dado que son dos lenguajes de programacion desconocidos para m,
ser
a necesario estudiar tanto el entorno de desarrollo como los propios lenguajes.

Dise
no preliminar de la aplicaci
on
Habr
a que determinar las acciones que podra realizar el usuario en la aplicacion y
hacer un primer dise
no 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
m
as complejas, como son la inclusion de mapas y la geolocalizacion en ambos sistemas
operativos.

Desarrollo de la aplicaci
on

7
 Se desarrollar
an 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 p
ubli-
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 a
nos ejerciendo
como programador en entornos .Net y entenda que era el momento de probar cosas nue-
vas. En este sentido, me pareci
o 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 m
oviles.

8
 Capitulo 2

2. Estado del Arte

En este captulo introduciremos las diferentes tecnologas que se han utilizado en este pro-
yecto, como son las tecnicas de geolocalizacion o los sistemas de representacion de mapas.
En general se procurar
a no entrar en demasiado detalle y mostrar una vision lo mas cercana
posible al
ambito de este proyecto.

2.1. Geolocalizaci
on

Entendemos por geolocalizaci

on al conjunto de tecnicas que permiten determinar la posi-
cion geogr
afica 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 tecnologa
requiere de la perfecta sincronizacion entre hardware y software, es necesario un dispositivo
con GPS o conexi
on a internet y un software que permita hacer uso de ellos en esta direccion.

En los u
ltimos a
nos 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-
localizaci
on con facilidad y puedan centrarse en explorar sus m
ultiples utilidades. No es de
extra
nar pues la gran cantidad de aplicaciones que hay disponibles en telefonos moviles que
hacen uso de esta tecnologa. Entre ellas podemos diferenciar tres usos comunes:

Georreferenciaci
on: Es el proceso mediante el que se localiza un objeto, lugar o
persona en el espacio fsico 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.

Geocodificaci
on: Es el proceso de obtencion de coordenadas geograficas a partir
de otro tipo de datos geogr
aficos, como la direccion o el codigo postal. Al proceso

9
 contrario, la obtenci
on de direcciones postales a partir de coordenadas se le denomina
Geocodificaci
on 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 direcci
on
postal.

Geoetiquetado: Es el proceso mediante el cual se a

nade informacion geografica en
forma de metadatos a otro tipo de contenido. Usualmente es un paso posterior a la
georreferenciaci
on. Un ejemplo de geoetiquetado sera incluir en una fotografa 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 mayora de las aplicaciones de geolocalizacion, es habitual
ver como se usan ambos terminos indistintamente [1, 2, 3, 4, 5].

2.1.1. M
etodos de georreferenciaci
on en dispositivos m
oviles

Un mismo dispositivo m
ovil dispone de diferentes vas para determinar su posicion, siendo
algunas mucho m
as precisas que otras. Sin embargo en ocasiones al dispositivo no le sera po-
sible utilizar la tecnica m
as 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 informaci
on
y situaci
on de gran cantidad de redes Wi-Fi. El metodo consiste en enviar la direcci
on
MAC del router Wi-FI y el SSID (nombre la red) y contrastarlo con la base de datos
que devolver
a la posici
on geografica de la red. De esta forma es posible determinar con
una precisi
on de entre 30 y 100 metros la ubicacion de cualquier dispositivo conectado
a una red inal
ambrica.
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 vehculos a

10
recorrer las ciudades que registraban las redes Wi-Fi que encontraban a su paso. Hoy
da son los propios telefonos moviles de los usuarios los que completan estas bases de
datos enviando su ubicaci
on [1, 9].

Redes de telefona m
ovil:
Hay un gran n
umero de tecnicas de georreferenciacion que permiten obtener la posici
on
de un dispositivo que este conectado a una red de telefona movil y su precision oscila
entre los 50 y los 500 metros. Mientras que en el siguiente apartado veremos las m
as
relevantes, en este nos limitaremos a clasificarlas en tres grandes grupos:

Basadas en la red
Estas tecnicas utilizan la infraestructura del operador de telefona movil para
determinar la ubicaci
on del terminal. La principal ventaja es que no son tecnicas
intrusivas y no requieren que el dispositivo disponga de hardware o software es-
pecfico. La precisi
on de estas tecnicas vara 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 se
nales y de apli-
caciones especficas que realicen las tareas necesarias para determinar la posici
on
geogr
afica, 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 m
as conocidas, encontramos E-OTD (Enhanced Observed Time
Difference) y variaciones de CGI y TDOA.

Hbridas

11
 Combinan las tecnicas basadas en la red y las basadas en el terminal para con-
seguir mayor precisi
on, 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 est
a formado por 27 satelites (24 operativos y 3 de repuesto)
cuya funci
on es emitir se
nales con informacion sobre el tiempo de emision y su posici
on
para que los receptores GPS las interpreten y utilicen en el calculo de su situaci
on
geogr
afica. Este c
alculo 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 se
nal emitida por estos. Una vez tenemos el retraso y conocien-

12
do que la se
nal 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
se
nal 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 se

nal 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 precisi
on del resultad y para compensarlos es necesario involucrar
m
as 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
simult
aneamente no menos de cinco satelites.

Figura 2: Funcionamiento GPS

Hoy da hay un considerable n

umero de telefonos moviles que disponen de receptor

13
 GPS y es la primera opci
on que utilizan las aplicaciones de geolocalizacion cuando
se prioriza la precisi
on, pero es requisito indispensable que el dispositivo se encuentre
en cielo abierto y despejado, de lo contrario no puede recibir la se
nal 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. T
ecnicas de geolocalizaci
on en redes de telefona m
ovil

A continuaci
on describiremos brevemente algunas de las tecnicas de georreferenciacion que
es posible efectuar sobre dispositivos conectados a redes de telefona movil.

Cell Global Identity (CGI)

Para entender el funcionamiento de esta tecnica es necesario comprender primero como
estan dise
nadas las redes de telefona movil. A estas redes tambien se las conoce como redes
celulares ya que est
an 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 se
nales de las antenas de estas celulas y se conecta a la que recibe con mas fuerza.
Este tipo de red est
a dise
nado a modo de panal, de manera que cada celula esta rodeada de
otras seis, formando hex
agonos, 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 f

acil entender el funcionamiento de esta tecnica, ya que u
nicamente
consiste en determinar a que antena del hexagono esta conectado el terminal, que sera la
que tenga m
as cercana puesto que es cuya se
nal recibe con mas fuerza. As pues sabremos
que el terminal est
a situado en el radio de alcance de esta antena.

Esta tecnica tiene la ventaja de que no necesita ning

un 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 telefona movil en la zona en la que
nos encontremos. En ciudades, donde el n
umero 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 m
ovil. Para ello se miden los retardos en la propagacion de la se
nal 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 se
nal en llegar desde el
terminal m
ovil 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 trilateraci
on, 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 funci
on
de los par
ametros de tiempo obtenidos los lleva a cabo el operador de la red, el terminal no
interviene en ning
un momento, por lo que esta tecnica, al igual que CGI, es posible llevarla
a cabo en cualquier telefono m
ovil [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 se
nales
que emite el dispositivo m
ovil. 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 se
nales [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 se
nales establece la posicion del terminal movil. La gran diferencia es que en

17
este caso quien lleva a cabo el c
alculo 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 precisi
on de esta tecnica fluct
ua entre lo 50 y los 100 metros [8].

Assisted Global Positioning System (A-GPS)

Es una tecnica hbrida 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 u
nicamente podran usar
aquellos terminales dotados de un receptor GPS. Estos terminales se podran conectar con
los dispositivos mediante una se
nal wireless o de telefona y as combinar el uso del GPS con
algunas de las tecnicas vistas anteriormente. De esta manera se salvan los problemas que
tena 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 geolocalizaci
on

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 a
no 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 n
umeros de coma
flotante y la API los necesita para representar las coordenadas. Esta API puede usarse como
librera en cualquier aplicaci
on, ya sea de codigo abierto o cerrado, ya que se encuentra bajo
licencia GNU Lesser General Public License (LGPL).

El objetivo principal que se tena con esta API era proporcionar una herramienta de geolo-
caclizaci
on al mayor n
umero de dispositivos posible, sin importar sus caractersticas, por lo
que se program
o con la capacidad de hacer uso de un gran n
umero de tecnicas de georrefe-
renciaci
on. Sin embargo s que seran las caractersticas del dispositivo las que determinen
que tecnica puede utilizarse en u
ltima 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 m
as
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 br
ujula). 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-
tersticas es que permite elegir entre velocidad y precision a la hora de obtener un resultado,
siempre y cuando las caractersticas del dispositivo den la posibilidad de usar mas de una
tecnica de geolocalizaci
on [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 posici
on (latitud, longitud, altura, velocidad y direccion) y la actualiza en tiempo
real. Adem
as tiene la opci
on de consultar la u
ltima 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 ubicaci
on previamente marcada.

Como es com
un en estas APIs, permite utilizar las tecnicas de geoposicionamiento mediante
redes Wi-Fi locales, redes de telefona 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 geolocalizaci
on 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 batera.

Significant-change location service

Es un servicio de bajo coste energetico que ademas permite recibir alertas sobre los
cambios de posici
on del terminal, incluso si la aplicacion se encuentra en estado suspen-

dido o apagada. Estas alertas tambien informan del cruce entre fronteras. Unicamente
est
a disponible en iOS 4.0 y posteriores.

2.1.4. Aplicaciones con geolocalizaci

on

Actualmente son muchas las aplicaciones que hacen uso de la ubicacion del usuario en uno
u otro sentido. A continuaci
on vamos a ver alguna de ellas:

Br
ujula para iPhone
Esta aplicaci
on viene por defecto en todos los
telefonos iPhone. Haciendo gala del minimalismo
con el que Apple dota a todos sus productos, la
aplicaci
on consta de una u
nica pantalla que na-
da mas mostrarse ya indica la ubicacion en for-
ma de coordenadas geogr
aficas (grados, minutos
y segundos), como podemos ver en la figura 8.
Ademas, como su nombre indica, hace las veces de
br
ujula 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 aplicaci
on de mapas y mos-
trarnos el punto geogr
aficos donde estamos ubica- Figura 8: Br
ujula

dos.

21
Star Walk
Star Walk es una aplicaci
on pensada para los aficionados a la astronoma. Se hace valer de
la ubicaci
on geogr
afica 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, cat
alogo Messier...) hacia los que estamos mirando. Es una aplicaci
on
disponible para dispositivos con sistema operativo iOS.

TomTom
TomTom es una aplicaci
on para dispositivos iOS que hace las veces de sistema GPS de
carretera. Utiliza la ubicaci
on 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
vehculo 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 conducci
on
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 se
nal GPS.

Around Me
Esta aplicaci
on, disponible tanto para dispositi-
vos Android como iOS, utiliza nuestra ubicacion
geografica para indicarnos los lugares de nuestro
interes que tenemos pr
oximos. El usuario en pri-
mer lugar indica que lugares le interesa encontrar
y la aplicaci
on 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 m
as. Si lo deseamos
Around Me tambien puede mostrarnos un mapa
con nuestra ubicaci
on y la de los lugares selecciona-
dos. Figura 10: Around Me

Aplicaciones de Mapas
Tanto Android como iOS vienen instalados por defecto con una aplicacion de mapas, que
aunque son diferentes ambas tienen caractersticas muy parecidas puesto que las dos funcio-
nan con la API de mapas Google Maps. Estas aplicaciones nos muestran nuestra posici
on
en un mapa y se
nalizan todo lo que tenemos alrededor: el nombre de las calles, los portales,
estaciones de metro, paradas de autob
us... Tambien permiten escribir una direccion postal

23
para que la aplicaci
on 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. Representaci
on 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 u
nica manera posible de representar sin ning
un tipo de imprecisi
on
la superficie de nuestro planeta es utilizar una esfera de verdad (como un globo terraqueo),
pero no es c
omodo 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. Proyecci
on de mapas

Una proyecci
on 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 alg
un aspecto del objeto original, ya sea
la forma, el
area, la distancia o la direccion. Sin embargo seg
un 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 tpica de clasificar los tipos de proyecciones de mapas es seg

un la forma del
objeto sobre el que se proyectar
a la esfera terrestre, dando lugar a tres grandes grupos:
cilndricas, c
onicas y planas

Proyecciones cilndricas
Se basan en proyectar la superfcie de la Tierra en un cilindro. Este cilindro puede ser
tangente a la esfera terrestre en una lnea seleccionada o bien secante y cortarla por dos
lneas. Una vez se proyecte la esfera sobre la superficie del cilindro los puntos donde la este
es tangente o secante ser
an los que menos distorsion tengan. Una caracterstica 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 cilndrica tangente y secante

Entre las proyecciones cilndricas 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 navegaci
on y, al ser tangente por el Ecuador, es com
un verla en los pases cercanos a
este. Como contrapartida pierde precision a medida que nos acercamos a los polos, dando
la falsa impresi
on de que Groenlandia y la antigua Union Sovietica son mas extensas que

Sudamerica y Africa.

Otras proyecciones cilndricas o pseudocilndricas 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 difcil de leer.

Proyecciones c
onicas
En este tipo de proyecci
on 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 proyecci

on 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 categora tenemos
la proyecci
on 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
distorsi
on mnima 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 proyecci
on ortogr
afica.

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 proyecci
on ortogr
afica, 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 Informaci

on Geogr
afica (SIG)

Un Sistema de Informaci
on 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 b
usqueda de
direcciones, el trazado de rutas, c
alculo 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 se
nalan-

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 b
usqueda
podemos ser trasladados a su posicion en el mapa.

Los SIG funcionan agrupando su informacion por capas que se sit

uan 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 informaci
on 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 m
as directa y podemos discriminar los datos que no deseamos ver.

Figura 15: Sistema de capas

Representaci
on 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 lmites estan bien delimitados, como puede ser un edificio o
una carretera. En cambio los continuos son aquellos fenomenos con lmites mas imprecisos,
como puede ser la lluvia cada, 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 contnuos.

Raster

29
 El tipo de datos raster se centra mas en las propiedades del espacio que en la precisi
on
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 geogr
aficos en el espacio. Por ello, a fin de mantener sus caractersticas
geometricas y delimitarlos adecuadamente se definen mediante vectores. Utilizan tres
tipos de figuras para modelar los elementos geograficos: el punto, la lnea y el polgono.
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 monta
na u otros
puntos de interes. A escalas peque
nas tambien sirven para representar poblaciones. La
lnea se utiliza para medir todo aquello que se caracteriza por su longitud, como pueden
ser carreteras, ros, caminos, vas, ferrocarriles, fronteras, etc. Los datos representados
por lneas permiten medir distancias. Por u
ltimo el polgono 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 u
nico
que falta es la fase de renderizado. Esta fase es la encargada de reunir toda la informaci
on
de la base de datos, unir las capas y generar la imagen final con la que trabajara el usuario.
Hay servicios de mapas que u
nicamente 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 especficas [18].

30
2.2.3. APIs de mapas

En los u
ltimos 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 seg
un nuestras
necesidades. Las funciones que ofrecen todas ellas son muy similares, en general encontramos
geocodificaci
on, geocodificaci
on inversa, soporte para marcadores, calculo de distancias,
lugares de interes, etc. A continuacion veremos un peque
no 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
ning
un tipo de restricci
on. Su principal caracterstica es que da acceso a la base de da-
tos subyacente y no u
nicamente a los datos renderizados, por lo que los desarrolladores
tienen muchsima m
as 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 versi
on m
ovil viene incluida en el paquete com.google.android.maps del SDK
de Android. Aunque hasta hace relativamente poco su uso era gratuito, recientemente
Google a
nadi
o unos lmites para su uso: 25000 cargas de mapas diarias y 2500 cargas
de mapas modificados. Si nuestra aplicacion sobrepasa ese lmite Google da la opci
on
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
u
ltima versi
on 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 seg
un el tipo de usuario y muchas restricciones [21].

CloudMade: Esta API est

a 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 opci
on 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 n
umero de usuarios o cantidad de llamadas a la API
[23].

Map Kit Framework: Esta librera 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
adem
as 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 c
odigo extra [15].

2.3. iOS Vs Android

En esta secci
on vamos a analizar los dos sistemas operativos para los que se ha decido rea-
lizar la aplicaci
on.

Cuando hablamos de iOS y de Android estamos hablando de los dos sistemas operati-
vos con m
as 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: Gr
afico de ventas de dispositivos moviles seg
un 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 m
as 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 compa
nas que encontramos detras de ambos sistemas operativos son dos de las em-
presas m
as poderosas en el mundo de la tecnologa. 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 filosofas muy diferentes. Google dise
no An-
droid para que fuera un sistema operativo abierto, quera que cualquier compa
na pudiese
instalarlo en su telefono m
ovil y se sintiese libre de modificarlo seg
un sus necesidades. Por
contra Apple desarroll
o iOS pensando exclusivamente en su nuevo dispositivo, el iPhone,
que estaba destinado a revolucionar el mundo de la telefona movil. Y como viene siendo

33
tradicional con todos los productos Apple, cuya poltica consiste en crear un ecosistema
propio, cerrado, basado en la eficiencia, el dise
no y la facilidad de uso, su nuevo sistema
operativo sera exclusivo y no podra ser modificado por nadie.

2.3.1. Lenguajes

Los lenguajes de programaci

on con los que por defecto se trabaja en estos sistemas operati-
vos siguen las filosofas de las que hablabamos antes. Por un lado Objective-C para iOS, que
es un superconjunto de C creado a principios de los a
nos 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, a
un teniendo la misma base, es mucho mas legible en el caso de Java.
Objective-C obliga a emplear largas lneas de codigo con caracteres que no son habituales
en la mayora 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 deber
a emplear tiempo en familiarizarse. Ademas, como Java es un lenguaje muy
conocido, resulta m
as sencillo encontrar documentacion extra o consultar dudas con otros
programadores puesto que la comunidad Java es mayor y hay mas bibliografa disponible.

Una de las diferencias fundamentales entre ambos lenguajes es que, mientras que Java se
desarroll
o con la idea de resultar mas sencillo de cara al programador ahorrandole las tareas

34
de bajo nivel que tena 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 deba, 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 gesti
on 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 filosofas. Objective-C es un lenguaje cuyas aplicaciones se compilan directamente
en codigo ejecutable para el procesador. Esto es posible porque Apple tiene una filosofa
cerrada y toda aplicaci
on se ejecutara u
nicamente 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 dise
nar una
maquina virtual intermedia sobre la cual funcionaran 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 documentaci
on 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 afirmaci
on 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 fsicos, u
nicamente en el simulador que viene con el kit de
desarrollo. La versi
on de pago no tiene estas restricciones y cuesta 99 dolares al a
no. Adem
as
para poder trabajar con la u
ltima version del SDK y desarrollar as para la u
ltima versi
on
de iOS, es necesario tener instalado en el Mac la u
ltima version de Mac OS X. En caso
contrario habr
a que comprarlo e instalarlo. Por u
ltimo 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 u

nicamente 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. Adem
as el SDK de Android puede instalarse en Linux, Windows o Mac
OS X.

Una vez se est

a 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 u
nica-
mente para Mac OS X que est
a pensado u
nicamente 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
tama
no que la utilizada durante el testeo.

2.3.3. Plataformas de distribuci

on

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 descripci
on, 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 aplicaci
on
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. Dise
no de la aplicaci
on

En este captulo veremos la informacion relacionada con el analisis funcional y la especifica-

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

3.1. Requisitos funcionales

A continuaci
on describiremos las funcionalidades de la aplicacion desarrollada:

Mostrar en el mapa la posici

on geogr
afica del usuario
La aplicaci
on deber
a mostrar en un mapa, siempre que disponga de alguna conexi
on
de red, la posici
on geogr
afica del usuario y actualizarla en tiempo real. El usuario
podr
a manipular el mapa mediante zooms y desplazamientos y volver a centrarse en
la posici
on del usuario apretando a un boton.

Ubicar en el mapa hornos cercanos

La aplicaci
on deber
a mostrar en el mapa, nada mas cargar la aplicacion, todos los
hornos que est
an pr
oximos al usuario en un radio de 2 kilometros.

Ubicar en el mapa hornos por distancia

Existir
a una pantalla donde se podra seleccionar en cualquier momento una distancia
no mayor de 100 kil
ometros 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 podr
a 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 ubicaci
on
actual del usuario o una direccion postal introducida por el.

Mostrar lista de hornos

38
 La aplicaci
on deber
a 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 podr
a mostrar en el mapa cualquiera de los hornos de la lista de manera
independiente.

Mostrar datos de inter

es de cualquier horno
El usuario deber
a poder consultar en una misma pantalla todos los datos disponibles
del horno que seleccione.

Telefonear a cualquier horno de la lista

El usuario deber
a poder telefonear al horno que seleccione sin marcar su n
umero de
telefono, u
nicamente presionando un boton.

3.2. Requisitos no funcionales

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

Versi
on del sistema operativo
La aplicaci
on deber
a funcionar en todos los dispositivos Android que tengan instalada
la versi
on 2.3.3 (o superior) del sistema operativo. En dispositivos iPhone, la aplicaci
on
deber
a funcionar en todos aquellos que tengan la version 5.0 de iOS, o superior.

Acceso a la aplicaci
on
La aplicaci
on deber
a poder descargarse gratuitamente desde las plataformas de dis-
tribuci
on oficiales de Google y Apple: Google Play y App Store respectivamente.

Idioma
La aplicaci
on deber
a estar disponible al menos en catalan.

Lenguaje de programaci
on

39
 La aplicaci
on Android estar
a desarrollada en Java, mientras que la version para iOS
estar
a 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.

Aplicaci
on de mapas
Para poder indicar las rutas, el dispositivo movil debera tener instalada la aplicaci
on
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
deber
a 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
navegaci
on entre ellas.

3.3.1. Inicio de la aplicaci

on

A continuaci
on detallamos los procesos que la aplicacion lleva a cabo cuando empieza a
ejecutarse.

40
 Cargar BBDD Error
[Si es la
primera vez]

[Si localizacin
no disponible]

Inicializar
Pantalla Mapa
[Si no es la aplicacin [Si localizacin
primera vez] disponible]

Mostrar Posicin

Mostrar Hornos
Cercanos

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 ejecuci
on en una base de datos y leerlos desde ah en el futuro.

Inicializar Aplicaci
on
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 Posici
on
Este proceso es el encargado de determinar las coordenadas actuales del dispositivo y
representarlas en el mapa.

Mostrar Hornos Cercanos

Una vez obtenida la posici
on 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 kil
ometros. 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 aplicaci

on

A continuaci
on se muestra un par de esquemas para entender la navegacion en funciona-
miento general de la aplicaci
on. En la figura 18 se muestra la navegacion entre pantallas.

Pantalla Lista
Hornos

Pantalla Mapa

Pantalla Vista
Horno

Pantalla Hornos
Distancia

Figura 18: Navegacion entre pantallas desde el men

u

Al ejecutarse la aplicaci
on en primer lugar aparecera la pantalla Mapa. Haciendo uso del
men
u podremos desplazarnos libremente por tres pantallas: Mapa, Lista Hornos y Hornos
Distancia. Adem
as desde lista podremos ver la pantalla Vista Horno, que al mostrarse ocu-
para el lugar de Lista Hornos en el men
u. 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.

Pantalla Mapa
Seleccionar
marcador

Mostrar Hornos
Mostrar Ruta Mostrar Posicin
Cercanos

Pantalla Lista Pantalla Hornos

Pantalla Vista Horno
Hornos Distancia

Seleccionar Seleccionar
horno distancia

Mostrar Datos Mostrar Horno Telefonear al Mostrar Hornos

Horno Seleccionado Horno por Distancia

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 posici
on
geogr
afica del dispositivo. Esa posicion sera visible en todo momento (siempre que sea
posible calcularla) y se podr
a centrar el mapa en ella pulsando un boton. Por u
ltimo
podremos ver la ruta a alguno de los hornos que este mostrandose en ese momento.
Esta u
ltima funci
on dejar
a la aplicacion ejecutandose en segundo plano y mostrara la
aplicaci
on de mapas del sistema operativo con la ruta trazada.

43
 Pantalla Lista Hornos
La u
nica funci
on de esta pantalla sera navegar por la lista de hornos y seleccionar
uno, que se mostrar
a en la Pantalla Vista Horno

Pantalla Vista Horno

Esta pantalla se abrir
a despues de seleccionar un horno de la lista. Contendra toda
la informaci
on del horno y permitira pulsar un boton para mostrarlo en el mapa (en
cuyo caso cargar
a la Pantalla Mapa con un marcador indicando la posicion del horno).
Tambien existir
a otro bot
on para telefonear al horno, lo que dejara la aplicacion en
segundo plano y marcar
a el n
umero de telefono con la aplicacion predeterminada del
sistema operativo.

Pantalla Hornos Distancia

Esta pantalla permitir
a 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 bot
on se abrir
a 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 dise
nada la
lista de hornos. Como ya hemos comentado, cuando ejecutamos por primera vez la aplicaci
on
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 ubicaci
on: 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 :

Pantalla Lista Hornos

Nivel 1 Provincia 1 Provincia 2 Provincia n

Nivel 2 Comarca 1.1 Comarca 1.2 Comarca 1.n

Nivel 3 Poblacin 1.1.1 Poblacin 1.1.2 Poblacin 1.1.n

Nivel 4 Horno 1.1.1.1 Horno 1.1.1.2 Horno 1.1.1.n

Pantalla Vista
Horno

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 funci
on 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
 Provincia Comarca Poblacin Horno

Pantalla Pantalla Pantalla Pantalla Pantalla

Lista Lista Lista Lista Vista
Hornos Hornos Hornos Hornos Horno

Atrs Atrs Atrs Atrs

Mostrar Horno Telefonear al

Seleccionado Horno

Pantalla
Mapa

Figura 21: Diagrama de estados mostrar y telefonear horno

3.4. Diagramas de secuencia

En esta secci
on vamos a dise
nar los diagramas de secuencia de las funcionalidades m
as
importantes de la aplicaci
on. 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 libreras del
SDK de una y otra tecnologa permiten hacer las cosas de manera diferente. Una misma
funcionalidad puede resultar m
as sencilla de implementar gracias al uso de estas libreras y
requerir menos lneas de c
odigo, dando como resultado una organizacion diferente de clases.
Es importante destacar que estas diferencias en ning
un momento han perjudicado ni a la
claridad del c
odigo ni a la posible reusabilidad del mismo. En el siguiente captulo veremos la
implementaci
on con m
as detalle, ahora u
nicamente 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 genrico iOS Android

Capa de presentacin CtrlMapa VistaMapaController FornsIGPActivity

CtrlLista LlistatFornController LlistatActivity
CtrlHorno VistaFornController VistaFornActivity
CtrlProximos FornsProximsController FornsProximsActivity
Marcador DisplayMap BalloonMap

Capa de negocio Horno Forn Forn

GestorAplicacin AppDelegate GestorAplicacion
GestorLocalizacin CoreLocation.framework GestorLocalizacion
ProcesadorUbicacion
Localizador
LocationWaiter

GestorBBDD CoreDataDelegate GestorBBDD

FornDAO

Capa de datos DBObject CoreData.framework XMLPListParser

DataBaseCreator
DataBaseInit

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 u
nico nombre generico para los diagramas y ganar
as claridad en estos. Se
nalar tambien que las clases escritas en azul son libreras del SDK.

47
3.4.1. Inicio de la aplicaci
on

Usuario
:CtrlMapa GestorAplicacin GestorBBDD :DBObject GestorLocalizacin
<<Actor>>

inicio
inicializarAplicacion()
inicializarBBDD() new()
opt [ 1 vez ]
leerPList()

insertarHornos()

inicializarLocalizacion()

loop [ TRUE ]
getLocation()

loc
draw(loc)

obtenerHornosDistancia(2)

listaHornos

m:Marcador

loop 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
inicializarAplicaci
on() 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 aplicaci
on. Acto seguido GestorAplicacion inicializara los objetos que se encargan
de obtener la localizaci
on geogr
afica con el metodo inicializarLocalizacion() de la clase
GestorLocalizaci
on. Acto seguido CtrlMapa lanza un proceso asncrono que ira solicitando la
posicion a GestorLocaci
on 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 est
an 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

Usuario
:CtrlLista GestorBBDD :CtrlHorno :CtrlMapa
<<Actor>>

ir a la lista
nivel := 1

loop [ nivel < 5 ]

alt
obtenerProvincias() [ nivel = 1 ]

obtenerComarcas(s) [ nivel = 2 ]

obtenerPoblaciones(s) [ nivel = 3 ]

obtenerHornos(s) [ nivel = 4 ]

lista
mostrar(lista)

elegir tem s
nivel ++

h:Horno

new(s)

new(h)

presionar "Mostrar en mapa"

m:Marcador

dibujarHorno(h) 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 men
u de
la aplicaci
on. Como se vi
o en el captulo 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 ser
an 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, crear
a 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 c

odigo 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.

Usuario Sistema
:CtrlLista :CtrlHorno AppTelefono
<<Actor>> Operativo

new(h)

presionar "Telefonear"

apiTelefonear(h.telf) 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 funci
on 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 telef
onicas. Una vez finalizada la llamada telefonica el control lo recupera el sistema
operativo y el usuario ser
a libre de realizar cualquier otra accion. Nuestra aplicacion no se
habra cerrado, seguir
a ejecut
andose en segundo plano a la espera de que el usuario vuelva
a necesitarla.

52
3.4.4. Mostrar Hornos Distancia

Usuario GestorBBDD
:CtrlProximos :DBObject :CtrlMapa
<<Actor>>

ir a la pantalla
elegir distancia
pulsar botn << d := distancia >>

obtenerHornosDistancia(d)
obtenerTodos()

listaTodos

GestorLocalizacin

getLocation()

loc
lista := null
loop [ ! h listaTodos ]
dH := distancia entre loc y h
alt [ "#$$" ]
lista.add(h)

lista
dibujarHornos(lista)
loop [ ! h lista ]
dibujarHorno(h)

Figura 26: Diagrama mostrar hornos seg

un distancia

Para realizar esta funcionalidad el usuario debe ir a traves del men

u a la Pantalla Hornos
Distancia. All deber
a seleccionar una distancia y darle a un boton. En ese momento CtrlPro-
ximos capturar
a la acci
on y lanzara el metodo obtenerHornosDistancia del GestorBBDD,
pasandole como par
ametro 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
necesitar
a la localizaci
on actual del dispositivo, que la obtendra del GestorLocalizacion.
Cuando tenga las dos cosas entrar
a en un bucle y comparara, para cada horno, la distancia
que hay entre el dispositivo m
ovil y el horno con la distancia que ha seleccionado usuario.
Todos los hornos que esten a una distancia igual o menor los a
nadira a una lista. Finalmente
se pasar
a 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 situaci
on se puede llegar despues de los diagramas de las figuras 23, 24 o 26.

Usuario Sistema Aplicacin de

:CtrlMapa GestorLocalizacin
<<Actor>> Operativo mapas

inicio
elegir marcador inicio := null
mostrarPanelRuta()

alt
indicar direccin inicio inicio := addr
(addr)

indicar posicin actual

como inicio getLocation()

loc
inicio := loc

presionar botn :Marcardor

getCoordenadas()

destino

URL := << formar URL con

inicio y destino >>

llamadaSO(URL)

abrirApp(URL)

Figura 27: Diagrama mostrar ruta

54
 La primera acci
on que debe realizar el usuario es seleccionar el marcador que se
nala al
horno donde desea ir. En ese instante el CtrlMapa mostrara un panel donde podra indicarse
el origen de la ruta y un bot
on para ejecutar la funcionalidad. El usuario podra indicar
cualquier direcci
on postal como inicio de la ruta o bien dejar por defecto la ubicaci
on
actual del dispositivo. Si elige esta segunda opcion CtrlMapa pedira a GestorLocalizaci
on
la ubicaci
on mediante el metodo getLocation(). Si por contra prefiere indicar una direcci
on
la aplicaci
on la transformar
a en coordenadas que usara como inicio de la ruta. Cuando el
usuario presione el bot
on para ver la ruta, CtrlMapa obtendra del marcador las coordenadas
del horno y las usar
a como destino. Despues compondra una direccion URL con el inicio y
el destino y se la lanzar
a al sistema operativo, que traducira la URL y abrira la aplicaci
on
de mapas que tenga por defecto (Google Maps en Android y Maps en iOS) y dibujara la
ruta. Al igual que ocurra 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. Implementaci
on

En este captulo dejamos atr

as todas aquellas tareas que son responsabilidad del arquitecto
de software y vamos a entrar en el detalle de la estructura de clases, su dise
no 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

implementaci
on de la aplicaci
on Android, puesto que ambas tienen diferencias importantes
en su codigo, m
as all
a de lo que seran las diferencias vinculadas al propio lenguaje de pro-
gramaci
on. Por ello primero describiremos la implementacion en iOS, luego en Android y
finalmente se
nalaremos las diferencias mas notorias entre ambas y analizaremos cuanto han
ayudado los respectivos SDKs a la hora de implementar.

4.1. Implementaci
on en iOS

Esta implementaci
on 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
libreras del SDK de iOS que han sido necesarias para el desarrollo de esta aplicacion.

56
 Capa Clase/Objeto Origen
Interfaz MainStoryboard.storyboard Desarrollado
MapKit.framework iOS SDK

Capa de gestin VistaMapaController Desarrollado

LlistaFornController Desarrollado
VistaFornController Desarrollado
FornsProximsController Desarrollado
Marcador Desarrollado
Forn Desarrollado
AppDelegate Desarrollado
CoreLocation.framework iOS SDK
CoreDataDelegate Desarrollado

Capa de datos CoreData.framework iOS SDK

ModeloDeDatos.xcdatamodeld Desarrollado

Libreras del sistema UIKit.framework iOS SDK

CoreGraphics.framework iOS SDK
Foundation.framework iOS SDK

Figura 28: Clases aplicacion iOS

4.1.1. Libreras del sistema

Estas tres libreras contienen las clases y las funcionalidades mas basicas de un proyecto
iOS. Componen el n
ucleo de cualquier aplicacion.

CoreGraphics.framework
Es una librera 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 gr
aficos, transformaciones, coloreado, paletas, degradados y matices,
muestra de im
agenes e incluso de archivos PDF.

Foundation.framework

57
Esta librera 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 raz de la jerarqua de clases y aquellas clases que
representan los tipos de datos b
asicos, 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 raz de la mayora 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
deberamos usar su subclase NSMutableString.

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

informaci
on del error que se ha producido.

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

permite colecciones est
aticas, es necesario definir su tama
no antes de utilizarlas. Para
poder modificar la longitud de la coleccion se requiere el uso de su subclase NSMuta-
bleArray.

UIKit.framework
Esta librera proporciona las clases necesarias para la construccion y el manejo de la interfaz

58
grafica de la aplicaci
on. 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 aplicaci
on usa varias de estas clases. A continuacion se destacan las m
as
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
aceler
ometro). Estos objetos envan 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 continuaci
on.

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

alg
un 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 librera ya nos proporciona los controles basicos que puede
necesitar una aplicaci
on, 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 detr
as

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 aplicaci
on una distribucion de pantallas accesibles por pesta
nas se ha
utilizado un objeto UITabBarController que se encarga de toda la logica relacionada
con esta funci
on, 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 implementaci
on de la interfaz en iOS 5 esta basada en ficheros .storyboard. Este fichero
no es m
as que un fichero XML pero que mediante el Interface Builder de Xcode se permite
su dise
no de una manera gr
afica. Los .storyboard son especialmente u
tiles en aplicaciones
multipantalla, puesto que no u
nicamente 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 relaci
on 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 dise
no de este tipo de interfaces y reduce el codigo de la aplicacion.
A continuaci
on, en la figura 29, podemos ver un ejemplo de transicion en el storyboard
de nuestra aplicaci
on, concretamente la relacion que existe entre el objeto que controla las
pesta
nas 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 aplicaci

on
no ha requerido ni clases ni metodos extra para controlar el flujo de la aplicacion y todo lo
necesario est
a contenido en el fichero MainStoryboard.storyboard.

MapKit.framework
Esta librera 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 sit
ua 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 gesti
on

En esta capa encontramos todos las clases necesarias para tratar los eventos producidos en
la interfaz, tratarlos, hacer los c
alculos 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 interact
ue con el de una forma
sencilla y c
omoda. 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 m
as
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 u
nicamente 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 librera 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 n
umero 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 m
as importantes son:

64
 Metodo Descripcion

seleccionarKM() Es el metodo que captura el evento del slider. Actualiza los

kil
ometros 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 est
atica encargada de inicializar y realizar los accesos a la base de datos. Su fun-
cionamiento est
a basado en los metodos que proporciona la librera 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-

cuci
on, crea una base de datos .sqlite.

leerPList() Es el encargado de leer el fichero pList que contiene la informa-

ci
on 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 c
odigo 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 aplicaci
on. Para la aplicaci
on desarrollada u
nicamente 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 librera contiene los metodos necesarios para trabajar con coordenadas y obtener la
posicion geogr
afica 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 est
a disponible y establecer los criterios de obtencion de la misma (frecuencia
de actualizaci
on, metodo de obtencion, precison...)

4.1.4. Capa de datos

En esta capa vemos los objetos m

as basicos relacionados con el almacenamiento de datos.

CoreData.framework
Esta librera 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 aplicaci
on se ha optado por el uso de una base de datos SQLite. Las clases m
as
importantes que se han utilizado han sido las siguientes:

NSFetchRequest
Se utiliza para establecer los criterios de obtencion de los datos. Sera el equivalente
a construir una consulta SQL.

NSManagedObject
Su funci
on 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 Funci
on

nom Es el nombre comercial del horno.

adreca Direcci
on 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. Implementaci
on en Android

La implementaci
on de la aplicaci
on 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 libreras externas.

69
 Capa Clase/Objeto Origen
Interfaz Archivos XML Desarrollado

Capa de gestin FornsIGPActivity Desarrollado

LlistatActivity Desarrollado
VistaFornActivity Desarrollado
FornsProximsActivity Desarrollado
BalloonMap Desarrollado
CapaPosicion Desarrollado
Forn Desarrollado
GestorAplicacion Desarrollado
GestorBBDD Desarrollado
XMLPListParser Desarrollado
maps.jar Android SDK

Capa de localizacin GestorLocalizacion Desarrollado

Localizador Desarrollado
ProcesadorUbicacion Desarrollado
LocationWaiter Desarrollado

Capa de datos DataBaseCreator Desarrollado

DataBaseInit Desarrollado
FornDAO Desarrollado

Libreras del sistema android.jar Android SDK

Figura 32: Clases aplicacion Android

4.2.1. Libreras del sistema

android.jar
Esta librera es la libera 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 m
ovil, 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 librera
nos proporciona un gran n
umero 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 funci
on de estos objetos es detectar eventos producidos por el sistema operativo
(batera baja, sms entrante, localizacion actualizada...) o por otras aplicaciones.

Intent
Son mensajes que envan 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 dise

na mediante archivos XML. En ellos se definen los objetos
que se mostrar
an en pantalla y sus atributos: estilo, posicion, texto, etc...
Seg
un el IDE con el que se este trabajando tienes la opcion dise
nar las pantallas con una

71
interfaz gr
afica.
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 dise
no de la Pantalla Lista Hornos.

vista forn.xml
Contiene el dise
no 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 men
u de pesta
nas, el aspecto personalizado
de algunos botones o el globo que aparece al presionar un marcador.

4.2.3. Capa de gesti

on

maps.jar
Esta libera 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 a
nadir capas con informacion visual. Tambien es necesario destacar la clase Geo-
Point, que sirve para se
nalar un punto en el mapa previa transformacion a n
umeros enteros
de las coordenadas geogr
aficas.

72
FornsIGPActivity
Esta clase es el equivalente a la clase VistaMapaController de iOS. Representa la pantalla
mapa y controla toda interacci
on 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- Obtiene la latitud o la longitud de la direccion postal que

nerLongitud() 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
m
aximo.

Dada la importancia de los objetos intent en el sistema Android, vamos a ver en la figura 33
el fragmento del c
odigo del metodo mostrarRuta() donde se lanza el Intent para comunicarse
con la aplicaci
on 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 seg
un 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 u
ltimo
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 n

umero 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 u
nicos 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 a
nadirse como capa a un objeto MapView y ver su representacion grafica en el punto
se
nalado 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 librera 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 posici
on
geografica del usuario. En su metodo draw obtenemos la localizacion geografica, si es que
ha cambiado desde la u
ltima vez, y dibujamos un circulo sobre la posicion indicada.

Forn
Es la representaci
on l
ogica 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 est
atica 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 m
as importantes son:

76
 Metodo Descripcion

myOnOptionItemSelected() Es el metodo encargado de dibujar el men

u de pesta
nas
en cada pantalla.

onOptionsItemSelected() Este metodo detecta cuando se ha pulsado un tem del

men
u de pesta
nas 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 est
atica recoge las peticiones de acceso a base de datos de los objetos de la capa
de gesti
on 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 f
acilmente.

4.2.4. Capa de localizaci

on

Esta capa contiene las clases relacionadas con la obtencion de la posicion geograficas del
dispositivo.

GestorLocalizacion
Esta clase est
atica 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 enve eventos. Su metodo m
as
importante es getLocalizaci
on(), 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 GestorLocalizaci
on
indicando que no ha sido posible obtener la localizacion actual. Por contra, si devuelve
coordenadas y son diferentes a las que haba devuelto en alg
un 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 geogr
afica. En primer lugar establece la b
usqueda en modo GPS. Si despues de
un tiempo determinado el dispositivo es incapaz de localizar el n
umero de satelites adecuado

79
para obtener una localizaci
on GPS, pasa a intentar obtener su posicion con tecnicas a traves
de la red m
ovil.

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 versi
on
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 s
on:

80
 Metodo Descripcion

open() / close() Son los metodos encargados de abrir y cerrar la base de

datos.

insertForn() Crea una lnea 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 secci
on vamos analizar las diferencias que han habido durante el proceso de imple-
mentaci
on de las dos aplicaciones.

81
4.3.1. Lenguaje de programaci
on

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 da y ademas su sintaxis es
bastante com
un, por lo que de no haberlo conocido previamente, igualmente habra sido
sencilla la adaptaci
on.
Por contra Objective-C requiri
o 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 dise

nan 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 u
nico fichero.
A la hora de dise
nar cada pantalla, la interfaz grafica de Xcode ha resultado mucho m
as
eficiente que la de Eclipse, hasta el punto que en Android se acabo por dise
nar la interfaz
directamente en c
odigo 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 debera ser y no existe una paleta de colores para pintar
los objetos desde la interfaz gr
afica (debe indicarse su codigo RGB). Ello comporta que la
tarea m
as estrictamente vinculada con el dise
no se vuelve muy incomoda. Ademas, si como
ha sido el caso las pantallas se han dise
nado 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 dise
no en Android e iOS es la posibilidad que

82
brinda este u
ltimo 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
u
nicamente a
nadiendolos 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 llev
o m
as tiempo y fue necesario programar varios metodos.

4.3.3. Localizaci
on

Mostrar la ubicaci
on geogr
afica 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 precisi
on
con la que se ha obtenido. El mismo objeto se encarga de elegir el mejor metodo para ob-
tener la localizaci
on seg
un 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-
calizaci
on 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 ning
un 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 habr
a llevado algo de tiempo y unas cuantas clases. Llegados a este punto hay
que se
nalar 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. Adem
as hay que asegurarse de que la posicion se va actualizando regularmente,
por lo que es necesario crear todo esto en alg
un 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
libreras 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 est
a totalmente vaca de contenido, no tiene ninguna imagen
que dibujar como marcador, ni lanza ning
un evento cuando el marcador es presionado ni
tampoco dispone de alg
un 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 a
nadirle ning
un metodo ya tendremos un
marcador con imagen predeterminada que podremos presionar y que mostrara un bocadillo
con la informaci
on que le asignemos. Si deseamos realizar alguna modificacion sobre el
marcador predeterminado, como cambiar su apariencia o a
nadir alg
un boton al globo de
texto, habr
a 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 aplicaci
on 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 m
as 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 libreras del SDK de iOS han hecho el desarrollo mas satisfactorio.

4.4. Aspecto final de las pantallas

Para terminar con el captulo 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 aplicaci
on 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. Planificaci
on y Costes

El objetivo de este captulo es ver la planificacion en tiempo de trabajo que se haba

realizado para este proyecto y compararla con el tiempo real que ha sido empleado.
Tambien se pretende hacer una estimacion de los costes que tendra 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 tecnologas 40 37

Analisis de requisitos 30 25

Especificaci
on 16 16

Dise
no 40 38

Implementaci
on Android 160 176

Implementaci
on iOS 176 152

Testeo 30 29

Documentaci
on 140 127

Total 632 horas 600 horas

En el desarrollo de la aplicaci
on 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 gesti
on de recursos. Le imputaremos las horas de las reuniones para el
an
alisis 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
an
alisis funcional, la especificacion, el dise
no, ambas implementaciones y la documen-
taci
on.

Becario: Para la fase de testeo fue contratado un becario que se encargo del testeo
de la aplicaci
on.

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 0e

Una vez conocidos los salarios, vamos calcular seg

un 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 0e

Total 20430 e

Ademas de los costes en recursos humanos hay que a

nadir 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 m
as fidedigno posible con los costes que habra 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 M
ovil 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 habra 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 captulo, finalmente, vamos a valorar el estado final del proyecto, lo que ha supuesto
para el autor y las mejoras que se pueden a
nadir 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 planificaci
on se haba hecho partiendo de un escenario pesimista, hay que se
nalar
que se ha reducido la estimaci
on de tiempo prevista. En este sentido la implementacion de
ambas aplicaciones ha jugado un papel sorprendente en ambos casos. En un principio se
haba estimado que llevara menos tiempo desarrollar la aplicacion de Android que la de iOS
porque el programador ya conoca el lenguaje Java y el entorno de desarrollo, mientras que
en iOS todo era nuevo. Despues la realidad fue diferente. El SDK y las librera 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 gustara se

nalar 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 tena aprendido despues de cuatro a
nos trabajando
como programador y empezar a realizar aplicaciones para estos dispositivos que veo y uso
cada da.
Hoy mis conocimientos como programador Android e iOS, a
un 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 senta desde hace mucho tiempo.
Trabajar en un consultora, realizando proyectos clonicos en tiempo record para otras em-
presas cuyos intereses est
an lejos de ser los mos es algo que me ha ido desgastando y que
converta algo tan vocacional, como lo es para m el desarrollo de software, en un simple
trabajo que haca por obligaci
on. 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 id
oneo para ello.

6.3. Trabajo futuro

Una vez finalizada la aplicaci

on nos gustara mejorarla en futuras versiones partiendo de
las siguientes consideraciones:

Actualizaci
on de la lista de hornos
Durante el desarrollo actual, por temas de eficiencia, se decidio leer el archivo pList
u
nicamente 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 alg
un cambio. Incluso sera interesante considerar la opcion de disponer
de un servicio Web que facilitara la lista de hornos, as no sera necesario un cambio
de versi
on cada vez que se a
nadiesen nuevos hornos.

Implementaci
on en iPad y tablets Android
Si bien el desarrollo efectuado permitira ejecutar ambas aplicaciones en los tablet
disponibles con su sistema operativo, es necesario desarrollar una interfaz que se ajuste

93
al cambio de tama
no de la pantalla y si puede ser saque mas partido de una pantalla
tan grande.

Soporte para otros idiomas

Dado el car
acter comercial y publicitario de esta aplicacion, sera bueno que pudiese
llegar a m
as gente, sobre todo a turistas que pueden encontrar interesante comprar un
producto tan aut
octono como el pa de pages catal`
a. Por ello es necesario considerar la
posibilidad de a
nadir m
as idiomas, como el ingles y el castellano.

94
 Capitulo 7

7. Referencias

7.1. Geolocalizaci
on

[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. Representaci
on 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

[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. Implementaci
on

[28] http://www.sgoliver.net/blog/?p=1313

[29] http://developer.android.com/index.html

[30] https://developer.apple.com

[31] The iPhone Developers Cookbook - Erica Sadun - Addison Wesley

96