Indice
1. Introduccion 6
1.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. Motivaciones personales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2. Estado del Arte 9
2.1. Geolocalizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1. Metodos de georreferenciacion en dispositivos moviles . . . . . . . . 10
2.1.2. Tecnicas de geolocalizacion en redes de telefonıa movil . . . . . . . . 14
2.1.3. Herramientas de geolocalizacion . . . . . . . . . . . . . . . . . . . . . 19
2.1.4. Aplicaciones con geolocalizacion . . . . . . . . . . . . . . . . . . . . 21
2.2. Representacion de mapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.1. Proyeccion de mapas . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.2. Sistema de Informacion Geografica (SIG) . . . . . . . . . . . . . . . 28
2.2.3. APIs de mapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3. iOS Vs Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.1. Lenguajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3.2. Herramientas de desarrollo . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.3. Plataformas de distribucion . . . . . . . . . . . . . . . . . . . . . . . 37
3. Diseno de la aplicacion 38
3.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3. Diagrama de estados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.1. Inicio de la aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.2. Esquema general de la aplicacion . . . . . . . . . . . . . . . . . . . . 42
3.3.3. Mostrar y telefonear a un horno de la lista . . . . . . . . . . . . . . . 44
3.4. Diagramas de secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2
3.4.1. Inicio de la aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.4.2. Mostrar Horno Seleccionado . . . . . . . . . . . . . . . . . . . . . . . 50
3.4.3. Telefonear al Horno . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.4.4. Mostrar Hornos Distancia . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4.5. Mostrar Ruta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4. Implementacion 56
4.1. Implementacion en iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.1.1. Librerıas del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.1.2. Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.1.3. Capa de gestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.1.4. Capa de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.2. Implementacion en Android . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.2.1. Librerıas del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.2.2. Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.2.3. Capa de gestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.2.4. Capa de localizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.2.5. Capa de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.3. Diferencias entre iOS y Android . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.3.1. Lenguaje de programacion . . . . . . . . . . . . . . . . . . . . . . . . 82
4.3.2. Desarrollo de la interfaz . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.3.3. Localizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.3.4. Uso de Mapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.3.5. Valoraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.4. Aspecto final de las pantallas . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5. Planificacion y Costes 89
6. Conclusiones y trabajo futuro 92
3
6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.2. Valoraciones personales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.3. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7. Referencias 95
7.1. Geolocalizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.2. Representacion de Mapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.3. iOS vs Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.4. Implementacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4
Agradecimientos
Llegados a este punto son muchas las personas que seguro merecen mi agradecimiento
durante todos estos anos de carrera, pero en esta ocasion procurare centrarme en los que
han ayudado a ponerles fin con este proyecto.
En primer lugar, como no, a mi tutor de proyecto. Gracias Jordi por pensar que serıa
capaz de llevarlo a cabo y por todo el asesoramiento y recursos que me has facilitado.
Gracias tambien a David Gaso, Ciro Alonso y Rosa Garcıa, mis responsables directos en la
empresa para la que trabajo. Gracias por toda la confianza que me habeis mostrado desde
que empece a trabajar con vosotros, gracias por vuestra comprension con respecto al rumbo
que decidı tomar y por facilitarmelo todo en forma de excedencia.
Y por ultimo gracias a toda mi familia por apoyarme y aguantarme habitualmente y sobre
todo estos ultimos meses, pues posiblemente me habre mostrado mas agitado de lo habitual.
5
Capıtulo 1
1. Introduccion
Los avances tecnologicos que los telefonos moviles han experimentado en el ultimo lustro
han permitido que el usuario tenga al alcance de la mano todo lo que puede necesitar en su
dıa a dıa. La limitada potencia de calculo o el reducido tamano de la memoria que estos dis-
positivos tenıan antano ha dejado de ser un problema para los desarrolladores que ademas
han visto como la interfaz tactil, el acceso a internet o la geolocalizacion les abrıan un nuevo
abanico de posibilidades a la hora de desarrollar aplicaciones mas utiles y accesibles para
todo el mundo.
Quizas algunas de las aplicaciones que mas hayan proliferado sean aquellas que permi-
ten al usuario ubicarse en tiempo real en un mapa y encontrar lugares de interes, ya sean
turısticos, de ocio o cualquier tipo de establecimiento. Y no es de extranar que sea ası,
ya que este tipo de aplicaciones no solo son utiles para el usuario, sino tambien para las
empresas que gracias a ellas pueden indicar a sus clientes la manera de llegar a su tienda
mas cercana. Es una manera sencilla de publicitarse y fidelizar clientes a muy bajo coste.
Con esa idea en mente nace este proyecto, cuyo objetivo principal es desarrollar una apli-
cacion que muestre nuestra posicion geografica en tiempo real y disponga de un catalogo
de establecimientos de manera que el usuario pueda navegar por el y elegir a cual desea
ir; o simplemente encontrar la manera de llegar al mas cercano. Estos establecimientos son
tiendas donde se puede adquirir pan con Indicacion Geografica Protegida (IGP) ”Pa de
Pages Catala”1.
Teniendo esto en cuenta se decidio utilizar los dispositivos moviles como plataforma pa-
ra esta aplicacion. Su tamano permite al usuario moverse con el y el GPS o el acceso a
1De ahora en adelante nos referiremos a ellos como ”hornos”
6
la red de telefonıa movil permite obtener la posicion geografica de manera mas precisa.
Los modelos escogidos han sido aquellos que funcionan sobre los sistemas operativos iOS
y Android, ya que son los que gozan de mayor implantacion en el mercado, proporcionan
facilidad para acceder a su SDK y una extensa base de conocimientos para ayudar al desa-
rrollador. Ademas las companıas que estan detras de estos sistemas operativos (Apple y
Google respectivamente) disponen de plataformas de distribucion de aplicaciones amplia-
mente aceptadas por sus usuarios (AppStore y GooglePlay, respectivamente).
1.1. Objetivos
Los objetivos para llevar a cabo este proyecto podemos desglosarlos de la siguiente manera:
Investigacion previa
En primer lugar habra que hacer un pequeno estudio sobre las diferentes tecnologıas
que permiten la localizacion geografica y determinar cual o cuales son las mas ade-
cuadas para esta aplicacion.
Posteriormente y dado que son dos lenguajes de programacion desconocidos para mı,
sera necesario estudiar tanto el entorno de desarrollo como los propios lenguajes.
Diseno preliminar de la aplicacion
Habra que determinar las acciones que podra realizar el usuario en la aplicacion y
hacer un primer diseno de la estructura de esta.
Estudio de particularidades
Una vez instalados los SDKs, asimilados los conceptos basicos de los lenguajes y
con la idea general de lo que necesitara la aplicacion, sera necesario investigar las
diferentes herramientas o APIs que tenemos disponibles para llevar a cabo las tareas
mas complejas, como son la inclusion de mapas y la geolocalizacion en ambos sistemas
operativos.
Desarrollo de la aplicacion
7
Se desarrollaran dos versiones de la aplicacion, una para dispositivos Android y otra
para iPhone.
Despliegue final
Finalmente las versiones definitivas de la aplicacion se pondran a disposicion del publi-
co en las plataformas de distribucion de Google y Apple.
1.2. Motivaciones personales
A nivel personal, la principal motivacion que encontre para realizar este proyecto fue el
deseo de iniciarme en el desarrollo para dispositivos moviles. Llevo cuatro anos ejerciendo
como programador en entornos .Net y entendıa que era el momento de probar cosas nue-
vas. En este sentido, me parecio que la programacion para iOS y Android era una buena
eleccion puesto que son dos plataformas en continuo crecimiento y permiten hacer llegar
tus aplicaciones a un amplio mercado de manera rapida y directa. Ademas este proyecto
me daba la oportunidad de trabajar con mapas y geolocalizacion, dos conceptos clave en el
desarrollo de aplicaciones moviles.
8
Capitulo 2
2. Estado del Arte
En este capıtulo introduciremos las diferentes tecnologıas que se han utilizado en este pro-
yecto, como son las tecnicas de geolocalizacion o los sistemas de representacion de mapas.
En general se procurara no entrar en demasiado detalle y mostrar una vision lo mas cercana
posible al ambito de este proyecto.
2.1. Geolocalizacion
Entendemos por geolocalizacion al conjunto de tecnicas que permiten determinar la posi-
cion geografica de un elemento (un ordenador, un telefono movil o cualquier dispositivo
capaz de ser detectado) en el mundo real y hacer uso de esa informacion. Esta tecnologıa
requiere de la perfecta sincronizacion entre hardware y software, es necesario un dispositivo
con GPS o conexion a internet y un software que permita hacer uso de ellos en esta direccion.
En los ultimos anos los smartphone se han tornado el dispositivo ideal para la geoloca-
lizacion gracias al hardware que incorporan y a que sus fabricantes han dotado sus sistemas
operativos de las herramientas necesarias para que los desarrolladores hagan uso de la geo-
localizacion con facilidad y puedan centrarse en explorar sus multiples utilidades. No es de
extranar pues la gran cantidad de aplicaciones que hay disponibles en telefonos moviles que
hacen uso de esta tecnologıa. Entre ellas podemos diferenciar tres usos comunes:
Georreferenciacion: Es el proceso mediante el que se localiza un objeto, lugar o
persona en el espacio fısico para posteriormente representarlo en un sistema de coor-
denadas o mapa. Un ejemplo habitual es la representacion de tu posicion en el mapa
de tu ciudad y actualizarla a medida que te desplazas.
Geocodificacion: Es el proceso de obtencion de coordenadas geograficas a partir
de otro tipo de datos geograficos, como la direccion o el codigo postal. Al proceso
9
contrario, la obtencion de direcciones postales a partir de coordenadas se le denomina
Geocodificacion Inversa. El ejemplo claro lo vemos en la aplicacion Google Maps, que
muestra en un mapa el punto donde quieres despues de haber indicado la direccion
postal.
Geoetiquetado: Es el proceso mediante el cual se anade informacion geografica en
forma de metadatos a otro tipo de contenido. Usualmente es un paso posterior a la
georreferenciacion. Un ejemplo de geoetiquetado serıa incluir en una fotografıa las
coordenadas del lugar donde fue tomada.
Ya que el proceso de georreferenciacion es quizas el mas importante de todos, y dado que
juega un papel importante en la mayorıa de las aplicaciones de geolocalizacion, es habitual
ver como se usan ambos terminos indistintamente [1, 2, 3, 4, 5].
2.1.1. Metodos de georreferenciacion en dispositivos moviles
Un mismo dispositivo movil dispone de diferentes vıas para determinar su posicion, siendo
algunas mucho mas precisas que otras. Sin embargo en ocasiones al dispositivo no le sera po-
sible utilizar la tecnica mas precisa y debera recurrir al metodo que tenga disponible. Esta
disponibilidad la marca el medio al que esta conectado el dispositivo, y en funcion de este
medio podemos dividir las tecnicas de georreferenciacion en tres grupos:
Redes Wi-Fi
Este metodo se basa en el uso de enormes bases de datos que contienen la informacion
y situacion de gran cantidad de redes Wi-Fi. El metodo consiste en enviar la direccion
MAC del router Wi-FI y el SSID (nombre la red) y contrastarlo con la base de datos
que devolvera la posicion geografica de la red. De esta forma es posible determinar con
una precision de entre 30 y 100 metros la ubicacion de cualquier dispositivo conectado
a una red inalambrica.
Google, por ejemplo, es propietaria de una de estas bases de datos y la utiliza en
su sistema de mapas Google Maps. Para crear la base de datos enviaron vehıculos a
10
recorrer las ciudades que registraban las redes Wi-Fi que encontraban a su paso. Hoy
dıa son los propios telefonos moviles de los usuarios los que completan estas bases de
datos enviando su ubicacion [1, 9].
Redes de telefonıa movil:
Hay un gran numero de tecnicas de georreferenciacion que permiten obtener la posicion
de un dispositivo que este conectado a una red de telefonıa movil y su precision oscila
entre los 50 y los 500 metros. Mientras que en el siguiente apartado veremos las mas
relevantes, en este nos limitaremos a clasificarlas en tres grandes grupos:
• Basadas en la red
Estas tecnicas utilizan la infraestructura del operador de telefonıa movil para
determinar la ubicacion del terminal. La principal ventaja es que no son tecnicas
intrusivas y no requieren que el dispositivo disponga de hardware o software es-
pecıfico. La precision de estas tecnicas varıa no solo en funcion de la tecnica en
sı, sino tambien en funcion de la infraestructura del operador. De estas tecnicas
destacamos la CGI (Cell Global Identity), CGI-TA, que combina las tecnicas Ti-
ming Advance junto con CGI, TDOA (Time Difference Of Arrival), AoA (Angle
of Arrival) y A-GPS (Assisted Global Positioning System)
• Basadas en el terminal
Son tecnicas que requieren dotar al terminal de un receptor de senales y de apli-
caciones especıficas que realicen las tareas necesarias para determinar la posicion
geografica, por ello estas tecnicas dependen en gran medida del fabricante del
dispositivo. La principal ventaja de estas tecnicas sobre las anteriores radica en
que no son tecnicas tan dependientes de la infraestructura del proveedor de ser-
vicios. Entre las mas conocidas, encontramos E-OTD (Enhanced Observed Time
Difference) y variaciones de CGI y TDOA.
• Hıbridas
11
Combinan las tecnicas basadas en la red y las basadas en el terminal para con-
seguir mayor precision, pero heredan los inconvenientes de ambas.
GPS
GPS son las siglas de Global Positioning System. Es un sistema de localizacion por
satelites que permite determinar la posicion de un dispositivo en cualquier lugar del
globo terrestre con una precision de entre 1 y 15 metros; en el 95 % esta precision es
de 3 metros. El sistema esta formado por 27 satelites (24 operativos y 3 de repuesto)
cuya funcion es emitir senales con informacion sobre el tiempo de emision y su posicion
para que los receptores GPS las interpreten y utilicen en el calculo de su situacion
geografica. Este calculo se basa en el concepto de trilateracion, que es un principio
geometrico que permite conocer la ubicacion de un punto conociendo su distancia a
otros puntos ya conocidos, en este caso los satelites.
Figura 1: Trilateracion
Para calcular la distancia entre el dispositivo y los satelites se mide el retraso que
marca el tiempo de la senal emitida por estos. Una vez tenemos el retraso y conocien-
12
do que la senal ha viajado a la velocidad de la luz, podemos determinar la distancia
a la que se encuentra el satelite. Para que este proceso funcione es necesario recibir la
senal de al menos otros dos satelites. Con tres satelites ubicados podemos hacer una
esfera alrededor de cada uno de ellos, con el satelite como centro, y obtendremos tres
esferas que se cortaran en dos puntos, uno de ellos es despreciable puesto que no se
encuentra en la superficie de la tierra y el otro sera el que indique donde se encuentra
el receptor GPS.
No obstante, debido a que la senal no viaja realmente a la velocidad de la luz (por
retrasos en la ionosfera y estratosfera y otro tipo de obstaculos), hay errores que se
ven reflejados en la precision del resultad y para compensarlos es necesario involucrar
mas satelites y calcular sus distancias. Es por ello que el sistema GPS garantiza que
las orbitas de los satelites permiten que desde cualquier punto de la tierra sean visibles
simultaneamente no menos de cinco satelites.
Figura 2: Funcionamiento GPS
Hoy dıa hay un considerable numero de telefonos moviles que disponen de receptor
13
GPS y es la primera opcion que utilizan las aplicaciones de geolocalizacion cuando
se prioriza la precision, pero es requisito indispensable que el dispositivo se encuentre
en cielo abierto y despejado, de lo contrario no puede recibir la senal de los satelites.
Otro de sus inconvenientes es que es un sistema considerablemente lento. El resultado
puede tardar en obtenerse en torno a unos 20 - 45 segundos [1, 7, 10].
2.1.2. Tecnicas de geolocalizacion en redes de telefonıa movil
A continuacion describiremos brevemente algunas de las tecnicas de georreferenciacion que
es posible efectuar sobre dispositivos conectados a redes de telefonıa movil.
Cell Global Identity (CGI)
Para entender el funcionamiento de esta tecnica es necesario comprender primero como
estan disenadas las redes de telefonıa movil. A estas redes tambien se las conoce como redes
celulares ya que estan formadas por un conjunto de celulas que emiten a un determinada
distancia las unas de las otras. Cuando un telefono movil quiere realizar una llamada loca-
liza las senales de las antenas de estas celulas y se conecta a la que recibe con mas fuerza.
Este tipo de red esta disenado a modo de panal, de manera que cada celula esta rodeada de
otras seis, formando hexagonos, y cada una de las antenas emite en una frecuencia diferente,
por lo que tenemos siete frecuencias por hexagono (seis en las antenas de los vertices y una
en el centro).
14
Figura 3: Redes celulares
Teniendo esto claro, es facil entender el funcionamiento de esta tecnica, ya que unicamente
consiste en determinar a que antena del hexagono esta conectado el terminal, que sera la
que tenga mas cercana puesto que es cuya senal recibe con mas fuerza. Ası pues sabremos
que el terminal esta situado en el radio de alcance de esta antena.
Esta tecnica tiene la ventaja de que no necesita ningun tipo de modificacion en el dispositivo
movil (es una tecnica basada en la red), pero la precision del resultado esta ıntimamente
ligada a la densidad de antenas que tenga el operador de telefonıa movil en la zona en la que
nos encontremos. En ciudades, donde el numero de antenas es mayor, obtenemos mejores
resultados que en zonas rurales, donde el margen de error puede llegar a ser kilometrico [7, 8].
Cell Global Identity + Timing Advance (CGI-TA)
Es una mejora de la tecnica anterior haciendo uso del Timing Advance. Timing Advance
es un tecnica que permite calcular (con baja precision) la distancia entre una antena y el
dispositivo movil. Para ello se miden los retardos en la propagacion de la senal y, asumiendo
que viaja a un velocidad cercana a la de la luz, es posible determinar la distancia.
15
Figura 4: Timing Advance
Esta tecnica esta directamente vinculada a la cobertura de la celula, por lo que en entornos
rurales el margen de error puede llegar a ser tan alto como el de la tecnica CGI simple pero
en ciudad puede alcanzar una precision de hasta 10 metros [8].
Time Difference of Arrival (TDOA)
Esta tecnica consiste en medir los tiempos que tarda una misma senal en llegar desde el
terminal movil a un conjunto de antenas y ver la diferencia. A partir de ahı podemos cal-
cular la distancia a la que se encuentra de cada antena y averiguar su ubicacion exacta
gracias a la trilateracion, al igual que ocurre en el calculo de posicion mediante GPS pero
esta vez en un plano bidimensional. Cabe destacar que el calculo de la ubicacion en funcion
de los parametros de tiempo obtenidos los lleva a cabo el operador de la red, el terminal no
interviene en ningun momento, por lo que esta tecnica, al igual que CGI, es posible llevarla
a cabo en cualquier telefono movil [7, 8].
16
Figura 5: Trilateracion aplicada en TDOA
Angle of Arrival (AOA)
Es una tecnica que mide el angulo con el que inciden sobre un conjunto de antenas las senales
que emite el dispositivo movil. Para calcular estos angulos es necesario utilizar la tecnica
TDOA, y una vez se obtenien podemos calcular la posicion geografica por triangulacion.
Figura 6: Angle of Arrival
Esta es una tecnica costosa ya que requiere de un determinado tipo de antena y que pierde
eficacia en entornos urbanos, donde los edificios interrumpen las senales [7, 8].
Enhanced Obeserved Time Difference (E-OTD)
Esta tecnica se basa en el mismo principio que TDOA: a partir de la diferencia de tiem-
pos en las senales establece la posicion del terminal movil. La gran diferencia es que en
17
este caso quien lleva a cabo el calculo a partir de los parametros obtenidos es el propio
dispositivo. Ello significa que para poder hacer uso de este metodo se requieren terminales
convenientemente adaptados.
Figura 7: Esquema E-OTD
La precision de esta tecnica fluctua entre lo 50 y los 100 metros [8].
Assisted Global Positioning System (A-GPS)
Es una tecnica hıbrida que mezcla las tecnicas de geolocacilacion por redes moviles con el
sistema GPS. Para ello el operador de la red distribuye cada 200-400 kilometros de cober-
tura bajo estaciones base unos dispositivos de asistencia GPS que unicamente podran usar
aquellos terminales dotados de un receptor GPS. Estos terminales se podran conectar con
los dispositivos mediante una senal wireless o de telefonıa y ası combinar el uso del GPS con
algunas de las tecnicas vistas anteriormente. De esta manera se salvan los problemas que
tenıa el GPS para posicionar en espacios cerrados o con condiciones climatologicas adversas
y se mejoran los tiempos de obtencion del resultado, que pasan a ser de 1-8 segundos. Tam-
bien tiene un modo de funcionamiento off-line, que consiste en descargase de los dispositivos
distribuidos un fichero con los datos de los satelites y hacer uso de el cuando junto con los
resultados que de el GPS cuando se solicite el geoposicionamiento [7, 8, 11].
18
2.1.3. Herramientas de geolocalizacion
Location API for J2ME (JSR 179)
Location API for J2ME es una conjunto de APIs genericas para dispositivos moviles que
permite obtener todo tipo de informacion relacionada con la ubicacion del terminal que
utiliza el servicio. Fue desarrollada bajo el ambito del Java Community Process (JSP) en
el ano 2003 con el nombre de JSR 179, siendo Nokia el principal desarrollador y encargado
de su mantenimiento.
Es posible utilizarla mediante el paquete Javax.microedition.location pero requiere del fra-
mework Connected Device Configuration (CDC) o del Connected Limited Device Configura-
tion (CLDC) pero no en su primera version (1.0), ya que esta no soporta numeros de coma
flotante y la API los necesita para representar las coordenadas. Esta API puede usarse como
librerıa en cualquier aplicacion, ya sea de codigo abierto o cerrado, ya que se encuentra bajo
licencia GNU Lesser General Public License (LGPL).
El objetivo principal que se tenıa con esta API era proporcionar una herramienta de geolo-
caclizacion al mayor numero de dispositivos posible, sin importar sus caracterısticas, por lo
que se programo con la capacidad de hacer uso de un gran numero de tecnicas de georrefe-
renciacion. Sin embargo sı que seran las caracterısticas del dispositivo las que determinen
que tecnica puede utilizarse en ultima instancia y la precision en el resultado sera resultado
directo de esto. Haciendo uso de los metodos de localizacion a traves de redes moviles,
obtendremos mediciones con un margen de error de entre 50 y 500 metros (puede que mas
en zonas rurales), mientras que si el dispositivo tiene receptor GPS el precision se vera in-
crementada hasta los 4 - 40 metros.
Esta API funciona tanto en espacios abiertos como cerrados y permite obtener latitud,
longitud, velocidad, altura e incluso la orientacion del dispositivo (siempre que este dispon-
ga de brujula). Tiene la capacidad de asignar nombres y valores textuales (como direcciones
19
postales) a las posiciones obtenidas y almacenarlas como marcadores. Otra de sus carac-
terısticas es que permite elegir entre velocidad y precision a la hora de obtener un resultado,
siempre y cuando las caracterısticas del dispositivo den la posibilidad de usar mas de una
tecnica de geolocalizacion [12, 13].
Android Location Services
Es una API desarrollada por Google que podemos descargar gratuitamente junto con el en-
torno de desarrollo para Android y que encontramos dentro del paquete Android.Location.
Al igual que la API anterior, permite conocer todos los parametros necesarios para determi-
nar una posicion (latitud, longitud, altura, velocidad y direccion) y la actualiza en tiempo
real. Ademas tiene la opcion de consultar la ultima ubicacion obtenida, por si en un mo-
mento dado no tenemos la posibilidad de calcularla de nuevo. Otra de sus prestaciones es la
posibilidad de suscribirse a un intent o evento que lanzara cualquier aplicacion que elijamos
al llegar a una ubicacion previamente marcada.
Como es comun en estas APIs, permite utilizar las tecnicas de geoposicionamiento mediante
redes Wi-Fi locales, redes de telefonıa movil y GPS (siempre que el terminal este prepara-
do). La principal ventaja de esta API es que al ser de Google esta pensada para funcionar
con su API de mapas Google Maps y su integracion es muy sencilla [14].
Core Location
Este paquete ha sido desarrollado por Apple y solo es posible obtenerlo con su SDK y uti-
lizarlo en aplicaciones que funcionen sobre el sistema operativo iOS. Funciona empleando
las tecnicas de geolocalizacion en redes Wi-Fi, moviles o GPS que hemos visto y permite
elegir entre dos servicios diferentes a la hora solicitar la posicion del terminal [15].
Standard location service
Es un servicio configurable para un uso general y que soportan todas las versiones de
iOS. Permite solicitar la posicion del terminal en un momento determinado pero no
20
subscribirse para ser avisado en caso de cambios en esa posicion. Ademas tiene un
alto consumo energetico y es conveniente utilizarlo con mesura para ahorrar baterıa.
Significant-change location service
Es un servicio de bajo coste energetico que ademas permite recibir alertas sobre los
cambios de posicion del terminal, incluso si la aplicacion se encuentra en estado suspen-
dido o apagada. Estas alertas tambien informan del cruce entre fronteras. Unicamente
esta disponible en iOS 4.0 y posteriores.
2.1.4. Aplicaciones con geolocalizacion
Actualmente son muchas las aplicaciones que hacen uso de la ubicacion del usuario en uno
u otro sentido. A continuacion vamos a ver alguna de ellas:
Figura 8: Brujula
Brujula para iPhone
Esta aplicacion viene por defecto en todos los
telefonos iPhone. Haciendo gala del minimalismo
con el que Apple dota a todos sus productos, la
aplicacion consta de una unica pantalla que na-
da mas mostrarse ya indica la ubicacion en for-
ma de coordenadas geograficas (grados, minutos
y segundos), como podemos ver en la figura 8.
Ademas, como su nombre indica, hace las veces de
brujula indicando el norte (podemos elegir entre
el norte real y el norte magnetico) y hacia donde
esta orientado el dispositivo. Finalmente nos da la
opcion de llamar a una aplicacion de mapas y mos-
trarnos el punto geograficos donde estamos ubica-
dos.
21
Star Walk
Star Walk es una aplicacion pensada para los aficionados a la astronomıa. Se hace valer de
la ubicacion geografica para mostrar el cielo tal y como lo estamos viendo en la realidad y
lo va actualizando en tiempo real.
Figura 9: Star Walk
Ademas utiliza la el calculo de la orientacion del dispositivo para poder usarlo como si de
un cristal transparente se tratase, de forma que si lo ponemos delante de nuestros ojos y
miramos al cielo, veremos indicados en la pantalla nombre de todos los objetos celestes
(estrellas, planetas, catalogo Messier...) hacia los que estamos mirando. Es una aplicacion
disponible para dispositivos con sistema operativo iOS.
TomTom
TomTom es una aplicacion para dispositivos iOS que hace las veces de sistema GPS de
carretera. Utiliza la ubicacion del usuario para mostrarla en un mapa de carretera y guiar-
le durante el trayecto mediante voz. Tambien calcula la velocidad a la que se desplaza el
vehıculo e indica los lugares de interes a los que se va acercando (estaciones de servicio,
22
radares, accidentes... ). Sin embargo debido a la alta precision que requiere la conduccion
en carretera, solo soporta la tecnica de geoposicionamiento por GPS, por lo que es obligado
que los dispositivos que ejecuten a aplicacion tengan un receptor de senal GPS.
Figura 10: Around Me
Around Me
Esta aplicacion, disponible tanto para dispositi-
vos Android como iOS, utiliza nuestra ubicacion
geografica para indicarnos los lugares de nuestro
interes que tenemos proximos. El usuario en pri-
mer lugar indica que lugares le interesa encontrar
y la aplicacion le muestra una lista con los resul-
tados que ha obtenido, mostrando en primer lugar
los mas cercanos e indicando la distancia hasta ellos
y como llegar. Entre los lugares que podemos bus-
car tenemos disponibles bancos, gasolineras, hospi-
tales, bares, cines y muchos mas. Si lo deseamos
Around Me tambien puede mostrarnos un mapa
con nuestra ubicacion y la de los lugares selecciona-
dos.
Aplicaciones de Mapas
Tanto Android como iOS vienen instalados por defecto con una aplicacion de mapas, que
aunque son diferentes ambas tienen caracterısticas muy parecidas puesto que las dos funcio-
nan con la API de mapas Google Maps. Estas aplicaciones nos muestran nuestra posicion
en un mapa y senalizan todo lo que tenemos alrededor: el nombre de las calles, los portales,
estaciones de metro, paradas de autobus... Tambien permiten escribir una direccion postal
23
para que la aplicacion la localice y nos la muestre en el mapa con un marcador. Podemos
ver las diferentes rutas que tenemos para llegar allı desde nuestra ubicacion actual o desde
otro punto que le indiquemos. A medida que nos movemos vemos como nuestra posicion en
el mapa se desplaza de la misma forma y podemos pedir que nos muestre la direccion hacia
la que estamos mirando.
Figura 11: Mapas para iOS
2.2. Representacion de mapas
Cuando tratamos de representar una superficie esferica sobre un plano nos encontramos con
el problema de que es imposible hacerlo sin deformarlo o distorsionarlo de alguna manera,
ası que las distancias en determinados puntos no se ajustaran a las reales. Esto hace que
fijar un sistema de coordenadas en ese plano sea una tarea complicada. Ademas si lo que
queremos representar es la corteza terrestre nos encontramos con que la superficie de la
24
Tierra (al igual que la el resto de cuerpos celestes) no es perfectamente esferica, mas bien
es un esferoide ligeramente aplanado por los polos y con multitud de irregularidades en su
superficie. Ası pues la unica manera posible de representar sin ningun tipo de imprecision
la superficie de nuestro planeta es utilizar una esfera de verdad (como un globo terraqueo),
pero no es comodo trabajar con este tipo de formas en una pantalla, es por ello que para
representar mapas digitales se utilizan otros metodos [16, 17].
2.2.1. Proyeccion de mapas
Una proyeccion es un metodo matematico que permite representar un cuerpo esferico, o
cualquier cuerpo tridimensional, en un plano bidimensional. Existen varios tipos de pro-
yecciones y todas y cada una de ellas deforman algun aspecto del objeto original, ya sea
la forma, el area, la distancia o la direccion. Sin embargo segun cual sea nuestro proposito
algunas deformaciones son aceptables, por lo que podemos escoger el tipo de proyeccion que
mas se ajusta a nuestras necesidades.
La forma tıpica de clasificar los tipos de proyecciones de mapas es segun la forma del
objeto sobre el que se proyectara la esfera terrestre, dando lugar a tres grandes grupos:
cilındricas, conicas y planas
Proyecciones cilındricas
Se basan en proyectar la superfıcie de la Tierra en un cilindro. Este cilindro puede ser
tangente a la esfera terrestre en una lınea seleccionada o bien secante y cortarla por dos
lıneas. Una vez se proyecte la esfera sobre la superficie del cilindro los puntos donde la este
es tangente o secante seran los que menos distorsion tengan. Una caracterıstica interesante
de estas proyecciones es que si el cilindro es tangente o secante por los paralelos terrestres,
obtendremos mapa con todos los paralelos y meridianos rectos y paralelos entre sı.
25
Figura 12: Proyeccion cilındrica tangente y secante
Entre las proyecciones cilındricas mas famosas se encuentra la proyeccion Mercator, adop-
tada por ejemplo en aplicaciones de mapas como Google Maps. Su uso esta muy extendido
en la navegacion y, al ser tangente por el Ecuador, es comun verla en los paıses cercanos a
este. Como contrapartida pierde precision a medida que nos acercamos a los polos, dando
la falsa impresion de que Groenlandia y la antigua Union Sovietica son mas extensas que
Sudamerica y Africa.
Otras proyecciones cilındricas o pseudocilındricas muy conocidas son la Mollweide, que
dibuja la tierra dentro de un ovalo, o la discontinua de Goode, que representa como si fue-
sen gajos, de forma que aunque consigue mucha precision es muy difıcil de leer.
Proyecciones conicas
En este tipo de proyeccion la superficie de la tierra se proyecta sobre un cono imaginario.
Este cono puede ser tangente a alguno de los paralelos terrestres o secante en dos de ellos,
tal y como podemos apreciar en la figura 13.
26
Figura 13: Proyeccion conica tangente y secante
Este tipo de proyeccion no presenta deformidades allı donde el cono es tangente o secante,
por lo que es recomendable para regiones poco extensas de latitudes medias, pero presenta
grandes deformaciones regiones mayores. Como representantes de esta categorıa tenemos
la proyeccion Lambert, utilizada a menudo en aeronautica, y la proyeccion Albers, que es
secante por dos paralelos y aunque no conserva la escala y forma del original, consigue una
distorsion mınima entre los dos paralelos secantes.
Proyecciones planas
Tambien conocidas como proyecciones acimutales, en este tipo de proyeccion es un plano
bidimensional quien es tangente a la esfera terrestre por un punto o bien secante por toda
una circunferencia. Tambien es posible que el plano sea totalmente exterior a la esfera, como
en el caso de la proyeccion ortografica.
27
Figura 14: Proyeccion planar tangente y secante
Estas proyecciones tienen la particularidad de que apenas presentan deformidades en las
zonas centrales del plano, pero sı en los extremos.
Entre sus ejemplos, podemos destacar la ya mencionada proyeccion ortografica, que tiene la
apariencia de una foto del planeta Tierra tomada por un astronauta, y la proyeccion azimutal
equidistante, que tiene como principal ventaja que todas las distancias y direcciones medidas
desde el centro del mapa son verdaderas, es decir, que si trazamos una circunferencia desde
el centro, todos los puntos de ese circulo seran equidistantes respecto al origen [16, 17].
2.2.2. Sistema de Informacion Geografica (SIG)
Un Sistema de Informacion Geografica es un sistema de mapas digitalizados cuyo fin es
capturar, almacenar, manipular, analizar y desplegar la informacion geografica almacena-
da para poder ejecutar cualquier tipo de operacion relacionada con mapas de una manera
sencilla para el usuario. Entre las operaciones mas comunes se encuentra la busqueda de
direcciones, el trazado de rutas, calculo de distancias, etc.
Podemos pensar en un SIG como si de una base de datos se tratase, una base de datos
donde se almacena todo tipo de informacion geografica cuyo identificador es un objeto
grafico representado en mapa en unas determinadas coordenadas. De esta manera senalan-
28
do este objeto en el mapa podemos obtener todos los datos asociados a el que hay en la
base de datos y viceversa, si introducimos alguno de estos datos como criterio de busqueda
podemos ser trasladados a su posicion en el mapa.
Los SIG funcionan agrupando su informacion por capas que se situan la una sobre la otra
y compartiendo un mismo sistema de coordenadas. Tal y como vemos en la figura 15, una
capa puede tener la informacion fluvial, otra los mapas de carteras, otra los nombres de los
lugares de interes, etc. De esta manera es posible acceder a la informacion deseada de una
manera mas directa y podemos discriminar los datos que no deseamos ver.
Figura 15: Sistema de capas
Representacion de los datos
El leitmotiv de todo SIG es poder representar en una pantalla la realidad y sus objetos.
Estos objetos podemos dividirlos de dos grupos: discretos y continuos. Entendemos por
objetos discretos aquellos cuyos lımites estan bien delimitados, como puede ser un edificio o
una carretera. En cambio los continuos son aquellos fenomenos con lımites mas imprecisos,
como puede ser la lluvia caıda, la contaminacion o la temperatura en una zona determinada.
Para ambos objetos tenemos una forma de almacenar datos: vectorial para los discretos y
raster para los contınuos.
Raster
29
El tipo de datos raster se centra mas en las propiedades del espacio que en la precision
de las localizaciones. Consiste en dividir el espacio en celdas regulares, a modo de
malla, y asignarles un valor. Es el mismo funcionamiento que una imagen, donde a
cada pixel se le asigna un color y la union de todos acaba definiendo la imagen en
su totalidad. De hecho una forma de almacenar datos raster es como si de imagen
se tratarse, con formatos TIFF, JPEG... o tambien puden almacenarse en grandes
ficheros binarios llamados BLOB.
Vectorial
Los datos vectoriales se utilizan cuando se quiere dar prioridad a la precision de los
elementos geograficos en el espacio. Por ello, a fin de mantener sus caracterısticas
geometricas y delimitarlos adecuadamente se definen mediante vectores. Utilizan tres
tipos de figuras para modelar los elementos geograficos: el punto, la lınea y el polıgono.
El punto se utiliza para representar los elementos del mundo real que pueden ser
definidos mediante un punto concreto, como puede ser el pico de una montana u otros
puntos de interes. A escalas pequenas tambien sirven para representar poblaciones. La
lınea se utiliza para medir todo aquello que se caracteriza por su longitud, como pueden
ser carreteras, rıos, caminos, vıas, ferrocarriles, fronteras, etc. Los datos representados
por lıneas permiten medir distancias. Por ultimo el polıgono sirve para representar
elementos del mundo real que abarcan cierta extension sobre la superficie terrestre:
lagos, provincias, ciudades, parques naturales... Permiten calcular el area que abarcan.
Renderizado
Una vez tenemos los datos en la base de datos y tenemos claro como representarlos, lo unico
que falta es la fase de renderizado. Esta fase es la encargada de reunir toda la informacion
de la base de datos, unir las capas y generar la imagen final con la que trabajara el usuario.
Hay servicios de mapas que unicamente centran su trabajo en esta fase: obtienen los datos
de alguna otra fuente (por ejemplo OpenStreetMap) y se encargan de ofrecer al usuario un
renderizado y unas funcionalidades especıficas [18].
30
2.2.3. APIs de mapas
En los ultimos tiempos la creciente demanda por las aplicaciones de geolocalizacion y mapas
ha dado lugar una gran oferta de APIs disponibles entre las que poder elegir segun nuestras
necesidades. Las funciones que ofrecen todas ellas son muy similares, en general encontramos
geocodificacion, geocodificacion inversa, soporte para marcadores, calculo de distancias,
lugares de interes, etc. A continuacion veremos un pequeno listado con algunas de ellas:
OpenStreetMap: Es una base de datos geograficos de libre uso cuya popularidad
va en aumento. Desarrollada por la OpenStreetMap Foundation, permite a cualquier
tipo de desarrollador, ya sea aficionado, autonomo o una empresa, usar sus mapas sin
ningun tipo de restriccion. Su principal caracterıstica es que da acceso a la base de da-
tos subyacente y no unicamente a los datos renderizados, por lo que los desarrolladores
tienen muchısima mas libertad a la hora de crear sus aplicaciones [19].
Google Maps: Esta API desarrollada por Google es la API cuyo uso esta mas exten-
dido. Su version movil viene incluida en el paquete com.google.android.maps del SDK
de Android. Aunque hasta hace relativamente poco su uso era gratuito, recientemente
Google anadio unos lımites para su uso: 25000 cargas de mapas diarias y 2500 cargas
de mapas modificados. Si nuestra aplicacion sobrepasa ese lımite Google da la opcion
de pagar por la sobrecarga o adquirir una licencia premium. Es debido a este movi-
miento que algunas empresas se estan replanteando su uso (como Apple, que con la
ultima version de iPhoto ha cambiado Google Maps por OpenStreetMap) [20].
Bing Maps: Bing Maps es una API desarrollada por Microsoft con el objetivo de
ser el sistema principal de mapas en Windows Phone 7, aunque tambien disponen de
SDK para hacer uso de ellos en Android e iOS. Es una API de acceso gratuito pero
tiene diferentes planes de uso segun el tipo de usuario y muchas restricciones [21].
CloudMade: Esta API esta disponible para varios sistemas operativos, entre ellos iOS
y RIM BlackBerry, y presenta como principal atractivo la posibilidad de customizar los
31
mapas. No tienen una base de datos geograficos propia, sino que utilizan los mapas de
OpenStreetMap. Es una API que obliga a tener publicidad en la aplicacion (de cuyas
ganancias se benefician) o bien, para eliminarla, hacen pagar 0.30 dolares por cada
usuario que la descargue [22].
Nutiteq Map: Nutiteq Map API esta pensada para plataformas java: Android, J2ME
y RIM BlackBerry. Tiene como base los mapas de OpenStreetMap pero tambien da
la opcion de usar otros mapas, como CloudMade o Binq. Para poder utilizarla debe
comprarse una licencia que cuesta 2000 euros en su version basica. Una vez pagada la
licencia no hay cargos extra por numero de usuarios o cantidad de llamadas a la API
[23].
Map Kit Framework: Esta librerıa desarrollada por Apple funciona sobre los servi-
cios de Google Maps y es la manera mas simple que tienen los desarrolladores de
introducir mapas en las aplicaciones para iOS. Se encuentra en el paquete Map-
Kit.framework del SDK de iOS y se basa en el uso de la clase MKMapView, que
ademas de mostrar el mapa te da gran variedad de opciones interesantes, como por
ejemplo visualizar en tiempo real la posicion del dispositivo dentro del mapa sin ne-
cesidad de codigo extra [15].
2.3. iOS Vs Android
En esta seccion vamos a analizar los dos sistemas operativos para los que se ha decido rea-
lizar la aplicacion.
Cuando hablamos de iOS y de Android estamos hablando de los dos sistemas operati-
vos con mas base de usuarios y aplicaciones de todo el panorama smartphones. Desde que
fueron lanzados en 2007 y 2008 respectivamente, sus ventas no han hecho mas que crecer
en detrimento de sus competidores.
32
Figura 16: Grafico de ventas de dispositivos moviles segun su SO
Como podemos apreciar en la figura 16 el crecimiento de Android ha sido mucho mas pro-
nunciado que el iOS. Esto se debe fundamentalmente que Android es un sistema operativo
instalado en mas de 200 dispositivos, mientras que iOS nacio por y para iPhone, aunque
mas adelante su uso se ha portado al iPad, iPod Touch y Apple TV.
Las companıas que encontramos detras de ambos sistemas operativos son dos de las em-
presas mas poderosas en el mundo de la tecnologıa. Lo son y lo eran antes de semejante
exito con los smartphone. Hablamos de Apple en el caso de iOS y Google en el de Android.
Que si bien coinciden en el exito, ambas tienen filosofıas muy diferentes. Google diseno An-
droid para que fuera un sistema operativo abierto, querıa que cualquier companıa pudiese
instalarlo en su telefono movil y se sintiese libre de modificarlo segun sus necesidades. Por
contra Apple desarrollo iOS pensando exclusivamente en su nuevo dispositivo, el iPhone,
que estaba destinado a revolucionar el mundo de la telefonıa movil. Y como viene siendo
33
tradicional con todos los productos Apple, cuya polıtica consiste en crear un ecosistema
propio, cerrado, basado en la eficiencia, el diseno y la facilidad de uso, su nuevo sistema
operativo serıa exclusivo y no podrıa ser modificado por nadie.
2.3.1. Lenguajes
Los lenguajes de programacion con los que por defecto se trabaja en estos sistemas operati-
vos siguen las filosofıas de las que hablabamos antes. Por un lado Objective-C para iOS, que
es un superconjunto de C creado a principios de los anos ochenta y que Apple utiliza tanto
en el desarrollo de iOS como en el de Mac OS X. Por el otro tenemos Java, que aparecio a
mediados de los noventa con la idea clara de ser un lenguaje multiplataforma, es decir, que
un mismo programa pudiese ejecutarse en cualquier tipo de hardware. Como vemos esto
casa perfectamente con la idea de Android de ser un SO operativo que pueda funcionar en
cualquier dispositivo.
De cara al programador, aunque Java y Objective-C son dos lenguajes orientados a ob-
jetos cuya sintaxis se inspira en C, no es en absoluto lo mismo trabajar con ellos. Para
empezar la sintaxis, aun teniendo la misma base, es mucho mas legible en el caso de Java.
Objective-C obliga a emplear largas lıneas de codigo con caracteres que no son habituales
en la mayorıa de lenguajes de programacion. Si el programador tiene experiencia previa,
debido a la naturaleza multiplataforma de Java, es probable que alguna vez haya trabajado
con el o al menos este familiarizado con sintaxis parecidas. Por contra si el programador
no tiene experiencia previa en iOS o Mac OS X, Objective-C sera un completo desconocido
para el y debera emplear tiempo en familiarizarse. Ademas, como Java es un lenguaje muy
conocido, resulta mas sencillo encontrar documentacion extra o consultar dudas con otros
programadores puesto que la comunidad Java es mayor y hay mas bibliografıa disponible.
Una de las diferencias fundamentales entre ambos lenguajes es que, mientras que Java se
desarrollo con la idea de resultar mas sencillo de cara al programador ahorrandole las tareas
34
de bajo nivel que tenıa C, Objective-C, al ser un superconjunto de este, las conserva todas.
La mas importante sin duda es el manejo de memoria. Mientras Java se olvida de punteros,
de reservar memoria y liberar espacio, dejando todo el trabajo al recolector de basura de
turno (el de Android en este caso), Objective-C, puesto que iOS no dispone de el, debe
lidiar con ello. O debıa, ya que la salida del reciente iOS 5 ha supuesto un gran cambio en
este sentido. Sigue sin tener implementado un recolector de basura propiamente dicho, pero
tiene un Automatic Reference Counting (ARC). Mientras un recolector de basura pierde
recursos del hardware durante el proceso de liberar memoria, el ARC lo que hace es insertar
la logica de la gestion de memoria dentro del codigo durante el proceso de compilado. De
esta manera logramos tener la eficiencia que da la gestion manual de memoria, sin perder
tiempo pensando en ella ni la seguridad que da un recolector de basura, pero sin sacrificar
rendimiento por el camino.
Como apunte final, hablando de rendimiento, en general podemos decir que la dupla iOS y
Objective-C consigue mejores resultados que Android y Java. Esto de nuevo tiene que ver
con sus filosofıas. Objective-C es un lenguaje cuyas aplicaciones se compilan directamente
en codigo ejecutable para el procesador. Esto es posible porque Apple tiene una filosofıa
cerrada y toda aplicacion se ejecutara unicamente en las CPU que ellos decidan ensamblar
en sus dispositivos. Por otro lado, como Android es un SO abierto destinado a multitud de
dispositivos diferentes con procesadores igual de diversos, y no es recomendable un sistema
que obligue a compilar una aplicacion para cada tipo de procesador, decidieron disenar una
maquina virtual intermedia sobre la cual funcionarıan sus aplicaciones. Esto claro tiene un
coste en cuanto a rendimiento [24, 25].
2.3.2. Herramientas de desarrollo
Tanto Apple como Google tienen a disposicion de los futuros desarrolladores un completo
SDK y toda la documentacion necesaria para configurarlos y empezar de cero. Ambos son
accesibles de manera gratuita, pero en el caso de Apple hay una serie de consideraciones
35
que pueden hacer que esa afirmacion no sea del todo cierta. En primer lugar, Xcode, que es
como se llama el IDE para desarrollar tanto para iOS como para Mac OS X, solo funciona
en un ordenador Mac. Ası pues, si no se dispone de uno, es necesario efectuar un desembolso
inicial de al menos 699 euros para comprar uno. Si ya se dispone de un Mac, el siguiente
paso es hacerse una cuenta de desarrollador. La version gratuita de esta cuenta permite
descargar el SDK y empezar a programar, pero no permite distribuir tus aplicaciones ni
testearlas en dispositivos iOS fısicos, unicamente en el simulador que viene con el kit de
desarrollo. La version de pago no tiene estas restricciones y cuesta 99 dolares al ano. Ademas
para poder trabajar con la ultima version del SDK y desarrollar ası para la ultima version
de iOS, es necesario tener instalado en el Mac la ultima version de Mac OS X. En caso
contrario habra que comprarlo e instalarlo. Por ultimo tambien hay que tener en cuenta
que para testear tus aplicaciones iOS es necesario disponer en un iPhone, iPad o un iPod
Touch, que no son dispositivos baratos, en cambio en Android tienes una gran variedad de
dispositivos donde para elegir.
En cuanto al IDE, programar para iOS unicamente es posible con Xcode. En cambio Google
permite instalar el kit de desarrollo en tu IDE habitual, como por ejemplo Eclipse, NetBeans
o IntelliJ IDEA. Ademas el SDK de Android puede instalarse en Linux, Windows o Mac
OS X.
Una vez se esta listo para desarrollar, cabe decir que Xcode supera en eficiencia y ren-
dimiento a cualquier IDE que escojamos para desarrollar en Android. Esto sin duda es
debido de nuevo al ecosistema cerrado que envuelve a Apple. Xcode esta pensado unica-
mente para Mac OS X que esta pensado unicamente para funcionar sobre un Mac. Esto
permite aprovechar mejor el hardware de la maquina. La diferencia se vuelve mas que no-
toria cuando se quiere ejecutar tu aplicacion sobre el simulador: mientras que el de Android
puede tardar cerca de dos minutos en arrancar, el de iOS es mucho mas inmediato.
36
Finalmente, una vez tenemos la aplicacion lista, siempre es recomendable testearla en varios
de los dispositivos sobre los que podra funcionar. En el caso de iOS esto se reduce a menos
de una decena. En cambio en Android, al estar mucho mas fragmentado, directamente es
imposible hacerlo. Esto puede provocar que en alguno de los dispositivos el rendimiento
no sea el esperado o que la interfaz grafica se vea desajustada en una pantalla de menor
tamano que la utilizada durante el testeo.
2.3.3. Plataformas de distribucion
Apple y Google disponen de su propia plataforma de distribucion: App Store y Google Play
respectivamente. Como ya se ha comentado, para poder subir aplicaciones a la App Sto-
re debers tener una cuenta de desarrollador de Apple que cuesta 99 dolares anuales. Para
Google Play tambien se precisa un perfil de desarrollador y pagar una cuota de registro de
25 dolares.
Los requisitos solicitados durante el proceso de subir aplicaciones es similar en ambas
plataformas. Siempre se solicita adjuntar los iconos de la aplicacion en una resoluciones
determinadas, indicar los idiomas que soporta la aplicacion, el nombre de la misma y una
breve descripcion, etc. La diferencia principal es el proceso de validacion por el que Apple
hace pasar a todas las aplicaciones. Mientras que con Android puedes tener tu aplicacion
disponible para descargar en cuestion de minutos, el proceso de Apple se puede hacer te-
diosamente largo. El objetivo de este es comprobar que las aplicaciones cumplen una serie
de requisitos de calidad y que no pondran en uso practicas que comprometan la eficiencia
y el buen funcionamiento de iOS [26, 27].
37
Capitulo 3
3. Diseno de la aplicacion
En este capıtulo veremos la informacion relacionada con el analisis funcional y la especifica-
cion de la aplicacion, es decir, las tareas mas relacionadas con la arquitectura del software.
3.1. Requisitos funcionales
A continuacion describiremos las funcionalidades de la aplicacion desarrollada:
Mostrar en el mapa la posicion geografica del usuario
La aplicacion debera mostrar en un mapa, siempre que disponga de alguna conexion
de red, la posicion geografica del usuario y actualizarla en tiempo real. El usuario
podra manipular el mapa mediante zooms y desplazamientos y volver a centrarse en
la posicion del usuario apretando a un boton.
Ubicar en el mapa hornos cercanos
La aplicacion debera mostrar en el mapa, nada mas cargar la aplicacion, todos los
hornos que estan proximos al usuario en un radio de 2 kilometros.
Ubicar en el mapa hornos por distancia
Existira una pantalla donde se podra seleccionar en cualquier momento una distancia
no mayor de 100 kilometros y, al presionar un boton, se mostraran en el mapa todos
los hornos que esten a una distancia del usuario igual o menor a la seleccionada.
Mostrar ruta hasta el horno seleccionado
El usuario podra seleccionar cualquiera de los hornos mostrados en el mapa y ver la
ruta a seguir para llegar hasta a el. El punto de inicio de la ruta podra ser la ubicacion
actual del usuario o una direccion postal introducida por el.
Mostrar lista de hornos
38
La aplicacion debera mostrar en una pantalla el listado de hornos organizado por
provincias, comarcas y poblaciones.
Ubicar en el mapa un horno de la lista
El usuario podra mostrar en el mapa cualquiera de los hornos de la lista de manera
independiente.
Mostrar datos de interes de cualquier horno
El usuario debera poder consultar en una misma pantalla todos los datos disponibles
del horno que seleccione.
Telefonear a cualquier horno de la lista
El usuario debera poder telefonear al horno que seleccione sin marcar su numero de
telefono, unicamente presionando un boton.
3.2. Requisitos no funcionales
Siguiendo el esquema del apartado anterior, en este punto detallaremos los requisitos no
funcionales.
Version del sistema operativo
La aplicacion debera funcionar en todos los dispositivos Android que tengan instalada
la version 2.3.3 (o superior) del sistema operativo. En dispositivos iPhone, la aplicacion
debera funcionar en todos aquellos que tengan la version 5.0 de iOS, o superior.
Acceso a la aplicacion
La aplicacion debera poder descargarse gratuitamente desde las plataformas de dis-
tribucion oficiales de Google y Apple: Google Play y App Store respectivamente.
Idioma
La aplicacion debera estar disponible al menos en catalan.
Lenguaje de programacion
39
La aplicacion Android estara desarrollada en Java, mientras que la version para iOS
estara desarrollada en objective-C.
Tiempos de carga
Con el fin de hacer que la aplicacion sea los mas agil posible, se minimizaran los
tiempos de carga. Esto implica reducir sobre todo los accesos a la base de datos y al
fichero pList que contiene la informacion de los hornos.
Aplicacion de mapas
Para poder indicar las rutas, el dispositivo movil debera tener instalada la aplicacion
de mapas que viene por defecto en el sistema operativo.
Tarjeta SIM
Para poder hacer uso de la funcion de telefonear a los hornos, el dispositivo movil
debera tener insertada una tarjeta SIM operativa.
3.3. Diagrama de estados
En este apartado vamos a mostrar una serie de diagramas de estado que se han hecho para
detallar el comportamiento de las funcionalidades basicas, de las diferentes pantallas y la
navegacion entre ellas.
3.3.1. Inicio de la aplicacion
A continuacion detallamos los procesos que la aplicacion lleva a cabo cuando empieza a
ejecutarse.
40
Inicializar aplicación
[Si es la
primera vez]
Cargar BBDD
Pantalla Mapa
Error
Mostrar Posición
Mostrar Hornos Cercanos
[Si localización
no disponible]
[Si localización
disponible]
[Si no es la
primera vez]
Figura 17: Diagrama de estados de inicio de la aplicacion
Cargar BBDD
Todos los datos de los hornos de los que dispone la aplicacion se encuentran en un
fichero formato pList que fue proporcionado por el grupo de hornos. Acceder a estos
datos directamente es un proceso lento, por lo que se ha optado por almacenarlos
durante la primera ejecucion en una base de datos y leerlos desde ahı en el futuro.
Inicializar Aplicacion
En esta fase se ponen en marcha los servicios de localizacion del dispositivo movil y
se inicializan los objetos necesarios para poder leer la base de datos.
Mostrar Posicion
Este proceso es el encargado de determinar las coordenadas actuales del dispositivo y
representarlas en el mapa.
Mostrar Hornos Cercanos
Una vez obtenida la posicion del dispositivo se accede a la base de datos en busca
de todos aquellos hornos que estan cerca del usuario, concretamente a una distancia
41
no superior a 2 kilometros. Una vez se obtiene la lista de hornos que cumplen con el
requisito se muestra un marcador para cada uno de ellos en la pantalla del mapa.
3.3.2. Esquema general de la aplicacion
A continuacion se muestra un par de esquemas para entender la navegacion en funciona-
miento general de la aplicacion. En la figura 18 se muestra la navegacion entre pantallas.
Pantalla Mapa
Pantalla Lista
Hornos
Pantalla Hornos
Distancia
Pantalla Vista
Horno
Figura 18: Navegacion entre pantallas desde el menu
Al ejecutarse la aplicacion en primer lugar aparecera la pantalla Mapa. Haciendo uso del
menu podremos desplazarnos libremente por tres pantallas: Mapa, Lista Hornos y Hornos
Distancia. Ademas desde lista podremos ver la pantalla Vista Horno, que al mostrarse ocu-
para el lugar de Lista Hornos en el menu. Esto significa que podremos movernos libremente
entre Mapa, Vista Horno y Hornos Distancia. Para volver a la lista habra que situarse en
Vista Horno y retroceder a la lista. En la proxima seccion veremos en detalle el funciona-
miento de la pantalla Lista Horno para entenderlo mejor.
42
El siguiente esquema muestra la ubicacion de las funcionalidades en las distintas panta-
llas y como nos desplazamos por la aplicacion a traves de ellas.
Mostrar Ruta
Pantalla Mapa
Mostrar PosiciónMostrar Hornos
Cercanos
Seleccionar
marcador
Mostrar Datos Horno
Pantalla Lista Hornos
Pantalla Vista HornoPantalla Hornos
Distancia
Mostrar Horno Seleccionado
Telefonear al Horno
Mostrar Hornos por Distancia
Seleccionar
distancia
Seleccionar
horno
Figura 19: Esquema general de la aplicacion
Pantalla Mapa
Esta es la primera pantalla que cargara la aplicacion. Ademas al hacerlo se mostrara un
marcador indicando la posicion de cada uno de los hornos que hay cerca de la posicion
geografica del dispositivo. Esa posicion sera visible en todo momento (siempre que sea
posible calcularla) y se podra centrar el mapa en ella pulsando un boton. Por ultimo
podremos ver la ruta a alguno de los hornos que este mostrandose en ese momento.
Esta ultima funcion dejara la aplicacion ejecutandose en segundo plano y mostrara la
aplicacion de mapas del sistema operativo con la ruta trazada.
43
Pantalla Lista Hornos
La unica funcion de esta pantalla sera navegar por la lista de hornos y seleccionar
uno, que se mostrara en la Pantalla Vista Horno
Pantalla Vista Horno
Esta pantalla se abrira despues de seleccionar un horno de la lista. Contendra toda
la informacion del horno y permitira pulsar un boton para mostrarlo en el mapa (en
cuyo caso cargara la Pantalla Mapa con un marcador indicando la posicion del horno).
Tambien existira otro boton para telefonear al horno, lo que dejara la aplicacion en
segundo plano y marcara el numero de telefono con la aplicacion predeterminada del
sistema operativo.
Pantalla Hornos Distancia
Esta pantalla permitira indicar una distancia y pulsar un boton para mostrar todos
los hornos de la lista que haya a una distancia igual o menor a la seleccionada. Al
pulsar el boton se abrira la Pantalla Mapa con un marcador para cada uno de los
hornos que han cumplido el requisito de la distancia.
3.3.3. Mostrar y telefonear a un horno de la lista
Ahora vamos a detallar la manera de seleccionar un horno de la lista. Al seleccionarlo
iremos a la pantalla Vista Horno y habran dos botones para mostrar el horno en el mapa
o telefonearlo.
Antes de empezar a describir esta funcionalidad es necesario entender como esta disenada la
lista de hornos. Como ya hemos comentado, cuando ejecutamos por primera vez la aplicacion
se lanza un proceso que lee los datos de los hornos de un fichero pList y los introduce en la
base de datos. Ası pues antes de llegar a la Pantalla Lista Hornos disponemos de una base de
datos con los atributos de cada horno. Para facilitar la localizacion del horno deseado dentro
de la lista se han utilizado algunos de estos atributos para agrupar los hornos, concretamente
los relacionados con su ubicacion: provincia, comarca y poblacion. Ahora debemos imaginar
44
la lista como si de un arbol se tratase, de forma que seleccionando uno de los nodos de cada
nivel pasamos a ver el siguiente, tal y como se muestra en la figura 20 :
Provincia 1 Provincia 2 Provincia n
Comarca 1.1
Población 1.1.1
Horno 1.1.1.1
Nivel 1
Nivel 2
Nivel 3
Nivel 4
Comarca 1.2 Comarca 1.n
Población 1.1.2 Población 1.1.n
Horno 1.1.1.2 Horno 1.1.1.n
Pantalla Vista
Horno
Pantalla Lista Hornos
Figura 20: Esquema de la Pantalla Lista Hornos
Ası pues en esta pantalla el objetivo es ir nivel a nivel hasta llegar a un subconjunto de
hornos elegido en funcion del nodo seleccionado en cada nivel. Una vez pulsamos sobre un
horno del subconjunto cambiaremos a la Pantalla Vista Horno y allı habra dos botones: uno
para telefonear al horno y el otro para mostrar su marcador en el mapa. El funcionamiento
se resume con el diagrama de la figura 21 :
45
Pantalla Lista
Hornos
Pantalla Lista
Hornos
Pantalla Lista
Hornos
Pantalla Lista
Hornos
Pantalla Vista
Horno
Pantalla Mapa
Mostrar Horno Seleccionado
Telefonear al Horno
Provincia Comarca Población Horno
Atrás Atrás Atrás Atrás
Figura 21: Diagrama de estados mostrar y telefonear horno
3.4. Diagramas de secuencia
En esta seccion vamos a disenar los diagramas de secuencia de las funcionalidades mas
importantes de la aplicacion. Mostraremos las relaciones entre las clases y los metodos que
se ejecutan en cada momento. Es necesario tener en cuenta que las dos aplicaciones de este
proyecto (iOS y Android) no tienen las mismas clases. Esto es debido a que las librerıas del
SDK de una y otra tecnologıa permiten hacer las cosas de manera diferente. Una misma
funcionalidad puede resultar mas sencilla de implementar gracias al uso de estas librerıas y
requerir menos lıneas de codigo, dando como resultado una organizacion diferente de clases.
Es importante destacar que estas diferencias en ningun momento han perjudicado ni a la
claridad del codigo ni a la posible reusabilidad del mismo. En el siguiente capıtulo veremos la
implementacion con mas detalle, ahora unicamente nos interesa conocer esto para entender
los diagramas de secuencia que vienen a continuacion.
La siguiente figura muestra la equivalencia entre los nombres de las clases que vamos a
utilizar en los diagramas y las clases que aparecen en las aplicaciones.
46
Capa Nombre genérico iOS Android
CtrlMapa
CtrlLista
CtrlHorno
CtrlProximos
VistaMapaController FornsIGPActivity
LlistatFornController
VistaFornController
FornsProximsController
LlistatActivity
VistaFornActivity
FornsProximsActivity
Capa de presentación
Capa de negocio Horno
GestorAplicación
GestorLocalización
Forn
AppDelegate
CoreLocation.framework
Forn
GestorAplicacion
GestorLocalizacion
ProcesadorUbicacion
Localizador
LocationWaiter
Capa de datos DBObject
CoreDataDelegate
FornDAO
XMLPListParser
DataBaseCreator
DataBaseInit
Marcador DisplayMap BalloonMap
GestorBBDD GestorBBDD
CoreData.framework
Figura 22: Equivalencia de clases
El nombre generico de las clases que vemos en la figura 21 sera el utilizado el los diagramas.
Las clases que aparecen agrupadas lo estan porque su funcionamiento es totalmente equi-
valente. Por eso es posible asignarles un unico nombre generico para los diagramas y ganar
ası claridad en estos. Senalar tambien que las clases escritas en azul son librerıas del SDK.
47
3.4.1. Inicio de la aplicacion
loop
GestorBBDD
loop
GestorLocalización
opt
Usuario<<Actor>>
:CtrlMapa
inicio
GestorAplicación
inicializarAplicacion()inicializarBBDD()
:DBObject
new()
leerPList()
insertarHornos()
inicializarLocalizacion()
[ 1ª vez ]
getLocation()
locdraw(loc)
[ TRUE ]
obtenerHornosDistancia(2)
listaHornos
m:Marcador
new(h) [ ! h ∈ listaHornos ]
draw(m)
Figura 23: Diagrama de inicio de la aplicacion
48
Cuando el usuario inicia la aplicacion se carga automaticamente la Pantalla Mapa como
pantalla de inicio y su clase responsable es CtrlMapa. Automaticamente se llama al metodo
inicializarAplicacion() de la clase estatica GestorAplicacion. Este metodo realiza las tareas
que son necesarias para poner a punto el programa. En primer lugar se inician los objetos
de la base de datos mediante el metodo inicializarBBDD() de la clase GestorBBDD. Este
crea un nuevo objeto DBObject, que ademas de poner a punto la BBDD lee el fichero
pList y guarda los datos de los hornos en la base de datos si es la primera vez que se
ejecuta la aplicacion. Acto seguido GestorAplicacion inicializara los objetos que se encargan
de obtener la localizacion geografica con el metodo inicializarLocalizacion() de la clase
GestorLocalizacion. Acto seguido CtrlMapa lanza un proceso asıncrono que ira solicitando la
posicion a GestorLocacion con el metodo getLocation() y la indicara en el mapa. Finalmente
llamara al metodo obtenerHornosDistancia() de GestorBBDD con el valor 2 para obtener
la lista de hornos que estan a menos de 2 kilometros de distancia y creara un marcador
para cada uno de ellos que dibujara en el mapa. La aplicacion restara a la espera de que el
usuario ejecute nuevas acciones.
49
3.4.2. Mostrar Horno Seleccionado
:CtrlHorno
loop
Usuario<<Actor>>
:CtrlLista
ir a la listanivel := 1
alt
[ nivel < 5 ]
GestorBBDD
obtenerProvincias()
lista
obtenerComarcas(s)
obtenerPoblaciones(s)
obtenerHornos(s)
[ nivel = 1 ]
[ nivel = 2 ]
[ nivel = 3 ]
[ nivel = 4 ]
mostrar(lista)
elegir ítem snivel ++
h:Horno
new(s)
new(h)
presionar "Mostrar en mapa"
:CtrlMapa
dibujarHorno(h)
m:Marcador
new(h)
draw(m)
Figura 24: Diagrama mostrar horno seleccionado
En primer lugar el usuario debe dirigirse a la Pantalla Lista Hornos a traves del menu de
la aplicacion. Como se vio en el capıtulo anterior, esta pantalla funciona como un arbol y
cada vez que avanzamos por los niveles del arbol los nodos cambian, cosa que se ve reflejada
en los ıtems que muestra la lista. Nada mas cargar la pantalla se establece el valor de
50
la variable nivel a 1. Cada vez que el usuario selecciona un ıtem incrementa este nivel y
cambian los valores de la lista. Estos valores se solicitan a la clase GestorBBDD con los
diferentes metodos que vemos en el diagrama. Cuando el valor de nivel es igual a 4 los
ıtems de la lista seran los nombres de los hornos. Si el usuario selecciona uno creara un
objeto de la clase Horno con el valor que ha seleccionado y se llamara al controlador de la
Pantalla Vista Horno, CtrlHorno, para cargar la pantalla con los valores del objeto Horno.
Acto seguido, cuando el usuario presione un boton, invocara el metodo dibujarHorno() de
CtrlMapa pasando como valor el objeto Horno. En ese instante se mostrara esta pantalla en
primer plano, creara un objeto Marcador con los valores del objeto Horno y lo dibujara en
el mapa.
3.4.3. Telefonear al Horno
El proximo diagrama comparte codigo con el diagrama de la figura 24 hasta la marca de
color amarillo, ası que para no repetir informacion vamos a considerar que este diagrama
comienza desde la citada marca.
:CtrlHornoUsuario
<<Actor>>:CtrlLista
new(h)
presionar "Telefonear"
Sistema Operativo
apiTelefonear(h.telf)
AppTelefono
marcar
Figura 25: Diagrama telefonear a un horno
Como ya se ha comentado, este diagrama comparte la misma logica que el diagrama de
51
la figura 24 hasta el momento en el que el usuario debe pulsar uno de los dos botones
de la Pantalla Vista Horno. En este caso, si el usuario presiona el boton encargado de
ejecutar la funcion para telefonear, el CtrlHorno recoge la accion y lanza una llamada
al sistema operativo para que ejecute la aplicacion que por defecto se encarga de realizar
llamadas telefonicas. Una vez finalizada la llamada telefonica el control lo recupera el sistema
operativo y el usuario sera libre de realizar cualquier otra accion. Nuestra aplicacion no se
habra cerrado, seguira ejecutandose en segundo plano a la espera de que el usuario vuelva
a necesitarla.
52
3.4.4. Mostrar Hornos Distancia
loop [ ! h ∈ lista ]
loop
alt
Usuario<<Actor>>
:CtrlProximos
ir a la pantalla
elegir distancia
<< d := distancia >>pulsar botón
:DBObjectGestorBBDD
obtenerHornosDistancia(d)obtenerTodos()
listaTodos
GestorLocalización
getLocation()
loc
lista := null
[ ! h ∈ listaTodos ]
dH := distancia entre loc y h
[ "#$≤$" ]lista.add(h)
lista
:CtrlMapa
dibujarHornos(lista)
dibujarHorno(h)
Figura 26: Diagrama mostrar hornos segun distancia
Para realizar esta funcionalidad el usuario debe ir a traves del menu a la Pantalla Hornos
Distancia. Allı debera seleccionar una distancia y darle a un boton. En ese momento CtrlPro-
ximos capturara la accion y lanzara el metodo obtenerHornosDistancia del GestorBBDD,
pasandole como parametro la distancia seleccionada. Para discernir que hornos estan a una
distancia igual o menor a la seleccionada, en primer lugar obtendra todos los hornos existen-
tes en la base de datos mediante el metodo obtenerTodos() de la clase DBObject. Tambien
53
necesitara la localizacion actual del dispositivo, que la obtendra del GestorLocalizacion.
Cuando tenga las dos cosas entrara en un bucle y comparara, para cada horno, la distancia
que hay entre el dispositivo movil y el horno con la distancia que ha seleccionado usuario.
Todos los hornos que esten a una distancia igual o menor los anadira a una lista. Finalmente
se pasara esa lista a CtrlMapa y allı se ejecutara el metodo dibujarHorno() para cada horno,
cuyo funcionamiento ya hemos visto en el diagrama de la figura 24.
3.4.5. Mostrar Ruta
El siguiente diagrama parte del estado en el cual hay marcadores de hornos en el mapa. A
esta situacion se puede llegar despues de los diagramas de las figuras 23, 24 o 26.
alt
GestorLocalizaciónUsuario
<<Actor>>:CtrlMapa
inicio
indicar dirección inicio (addr)
indicar posición actual como inicio getLocation()
inicio := null
inicio := addr
locinicio := loc
:Marcardor
getCoordenadas()
destino
URL := << formar URL con inicio y destino >>
Sistema Operativo
llamadaSO(URL)
Aplicación de mapas
abrirApp(URL)
presionar botón
elegir marcador
mostrarPanelRuta()
Figura 27: Diagrama mostrar ruta
54
La primera accion que debe realizar el usuario es seleccionar el marcador que senala al
horno donde desea ir. En ese instante el CtrlMapa mostrara un panel donde podra indicarse
el origen de la ruta y un boton para ejecutar la funcionalidad. El usuario podra indicar
cualquier direccion postal como inicio de la ruta o bien dejar por defecto la ubicacion
actual del dispositivo. Si elige esta segunda opcion CtrlMapa pedira a GestorLocalizacion
la ubicacion mediante el metodo getLocation(). Si por contra prefiere indicar una direccion
la aplicacion la transformara en coordenadas que usara como inicio de la ruta. Cuando el
usuario presione el boton para ver la ruta, CtrlMapa obtendra del marcador las coordenadas
del horno y las usara como destino. Despues compondra una direccion URL con el inicio y
el destino y se la lanzara al sistema operativo, que traducira la URL y abrira la aplicacion
de mapas que tenga por defecto (Google Maps en Android y Maps en iOS) y dibujara la
ruta. Al igual que ocurrıa en la funcionalidad Telefonear al Horno, la aplicacion quedara en
segundo plano a la espera de que el usuario vuelva a necesitarla.
55
Capitulo 4
4. Implementacion
En este capıtulo dejamos atras todas aquellas tareas que son responsabilidad del arquitecto
de software y vamos a entrar en el detalle de la estructura de clases, su diseno y las funciones
de cada una de ellas, es decir, lo que ha sido el trabajo del programador.
En primer lugar es importante diferenciar la implementacion de la aplicacion iOS de la
implementacion de la aplicacion Android, puesto que ambas tienen diferencias importantes
en su codigo, mas alla de lo que serıan las diferencias vinculadas al propio lenguaje de pro-
gramacion. Por ello primero describiremos la implementacion en iOS, luego en Android y
finalmente senalaremos las diferencias mas notorias entre ambas y analizaremos cuanto han
ayudado los respectivos SDKs a la hora de implementar.
4.1. Implementacion en iOS
Esta implementacion se ha llevado a cabo en el entorno Xcode y el lenguaje utilizado para
el desarrollo ha sido Objective-C.
Si observamos la figura 28, podemos ver las diferentes capas que componen la aplicacion y
como quedan emplazadas dentro de ellas las clases desarrolladas. Tambien incluiremos las
librerıas del SDK de iOS que han sido necesarias para el desarrollo de esta aplicacion.
56
Capa Clase/Objeto
VistaMapaController
LlistaFornController
VistaFornController
FornsProximsController
Capa de gestión
Forn
AppDelegate
CoreLocation.framework
Capa de datos
CoreDataDelegate
Marcador
CoreData.framework
Origen
Interfaz MainStoryboard.storyboard Desarrollado
Desarrollado
Desarrollado
Desarrollado
Desarrollado
Desarrollado
Desarrollado
Desarrollado
iOS SDK
Desarrollado
Librerías del sistema UIKit.framework iOS SDK
iOS SDK
CoreGraphics.framework iOS SDK
Foundation.framework iOS SDK
ModeloDeDatos.xcdatamodeld Desarrollado
MapKit.framework iOS SDK
Figura 28: Clases aplicacion iOS
4.1.1. Librerıas del sistema
Estas tres librerıas contienen las clases y las funcionalidades mas basicas de un proyecto
iOS. Componen el nucleo de cualquier aplicacion.
CoreGraphics.framework
Es una librerıa desarrollada en C basada en el motor de graficos Quartz, que proporciona
mecanismos para el renderizado a bajo nivel de graficos en 2D. Se encarga entre otras co-
sas del dibujo de los graficos, transformaciones, coloreado, paletas, degradados y matices,
muestra de imagenes e incluso de archivos PDF.
Foundation.framework
57
Esta librerıa define la capa base sobre la que se sustentan las clases de Objective-C. Propor-
ciona un conjunto de objetos primitivos e introduce paradigmas no cubiertos originariamente
por el propio lenguaje con el objetivo de facilitar el desarrollo en Objective-C y favorecer
la portabilidad.
Foundation.framework incluye los objetos raız de la jerarquıa de clases y aquellas clases que
representan los tipos de datos basicos, como los strings, los arrays de bytes o las colecciones
de objetos.
De entre las clases que han servido para desarrollar esta aplicacion, podemos destacar las
siguientes:
NSObject: Es la clase raız de la mayorıa de clases en Objective-C. A traves de esta
clase se heredan los mecanismos necesarios para convertirse en un objeto de Objective-
C y ser tratado como tal en tiempo de ejecucion. Entre sus metodos podemos destacar
alloc, que reserva espacio en memoria para el objeto; init, que lo inicializa y finalize,
que prepara el objeto para ser liberado en memoria.
NSString: En Objective-C NSString es la clase que se utiliza para definir cadenas
de texto Unicode. Proporciona los metodos habituales para trabajar con este tipo
de objetos pero no permite modificar su valor una vez le ha sido asignado. Para ello
deberıamos usar su subclase NSMutableString.
NSException: Esta clase se usa para el control de excepciones y contiene toda la
informacion del error que se ha producido.
NSArray: Es la clase que permite manejar colecciones de objetos. NSArray solo
permite colecciones estaticas, es necesario definir su tamano antes de utilizarlas. Para
poder modificar la longitud de la coleccion se requiere el uso de su subclase NSMuta-
bleArray.
UIKit.framework
Esta librerıa proporciona las clases necesarias para la construccion y el manejo de la interfaz
58
grafica de la aplicacion. Se encarga de facilitar los mecanismos que controlan la aplicacion,
el manejo de eventos, la estructura de ventanas, los objetos basicos para el uso de interfaces
tactiles, etc.
La interfaz de esta aplicacion usa varias de estas clases. A continuacion se destacan las mas
importantes:
UIEvent / UIResponder: Un objeto UIEvent representa un evento del sistema iOS.
Estos eventos pueden ser de tres tipos: tactiles (aquellos que se producen al tocar la
pantalla), de control remoto (aquellos producidos por accesorios externos al terminal)
o de movimiento (los producidos por el movimiento del dispositivo, por ejemplo por un
acelerometro). Estos objetos envıan toda la informacion a los objetos UIResponder
que esten a la escucha, que trataran el evento e informaran a la aplicacion que se
ha producido. En realidad UIResponder no es un objeto, es una interfaz que deben
heredar e implementar aquellos objetos que quieran reaccionar a eventos, como los
que veremos a continuacion.
UIView: Todas las pantallas de la aplicacion desarrollada contienen un UIView o
algun objeto que lo hereda. Esta clase define un area rectangular en la pantalla y los
mecanismos para manejar los objetos que puede contener. Se encarga de renderizar
cualquier contenido que haya en este area y de manejar sus eventos. De entre las
clases que la heredan podemos destacar UILabel, que es un rectangulo con texto,
UIImageView, que contiene una imagen o UIControl, que veremos ahora.
UIControl: La clase UIControl es aquella de la que heredan todos los controles con los
que podemos interactuar en una interfaz tactil iOS. No es posible instanciar objetos
UIControl puesto que se trata de una interfaz, por lo que es necesario crear clases
que la implementen. Esta librerıa ya nos proporciona los controles basicos que puede
necesitar una aplicacion, como los botones, sliders, campos de texto, etc.
UIViewController: Esta clase proporciona los mecanismos para manejar vistas o
conjuntos de vistas (tambien conjuntos de UIViewController). Funciona por detras
59
de los objetos UIView y se encarga entre otras cosas de recoger la interaccion del
usuario, redimensionar o reorientar las vistas y redistribuir los controles que contienen.
Todo UIView requiere de un UIViewController. En nuestra aplicacion ademas de
UIViewController se usan objetos que lo heredan. En primera lugar, para darle al
conjunto de la aplicacion una distribucion de pantallas accesibles por pestanas se ha
utilizado un objeto UITabBarController que se encarga de toda la logica relacionada
con esta funcion, ası que es el objeto del que dependen el resto de pantallas. Tambien
se ha utilizado un UINavigationController para el movimiento a traves de los niveles
de la Pantalla Lista Hornos y un UITableViewController para mostrar e interactuar
con la propia lista.
4.1.2. Interfaz
La implementacion de la interfaz en iOS 5 esta basada en ficheros .storyboard. Este fichero
no es mas que un fichero XML pero que mediante el Interface Builder de Xcode se permite
su diseno de una manera grafica. Los .storyboard son especialmente utiles en aplicaciones
multipantalla, puesto que no unicamente especifican las pantallas de la aplicacion y los ob-
jetos que contienen, tambien incluyen las relaciones entre pantallas e indican de que manera
se realizan las transiciones. Por poner un ejemplo, podemos arrastrar un boton dentro de
una pantalla y crear una relacion con otra pantalla. La relacion hara que al presionar el
boton de la primera pantalla se muestre la segunda sin necesidad de codigo extra. Esto
simplifica mucho el diseno de este tipo de interfaces y reduce el codigo de la aplicacion.
A continuacion, en la figura 29, podemos ver un ejemplo de transicion en el storyboard
de nuestra aplicacion, concretamente la relacion que existe entre el objeto que controla las
pestanas y la Pantalla Mapa.
60
Figura 29: Ejemplo de transicion en storyboard
Al disponer de una herramienta tan potente para el desarrollo de interfaces, la aplicacion
no ha requerido ni clases ni metodos extra para controlar el flujo de la aplicacion y todo lo
necesario esta contenido en el fichero MainStoryboard.storyboard.
MapKit.framework
Esta librerıa contiene los objetos necesarios para trabajar con mapas. El mas importante, y
el que ha sido utilizado en la Pantalla Mapa, es el MKMapView, que es un tipo de UIView
que situa en la pantalla un mapa que funciona gracias a la API de GoogleMaps. Tambien
proporciona metodos y propiedades para hacer zoom sobre el mapa, situar marcadores,
cambiar el tipo de vista e incluso para mostrar la localizadion geografica dentro del mapa
(siempre que sea posible obtenerla).
61
4.1.3. Capa de gestion
En esta capa encontramos todos las clases necesarias para tratar los eventos producidos en
la interfaz, tratarlos, hacer los calculos necesarios y devolver la informacion que el usuario
necesita.
VistaMapaController
Esta clase es la encargada del funcionamiento de la Pantalla Mapa. Se encarga principal-
mente de representar el mapa y permitir que el usuario interactue con el de una forma
sencilla y comoda. Tambien se encarga de tratar los eventos producidos en los botones,
en el mapa y sus marcadores. A continuacion se muestra un listado con sus metodos mas
importantes.
Metodo Descripcion
mostrarUbicacion() Este metodo recibe las coordenadas, el nombre y la direccion
del horno y coloca un marcador en el mapa indicando su
ubicacion.
findme() Centra el mapa en la posicion geografica del dispositivo.
borrarAnotaciones() Borra del mapa todos los marcadores de los hornos y deja
visible unicamente el indicador de la posicion geografica del
dispositivo.
mostrarRuta() Muestra la ruta has a el horno que haya seleccionado.
addressToCoordinate() Transforma una direccion postal en coordenadas geograficas.
62
mostrarHornosDistancia() Dibuja en el mapa los marcadores de los hornos situados a una
distancia igual o menor a la seleccionada.
Marcador
Esta clase hereda de la clase MKAnnotation de la librerıa MapKit.framework. Sirve para
representar un objeto marcador y poder situarlo en el mapa. No tiene metodos, tan solo
tres atributos para indicar las coordenadas del horno, su nombre y direccion.
LlistaFornController
Esta clase se encarga del funcionamiento de la Pantalla Lista Hornos. Se encarga de mostrar
los datos que corresponden en cada nivel de la lista y de gestionar los eventos tactiles que
produce. Estos son sus principales metodos:
Metodo Descripcion
initWithDepth() Este metodo inicializa la lista indicando el nivel en el que se
encuentra y cargando los datos que corresponden a ese nivel.
didSelectRowAtIndexPath() Es necesario sobreescribir este metodo de la clase UITableView
para capturar el evento que se lanza cuando el usuario pulsa
una celda de la lista. En nuestra aplicacion su funcion es cargar
una nueva lista aumentando el nivel siempre y cuando no nos
encontremos en el nivel maximo, de ser ası, abre la Pantalla
Vista Horno.
VistaFornController
Es la clase encargada del funcionamiento de la Pantalla Vista Horno. Su funcion es mostrar
los datos del horno y capturar los eventos de los botones. Sus metodos principales son:
63
Metodo Descripcion
initWithForn() Sirve para iniciar el objeto con los datos del horno.
mostrarAlMapa() Este metodo pasa los atributos del horno al objeto VistaMapa-
Controller para que coloque un marcador y cierra la Pantalla
Vista Horno para mostrar el mapa.
llamarPorTelefono() Se encarga de realizar la llamada al sistema operativo para que
el telefono marque el numero del horno. En la siguiente figura se
muestra su codigo como ejemplo de interaccion directa con iOS:
FornsProximsController
Es la clase que se encarga del funcionamiento de la Pantalla Hornos Distancia. Gestiona los
eventos del objeto tipo slider que sirve para seleccionar una distancia y de un boton. Sus
metodos mas importantes son:
64
Metodo Descripcion
seleccionarKM() Es el metodo que captura el evento del slider. Actualiza los
kilometros en pantalla y los guarda en una variable.
mostrarHornosDistancia() Es el metodo que captura la pulsacion del boton. Le pasa al
objeto VistaMapaController la distancia seleccionada para que
dibuje los marcadores de los hornos.
Forn
Esta clase es la que representa a un horno. Contiene todos los atributos necesarios para
trabajar con ellos en esta aplicacion: nombre, direccion, telefono, coordenadas... Es una
subclase de NSManagedObject, que es una clase generica que aporta todo el comportamien-
to necesario para facilitar el almacenamiento de estos objetos en base de datos. Necesita
que en el modelo de datos, que veremos en la capa de datos, exista una entidad asociada
con el mismo nombre.
CoreDataDelegate
Es la clase estatica encargada de inicializar y realizar los accesos a la base de datos. Su fun-
cionamiento esta basado en los metodos que proporciona la librerıa CoreData.framework y
requiere del modelo de datos. Sus metodos mas destacados son los siguientes:
65
Metodo Descripcion
initCoreData() Inicializa la base de datos y, si no existe por ser la primera eje-
cucion, crea una base de datos .sqlite.
leerPList() Es el encargado de leer el fichero pList que contiene la informa-
cion de los hornos y de insertarlos en la base de datos.
obtenerProvincias() Devuelve las diferentes provincias que hay en la base de datos.
obtenerComarcas() Devuelve las diferentes comarcas dada una provincia determina-
da.
obtenerPoblaciones() Devuelve las diferentes poblaciones dada una comarca determi-
nada.
obtenerForns() Devuelve los hornos de una poblacion determinada.
obtenerTodos() Devuelve todos los hornos que hay en la base de datos.
Los metodos que devuelven datos de la bbdd tienen todos el mismos esquema. En la figura
30 podemos ver el codigo del metodo obtenerComarcas().
66
Figura 30: Metodo obtenerComarcas
AppDelegate
Esta es una clase que se genera automaticamente al iniciar un proyecto iOS y que contiene
los metodos que capturan los eventos relacionados con el ciclo de vida y los estados de
la aplicacion. Para la aplicacion desarrollada unicamente ha sido necesario implementar el
metodo que se lanza cuando el sistema operativo ha terminado de lanzar la aplicacion. En
ese momento llamamos al metodo initCoreData() de la clase CoreDataDelegate.
CoreLocation.framework
Esta librerıa contiene los metodos necesarios para trabajar con coordenadas y obtener la
posicion geografica del dispositivo en un momento determinado. De entre sus clases, las que
han sido necesarias en este proyecto han sido las siguientes:
CLLocation
Representa un conjunto de coordenadas geograficas.
67
CLLocationManager
Permite obtener la localizacion actual del dispositivo, comprobar si el hardware para
obtenerla esta disponible y establecer los criterios de obtencion de la misma (frecuencia
de actualizacion, metodo de obtencion, precison...)
4.1.4. Capa de datos
En esta capa vemos los objetos mas basicos relacionados con el almacenamiento de datos.
CoreData.framework
Esta librerıa proporciona los mecanismos necesarios para el manejo y la persistencia de
datos en iOS. Aunque soporta varios formatos de archivos para su almacenamiento, para
nuestra aplicacion se ha optado por el uso de una base de datos SQLite. Las clases mas
importantes que se han utilizado han sido las siguientes:
NSFetchRequest
Se utiliza para establecer los criterios de obtencion de los datos. Serıa el equivalente
a construir una consulta SQL.
NSManagedObject
Su funcion es crear un objeto en el modelo logico equivalente a una tabla de la base
de datos. De esta manera podemos trabajar directamente con dicho objeto y luego
guardar los cambios que en el se han producido.
NSFetchedResultsController
Es un contenedor de datos en el que se guardan los resultados obtenidos despues de
realizar una consulta a la base de datos.
ModeloDeDatos.xcdatamodeld
Este fichero representa el esquema de la base de datos. En el se especifican las tablas, sus
68
atributos y relaciones. Para la aplicacion desarrollada tan solo ha sido necesaria una tabla
para representar a los hornos:
Figura 31: Esquema Forn en ModeloDeDatos
Como podemos ver se han definido ocho atributos, todos ellos de tipo texto.
Atributo Funcion
nom Es el nombre comercial del horno.
adreca Direccion postal del horno.
telefon Telefono del horno. Necesario para la funcion Telefonear al Horno.
provincia Provincia del horno. Consultado en el primer nivel de la lista.
comarca Comarca del horno. Consultado en el segundo nivel de la lista.
poblacio Municipio al que pertenece el horno. Consultado en el tercer nivel
de la lista.
latitud / longitud Coordenadas del horno. Utilizadas para situar su marcador en el
mapa.
4.2. Implementacion en Android
La implementacion de la aplicacion en su version Android se ha llevado a cabo en java. Al
igual que hicimos en el apartado anterior, vamos a ver un esquema con las clases que han
sido necesarias organizadas por capas, incluyendo tambien las librerıas externas.
69
Capa Clase/Objeto
FornsIGPActivity
LlistatActivity
VistaFornActivity
FornsProximsActivity
Capa de gestión
Forn
GestorAplicacion
Capa de datos
GestorBBDD
BalloonMap
Origen
Interfaz Archivos XML Desarrollado
Desarrollado
Desarrollado
Desarrollado
Desarrollado
Desarrollado
Desarrollado
Desarrollado
Desarrollado
Librerías del sistema android.jar Android SDK
DataBaseInit Desarrollado
CapaPosicion Desarrollado
XMLPListParser Desarrollado
DataBaseCreator Desarrollado
Capa de localización GestorLocalizacion
Localizador
Desarrollado
Desarrollado
ProcesadorUbicacion
LocationWaiter
Desarrollado
Desarrollado
maps.jar Android SDK
FornDAO Desarrollado
Figura 32: Clases aplicacion Android
4.2.1. Librerıas del sistema
android.jar
Esta librerıa es la liberıa base de todo proyecto Android. Contiene las clases y objetos
principales del entorno Android y las funciones basicas para la gestion de la aplicacion, de
memoria, de datos, de la interfaz grafica, interaccion con el sistema operativo, accesos a los
recursos del telefono movil, etc. Sus clases mas importantes son las siguientes:
Activity
70
Las Activity son el elemento principal de la interfaz grafica en un programa Android.
Son el equivalente a las ventanas en Windows.
View
Representan los controles que pueden colocarse dentro de los Activity. Esta librerıa
nos proporciona un gran numero de views basicos (botones, cuadros de texto, listas...)
pero tambien podemos heredar la clase y crearlos nosotros.
Service
Son componentes sin representacion grafica que se ejecutan en segundo plano. Cum-
plen las mismas funciones que los servicios de otros sistemas operativos: pueden uti-
lizarse para actualizar datos, lanzar notificaciones, mostrar activities, etc.
Content Provider
Es el mecanismo de Android que permite compartir datos entre dos aplicaciones.
Broadcast Receiver
La funcion de estos objetos es detectar eventos producidos por el sistema operativo
(baterıa baja, sms entrante, localizacion actualizada...) o por otras aplicaciones.
Intent
Son mensajes que envıan las aplicaciones Android para comunicarse entre ellas o
incluso para comunicarse entre componentes de una misma aplicacion. Con los intent
es posible ejecutar una aplicacion desde cualquier otra, iniciar un service, enviar un
mensaje broadcast para que lo detecten los broadcast receiver que haya a la escucha,
mostrar un activity desde otro, etc.
4.2.2. Interfaz
La interfaz en Android se disena mediante archivos XML. En ellos se definen los objetos
que se mostraran en pantalla y sus atributos: estilo, posicion, texto, etc...
Segun el IDE con el que se este trabajando tienes la opcion disenar las pantallas con una
71
interfaz grafica.
Los archivos XML que han sido necesarios para el desarrollo de esta aplicacion han sido los
siguientes:
main.xml
Representa el xml principal, el que se lanza en primer lugar y en nuestro caso es la
Pantalla Mapa.
llistat forns.xml
Es el xml que contiene el diseno de la Pantalla Lista Hornos.
vista forn.xml
Contiene el diseno de la Pantalla Vista Horno.
forns proxims.xml
Es el xml de la Pantalla Hornos Distancia.
Otros
Se han necesitado otros xml para definir el menu de pestanas, el aspecto personalizado
de algunos botones o el globo que aparece al presionar un marcador.
4.2.3. Capa de gestion
maps.jar
Esta liberıa contiene los elementos necesarios para trabajar con mapas. Su clase principal es
MapView, que es una pantalla que es un control que contiene un mapa para colocarlo sobre
un activity. Permite establecer el zoom del mapa, colocar algunos botones preestablecidos
sobre el y anadir capas con informacion visual. Tambien es necesario destacar la clase Geo-
Point, que sirve para senalar un punto en el mapa previa transformacion a numeros enteros
de las coordenadas geograficas.
72
FornsIGPActivity
Esta clase es el equivalente a la clase VistaMapaController de iOS. Representa la pantalla
mapa y controla toda interaccion que el usuario realice con ella. Sus metodo mas importantes
son:
Metodo Descripcion
pintarLocalizacion() Este metodo recibe un objeto Forn y coloca su marcador
correspondiente en el mapa.
centrarLocalizacionActual() Centra el mapa y ajusta el zoom sobre la posicion geografi-
ca actual del dispositivo.
reiniciarCapas() Borra del mapa los marcadores.
mostrarRuta() Lanza un intent a la aplicacion de Google Maps para que
dibuje la ruta al horno seleccionado.
obtenerLatitud() / obte-
nerLongitud()
Obtiene la latitud o la longitud de la direccion postal que
se le pase por parametro.
pintarHornosDistancia Recibe una distancia y pinta sobre el mapa los marcado-
res de los hornos que se encuentra a esa distancia como
maximo.
Dada la importancia de los objetos intent en el sistema Android, vamos a ver en la figura 33
el fragmento del codigo del metodo mostrarRuta() donde se lanza el Intent para comunicarse
con la aplicacion Google Maps.
73
Figura 33: Ejemplo de uso de un Intent
LlistatActivity
Esta clase es la encargada de controlar la Pantalla Lista Hornos. Su cometido es el mismo
que la clase LlistaFornController en iOS. Sus metodos a destacar son:
Metodo Descripcion
cargarLista() Este metodo es el responsable de solicitar y mostrar los datos
que deben mostrarse en la lista segun el nivel en el que este.
onItemClick() Este metodo se lanza automaticamente cuando el usuario ha
presionado un elemento de la lista. Su funcion es incrementar
la variable que indica el nivel de la lista y solicitar el cambio
de los datos que se muestran. Si la lista esta en el ultimo
nivel, lanza un intent para que se muestre la Pantalla Vista
Horno.
VistaFornActivity
Es la clase que controla la Pantalla Vista Horno. Sus metodos mas importantes son:
74
Metodo Descripcion
informarValores() Muestra por pantalla los valores del objeto Forn que le han
pasado.
mostrarHorno() Indica a la Pantalla Mapa que debe colocar un marcador del
horno que estamos mostrando.
llamarTelefono() Lanza un intent al sistema operativo con el numero de
telefono del horno para que lo marque en la aplicacion que
realiza las llamadas.
FornsProximsActivity
Es la clase que controla la Pantalla Hornos Distancia. Sus unicos metodos a destacar son:
Metodo Descripcion
onProgressChanged() Es el metodo que se lanza cuando se ha producido el evento
que indica un cambio de valor en el slider de la pantalla. Su
funcion es guardar la distancia en una variable y mostrar la
distancia seleccionada por pantalla.
mostrarHornos() Indica a la Pantalla Mapa que debe colocar un marcador
para cada uno de los hornos que cumplen el requisito de la
distancia seleccionada.
BalloonMap
Esta clase representa los marcadores en la aplicacion Android. Ha sido necesario crear le
marcador desde cero, tanto su apariencia como la deteccion de los eventos que se producen
sobre el. Hereda de la clase abstracta ItemizedOverlay de maps.jar, que son objetos capaces
75
de anadirse como capa a un objeto MapView y ver su representacion grafica en el punto
senalado y tambien detectar cuando el usuario lo presiona. Su metodo mas imporante por
lo tanto es el evento onTap(). Cuando se produce el marcador muestra los datos del horno
en un bocadillo sobre el y lanza un evento que recoge FornsIGPActivity para que muestre
los controles que permiten solicitar una ruta hasta el horno.
CapaPosicion
Esta clase hereda de la clase Overlay de la librerıa maps.jar. Los objetos Overlay permi-
ten dibujar sobre ellos cualquier cosa y luego colocarlos sobre el mapa, de manera que lo
dibujado en ellos se vea superpuesto. En este caso lo utilizamos para mostrar la posicion
geografica del usuario. En su metodo draw obtenemos la localizacion geografica, si es que
ha cambiado desde la ultima vez, y dibujamos un circulo sobre la posicion indicada.
Forn
Es la representacion logica de los hornos. Contiene todos los atributos que conforman un
horno y sus metodos para obtenerlos y editarlos. Tambien contiene un metodo save() para
guardar el objeto Forn en base de datos.
GestorAplicacion
Es una clase estatica encargada de llevar a cabo la funciones basicas de la aplicacion y
contiene los metodos necesarios para controlar las transiciones entre las diferentes pantallas.
Sus metodos mas importantes son:
76
Metodo Descripcion
myOnOptionItemSelected() Es el metodo encargado de dibujar el menu de pestanas
en cada pantalla.
onOptionsItemSelected() Este metodo detecta cuando se ha pulsado un ıtem del
menu de pestanas y lanza un intent para mostrar la pan-
talla que corresponda.
inicializarAplicacion() Se encarga de inicializar la base de datos y tambien el ges-
tor de localizacion (para empezar a detectar la posicion
geografica).
GestorBBDD
Esta clase estatica recoge las peticiones de acceso a base de datos de los objetos de la capa
de gestion y los traslada la clase FornDAO de la capa de datos. Tambien se encarga del
resto de tareas relacionadas con la base de datos. Sus metodos a destacar son los siguientes:
Metodo Descripcion
leerLista() Es el metodo encargado leer los hornos del fichero pList
e insertarlos en la base de datos.
inicializarBBDD() Inicializa los objetos que se encargan de atacar a la base
de datos.
77
obtenerProvincias() Devuelve las diferentes provincias a las que pertenecen
los hornos de la base de datos.
obtenerComcarcas() Devuelve las diferentes comarcas a las que pertenecen los
hornos de una determinada provincia.
obtenerPoblaciones() Devuelve las diferentes poblaciones a las que pertenecen
los hornos de una determinada comarca.
obtenerHornos() Devuelve la lista de hornos que pertenecen a una deter-
minada poblacion
obtenerHornosDistancia() Devuelve la lista de hornos que estan a una determinada
distancia del terminal
XMLPListParser
Es la clase encargada de leer directamente del fichero pList. Su cometido es leerlo como el
fichero xml que es en realidad y colocar las cadenas de texto en una serie de hashtables anida-
das. El objetivo es que la informacion quede bien estructurada para que el GestorBBDD
acceda a ella facilmente.
4.2.4. Capa de localizacion
Esta capa contiene las clases relacionadas con la obtencion de la posicion geograficas del
dispositivo.
GestorLocalizacion
Esta clase estatica se encarga de iniciar el proceso de localizacion. Para ello debe crear un
78
objeto de la clase LocationWaiter y esperar a que este le envıe eventos. Su metodo mas
importante es getLocalizacion(), que devuelve a quien lo llame la ubicacion actual del dis-
positivo.
LocationWaiter
Esta clase se encarga de arrancar un Thread que continuamente consultara las coordena-
das obtenidas por el objeto de la clase Localizador. Si ese objeto pasado un tiempo no ha
obtenido ningunas coordenadas, LocationWaiter enviara un evento al GestorLocalizacion
indicando que no ha sido posible obtener la localizacion actual. Por contra, si devuelve
coordenadas y son diferentes a las que habıa devuelto en algun momento previo, lanzara un
evento indicando que el dispositivo ha cambiado de ubicacion.
Localizador
Esta clase crea los objetos que se utilizan en Android para obtener la localizacion geografica.
Estos objetos son el LocationListener y el LocationManager. Una vez creados, crea tam-
bien un objeto de la clase ProcesadorUbicacion y le pasa por parametro los dos objetos
proveedores. En ese momento iniciara un thread para gestionar los eventos que recoge el
LocationListener, entre los que se encuentra el evento onLocationChanged, que se produce
cuando hay un cambio en la posicion del dispositivo.
ProcesadorUbicacion
Se encarga de inicializar los objetos proveedores de localizacion que le ha suministrado la
clase Localizador y tratar sus eventos para dejar definido el metodo de obtencion de la
ubicacion geografica. En primer lugar establece la busqueda en modo GPS. Si despues de
un tiempo determinado el dispositivo es incapaz de localizar el numero de satelites adecuado
79
para obtener una localizacion GPS, pasa a intentar obtener su posicion con tecnicas a traves
de la red movil.
4.2.5. Capa de datos
En esta capa se encuentran las clases mas ıntimamente ligadas con el manejo de la base de
datos.
DataBaseCreator
Es clase hereda de la clase SQLiteOpenHelper. Su funcion es crear o actualizar la base de
datos. Tiene dos atributos: DATABASE NAME y DATABASE VERSION. En primer lugar
busca un objeto en el sistema de archivos con el nombre DATABASE NAME, si no existe
lo crea y lanza un evento onCreate que recogera la clase DataBaseInit. Si existe y su version
es inferior a DATABASE VERSION, lanza un evento onUpgrade.
DataBaseInit
Esta clase recoge los eventos producidos en DataBaseCreator. Si recibe un evento onCreate,
ejecuta la query que crea la tabla para guardar los datos de los hornos. Si recibe un evento
onUpgrade borra los datos de la tabla para que se vuelvan a leer los datos del archivo pList.
FornDAO
Esta clase es la encargada de lanzar los accesos a la base de datos. Sus metodos mas im-
portantes son:
80
Metodo Descripcion
open() / close() Son los metodos encargados de abrir y cerrar la base de
datos.
insertForn() Crea una lınea en la tabla donde se guardan los hornos
con los datos pasados por parametro.
obtenerProvincias() Realiza una consulta a la tabla hornos para obtener las
diferentes provincias.
obtenerComarcas() Realiza una consulta a la tabla hornos para obtener las
diferentes comarcas de una provincia determinada.
obtenerPoblaciones() Realiza una consulta a la tabla hornos para obtener las
diferentes poblaciones de una comarca determinada.
obtenerHornos() Realiza una consulta a la tabla hornos para obtener los
hornos de una poblacion determinada.
obtenerTodos() Realiza una consulta para obtener todos los hornos de la
tabla.
4.3. Diferencias entre iOS y Android
En esta seccion vamos analizar las diferencias que han habido durante el proceso de imple-
mentacion de las dos aplicaciones.
81
4.3.1. Lenguaje de programacion
Puestos a analizar las diferencias entre ambas implementaciones, el primer punto donde
detenerse debe ser el propio lenguaje. El uso de Java para Android ha resultado ser mucho
mas amigable que Objetctive-C. En primer lugar el tiempo de adaptacion al lenguaje fue
nulo. Java es uno de los lenguajes que mas extendido esta hoy dıa y ademas su sintaxis es
bastante comun, por lo que de no haberlo conocido previamente, igualmente habrıa sido
sencilla la adaptacion.
Por contra Objective-C requirio de varias horas dedicadas exclusivamente al aprendizaje
del lenguaje. Una vez conocidas las bases, el uso de Objective-C no difiere mucho del uso de
Java puesto que ambos son lenguajes orientados a objetos, pero termina por dar resultados
menos legibles de cara al programador. La sintaxis del lenguaje es poco intuitiva y repasar
el funcionamiento de cualquier metodo acaba requiriendo mas tiempo que en Java.
4.3.2. Desarrollo de la interfaz
Como ya hemos visto ambas interfaces se disenan sobre ficheros xml. Android propone el
uso de un fichero por cada pantalla que tenga la aplicacion, para iOS en cambio solo ha
sido necesario un unico fichero.
A la hora de disenar cada pantalla, la interfaz grafica de Xcode ha resultado mucho mas
eficiente que la de Eclipse, hasta el punto que en Android se acabo por disenar la interfaz
directamente en codigo xml. Mientras que la interfaz de Xcode es agil e intuitiva, en Eclipse
nos encontramos con algo mucho mas rudimentario. Colocar los controles donde uno desea
no resulta todo lo sencillo que deberıa ser y no existe una paleta de colores para pintar
los objetos desde la interfaz grafica (debe indicarse su codigo RGB). Ello comporta que la
tarea mas estrictamente vinculada con el diseno se vuelve muy incomoda. Ademas, si como
ha sido el caso las pantallas se han disenado directamente en xml, al cambiar a la interfaz
grafica para comprobar el resultado, podemos encontrarnos con que la pantalla que vemos
no es del todo fiel con la pantalla que el usuario vera cuando ejecute la aplicacion.
Otra diferencia muy importante entre el diseno en Android e iOS es la posibilidad que
82
brinda este ultimo para determinar en el propio fichero xml las transiciones entre pantallas.
En iOS existen una serie de controles destinados exclusivamente a este cometido, ası que
unicamente anadiendolos a tu interfaz y definiendo una serie de relaciones entre las pantallas
ya tenemos el comportamiento deseado. En Android en cambio ha sido necesario controlar
todo este proceso mediante programacion. Como consecuencia tenemos que en iOS esta
tarea tuvo un coste en tiempo muy reducido y nulo en cuanto a lineas de codigo, mientras
que en Android llevo mas tiempo y fue necesario programar varios metodos.
4.3.3. Localizacion
Mostrar la ubicacion geografica del dispositivo ha sido mucho mas sencillo en iOS que en
Android. Por un lado, en iOS, esta opcion la tenemos totalmente integrada en el control
MKMapView. El mismo control que muestra un mapa por pantalla, tiene un atributo boo-
leano llamado showsUserLocation, ası que simplemente asignandole como valor CIERTO ya
dibuja en el mapa un completo marcador que no solo indica la posicion, tambien la precision
con la que se ha obtenido. El mismo objeto se encarga de elegir el mejor metodo para ob-
tener la localizacion segun las circunstancias. Si mas tarde necesitamos obtener el valor de
las coordenadas para por ejemplo utilizarlas como punto de inicio de una ruta, simplemente
debemos acceder a otro atributo de la clase MKMapView llamado userLocation.
En Android, en cambio, el proceso es algo mas costoso. En primer lugar obtener la loca-
lizacion y dibujarla en el mapa son dos tareas separadas. Para obtener la localizacion es
necesario crear una clase LocationListener que gestione los eventos relacionados con la lo-
calizacion que puedan producirse. Para que estos tengan lugar, antes hay que inicializar
un objeto LocationManager y pedirle que empiece a buscar la posicion. Si indicamos que
empiece a buscarla como GPS y no encuentra ningun satelite, debemos crear un sistema
capaz de detectarlo y pedirle que entonces la busque a traves de la red movil. Ası pues, una
vez montado todo este sistema, podremos recibir las coordenadas de nuestra posicion, pero
claro, ya nos habra llevado algo de tiempo y unas cuantas clases. Llegados a este punto hay
que senalar las coordenadas obtenidas en el mapa. Para ello es necesario crear una clase tipo
83
Overlay o un ItemazedOverlay, que son dos tipos de objeto que permiten dibujar encima de
un MapView. Ası pues hay que escoger una imagen como marcador, o simplemente dibujar
un punto, colocarlo en el Overlay y despues colocar este sobre el MapView como si fuera
una capa. Ademas hay que asegurarse de que la posicion se va actualizando regularmente,
por lo que es necesario crear todo esto en algun tipo de thread.
4.3.4. Uso de Mapas
El uso de la API de mapas tanto en iOS como en Android es bastante comodo. Ambas
librerıas proporcionan un control que al colocarlo en una pantalla muestra un mapa. Es al
colocar marcadores cuando encontramos algunas diferencias. En Android, como ya hemos
comentado, es necesario crear una clase y asignarsela como capa al mapa. El principal
problema es que esta clase esta totalmente vacıa de contenido, no tiene ninguna imagen
que dibujar como marcador, ni lanza ningun evento cuando el marcador es presionado ni
tampoco dispone de algun globo de texto con informacion personalizable. Todo esto ha
sido necesario crearlo de cero. En iOS, en cambio, solo es necesario crear una clase con
el protocolo MKAnnotation y sin necesidad de anadirle ningun metodo ya tendremos un
marcador con imagen predeterminada que podremos presionar y que mostrara un bocadillo
con la informacion que le asignemos. Si deseamos realizar alguna modificacion sobre el
marcador predeterminado, como cambiar su apariencia o anadir algun boton al globo de
texto, habra que sobreescribir un metodo de la clase MKMapView.
Otro punto a destacar sobre el uso de mapas es que el mapa en Android requiere una
clave de licencia de Google Maps para funcionar. En la pagina web para desarrolladores de
Android encontramos instrucciones para conseguir la clave y como utilizarla. Ademas esta
clave es diferente si el mapa se va a utilizar en un entorno de desarrollo o si se va a utilizar
en el producto final, por lo que durante el desarrollo de esta aplicacion ha sido necesario
obtener dos claves: una cuando empezo el desarrollo para poder testear y otra cuando se
compilo la aplicacion para subirla a Google Play.
84
4.3.5. Valoraciones
A nivel general las diferencias entre ambas implementaciones han hecho que el desarrollo
para iOS haya sido bastante mas rapido y sencillo. Si bien es cierto que el proceso de
aprendizaje de Objective-C fue un punto desfavorable, la gran cantidad de recursos que
proporcionan las librerıas del SDK de iOS han hecho el desarrollo mas satisfactorio.
4.4. Aspecto final de las pantallas
Para terminar con el capıtulo de la implementacion vamos a mostrar a modo comparativo
como han quedado las pantallas en una y otra aplicacion. Las pantallas de la izquierda
corresponden a la aplicacion iOS y las de la derecha a la aplicacion Android.
Figura 34: Pantalla Mapa
85
Figura 35: Pantalla Mapa con controles para trazar ruta
Figura 36: Pantalla Mapa con hornos cercanos
86
Capitulo 5
5. Planificacion y Costes
El objetivo de este capıtulo es ver la planificacion en tiempo de trabajo que se habıa
realizado para este proyecto y compararla con el tiempo real que ha sido empleado.
Tambien se pretende hacer una estimacion de los costes que tendrıa un proyecto como este
en un entorno empresarial.
La siguiente tabla nos muestra por un lado las horas estimadas en un principio y las que
finalmente han sido necesarias.
Tarea Horas estimadas Horas reales
Estudio previo de tecnologıas 40 37
Analisis de requisitos 30 25
Especificacion 16 16
Diseno 40 38
Implementacion Android 160 176
Implementacion iOS 176 152
Testeo 30 29
Documentacion 140 127
Total 632 horas 600 horas
En el desarrollo de la aplicacion han intervenido tres figuras: el jefe de proyecto, el analista
programador y el becario.
Jefe de proyecto: El jefe de proyecto ha sido el responsable de la planificacion del
proyecto y la gestion de recursos. Le imputaremos las horas de las reuniones para el
analisis funcional, las reuniones de seguimiento (una por semana) y aproximadamente
89
una decima parte de las horas empleadas en la documentacion.
Analista programador: Le corresponden las horas del estudio previo, tambien del
analisis funcional, la especificacion, el diseno, ambas implementaciones y la documen-
tacion.
Becario: Para la fase de testeo fue contratado un becario que se encargo del testeo
de la aplicacion.
Para analizar los costes de la aplicacion, vamos a ver en primer lugar el salario por horas
de las tres figuras implicadas:
Cargo Salario por hora
Jefe de proyecto 60 e
Analista programador 30 e
Becario 0 e
Una vez conocidos los salarios, vamos calcular segun las horas trabajadas de cada uno el
coste que han supuesto para el proyecto.
Cargo Dedicacion Coste
Jefe de proyecto 55 horas 3300 e
Analista programador 571 horas 17130 e
Becario 29 horas 0 e
Total 20430 e
Ademas de los costes en recursos humanos hay que anadir los relativos al hardware, software
y licencias. Si bien algunos de ellos no han supuesto un desembolso real por haber sido
facilitados por la universidad o por disponer de ellos previamente, para que este apartado
sea lo mas fidedigno posible con los costes que habrıa supuesto el proyecto en un entorno
laboral, vamos a suponer que fue necesario comprar todo para su realizacion
90
Gasto Coste
MacBook Pro 1745 e
iPhone 599 e
Telefono Movil Android 300 e
Cuota anual de desarrollador Apple 80 e
Cuota de desarrollador Google 20 e
Total 2744 e
Una vez calculados todos los costes, el gasto real del proyecto habrıa sido el siguiente:
Costes Cantidad
Recursos humanos 20430 e
Otros Recursos 2744 e
Total 23174 e
91
Capitulo 6
6. Conclusiones y trabajo futuro
En este capıtulo, finalmente, vamos a valorar el estado final del proyecto, lo que ha supuesto
para el autor y las mejoras que se pueden anadir en futuros proyectos.
6.1. Conclusiones
En general podemos decir que el desarrollo del proyecto ha sido satisfactorio. Todos los
objetivos marcados se han alcanzado y ambas aplicaciones estan disponibles para descargar
en Google Play y AppStore.
Aunque la planificacion se habıa hecho partiendo de un escenario pesimista, hay que senalar
que se ha reducido la estimacion de tiempo prevista. En este sentido la implementacion de
ambas aplicaciones ha jugado un papel sorprendente en ambos casos. En un principio se
habıa estimado que llevarıa menos tiempo desarrollar la aplicacion de Android que la de iOS
porque el programador ya conocıa el lenguaje Java y el entorno de desarrollo, mientras que
en iOS todo era nuevo. Despues la realidad fue diferente. El SDK y las librerıa disponibles
jugaron un papel vital. Por un lado en Android se dio la necesidad de desarrollar casi desde
cero partes cruciales, por el otro nos encontramos mas facilidades de las esperadas en este
sentido y finalmente se vio reflejado en los tiempos de desarrollo.
6.2. Valoraciones personales
A nivel personal me gustarıa senalar que he cumplido mis objetivos. Lo que me llevo a
presentarme voluntario para realizar este proyecto, y no otro, fue la oportunidad que me
brindaba para romper con todo lo que tenıa aprendido despues de cuatro anos trabajando
como programador y empezar a realizar aplicaciones para estos dispositivos que veo y uso
cada dıa.
Hoy mis conocimientos como programador Android e iOS, aun lejos de ser sobresalientes,
92
son lo suficientemente amplios como para sentirme animado a realizar mis propios proyectos
y distribuirlos en las correspondientes plataformas. Y he de decir que ese animo es algo que
no sentıa desde hace mucho tiempo.
Trabajar en un consultorıa, realizando proyectos clonicos en tiempo record para otras em-
presas cuyos intereses estan lejos de ser los mıos es algo que me ha ido desgastando y que
convertıa algo tan vocacional, como lo es para mı el desarrollo de software, en un simple
trabajo que hacıa por obligacion. Este proyecto ha cambiado eso y vuelvo a sentir las ganas
de programar lo que a mı verdaderamente me nace, y creo que las plataformas moviles son
un lugar idoneo para ello.
6.3. Trabajo futuro
Una vez finalizada la aplicacion nos gustarıa mejorarla en futuras versiones partiendo de
las siguientes consideraciones:
Actualizacion de la lista de hornos
Durante el desarrollo actual, por temas de eficiencia, se decidio leer el archivo pList
unicamente la primera vez que se ejecuta la aplicacion y guardar los datos en una
base de datos. El resultado ha sido muy satisfactorio pero nos da problemas si quere-
mos actualizar dicha lista en futuras versiones, puesto que ahora mismo no hay nada
implementado que permita leer de nuevo la lista sin desinstalar la aplicacion. Veo
prioritario desarrollar un sistema de actualizacion de versiones independiente del que
facilitan las plataformas de distribucion que permita leer el archivo pList de nuevo
cuando haya algun cambio. Incluso serıa interesante considerar la opcion de disponer
de un servicio Web que facilitara la lista de hornos, ası no serıa necesario un cambio
de version cada vez que se anadiesen nuevos hornos.
Implementacion en iPad y tablets Android
Si bien el desarrollo efectuado permitirıa ejecutar ambas aplicaciones en los tablet
disponibles con su sistema operativo, es necesario desarrollar una interfaz que se ajuste
93
al cambio de tamano de la pantalla y si puede ser saque mas partido de una pantalla
tan grande.
Soporte para otros idiomas
Dado el caracter comercial y publicitario de esta aplicacion, serıa bueno que pudiese
llegar a mas gente, sobre todo a turistas que pueden encontrar interesante comprar un
producto tan autoctono como el pa de pages catala. Por ello es necesario considerar la
posibilidad de anadir mas idiomas, como el ingles y el castellano.
94
Capitulo 7
7. Referencias
7.1. Geolocalizacion
[1] http://www.inteco.es/Seguridad/Observatorio/guias/Guia_Geolocalizacion
[2] http://en.wikipedia.org/wiki/Georeference
[3] http://en.wikipedia.org/wiki/Geocoding
[4] http://en.wikipedia.org/wiki/Geotagging
[5] http://en.wikipedia.org/wiki/Geolocation
[6] http://en.wikipedia.org/wiki/Mobile_phone_tracking
[7] http://www.gisdevelopment.net/technology/lbs/techlbs006.htm
[8] http://www.kriptopolis.org/geoposicionamiento-gsm-1
[9] http://www.rtve.es/noticias/20111115/como-borrar-tu-red-wifi-base-datos-google/
475608.shtml
[10] http://es.wikipedia.org/wiki/Sistema_de_posicionamiento_global
[11] http://es.wikipedia.org/wiki/GPS_Asistido
[12] http://en.wikipedia.org/wiki/Location_API_for_Java_ME
[13] http://developers.sun.com/mobility/apis/articles/location
[14] http://developer.android.com/guide/topics/location/index.html
[15] http://developer.apple.com/library/ios/#documentation/UserExperience/
Conceptual/LocationAwarenessPG/Introduction/Introduction.html
95
7.2. Representacion de Mapas
[16] http://en.wikipedia.org/wiki/Map_projection
[17] http://www.nationalatlas.gov/articles/mapping/a_projections.html
[18] http://es.wikipedia.org/wiki/Sistema_de_Informacion_Geografica
[19] http://www.openstreetmap.es/
[20] https://developers.google.com/maps/faq?hl=es-ES
[21] http://www.microsoft.com/maps/product/licensing_for_mobile.aspx
[22] http://cloudmade.com/about
[23] http://www.nutiteq.com/map-api
7.3. iOS vs Android
[24] http://gallir.wordpress.com/2011/12/07/android-ios-tiempos-de-respuestas-y-por-que-nada-es-gratis-en-sistemas-informaticos/
[25] http://www.sozpic.com/desarrollo-ios-vs-android-por-donde-empiezo/
[26] https://support.google.com/googleplay/android-developer/bin/answer.
py?hl=es&answer=113469
[27] https://developer.apple.com/programs/mac/distribution.html
7.4. Implementacion
[28] http://www.sgoliver.net/blog/?p=1313
[29] http://developer.android.com/index.html
[30] https://developer.apple.com
[31] The iPhone Developer’s Cookbook - Erica Sadun - Addison Wesley
96
Top Related