Escolar Documentos
Profissional Documentos
Cultura Documentos
iOS / Android
Ra
ul Sanchez Delgado
11 de junio de 2012
Indice
1. Introducci
on 6
1.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. Motivaciones personales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Dise
no de la aplicaci
on 38
3.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3. Diagrama de estados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.1. Inicio de la aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.2. Esquema general de la aplicacion . . . . . . . . . . . . . . . . . . . . 42
3.3.3. Mostrar y telefonear a un horno de la lista . . . . . . . . . . . . . . . 44
3.4. Diagramas de secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2
3.4.1. Inicio de la aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.4.2. Mostrar Horno Seleccionado . . . . . . . . . . . . . . . . . . . . . . . 50
3.4.3. Telefonear al Horno . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.4.4. Mostrar Hornos Distancia . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4.5. Mostrar Ruta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4. Implementaci
on 56
4.1. Implementaci
on en iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.1.1. Libreras del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.1.2. Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.1.3. Capa de gesti
on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.1.4. Capa de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.2. Implementaci
on en Android . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.2.1. Libreras del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.2.2. Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.2.3. Capa de gesti
on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.2.4. Capa de localizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.2.5. Capa de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.3. Diferencias entre iOS y Android . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.3.1. Lenguaje de programacion . . . . . . . . . . . . . . . . . . . . . . . . 82
4.3.2. Desarrollo de la interfaz . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.3.3. Localizaci
on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.3.4. Uso de Mapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.3.5. Valoraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.4. Aspecto final de las pantallas . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5. Planificaci
on y Costes 89
3
6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.2. Valoraciones personales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.3. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7. Referencias 95
7.1. Geolocalizaci
on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.2. Representaci
on de Mapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.3. iOS vs Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.4. Implementaci
on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4
Agradecimientos
Llegados a este punto son muchas las personas que seguro merecen mi agradecimiento
durante todos estos a
nos de carrera, pero en esta ocasion procurare centrarme en los que
han ayudado a ponerles fin con este proyecto.
En primer lugar, como no, a mi tutor de proyecto. Gracias Jordi por pensar que sera
capaz de llevarlo a cabo y por todo el asesoramiento y recursos que me has facilitado.
Y por u
ltimo gracias a toda mi familia por apoyarme y aguantarme habitualmente y sobre
todo estos u
ltimos meses, pues posiblemente me habre mostrado mas agitado de lo habitual.
5
Captulo 1
1. Introducci
on
Quizas algunas de las aplicaciones que mas hayan proliferado sean aquellas que permi-
ten al usuario ubicarse en tiempo real en un mapa y encontrar lugares de interes, ya sean
tursticos, de ocio o cualquier tipo de establecimiento. Y no es de extra
nar que sea as,
ya que este tipo de aplicaciones no solo son u
tiles para el usuario, sino tambien para las
empresas que gracias a ellas pueden indicar a sus clientes la manera de llegar a su tienda
mas cercana. Es una manera sencilla de publicitarse y fidelizar clientes a muy bajo coste.
Con esa idea en mente nace este proyecto, cuyo objetivo principal es desarrollar una apli-
cacion que muestre nuestra posicion geografica en tiempo real y disponga de un catalogo
de establecimientos de manera que el usuario pueda navegar por el y elegir a cual desea
ir; o simplemente encontrar la manera de llegar al mas cercano. Estos establecimientos son
tiendas donde se puede adquirir pan con Indicacion Geografica Protegida (IGP) Pa de
a1 .
Pages Catal`
Teniendo esto en cuenta se decidio utilizar los dispositivos moviles como plataforma pa-
ra esta aplicaci
on. Su tama
no permite al usuario moverse con el y el GPS o el acceso a
1
De ahora en adelante nos referiremos a ellos como hornos
6
la red de telefona m
ovil permite obtener la posicion geografica de manera mas precisa.
Los modelos escogidos han sido aquellos que funcionan sobre los sistemas operativos iOS
y Android, ya que son los que gozan de mayor implantacion en el mercado, proporcionan
facilidad para acceder a su SDK y una extensa base de conocimientos para ayudar al desa-
rrollador. Adem
as las compa
nas que estan detras de estos sistemas operativos (Apple y
Google respectivamente) disponen de plataformas de distribucion de aplicaciones amplia-
mente aceptadas por sus usuarios (AppStore y GooglePlay, respectivamente).
1.1. Objetivos
Los objetivos para llevar a cabo este proyecto podemos desglosarlos de la siguiente manera:
Investigaci
on previa
En primer lugar habr
a que hacer un peque
no estudio sobre las diferentes tecnologas
que permiten la localizaci
on geografica y determinar cual o cuales son las mas ade-
cuadas para esta aplicaci
on.
Posteriormente y dado que son dos lenguajes de programacion desconocidos para m,
ser
a necesario estudiar tanto el entorno de desarrollo como los propios lenguajes.
Dise
no preliminar de la aplicaci
on
Habr
a que determinar las acciones que podra realizar el usuario en la aplicacion y
hacer un primer dise
no de la estructura de esta.
Estudio de particularidades
Una vez instalados los SDKs, asimilados los conceptos basicos de los lenguajes y
con la idea general de lo que necesitara la aplicacion, sera necesario investigar las
diferentes herramientas o APIs que tenemos disponibles para llevar a cabo las tareas
m
as complejas, como son la inclusion de mapas y la geolocalizacion en ambos sistemas
operativos.
Desarrollo de la aplicaci
on
7
Se desarrollar
an dos versiones de la aplicacion, una para dispositivos Android y otra
para iPhone.
Despliegue final
Finalmente las versiones definitivas de la aplicacion se pondran a disposicion del p
ubli-
co en las plataformas de distribucion de Google y Apple.
A nivel personal, la principal motivacion que encontre para realizar este proyecto fue el
deseo de iniciarme en el desarrollo para dispositivos moviles. Llevo cuatro a
nos ejerciendo
como programador en entornos .Net y entenda que era el momento de probar cosas nue-
vas. En este sentido, me pareci
o que la programacion para iOS y Android era una buena
eleccion puesto que son dos plataformas en continuo crecimiento y permiten hacer llegar
tus aplicaciones a un amplio mercado de manera rapida y directa. Ademas este proyecto
me daba la oportunidad de trabajar con mapas y geolocalizacion, dos conceptos clave en el
desarrollo de aplicaciones m
oviles.
8
Capitulo 2
En este captulo introduciremos las diferentes tecnologas que se han utilizado en este pro-
yecto, como son las tecnicas de geolocalizacion o los sistemas de representacion de mapas.
En general se procurar
a no entrar en demasiado detalle y mostrar una vision lo mas cercana
posible al
ambito de este proyecto.
2.1. Geolocalizaci
on
En los u
ltimos a
nos los smartphone se han tornado el dispositivo ideal para la geoloca-
lizacion gracias al hardware que incorporan y a que sus fabricantes han dotado sus sistemas
operativos de las herramientas necesarias para que los desarrolladores hagan uso de la geo-
localizaci
on con facilidad y puedan centrarse en explorar sus m
ultiples utilidades. No es de
extra
nar pues la gran cantidad de aplicaciones que hay disponibles en telefonos moviles que
hacen uso de esta tecnologa. Entre ellas podemos diferenciar tres usos comunes:
Georreferenciaci
on: Es el proceso mediante el que se localiza un objeto, lugar o
persona en el espacio fsico para posteriormente representarlo en un sistema de coor-
denadas o mapa. Un ejemplo habitual es la representacion de tu posicion en el mapa
de tu ciudad y actualizarla a medida que te desplazas.
Geocodificaci
on: Es el proceso de obtencion de coordenadas geograficas a partir
de otro tipo de datos geogr
aficos, como la direccion o el codigo postal. Al proceso
9
contrario, la obtenci
on de direcciones postales a partir de coordenadas se le denomina
Geocodificaci
on Inversa. El ejemplo claro lo vemos en la aplicacion Google Maps, que
muestra en un mapa el punto donde quieres despues de haber indicado la direcci
on
postal.
2.1.1. M
etodos de georreferenciaci
on en dispositivos m
oviles
Un mismo dispositivo m
ovil dispone de diferentes vas para determinar su posicion, siendo
algunas mucho m
as precisas que otras. Sin embargo en ocasiones al dispositivo no le sera po-
sible utilizar la tecnica m
as precisa y debera recurrir al metodo que tenga disponible. Esta
disponibilidad la marca el medio al que esta conectado el dispositivo, y en funcion de este
medio podemos dividir las tecnicas de georreferenciacion en tres grupos:
Redes Wi-Fi
Este metodo se basa en el uso de enormes bases de datos que contienen la informaci
on
y situaci
on de gran cantidad de redes Wi-Fi. El metodo consiste en enviar la direcci
on
MAC del router Wi-FI y el SSID (nombre la red) y contrastarlo con la base de datos
que devolver
a la posici
on geografica de la red. De esta forma es posible determinar con
una precisi
on de entre 30 y 100 metros la ubicacion de cualquier dispositivo conectado
a una red inal
ambrica.
Google, por ejemplo, es propietaria de una de estas bases de datos y la utiliza en
su sistema de mapas Google Maps. Para crear la base de datos enviaron vehculos a
10
recorrer las ciudades que registraban las redes Wi-Fi que encontraban a su paso. Hoy
da son los propios telefonos moviles de los usuarios los que completan estas bases de
datos enviando su ubicaci
on [1, 9].
Redes de telefona m
ovil:
Hay un gran n
umero de tecnicas de georreferenciacion que permiten obtener la posici
on
de un dispositivo que este conectado a una red de telefona movil y su precision oscila
entre los 50 y los 500 metros. Mientras que en el siguiente apartado veremos las m
as
relevantes, en este nos limitaremos a clasificarlas en tres grandes grupos:
Basadas en la red
Estas tecnicas utilizan la infraestructura del operador de telefona movil para
determinar la ubicaci
on del terminal. La principal ventaja es que no son tecnicas
intrusivas y no requieren que el dispositivo disponga de hardware o software es-
pecfico. La precisi
on de estas tecnicas vara no solo en funcion de la tecnica en
s, sino tambien en funcion de la infraestructura del operador. De estas tecnicas
destacamos la CGI (Cell Global Identity), CGI-TA, que combina las tecnicas Ti-
ming Advance junto con CGI, TDOA (Time Difference Of Arrival ), AoA (Angle
of Arrival ) y A-GPS (Assisted Global Positioning System)
Basadas en el terminal
Son tecnicas que requieren dotar al terminal de un receptor de se
nales y de apli-
caciones especficas que realicen las tareas necesarias para determinar la posici
on
geogr
afica, por ello estas tecnicas dependen en gran medida del fabricante del
dispositivo. La principal ventaja de estas tecnicas sobre las anteriores radica en
que no son tecnicas tan dependientes de la infraestructura del proveedor de ser-
vicios. Entre las m
as conocidas, encontramos E-OTD (Enhanced Observed Time
Difference) y variaciones de CGI y TDOA.
Hbridas
11
Combinan las tecnicas basadas en la red y las basadas en el terminal para con-
seguir mayor precisi
on, pero heredan los inconvenientes de ambas.
GPS
GPS son las siglas de Global Positioning System. Es un sistema de localizacion por
satelites que permite determinar la posicion de un dispositivo en cualquier lugar del
globo terrestre con una precision de entre 1 y 15 metros; en el 95 % esta precision es
de 3 metros. El sistema est
a formado por 27 satelites (24 operativos y 3 de repuesto)
cuya funci
on es emitir se
nales con informacion sobre el tiempo de emision y su posici
on
para que los receptores GPS las interpreten y utilicen en el calculo de su situaci
on
geogr
afica. Este c
alculo se basa en el concepto de trilateracion, que es un principio
geometrico que permite conocer la ubicacion de un punto conociendo su distancia a
otros puntos ya conocidos, en este caso los satelites.
Figura 1: Trilateracion
Para calcular la distancia entre el dispositivo y los satelites se mide el retraso que
marca el tiempo de la se
nal emitida por estos. Una vez tenemos el retraso y conocien-
12
do que la se
nal ha viajado a la velocidad de la luz, podemos determinar la distancia
a la que se encuentra el satelite. Para que este proceso funcione es necesario recibir la
se
nal de al menos otros dos satelites. Con tres satelites ubicados podemos hacer una
esfera alrededor de cada uno de ellos, con el satelite como centro, y obtendremos tres
esferas que se cortaran en dos puntos, uno de ellos es despreciable puesto que no se
encuentra en la superficie de la tierra y el otro sera el que indique donde se encuentra
el receptor GPS.
13
GPS y es la primera opci
on que utilizan las aplicaciones de geolocalizacion cuando
se prioriza la precisi
on, pero es requisito indispensable que el dispositivo se encuentre
en cielo abierto y despejado, de lo contrario no puede recibir la se
nal de los satelites.
Otro de sus inconvenientes es que es un sistema considerablemente lento. El resultado
puede tardar en obtenerse en torno a unos 20 - 45 segundos [1, 7, 10].
2.1.2. T
ecnicas de geolocalizaci
on en redes de telefona m
ovil
A continuaci
on describiremos brevemente algunas de las tecnicas de georreferenciacion que
es posible efectuar sobre dispositivos conectados a redes de telefona movil.
14
Figura 3: Redes celulares
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].
16
Figura 5: Trilateracion aplicada en TDOA
Esta es una tecnica costosa ya que requiere de un determinado tipo de antena y que pierde
eficacia en entornos urbanos, donde los edificios interrumpen las se
nales [7, 8].
17
este caso quien lleva a cabo el c
alculo a partir de los parametros obtenidos es el propio
dispositivo. Ello significa que para poder hacer uso de este metodo se requieren terminales
convenientemente adaptados.
La precisi
on de esta tecnica fluct
ua entre lo 50 y los 100 metros [8].
18
2.1.3. Herramientas de geolocalizaci
on
El objetivo principal que se tena con esta API era proporcionar una herramienta de geolo-
caclizaci
on al mayor n
umero de dispositivos posible, sin importar sus caractersticas, por lo
que se program
o con la capacidad de hacer uso de un gran n
umero de tecnicas de georrefe-
renciaci
on. Sin embargo s que seran las caractersticas del dispositivo las que determinen
que tecnica puede utilizarse en u
ltima instancia y la precision en el resultado sera resultado
directo de esto. Haciendo uso de los metodos de localizacion a traves de redes moviles,
obtendremos mediciones con un margen de error de entre 50 y 500 metros (puede que m
as
en zonas rurales), mientras que si el dispositivo tiene receptor GPS el precision se vera in-
crementada hasta los 4 - 40 metros.
Esta API funciona tanto en espacios abiertos como cerrados y permite obtener latitud,
longitud, velocidad, altura e incluso la orientacion del dispositivo (siempre que este dispon-
ga de br
ujula). Tiene la capacidad de asignar nombres y valores textuales (como direcciones
19
postales) a las posiciones obtenidas y almacenarlas como marcadores. Otra de sus carac-
tersticas es que permite elegir entre velocidad y precision a la hora de obtener un resultado,
siempre y cuando las caractersticas del dispositivo den la posibilidad de usar mas de una
tecnica de geolocalizaci
on [12, 13].
Como es com
un en estas APIs, permite utilizar las tecnicas de geoposicionamiento mediante
redes Wi-Fi locales, redes de telefona movil y GPS (siempre que el terminal este prepara-
do). La principal ventaja de esta API es que al ser de Google esta pensada para funcionar
con su API de mapas Google Maps y su integracion es muy sencilla [14].
Core Location
Este paquete ha sido desarrollado por Apple y solo es posible obtenerlo con su SDK y uti-
lizarlo en aplicaciones que funcionen sobre el sistema operativo iOS. Funciona empleando
las tecnicas de geolocalizaci
on en redes Wi-Fi, moviles o GPS que hemos visto y permite
elegir entre dos servicios diferentes a la hora solicitar la posicion del terminal [15].
20
subscribirse para ser avisado en caso de cambios en esa posicion. Ademas tiene un
alto consumo energetico y es conveniente utilizarlo con mesura para ahorrar batera.
Actualmente son muchas las aplicaciones que hacen uso de la ubicacion del usuario en uno
u otro sentido. A continuaci
on vamos a ver alguna de ellas:
Br
ujula para iPhone
Esta aplicaci
on viene por defecto en todos los
telefonos iPhone. Haciendo gala del minimalismo
con el que Apple dota a todos sus productos, la
aplicaci
on consta de una u
nica pantalla que na-
da mas mostrarse ya indica la ubicacion en for-
ma de coordenadas geogr
aficas (grados, minutos
y segundos), como podemos ver en la figura 8.
Ademas, como su nombre indica, hace las veces de
br
ujula indicando el norte (podemos elegir entre
el norte real y el norte magnetico) y hacia donde
esta orientado el dispositivo. Finalmente nos da la
opcion de llamar a una aplicaci
on de mapas y mos-
trarnos el punto geogr
aficos donde estamos ubica- Figura 8: Br
ujula
dos.
21
Star Walk
Star Walk es una aplicaci
on pensada para los aficionados a la astronoma. Se hace valer de
la ubicaci
on geogr
afica para mostrar el cielo tal y como lo estamos viendo en la realidad y
lo va actualizando en tiempo real.
Ademas utiliza la el calculo de la orientacion del dispositivo para poder usarlo como si de
un cristal transparente se tratase, de forma que si lo ponemos delante de nuestros ojos y
miramos al cielo, veremos indicados en la pantalla nombre de todos los objetos celestes
(estrellas, planetas, cat
alogo Messier...) hacia los que estamos mirando. Es una aplicaci
on
disponible para dispositivos con sistema operativo iOS.
TomTom
TomTom es una aplicaci
on para dispositivos iOS que hace las veces de sistema GPS de
carretera. Utiliza la ubicaci
on del usuario para mostrarla en un mapa de carretera y guiar-
le durante el trayecto mediante voz. Tambien calcula la velocidad a la que se desplaza el
vehculo e indica los lugares de interes a los que se va acercando (estaciones de servicio,
22
radares, accidentes... ). Sin embargo debido a la alta precision que requiere la conducci
on
en carretera, solo soporta la tecnica de geoposicionamiento por GPS, por lo que es obligado
que los dispositivos que ejecuten a aplicacion tengan un receptor de se
nal GPS.
Around Me
Esta aplicaci
on, disponible tanto para dispositi-
vos Android como iOS, utiliza nuestra ubicacion
geografica para indicarnos los lugares de nuestro
interes que tenemos pr
oximos. El usuario en pri-
mer lugar indica que lugares le interesa encontrar
y la aplicaci
on le muestra una lista con los resul-
tados que ha obtenido, mostrando en primer lugar
los mas cercanos e indicando la distancia hasta ellos
y como llegar. Entre los lugares que podemos bus-
car tenemos disponibles bancos, gasolineras, hospi-
tales, bares, cines y muchos m
as. Si lo deseamos
Around Me tambien puede mostrarnos un mapa
con nuestra ubicaci
on y la de los lugares selecciona-
dos. Figura 10: Around Me
Aplicaciones de Mapas
Tanto Android como iOS vienen instalados por defecto con una aplicacion de mapas, que
aunque son diferentes ambas tienen caractersticas muy parecidas puesto que las dos funcio-
nan con la API de mapas Google Maps. Estas aplicaciones nos muestran nuestra posici
on
en un mapa y se
nalizan todo lo que tenemos alrededor: el nombre de las calles, los portales,
estaciones de metro, paradas de autob
us... Tambien permiten escribir una direccion postal
23
para que la aplicaci
on la localice y nos la muestre en el mapa con un marcador. Podemos
ver las diferentes rutas que tenemos para llegar all desde nuestra ubicacion actual o desde
otro punto que le indiquemos. A medida que nos movemos vemos como nuestra posicion en
el mapa se desplaza de la misma forma y podemos pedir que nos muestre la direccion hacia
la que estamos mirando.
2.2. Representaci
on de mapas
Cuando tratamos de representar una superficie esferica sobre un plano nos encontramos con
el problema de que es imposible hacerlo sin deformarlo o distorsionarlo de alguna manera,
as que las distancias en determinados puntos no se ajustaran a las reales. Esto hace que
fijar un sistema de coordenadas en ese plano sea una tarea complicada. Ademas si lo que
queremos representar es la corteza terrestre nos encontramos con que la superficie de la
24
Tierra (al igual que la el resto de cuerpos celestes) no es perfectamente esferica, mas bien
es un esferoide ligeramente aplanado por los polos y con multitud de irregularidades en su
superficie. As pues la u
nica manera posible de representar sin ning
un tipo de imprecisi
on
la superficie de nuestro planeta es utilizar una esfera de verdad (como un globo terraqueo),
pero no es c
omodo trabajar con este tipo de formas en una pantalla, es por ello que para
representar mapas digitales se utilizan otros metodos [16, 17].
2.2.1. Proyecci
on de mapas
Una proyecci
on es un metodo matematico que permite representar un cuerpo esferico, o
cualquier cuerpo tridimensional, en un plano bidimensional. Existen varios tipos de pro-
yecciones y todas y cada una de ellas deforman alg
un aspecto del objeto original, ya sea
la forma, el
area, la distancia o la direccion. Sin embargo seg
un cual sea nuestro proposito
algunas deformaciones son aceptables, por lo que podemos escoger el tipo de proyeccion que
mas se ajusta a nuestras necesidades.
Proyecciones cilndricas
Se basan en proyectar la superfcie de la Tierra en un cilindro. Este cilindro puede ser
tangente a la esfera terrestre en una lnea seleccionada o bien secante y cortarla por dos
lneas. Una vez se proyecte la esfera sobre la superficie del cilindro los puntos donde la este
es tangente o secante ser
an los que menos distorsion tengan. Una caracterstica interesante
de estas proyecciones es que si el cilindro es tangente o secante por los paralelos terrestres,
obtendremos mapa con todos los paralelos y meridianos rectos y paralelos entre s.
25
Figura 12: Proyeccion cilndrica tangente y secante
Entre las proyecciones cilndricas mas famosas se encuentra la proyeccion Mercator, adop-
tada por ejemplo en aplicaciones de mapas como Google Maps. Su uso esta muy extendido
en la navegaci
on y, al ser tangente por el Ecuador, es com
un verla en los pases cercanos a
este. Como contrapartida pierde precision a medida que nos acercamos a los polos, dando
la falsa impresi
on de que Groenlandia y la antigua Union Sovietica son mas extensas que
Sudamerica y Africa.
Proyecciones c
onicas
En este tipo de proyecci
on la superficie de la tierra se proyecta sobre un cono imaginario.
Este cono puede ser tangente a alguno de los paralelos terrestres o secante en dos de ellos,
tal y como podemos apreciar en la figura 13.
26
Figura 13: Proyeccion conica tangente y secante
Proyecciones planas
Tambien conocidas como proyecciones acimutales, en este tipo de proyeccion es un plano
bidimensional quien es tangente a la esfera terrestre por un punto o bien secante por toda
una circunferencia. Tambien es posible que el plano sea totalmente exterior a la esfera, como
en el caso de la proyecci
on ortogr
afica.
27
Figura 14: Proyeccion planar tangente y secante
Un Sistema de Informaci
on Geografica es un sistema de mapas digitalizados cuyo fin es
capturar, almacenar, manipular, analizar y desplegar la informacion geografica almacena-
da para poder ejecutar cualquier tipo de operacion relacionada con mapas de una manera
sencilla para el usuario. Entre las operaciones mas comunes se encuentra la b
usqueda de
direcciones, el trazado de rutas, c
alculo de distancias, etc.
Podemos pensar en un SIG como si de una base de datos se tratase, una base de datos
donde se almacena todo tipo de informacion geografica cuyo identificador es un objeto
grafico representado en mapa en unas determinadas coordenadas. De esta manera se
nalan-
28
do este objeto en el mapa podemos obtener todos los datos asociados a el que hay en la
base de datos y viceversa, si introducimos alguno de estos datos como criterio de b
usqueda
podemos ser trasladados a su posicion en el mapa.
Representaci
on de los datos
El leitmotiv de todo SIG es poder representar en una pantalla la realidad y sus objetos.
Estos objetos podemos dividirlos de dos grupos: discretos y continuos. Entendemos por
objetos discretos aquellos cuyos lmites estan bien delimitados, como puede ser un edificio o
una carretera. En cambio los continuos son aquellos fenomenos con lmites mas imprecisos,
como puede ser la lluvia cada, la contaminacion o la temperatura en una zona determinada.
Para ambos objetos tenemos una forma de almacenar datos: vectorial para los discretos y
raster para los contnuos.
Raster
29
El tipo de datos raster se centra mas en las propiedades del espacio que en la precisi
on
de las localizaciones. Consiste en dividir el espacio en celdas regulares, a modo de
malla, y asignarles un valor. Es el mismo funcionamiento que una imagen, donde a
cada pixel se le asigna un color y la union de todos acaba definiendo la imagen en
su totalidad. De hecho una forma de almacenar datos raster es como si de imagen
se tratarse, con formatos TIFF, JPEG... o tambien puden almacenarse en grandes
ficheros binarios llamados BLOB.
Vectorial
Los datos vectoriales se utilizan cuando se quiere dar prioridad a la precision de los
elementos geogr
aficos en el espacio. Por ello, a fin de mantener sus caractersticas
geometricas y delimitarlos adecuadamente se definen mediante vectores. Utilizan tres
tipos de figuras para modelar los elementos geograficos: el punto, la lnea y el polgono.
El punto se utiliza para representar los elementos del mundo real que pueden ser
definidos mediante un punto concreto, como puede ser el pico de una monta
na u otros
puntos de interes. A escalas peque
nas tambien sirven para representar poblaciones. La
lnea se utiliza para medir todo aquello que se caracteriza por su longitud, como pueden
ser carreteras, ros, caminos, vas, ferrocarriles, fronteras, etc. Los datos representados
por lneas permiten medir distancias. Por u
ltimo el polgono sirve para representar
elementos del mundo real que abarcan cierta extension sobre la superficie terrestre:
lagos, provincias, ciudades, parques naturales... Permiten calcular el area que abarcan.
Renderizado
Una vez tenemos los datos en la base de datos y tenemos claro como representarlos, lo u
nico
que falta es la fase de renderizado. Esta fase es la encargada de reunir toda la informaci
on
de la base de datos, unir las capas y generar la imagen final con la que trabajara el usuario.
Hay servicios de mapas que u
nicamente centran su trabajo en esta fase: obtienen los datos
de alguna otra fuente (por ejemplo OpenStreetMap) y se encargan de ofrecer al usuario un
renderizado y unas funcionalidades especficas [18].
30
2.2.3. APIs de mapas
En los u
ltimos tiempos la creciente demanda por las aplicaciones de geolocalizacion y mapas
ha dado lugar una gran oferta de APIs disponibles entre las que poder elegir seg
un nuestras
necesidades. Las funciones que ofrecen todas ellas son muy similares, en general encontramos
geocodificaci
on, geocodificaci
on inversa, soporte para marcadores, calculo de distancias,
lugares de interes, etc. A continuacion veremos un peque
no listado con algunas de ellas:
Google Maps: Esta API desarrollada por Google es la API cuyo uso esta mas exten-
dido. Su versi
on m
ovil viene incluida en el paquete com.google.android.maps del SDK
de Android. Aunque hasta hace relativamente poco su uso era gratuito, recientemente
Google a
nadi
o unos lmites para su uso: 25000 cargas de mapas diarias y 2500 cargas
de mapas modificados. Si nuestra aplicacion sobrepasa ese lmite Google da la opci
on
de pagar por la sobrecarga o adquirir una licencia premium. Es debido a este movi-
miento que algunas empresas se estan replanteando su uso (como Apple, que con la
u
ltima versi
on de iPhoto ha cambiado Google Maps por OpenStreetMap) [20].
Bing Maps: Bing Maps es una API desarrollada por Microsoft con el objetivo de
ser el sistema principal de mapas en Windows Phone 7, aunque tambien disponen de
SDK para hacer uso de ellos en Android e iOS. Es una API de acceso gratuito pero
tiene diferentes planes de uso seg
un el tipo de usuario y muchas restricciones [21].
31
mapas. No tienen una base de datos geograficos propia, sino que utilizan los mapas de
OpenStreetMap. Es una API que obliga a tener publicidad en la aplicacion (de cuyas
ganancias se benefician) o bien, para eliminarla, hacen pagar 0.30 dolares por cada
usuario que la descargue [22].
Nutiteq Map: Nutiteq Map API esta pensada para plataformas java: Android, J2ME
y RIM BlackBerry. Tiene como base los mapas de OpenStreetMap pero tambien da
la opci
on de usar otros mapas, como CloudMade o Binq. Para poder utilizarla debe
comprarse una licencia que cuesta 2000 euros en su version basica. Una vez pagada la
licencia no hay cargos extra por n
umero de usuarios o cantidad de llamadas a la API
[23].
Map Kit Framework: Esta librera desarrollada por Apple funciona sobre los servi-
cios de Google Maps y es la manera mas simple que tienen los desarrolladores de
introducir mapas en las aplicaciones para iOS. Se encuentra en el paquete Map-
Kit.framework del SDK de iOS y se basa en el uso de la clase MKMapView, que
adem
as de mostrar el mapa te da gran variedad de opciones interesantes, como por
ejemplo visualizar en tiempo real la posicion del dispositivo dentro del mapa sin ne-
cesidad de c
odigo extra [15].
En esta secci
on vamos a analizar los dos sistemas operativos para los que se ha decido rea-
lizar la aplicaci
on.
Cuando hablamos de iOS y de Android estamos hablando de los dos sistemas operati-
vos con m
as base de usuarios y aplicaciones de todo el panorama smartphones. Desde que
fueron lanzados en 2007 y 2008 respectivamente, sus ventas no han hecho mas que crecer
en detrimento de sus competidores.
32
Figura 16: Gr
afico de ventas de dispositivos moviles seg
un su SO
Como podemos apreciar en la figura 16 el crecimiento de Android ha sido mucho mas pro-
nunciado que el iOS. Esto se debe fundamentalmente que Android es un sistema operativo
instalado en m
as de 200 dispositivos, mientras que iOS nacio por y para iPhone, aunque
mas adelante su uso se ha portado al iPad, iPod Touch y Apple TV.
Las compa
nas que encontramos detras de ambos sistemas operativos son dos de las em-
presas m
as poderosas en el mundo de la tecnologa. Lo son y lo eran antes de semejante
exito con los smartphone. Hablamos de Apple en el caso de iOS y Google en el de Android.
Que si bien coinciden en el exito, ambas tienen filosofas muy diferentes. Google dise
no An-
droid para que fuera un sistema operativo abierto, quera que cualquier compa
na pudiese
instalarlo en su telefono m
ovil y se sintiese libre de modificarlo seg
un sus necesidades. Por
contra Apple desarroll
o iOS pensando exclusivamente en su nuevo dispositivo, el iPhone,
que estaba destinado a revolucionar el mundo de la telefona movil. Y como viene siendo
33
tradicional con todos los productos Apple, cuya poltica consiste en crear un ecosistema
propio, cerrado, basado en la eficiencia, el dise
no y la facilidad de uso, su nuevo sistema
operativo sera exclusivo y no podra ser modificado por nadie.
2.3.1. Lenguajes
De cara al programador, aunque Java y Objective-C son dos lenguajes orientados a ob-
jetos cuya sintaxis se inspira en C, no es en absoluto lo mismo trabajar con ellos. Para
empezar la sintaxis, a
un teniendo la misma base, es mucho mas legible en el caso de Java.
Objective-C obliga a emplear largas lneas de codigo con caracteres que no son habituales
en la mayora de lenguajes de programacion. Si el programador tiene experiencia previa,
debido a la naturaleza multiplataforma de Java, es probable que alguna vez haya trabajado
con el o al menos este familiarizado con sintaxis parecidas. Por contra si el programador
no tiene experiencia previa en iOS o Mac OS X, Objective-C sera un completo desconocido
para el y deber
a emplear tiempo en familiarizarse. Ademas, como Java es un lenguaje muy
conocido, resulta m
as sencillo encontrar documentacion extra o consultar dudas con otros
programadores puesto que la comunidad Java es mayor y hay mas bibliografa disponible.
Una de las diferencias fundamentales entre ambos lenguajes es que, mientras que Java se
desarroll
o con la idea de resultar mas sencillo de cara al programador ahorrandole las tareas
34
de bajo nivel que tena C, Objective-C, al ser un superconjunto de este, las conserva todas.
La mas importante sin duda es el manejo de memoria. Mientras Java se olvida de punteros,
de reservar memoria y liberar espacio, dejando todo el trabajo al recolector de basura de
turno (el de Android en este caso), Objective-C, puesto que iOS no dispone de el, debe
lidiar con ello. O deba, ya que la salida del reciente iOS 5 ha supuesto un gran cambio en
este sentido. Sigue sin tener implementado un recolector de basura propiamente dicho, pero
tiene un Automatic Reference Counting (ARC). Mientras un recolector de basura pierde
recursos del hardware durante el proceso de liberar memoria, el ARC lo que hace es insertar
la logica de la gesti
on de memoria dentro del codigo durante el proceso de compilado. De
esta manera logramos tener la eficiencia que da la gestion manual de memoria, sin perder
tiempo pensando en ella ni la seguridad que da un recolector de basura, pero sin sacrificar
rendimiento por el camino.
Como apunte final, hablando de rendimiento, en general podemos decir que la dupla iOS y
Objective-C consigue mejores resultados que Android y Java. Esto de nuevo tiene que ver
con sus filosofas. Objective-C es un lenguaje cuyas aplicaciones se compilan directamente
en codigo ejecutable para el procesador. Esto es posible porque Apple tiene una filosofa
cerrada y toda aplicaci
on se ejecutara u
nicamente en las CPU que ellos decidan ensamblar
en sus dispositivos. Por otro lado, como Android es un SO abierto destinado a multitud de
dispositivos diferentes con procesadores igual de diversos, y no es recomendable un sistema
que obligue a compilar una aplicacion para cada tipo de procesador, decidieron dise
nar una
maquina virtual intermedia sobre la cual funcionaran sus aplicaciones. Esto claro tiene un
coste en cuanto a rendimiento [24, 25].
Tanto Apple como Google tienen a disposicion de los futuros desarrolladores un completo
SDK y toda la documentaci
on necesaria para configurarlos y empezar de cero. Ambos son
accesibles de manera gratuita, pero en el caso de Apple hay una serie de consideraciones
35
que pueden hacer que esa afirmaci
on no sea del todo cierta. En primer lugar, Xcode, que es
como se llama el IDE para desarrollar tanto para iOS como para Mac OS X, solo funciona
en un ordenador Mac. As pues, si no se dispone de uno, es necesario efectuar un desembolso
inicial de al menos 699 euros para comprar uno. Si ya se dispone de un Mac, el siguiente
paso es hacerse una cuenta de desarrollador. La version gratuita de esta cuenta permite
descargar el SDK y empezar a programar, pero no permite distribuir tus aplicaciones ni
testearlas en dispositivos iOS fsicos, u
nicamente en el simulador que viene con el kit de
desarrollo. La versi
on de pago no tiene estas restricciones y cuesta 99 dolares al a
no. Adem
as
para poder trabajar con la u
ltima version del SDK y desarrollar as para la u
ltima versi
on
de iOS, es necesario tener instalado en el Mac la u
ltima version de Mac OS X. En caso
contrario habr
a que comprarlo e instalarlo. Por u
ltimo tambien hay que tener en cuenta
que para testear tus aplicaciones iOS es necesario disponer en un iPhone, iPad o un iPod
Touch, que no son dispositivos baratos, en cambio en Android tienes una gran variedad de
dispositivos donde para elegir.
36
Finalmente, una vez tenemos la aplicacion lista, siempre es recomendable testearla en varios
de los dispositivos sobre los que podra funcionar. En el caso de iOS esto se reduce a menos
de una decena. En cambio en Android, al estar mucho mas fragmentado, directamente es
imposible hacerlo. Esto puede provocar que en alguno de los dispositivos el rendimiento
no sea el esperado o que la interfaz grafica se vea desajustada en una pantalla de menor
tama
no que la utilizada durante el testeo.
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.
37
Capitulo 3
3. Dise
no de la aplicaci
on
A continuaci
on describiremos las funcionalidades de la aplicacion desarrollada:
38
La aplicaci
on deber
a mostrar en una pantalla el listado de hornos organizado por
provincias, comarcas y poblaciones.
Siguiendo el esquema del apartado anterior, en este punto detallaremos los requisitos no
funcionales.
Versi
on del sistema operativo
La aplicaci
on deber
a funcionar en todos los dispositivos Android que tengan instalada
la versi
on 2.3.3 (o superior) del sistema operativo. En dispositivos iPhone, la aplicaci
on
deber
a funcionar en todos aquellos que tengan la version 5.0 de iOS, o superior.
Acceso a la aplicaci
on
La aplicaci
on deber
a poder descargarse gratuitamente desde las plataformas de dis-
tribuci
on oficiales de Google y Apple: Google Play y App Store respectivamente.
Idioma
La aplicaci
on deber
a estar disponible al menos en catalan.
Lenguaje de programaci
on
39
La aplicaci
on Android estar
a desarrollada en Java, mientras que la version para iOS
estar
a desarrollada en objective-C.
Tiempos de carga
Con el fin de hacer que la aplicacion sea los mas agil posible, se minimizaran los
tiempos de carga. Esto implica reducir sobre todo los accesos a la base de datos y al
fichero pList que contiene la informacion de los hornos.
Aplicaci
on de mapas
Para poder indicar las rutas, el dispositivo movil debera tener instalada la aplicaci
on
de mapas que viene por defecto en el sistema operativo.
Tarjeta SIM
Para poder hacer uso de la funcion de telefonear a los hornos, el dispositivo movil
deber
a tener insertada una tarjeta SIM operativa.
En este apartado vamos a mostrar una serie de diagramas de estado que se han hecho para
detallar el comportamiento de las funcionalidades basicas, de las diferentes pantallas y la
navegaci
on entre ellas.
A continuaci
on detallamos los procesos que la aplicacion lleva a cabo cuando empieza a
ejecutarse.
40
Cargar BBDD Error
[Si es la
primera vez]
[Si localizacin
no disponible]
Inicializar
Pantalla Mapa
[Si no es la aplicacin [Si localizacin
primera vez] disponible]
Mostrar Posicin
Mostrar Hornos
Cercanos
Cargar BBDD
Todos los datos de los hornos de los que dispone la aplicacion se encuentran en un
fichero formato pList que fue proporcionado por el grupo de hornos. Acceder a estos
datos directamente es un proceso lento, por lo que se ha optado por almacenarlos
durante la primera ejecuci
on en una base de datos y leerlos desde ah en el futuro.
Inicializar Aplicaci
on
En esta fase se ponen en marcha los servicios de localizacion del dispositivo movil y
se inicializan los objetos necesarios para poder leer la base de datos.
Mostrar Posici
on
Este proceso es el encargado de determinar las coordenadas actuales del dispositivo y
representarlas en el mapa.
41
no superior a 2 kil
ometros. Una vez se obtiene la lista de hornos que cumplen con el
requisito se muestra un marcador para cada uno de ellos en la pantalla del mapa.
A continuaci
on se muestra un par de esquemas para entender la navegacion en funciona-
miento general de la aplicaci
on. En la figura 18 se muestra la navegacion entre pantallas.
Pantalla Lista
Hornos
Pantalla Mapa
Pantalla Vista
Horno
Pantalla Hornos
Distancia
Al ejecutarse la aplicaci
on en primer lugar aparecera la pantalla Mapa. Haciendo uso del
men
u podremos desplazarnos libremente por tres pantallas: Mapa, Lista Hornos y Hornos
Distancia. Adem
as desde lista podremos ver la pantalla Vista Horno, que al mostrarse ocu-
para el lugar de Lista Hornos en el men
u. Esto significa que podremos movernos libremente
entre Mapa, Vista Horno y Hornos Distancia. Para volver a la lista habra que situarse en
Vista Horno y retroceder a la lista. En la proxima seccion veremos en detalle el funciona-
miento de la pantalla Lista Horno para entenderlo mejor.
42
El siguiente esquema muestra la ubicacion de las funcionalidades en las distintas panta-
llas y como nos desplazamos por la aplicacion a traves de ellas.
Pantalla Mapa
Seleccionar
marcador
Mostrar Hornos
Mostrar Ruta Mostrar Posicin
Cercanos
Seleccionar Seleccionar
horno distancia
Pantalla Mapa
Esta es la primera pantalla que cargara la aplicacion. Ademas al hacerlo se mostrara un
marcador indicando la posicion de cada uno de los hornos que hay cerca de la posici
on
geogr
afica del dispositivo. Esa posicion sera visible en todo momento (siempre que sea
posible calcularla) y se podr
a centrar el mapa en ella pulsando un boton. Por u
ltimo
podremos ver la ruta a alguno de los hornos que este mostrandose en ese momento.
Esta u
ltima funci
on dejar
a la aplicacion ejecutandose en segundo plano y mostrara la
aplicaci
on de mapas del sistema operativo con la ruta trazada.
43
Pantalla Lista Hornos
La u
nica funci
on de esta pantalla sera navegar por la lista de hornos y seleccionar
uno, que se mostrar
a en la Pantalla Vista Horno
44
la lista como si de un
arbol se tratase, de forma que seleccionando uno de los nodos de cada
nivel pasamos a ver el siguiente, tal y como se muestra en la figura 20 :
Pantalla Vista
Horno
45
Provincia Comarca Poblacin Horno
Pantalla
Mapa
En esta secci
on vamos a dise
nar los diagramas de secuencia de las funcionalidades m
as
importantes de la aplicaci
on. Mostraremos las relaciones entre las clases y los metodos que
se ejecutan en cada momento. Es necesario tener en cuenta que las dos aplicaciones de este
proyecto (iOS y Android) no tienen las mismas clases. Esto es debido a que las libreras del
SDK de una y otra tecnologa permiten hacer las cosas de manera diferente. Una misma
funcionalidad puede resultar m
as sencilla de implementar gracias al uso de estas libreras y
requerir menos lneas de c
odigo, dando como resultado una organizacion diferente de clases.
Es importante destacar que estas diferencias en ning
un momento han perjudicado ni a la
claridad del c
odigo ni a la posible reusabilidad del mismo. En el siguiente captulo veremos la
implementaci
on con m
as detalle, ahora u
nicamente nos interesa conocer esto para entender
los diagramas de secuencia que vienen a continuacion.
La siguiente figura muestra la equivalencia entre los nombres de las clases que vamos a
utilizar en los diagramas y las clases que aparecen en las aplicaciones.
46
Capa Nombre genrico iOS Android
El nombre generico de las clases que vemos en la figura 21 sera el utilizado el los diagramas.
Las clases que aparecen agrupadas lo estan porque su funcionamiento es totalmente equi-
valente. Por eso es posible asignarles un u
nico nombre generico para los diagramas y ganar
as claridad en estos. Se
nalar tambien que las clases escritas en azul son libreras del SDK.
47
3.4.1. Inicio de la aplicaci
on
Usuario
:CtrlMapa GestorAplicacin GestorBBDD :DBObject GestorLocalizacin
<<Actor>>
inicio
inicializarAplicacion()
inicializarBBDD() new()
opt [ 1 vez ]
leerPList()
insertarHornos()
inicializarLocalizacion()
loop [ TRUE ]
getLocation()
loc
draw(loc)
obtenerHornosDistancia(2)
listaHornos
m:Marcador
draw(m)
48
Cuando el usuario inicia la aplicacion se carga automaticamente la Pantalla Mapa como
pantalla de inicio y su clase responsable es CtrlMapa. Automaticamente se llama al metodo
inicializarAplicaci
on() de la clase estatica GestorAplicacion. Este metodo realiza las tareas
que son necesarias para poner a punto el programa. En primer lugar se inician los objetos
de la base de datos mediante el metodo inicializarBBDD() de la clase GestorBBDD. Este
crea un nuevo objeto DBObject, que ademas de poner a punto la BBDD lee el fichero
pList y guarda los datos de los hornos en la base de datos si es la primera vez que se
ejecuta la aplicaci
on. Acto seguido GestorAplicacion inicializara los objetos que se encargan
de obtener la localizaci
on geogr
afica con el metodo inicializarLocalizacion() de la clase
GestorLocalizaci
on. Acto seguido CtrlMapa lanza un proceso asncrono que ira solicitando la
posicion a GestorLocaci
on con el metodo getLocation() y la indicara en el mapa. Finalmente
llamara al metodo obtenerHornosDistancia() de GestorBBDD con el valor 2 para obtener
la lista de hornos que est
an a menos de 2 kilometros de distancia y creara un marcador
para cada uno de ellos que dibujara en el mapa. La aplicacion restara a la espera de que el
usuario ejecute nuevas acciones.
49
3.4.2. Mostrar Horno Seleccionado
Usuario
:CtrlLista GestorBBDD :CtrlHorno :CtrlMapa
<<Actor>>
ir a la lista
nivel := 1
obtenerComarcas(s) [ nivel = 2 ]
obtenerPoblaciones(s) [ nivel = 3 ]
obtenerHornos(s) [ nivel = 4 ]
lista
mostrar(lista)
elegir tem s
nivel ++
h:Horno
new(s)
new(h)
dibujarHorno(h) new(h)
draw(m)
En primer lugar el usuario debe dirigirse a la Pantalla Lista Hornos a traves del men
u de
la aplicaci
on. Como se vi
o en el captulo anterior, esta pantalla funciona como un arbol y
cada vez que avanzamos por los niveles del arbol los nodos cambian, cosa que se ve reflejada
en los tems que muestra la lista. Nada mas cargar la pantalla se establece el valor de
50
la variable nivel a 1. Cada vez que el usuario selecciona un tem incrementa este nivel y
cambian los valores de la lista. Estos valores se solicitan a la clase GestorBBDD con los
diferentes metodos que vemos en el diagrama. Cuando el valor de nivel es igual a 4 los
tems de la lista ser
an los nombres de los hornos. Si el usuario selecciona uno creara un
objeto de la clase Horno con el valor que ha seleccionado y se llamara al controlador de la
Pantalla Vista Horno, CtrlHorno, para cargar la pantalla con los valores del objeto Horno.
Acto seguido, cuando el usuario presione un boton, invocara el metodo dibujarHorno() de
CtrlMapa pasando como valor el objeto Horno. En ese instante se mostrara esta pantalla en
primer plano, crear
a un objeto Marcador con los valores del objeto Horno y lo dibujara en
el mapa.
Usuario Sistema
:CtrlLista :CtrlHorno AppTelefono
<<Actor>> Operativo
new(h)
presionar "Telefonear"
apiTelefonear(h.telf) marcar
51
la figura 24 hasta el momento en el que el usuario debe pulsar uno de los dos botones
de la Pantalla Vista Horno. En este caso, si el usuario presiona el boton encargado de
ejecutar la funci
on para telefonear, el CtrlHorno recoge la accion y lanza una llamada
al sistema operativo para que ejecute la aplicacion que por defecto se encarga de realizar
llamadas telef
onicas. Una vez finalizada la llamada telefonica el control lo recupera el sistema
operativo y el usuario ser
a libre de realizar cualquier otra accion. Nuestra aplicacion no se
habra cerrado, seguir
a ejecut
andose en segundo plano a la espera de que el usuario vuelva
a necesitarla.
52
3.4.4. Mostrar Hornos Distancia
Usuario GestorBBDD
:CtrlProximos :DBObject :CtrlMapa
<<Actor>>
ir a la pantalla
elegir distancia
pulsar botn << d := distancia >>
obtenerHornosDistancia(d)
obtenerTodos()
listaTodos
GestorLocalizacin
getLocation()
loc
lista := null
loop [ ! h listaTodos ]
dH := distancia entre loc y h
alt [ "#$$" ]
lista.add(h)
lista
dibujarHornos(lista)
loop [ ! h lista ]
dibujarHorno(h)
53
necesitar
a la localizaci
on actual del dispositivo, que la obtendra del GestorLocalizacion.
Cuando tenga las dos cosas entrar
a en un bucle y comparara, para cada horno, la distancia
que hay entre el dispositivo m
ovil y el horno con la distancia que ha seleccionado usuario.
Todos los hornos que esten a una distancia igual o menor los a
nadira a una lista. Finalmente
se pasar
a esa lista a CtrlMapa y all se ejecutara el metodo dibujarHorno() para cada horno,
cuyo funcionamiento ya hemos visto en el diagrama de la figura 24.
El siguiente diagrama parte del estado en el cual hay marcadores de hornos en el mapa. A
esta situaci
on se puede llegar despues de los diagramas de las figuras 23, 24 o 26.
inicio
elegir marcador inicio := null
mostrarPanelRuta()
alt
indicar direccin inicio inicio := addr
(addr)
loc
inicio := loc
getCoordenadas()
destino
llamadaSO(URL)
abrirApp(URL)
54
La primera acci
on que debe realizar el usuario es seleccionar el marcador que se
nala al
horno donde desea ir. En ese instante el CtrlMapa mostrara un panel donde podra indicarse
el origen de la ruta y un bot
on para ejecutar la funcionalidad. El usuario podra indicar
cualquier direcci
on postal como inicio de la ruta o bien dejar por defecto la ubicaci
on
actual del dispositivo. Si elige esta segunda opcion CtrlMapa pedira a GestorLocalizaci
on
la ubicaci
on mediante el metodo getLocation(). Si por contra prefiere indicar una direcci
on
la aplicaci
on la transformar
a en coordenadas que usara como inicio de la ruta. Cuando el
usuario presione el bot
on para ver la ruta, CtrlMapa obtendra del marcador las coordenadas
del horno y las usar
a como destino. Despues compondra una direccion URL con el inicio y
el destino y se la lanzar
a al sistema operativo, que traducira la URL y abrira la aplicaci
on
de mapas que tenga por defecto (Google Maps en Android y Maps en iOS) y dibujara la
ruta. Al igual que ocurra en la funcionalidad Telefonear al Horno, la aplicacion quedara en
segundo plano a la espera de que el usuario vuelva a necesitarla.
55
Capitulo 4
4. Implementaci
on
4.1. Implementaci
on en iOS
Esta implementaci
on se ha llevado a cabo en el entorno Xcode y el lenguaje utilizado para
el desarrollo ha sido Objective-C.
Si observamos la figura 28, podemos ver las diferentes capas que componen la aplicacion y
como quedan emplazadas dentro de ellas las clases desarrolladas. Tambien incluiremos las
libreras del SDK de iOS que han sido necesarias para el desarrollo de esta aplicacion.
56
Capa Clase/Objeto Origen
Interfaz MainStoryboard.storyboard Desarrollado
MapKit.framework iOS SDK
Estas tres libreras contienen las clases y las funcionalidades mas basicas de un proyecto
iOS. Componen el n
ucleo de cualquier aplicacion.
CoreGraphics.framework
Es una librera desarrollada en C basada en el motor de graficos Quartz, que proporciona
mecanismos para el renderizado a bajo nivel de graficos en 2D. Se encarga entre otras co-
sas del dibujo de los gr
aficos, transformaciones, coloreado, paletas, degradados y matices,
muestra de im
agenes e incluso de archivos PDF.
Foundation.framework
57
Esta librera define la capa base sobre la que se sustentan las clases de Objective-C. Propor-
ciona un conjunto de objetos primitivos e introduce paradigmas no cubiertos originariamente
por el propio lenguaje con el objetivo de facilitar el desarrollo en Objective-C y favorecer
la portabilidad.
Foundation.framework incluye los objetos raz de la jerarqua de clases y aquellas clases que
representan los tipos de datos b
asicos, como los strings, los arrays de bytes o las colecciones
de objetos.
De entre las clases que han servido para desarrollar esta aplicacion, podemos destacar las
siguientes:
UIKit.framework
Esta librera proporciona las clases necesarias para la construccion y el manejo de la interfaz
58
grafica de la aplicaci
on. Se encarga de facilitar los mecanismos que controlan la aplicacion,
el manejo de eventos, la estructura de ventanas, los objetos basicos para el uso de interfaces
tactiles, etc.
La interfaz de esta aplicaci
on usa varias de estas clases. A continuacion se destacan las m
as
importantes:
UIControl: La clase UIControl es aquella de la que heredan todos los controles con los
que podemos interactuar en una interfaz tactil iOS. No es posible instanciar objetos
UIControl puesto que se trata de una interfaz, por lo que es necesario crear clases
que la implementen. Esta librera ya nos proporciona los controles basicos que puede
necesitar una aplicaci
on, como los botones, sliders, campos de texto, etc.
59
de los objetos UIView y se encarga entre otras cosas de recoger la interaccion del
usuario, redimensionar o reorientar las vistas y redistribuir los controles que contienen.
Todo UIView requiere de un UIViewController. En nuestra aplicacion ademas de
UIViewController se usan objetos que lo heredan. En primera lugar, para darle al
conjunto de la aplicaci
on una distribucion de pantallas accesibles por pesta
nas se ha
utilizado un objeto UITabBarController que se encarga de toda la logica relacionada
con esta funci
on, as que es el objeto del que dependen el resto de pantallas. Tambien
se ha utilizado un UINavigationController para el movimiento a traves de los niveles
de la Pantalla Lista Hornos y un UITableViewController para mostrar e interactuar
con la propia lista.
4.1.2. Interfaz
La implementaci
on de la interfaz en iOS 5 esta basada en ficheros .storyboard. Este fichero
no es m
as que un fichero XML pero que mediante el Interface Builder de Xcode se permite
su dise
no de una manera gr
afica. Los .storyboard son especialmente u
tiles en aplicaciones
multipantalla, puesto que no u
nicamente especifican las pantallas de la aplicacion y los ob-
jetos que contienen, tambien incluyen las relaciones entre pantallas e indican de que manera
se realizan las transiciones. Por poner un ejemplo, podemos arrastrar un boton dentro de
una pantalla y crear una relaci
on con otra pantalla. La relacion hara que al presionar el
boton de la primera pantalla se muestre la segunda sin necesidad de codigo extra. Esto
simplifica mucho el dise
no de este tipo de interfaces y reduce el codigo de la aplicacion.
A continuaci
on, en la figura 29, podemos ver un ejemplo de transicion en el storyboard
de nuestra aplicaci
on, concretamente la relacion que existe entre el objeto que controla las
pesta
nas y la Pantalla Mapa.
60
Figura 29: Ejemplo de transicion en storyboard
MapKit.framework
Esta librera contiene los objetos necesarios para trabajar con mapas. El mas importante, y
el que ha sido utilizado en la Pantalla Mapa, es el MKMapView, que es un tipo de UIView
que sit
ua en la pantalla un mapa que funciona gracias a la API de GoogleMaps. Tambien
proporciona metodos y propiedades para hacer zoom sobre el mapa, situar marcadores,
cambiar el tipo de vista e incluso para mostrar la localizadion geografica dentro del mapa
(siempre que sea posible obtenerla).
61
4.1.3. Capa de gesti
on
En esta capa encontramos todos las clases necesarias para tratar los eventos producidos en
la interfaz, tratarlos, hacer los c
alculos necesarios y devolver la informacion que el usuario
necesita.
VistaMapaController
Esta clase es la encargada del funcionamiento de la Pantalla Mapa. Se encarga principal-
mente de representar el mapa y permitir que el usuario interact
ue con el de una forma
sencilla y c
omoda. Tambien se encarga de tratar los eventos producidos en los botones,
en el mapa y sus marcadores. A continuacion se muestra un listado con sus metodos m
as
importantes.
Metodo Descripcion
borrarAnotaciones() Borra del mapa todos los marcadores de los hornos y deja
visible u
nicamente el indicador de la posicion geografica del
dispositivo.
62
mostrarHornosDistancia() Dibuja en el mapa los marcadores de los hornos situados a una
distancia igual o menor a la seleccionada.
Marcador
Esta clase hereda de la clase MKAnnotation de la librera MapKit.framework. Sirve para
representar un objeto marcador y poder situarlo en el mapa. No tiene metodos, tan solo
tres atributos para indicar las coordenadas del horno, su nombre y direccion.
LlistaFornController
Esta clase se encarga del funcionamiento de la Pantalla Lista Hornos. Se encarga de mostrar
los datos que corresponden en cada nivel de la lista y de gestionar los eventos tactiles que
produce. Estos son sus principales metodos:
Metodo Descripcion
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.
FornsProximsController
Es la clase que se encarga del funcionamiento de la Pantalla Hornos Distancia. Gestiona los
eventos del objeto tipo slider que sirve para seleccionar una distancia y de un boton. Sus
metodos m
as importantes son:
64
Metodo Descripcion
Forn
Esta clase es la que representa a un horno. Contiene todos los atributos necesarios para
trabajar con ellos en esta aplicacion: nombre, direccion, telefono, coordenadas... Es una
subclase de NSManagedObject, que es una clase generica que aporta todo el comportamien-
to necesario para facilitar el almacenamiento de estos objetos en base de datos. Necesita
que en el modelo de datos, que veremos en la capa de datos, exista una entidad asociada
con el mismo nombre.
CoreDataDelegate
Es la clase est
atica encargada de inicializar y realizar los accesos a la base de datos. Su fun-
cionamiento est
a basado en los metodos que proporciona la librera CoreData.framework y
requiere del modelo de datos. Sus metodos mas destacados son los siguientes:
65
Metodo Descripcion
Los metodos que devuelven datos de la bbdd tienen todos el mismos esquema. En la figura
30 podemos ver el c
odigo del metodo obtenerComarcas().
66
Figura 30: Metodo obtenerComarcas
AppDelegate
Esta es una clase que se genera automaticamente al iniciar un proyecto iOS y que contiene
los metodos que capturan los eventos relacionados con el ciclo de vida y los estados de
la aplicaci
on. Para la aplicaci
on desarrollada u
nicamente ha sido necesario implementar el
metodo que se lanza cuando el sistema operativo ha terminado de lanzar la aplicacion. En
ese momento llamamos al metodo initCoreData() de la clase CoreDataDelegate.
CoreLocation.framework
Esta librera contiene los metodos necesarios para trabajar con coordenadas y obtener la
posicion geogr
afica del dispositivo en un momento determinado. De entre sus clases, las que
han sido necesarias en este proyecto han sido las siguientes:
CLLocation
Representa un conjunto de coordenadas geograficas.
67
CLLocationManager
Permite obtener la localizacion actual del dispositivo, comprobar si el hardware para
obtenerla est
a disponible y establecer los criterios de obtencion de la misma (frecuencia
de actualizaci
on, metodo de obtencion, precison...)
CoreData.framework
Esta librera proporciona los mecanismos necesarios para el manejo y la persistencia de
datos en iOS. Aunque soporta varios formatos de archivos para su almacenamiento, para
nuestra aplicaci
on se ha optado por el uso de una base de datos SQLite. Las clases m
as
importantes que se han utilizado han sido las siguientes:
NSFetchRequest
Se utiliza para establecer los criterios de obtencion de los datos. Sera el equivalente
a construir una consulta SQL.
NSManagedObject
Su funci
on es crear un objeto en el modelo logico equivalente a una tabla de la base
de datos. De esta manera podemos trabajar directamente con dicho objeto y luego
guardar los cambios que en el se han producido.
NSFetchedResultsController
Es un contenedor de datos en el que se guardan los resultados obtenidos despues de
realizar una consulta a la base de datos.
ModeloDeDatos.xcdatamodeld
Este fichero representa el esquema de la base de datos. En el se especifican las tablas, sus
68
atributos y relaciones. Para la aplicacion desarrollada tan solo ha sido necesaria una tabla
para representar a los hornos:
Como podemos ver se han definido ocho atributos, todos ellos de tipo texto.
Atributo Funci
on
adreca Direcci
on postal del horno.
4.2. Implementaci
on en Android
La implementaci
on de la aplicaci
on en su version Android se ha llevado a cabo en java. Al
igual que hicimos en el apartado anterior, vamos a ver un esquema con las clases que han
sido necesarias organizadas por capas, incluyendo tambien las libreras externas.
69
Capa Clase/Objeto Origen
Interfaz Archivos XML Desarrollado
android.jar
Esta librera es la libera base de todo proyecto Android. Contiene las clases y objetos
principales del entorno Android y las funciones basicas para la gestion de la aplicacion, de
memoria, de datos, de la interfaz grafica, interaccion con el sistema operativo, accesos a los
recursos del telefono m
ovil, etc. Sus clases mas importantes son las siguientes:
Activity
70
Las Activity son el elemento principal de la interfaz grafica en un programa Android.
Son el equivalente a las ventanas en Windows.
View
Representan los controles que pueden colocarse dentro de los Activity. Esta librera
nos proporciona un gran n
umero de views basicos (botones, cuadros de texto, listas...)
pero tambien podemos heredar la clase y crearlos nosotros.
Service
Son componentes sin representacion grafica que se ejecutan en segundo plano. Cum-
plen las mismas funciones que los servicios de otros sistemas operativos: pueden uti-
lizarse para actualizar datos, lanzar notificaciones, mostrar activities, etc.
Content Provider
Es el mecanismo de Android que permite compartir datos entre dos aplicaciones.
Broadcast Receiver
La funci
on de estos objetos es detectar eventos producidos por el sistema operativo
(batera baja, sms entrante, localizacion actualizada...) o por otras aplicaciones.
Intent
Son mensajes que envan las aplicaciones Android para comunicarse entre ellas o
incluso para comunicarse entre componentes de una misma aplicacion. Con los intent
es posible ejecutar una aplicacion desde cualquier otra, iniciar un service, enviar un
mensaje broadcast para que lo detecten los broadcast receiver que haya a la escucha,
mostrar un activity desde otro, etc.
4.2.2. Interfaz
71
interfaz gr
afica.
Los archivos XML que han sido necesarios para el desarrollo de esta aplicacion han sido los
siguientes:
main.xml
Representa el xml principal, el que se lanza en primer lugar y en nuestro caso es la
Pantalla Mapa.
llistat forns.xml
Es el xml que contiene el dise
no de la Pantalla Lista Hornos.
vista forn.xml
Contiene el dise
no de la Pantalla Vista Horno.
forns proxims.xml
Es el xml de la Pantalla Hornos Distancia.
Otros
Se han necesitado otros xml para definir el men
u de pesta
nas, el aspecto personalizado
de algunos botones o el globo que aparece al presionar un marcador.
maps.jar
Esta libera contiene los elementos necesarios para trabajar con mapas. Su clase principal es
MapView, que es una pantalla que es un control que contiene un mapa para colocarlo sobre
un activity. Permite establecer el zoom del mapa, colocar algunos botones preestablecidos
sobre el y a
nadir capas con informacion visual. Tambien es necesario destacar la clase Geo-
Point, que sirve para se
nalar un punto en el mapa previa transformacion a n
umeros enteros
de las coordenadas geogr
aficas.
72
FornsIGPActivity
Esta clase es el equivalente a la clase VistaMapaController de iOS. Representa la pantalla
mapa y controla toda interacci
on que el usuario realice con ella. Sus metodo mas importantes
son:
Metodo Descripcion
Dada la importancia de los objetos intent en el sistema Android, vamos a ver en la figura 33
el fragmento del c
odigo del metodo mostrarRuta() donde se lanza el Intent para comunicarse
con la aplicaci
on Google Maps.
73
Figura 33: Ejemplo de uso de un Intent
LlistatActivity
Esta clase es la encargada de controlar la Pantalla Lista Hornos. Su cometido es el mismo
que la clase LlistaFornController en iOS. Sus metodos a destacar son:
Metodo Descripcion
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.
FornsProximsActivity
Es la clase que controla la Pantalla Hornos Distancia. Sus u
nicos metodos a destacar son:
Metodo Descripcion
BalloonMap
Esta clase representa los marcadores en la aplicacion Android. Ha sido necesario crear le
marcador desde cero, tanto su apariencia como la deteccion de los eventos que se producen
sobre el. Hereda de la clase abstracta ItemizedOverlay de maps.jar, que son objetos capaces
75
de a
nadirse como capa a un objeto MapView y ver su representacion grafica en el punto
se
nalado y tambien detectar cuando el usuario lo presiona. Su metodo mas imporante por
lo tanto es el evento onTap(). Cuando se produce el marcador muestra los datos del horno
en un bocadillo sobre el y lanza un evento que recoge FornsIGPActivity para que muestre
los controles que permiten solicitar una ruta hasta el horno.
CapaPosicion
Esta clase hereda de la clase Overlay de la librera maps.jar. Los objetos Overlay permi-
ten dibujar sobre ellos cualquier cosa y luego colocarlos sobre el mapa, de manera que lo
dibujado en ellos se vea superpuesto. En este caso lo utilizamos para mostrar la posici
on
geografica del usuario. En su metodo draw obtenemos la localizacion geografica, si es que
ha cambiado desde la u
ltima vez, y dibujamos un circulo sobre la posicion indicada.
Forn
Es la representaci
on l
ogica de los hornos. Contiene todos los atributos que conforman un
horno y sus metodos para obtenerlos y editarlos. Tambien contiene un metodo save() para
guardar el objeto Forn en base de datos.
GestorAplicacion
Es una clase est
atica encargada de llevar a cabo la funciones basicas de la aplicacion y
contiene los metodos necesarios para controlar las transiciones entre las diferentes pantallas.
Sus metodos m
as importantes son:
76
Metodo Descripcion
GestorBBDD
Esta clase est
atica recoge las peticiones de acceso a base de datos de los objetos de la capa
de gesti
on y los traslada la clase FornDAO de la capa de datos. Tambien se encarga del
resto de tareas relacionadas con la base de datos. Sus metodos a destacar son los siguientes:
Metodo Descripcion
77
obtenerProvincias() Devuelve las diferentes provincias a las que pertenecen
los hornos de la base de datos.
XMLPListParser
Es la clase encargada de leer directamente del fichero pList. Su cometido es leerlo como el
fichero xml que es en realidad y colocar las cadenas de texto en una serie de hashtables anida-
das. El objetivo es que la informacion quede bien estructurada para que el GestorBBDD
acceda a ella f
acilmente.
Esta capa contiene las clases relacionadas con la obtencion de la posicion geograficas del
dispositivo.
GestorLocalizacion
Esta clase est
atica se encarga de iniciar el proceso de localizacion. Para ello debe crear un
78
objeto de la clase LocationWaiter y esperar a que este le enve eventos. Su metodo m
as
importante es getLocalizaci
on(), que devuelve a quien lo llame la ubicacion actual del dis-
positivo.
LocationWaiter
Esta clase se encarga de arrancar un Thread que continuamente consultara las coordena-
das obtenidas por el objeto de la clase Localizador. Si ese objeto pasado un tiempo no ha
obtenido ningunas coordenadas, LocationWaiter enviara un evento al GestorLocalizaci
on
indicando que no ha sido posible obtener la localizacion actual. Por contra, si devuelve
coordenadas y son diferentes a las que haba devuelto en alg
un momento previo, lanzara un
evento indicando que el dispositivo ha cambiado de ubicacion.
Localizador
Esta clase crea los objetos que se utilizan en Android para obtener la localizacion geografica.
Estos objetos son el LocationListener y el LocationManager. Una vez creados, crea tam-
bien un objeto de la clase ProcesadorUbicacion y le pasa por parametro los dos objetos
proveedores. En ese momento iniciara un thread para gestionar los eventos que recoge el
LocationListener, entre los que se encuentra el evento onLocationChanged, que se produce
cuando hay un cambio en la posicion del dispositivo.
ProcesadorUbicacion
Se encarga de inicializar los objetos proveedores de localizacion que le ha suministrado la
clase Localizador y tratar sus eventos para dejar definido el metodo de obtencion de la
ubicacion geogr
afica. En primer lugar establece la b
usqueda en modo GPS. Si despues de
un tiempo determinado el dispositivo es incapaz de localizar el n
umero de satelites adecuado
79
para obtener una localizaci
on GPS, pasa a intentar obtener su posicion con tecnicas a traves
de la red m
ovil.
En esta capa se encuentran las clases mas ntimamente ligadas con el manejo de la base de
datos.
DataBaseCreator
Es clase hereda de la clase SQLiteOpenHelper. Su funcion es crear o actualizar la base de
datos. Tiene dos atributos: DATABASE NAME y DATABASE VERSION. En primer lugar
busca un objeto en el sistema de archivos con el nombre DATABASE NAME, si no existe
lo crea y lanza un evento onCreate que recogera la clase DataBaseInit. Si existe y su versi
on
es inferior a DATABASE VERSION, lanza un evento onUpgrade.
DataBaseInit
Esta clase recoge los eventos producidos en DataBaseCreator. Si recibe un evento onCreate,
ejecuta la query que crea la tabla para guardar los datos de los hornos. Si recibe un evento
onUpgrade borra los datos de la tabla para que se vuelvan a leer los datos del archivo pList.
FornDAO
Esta clase es la encargada de lanzar los accesos a la base de datos. Sus metodos mas im-
portantes s
on:
80
Metodo Descripcion
En esta secci
on vamos analizar las diferencias que han habido durante el proceso de imple-
mentaci
on de las dos aplicaciones.
81
4.3.1. Lenguaje de programaci
on
Puestos a analizar las diferencias entre ambas implementaciones, el primer punto donde
detenerse debe ser el propio lenguaje. El uso de Java para Android ha resultado ser mucho
mas amigable que Objetctive-C. En primer lugar el tiempo de adaptacion al lenguaje fue
nulo. Java es uno de los lenguajes que mas extendido esta hoy da y ademas su sintaxis es
bastante com
un, por lo que de no haberlo conocido previamente, igualmente habra sido
sencilla la adaptaci
on.
Por contra Objective-C requiri
o de varias horas dedicadas exclusivamente al aprendizaje
del lenguaje. Una vez conocidas las bases, el uso de Objective-C no difiere mucho del uso de
Java puesto que ambos son lenguajes orientados a objetos, pero termina por dar resultados
menos legibles de cara al programador. La sintaxis del lenguaje es poco intuitiva y repasar
el funcionamiento de cualquier metodo acaba requiriendo mas tiempo que en Java.
82
brinda este u
ltimo para determinar en el propio fichero xml las transiciones entre pantallas.
En iOS existen una serie de controles destinados exclusivamente a este cometido, as que
u
nicamente a
nadiendolos a tu interfaz y definiendo una serie de relaciones entre las pantallas
ya tenemos el comportamiento deseado. En Android en cambio ha sido necesario controlar
todo este proceso mediante programacion. Como consecuencia tenemos que en iOS esta
tarea tuvo un coste en tiempo muy reducido y nulo en cuanto a lineas de codigo, mientras
que en Android llev
o m
as tiempo y fue necesario programar varios metodos.
4.3.3. Localizaci
on
Mostrar la ubicaci
on geogr
afica del dispositivo ha sido mucho mas sencillo en iOS que en
Android. Por un lado, en iOS, esta opcion la tenemos totalmente integrada en el control
MKMapView. El mismo control que muestra un mapa por pantalla, tiene un atributo boo-
leano llamado showsUserLocation, as que simplemente asignandole como valor CIERTO ya
dibuja en el mapa un completo marcador que no solo indica la posicion, tambien la precisi
on
con la que se ha obtenido. El mismo objeto se encarga de elegir el mejor metodo para ob-
tener la localizaci
on seg
un las circunstancias. Si mas tarde necesitamos obtener el valor de
las coordenadas para por ejemplo utilizarlas como punto de inicio de una ruta, simplemente
debemos acceder a otro atributo de la clase MKMapView llamado userLocation.
En Android, en cambio, el proceso es algo mas costoso. En primer lugar obtener la loca-
lizacion y dibujarla en el mapa son dos tareas separadas. Para obtener la localizacion es
necesario crear una clase LocationListener que gestione los eventos relacionados con la lo-
calizaci
on que puedan producirse. Para que estos tengan lugar, antes hay que inicializar
un objeto LocationManager y pedirle que empiece a buscar la posicion. Si indicamos que
empiece a buscarla como GPS y no encuentra ning
un satelite, debemos crear un sistema
capaz de detectarlo y pedirle que entonces la busque a traves de la red movil. As pues, una
vez montado todo este sistema, podremos recibir las coordenadas de nuestra posicion, pero
claro, ya nos habr
a llevado algo de tiempo y unas cuantas clases. Llegados a este punto hay
que se
nalar las coordenadas obtenidas en el mapa. Para ello es necesario crear una clase tipo
83
Overlay o un ItemazedOverlay, que son dos tipos de objeto que permiten dibujar encima de
un MapView. As pues hay que escoger una imagen como marcador, o simplemente dibujar
un punto, colocarlo en el Overlay y despues colocar este sobre el MapView como si fuera
una capa. Adem
as hay que asegurarse de que la posicion se va actualizando regularmente,
por lo que es necesario crear todo esto en alg
un tipo de thread.
El uso de la API de mapas tanto en iOS como en Android es bastante comodo. Ambas
libreras proporcionan un control que al colocarlo en una pantalla muestra un mapa. Es al
colocar marcadores cuando encontramos algunas diferencias. En Android, como ya hemos
comentado, es necesario crear una clase y asignarsela como capa al mapa. El principal
problema es que esta clase est
a totalmente vaca de contenido, no tiene ninguna imagen
que dibujar como marcador, ni lanza ning
un evento cuando el marcador es presionado ni
tampoco dispone de alg
un globo de texto con informacion personalizable. Todo esto ha
sido necesario crearlo de cero. En iOS, en cambio, solo es necesario crear una clase con
el protocolo MKAnnotation y sin necesidad de a
nadirle ning
un metodo ya tendremos un
marcador con imagen predeterminada que podremos presionar y que mostrara un bocadillo
con la informaci
on que le asignemos. Si deseamos realizar alguna modificacion sobre el
marcador predeterminado, como cambiar su apariencia o a
nadir alg
un boton al globo de
texto, habr
a que sobreescribir un metodo de la clase MKMapView.
Otro punto a destacar sobre el uso de mapas es que el mapa en Android requiere una
clave de licencia de Google Maps para funcionar. En la pagina web para desarrolladores de
Android encontramos instrucciones para conseguir la clave y como utilizarla. Ademas esta
clave es diferente si el mapa se va a utilizar en un entorno de desarrollo o si se va a utilizar
en el producto final, por lo que durante el desarrollo de esta aplicacion ha sido necesario
obtener dos claves: una cuando empezo el desarrollo para poder testear y otra cuando se
compilo la aplicaci
on para subirla a Google Play.
84
4.3.5. Valoraciones
A nivel general las diferencias entre ambas implementaciones han hecho que el desarrollo
para iOS haya sido bastante m
as rapido y sencillo. Si bien es cierto que el proceso de
aprendizaje de Objective-C fue un punto desfavorable, la gran cantidad de recursos que
proporcionan las libreras del SDK de iOS han hecho el desarrollo mas satisfactorio.
85
Figura 35: Pantalla Mapa con controles para trazar ruta
86
Figura 37: Pantalla Lista Hornos (nivel comarcas)
87
Figura 39: Pantalla Vista Horno
88
Capitulo 5
5. Planificaci
on y Costes
La siguiente tabla nos muestra por un lado las horas estimadas en un principio y las que
finalmente han sido necesarias.
Analisis de requisitos 30 25
Especificaci
on 16 16
Dise
no 40 38
Implementaci
on Android 160 176
Implementaci
on iOS 176 152
Testeo 30 29
Documentaci
on 140 127
En el desarrollo de la aplicaci
on han intervenido tres figuras: el jefe de proyecto, el analista
programador y el becario.
89
una decima parte de las horas empleadas en la documentacion.
Analista programador: Le corresponden las horas del estudio previo, tambien del
an
alisis funcional, la especificacion, el dise
no, ambas implementaciones y la documen-
taci
on.
Becario: Para la fase de testeo fue contratado un becario que se encargo del testeo
de la aplicaci
on.
Para analizar los costes de la aplicacion, vamos a ver en primer lugar el salario por horas
de las tres figuras implicadas:
Jefe de proyecto 60 e
Analista programador 30 e
Becario 0e
Becario 29 horas 0e
Total 20430 e
90
Gasto Coste
iPhone 599 e
Telefono M
ovil Android 300 e
Total 2744 e
Una vez calculados todos los costes, el gasto real del proyecto habra sido el siguiente:
Costes Cantidad
Total 23174 e
91
Capitulo 6
En este captulo, finalmente, vamos a valorar el estado final del proyecto, lo que ha supuesto
para el autor y las mejoras que se pueden a
nadir en futuros proyectos.
6.1. Conclusiones
En general podemos decir que el desarrollo del proyecto ha sido satisfactorio. Todos los
objetivos marcados se han alcanzado y ambas aplicaciones estan disponibles para descargar
en Google Play y AppStore.
Aunque la planificaci
on se haba hecho partiendo de un escenario pesimista, hay que se
nalar
que se ha reducido la estimaci
on de tiempo prevista. En este sentido la implementacion de
ambas aplicaciones ha jugado un papel sorprendente en ambos casos. En un principio se
haba estimado que llevara menos tiempo desarrollar la aplicacion de Android que la de iOS
porque el programador ya conoca el lenguaje Java y el entorno de desarrollo, mientras que
en iOS todo era nuevo. Despues la realidad fue diferente. El SDK y las librera disponibles
jugaron un papel vital. Por un lado en Android se dio la necesidad de desarrollar casi desde
cero partes cruciales, por el otro nos encontramos mas facilidades de las esperadas en este
sentido y finalmente se vio reflejado en los tiempos de desarrollo.
92
son lo suficientemente amplios como para sentirme animado a realizar mis propios proyectos
y distribuirlos en las correspondientes plataformas. Y he de decir que ese animo es algo que
no senta desde hace mucho tiempo.
Trabajar en un consultora, realizando proyectos clonicos en tiempo record para otras em-
presas cuyos intereses est
an lejos de ser los mos es algo que me ha ido desgastando y que
converta algo tan vocacional, como lo es para m el desarrollo de software, en un simple
trabajo que haca por obligaci
on. Este proyecto ha cambiado eso y vuelvo a sentir las ganas
de programar lo que a m verdaderamente me nace, y creo que las plataformas moviles son
un lugar id
oneo para ello.
Actualizaci
on de la lista de hornos
Durante el desarrollo actual, por temas de eficiencia, se decidio leer el archivo pList
u
nicamente la primera vez que se ejecuta la aplicacion y guardar los datos en una
base de datos. El resultado ha sido muy satisfactorio pero nos da problemas si quere-
mos actualizar dicha lista en futuras versiones, puesto que ahora mismo no hay nada
implementado que permita leer de nuevo la lista sin desinstalar la aplicacion. Veo
prioritario desarrollar un sistema de actualizacion de versiones independiente del que
facilitan las plataformas de distribucion que permita leer el archivo pList de nuevo
cuando haya alg
un cambio. Incluso sera interesante considerar la opcion de disponer
de un servicio Web que facilitara la lista de hornos, as no sera necesario un cambio
de versi
on cada vez que se a
nadiesen nuevos hornos.
Implementaci
on en iPad y tablets Android
Si bien el desarrollo efectuado permitira ejecutar ambas aplicaciones en los tablet
disponibles con su sistema operativo, es necesario desarrollar una interfaz que se ajuste
93
al cambio de tama
no de la pantalla y si puede ser saque mas partido de una pantalla
tan grande.
94
Capitulo 7
7. Referencias
7.1. Geolocalizaci
on
[1] http://www.inteco.es/Seguridad/Observatorio/guias/Guia_Geolocalizacion
[2] http://en.wikipedia.org/wiki/Georeference
[3] http://en.wikipedia.org/wiki/Geocoding
[4] http://en.wikipedia.org/wiki/Geotagging
[5] http://en.wikipedia.org/wiki/Geolocation
[6] http://en.wikipedia.org/wiki/Mobile_phone_tracking
[7] http://www.gisdevelopment.net/technology/lbs/techlbs006.htm
[8] http://www.kriptopolis.org/geoposicionamiento-gsm-1
[9] http://www.rtve.es/noticias/20111115/como-borrar-tu-red-wifi-base-datos-google/
475608.shtml
[10] http://es.wikipedia.org/wiki/Sistema_de_posicionamiento_global
[11] http://es.wikipedia.org/wiki/GPS_Asistido
[12] http://en.wikipedia.org/wiki/Location_API_for_Java_ME
[13] http://developers.sun.com/mobility/apis/articles/location
[14] http://developer.android.com/guide/topics/location/index.html
[15] http://developer.apple.com/library/ios/#documentation/UserExperience/
Conceptual/LocationAwarenessPG/Introduction/Introduction.html
95
7.2. Representaci
on de Mapas
[16] http://en.wikipedia.org/wiki/Map_projection
[17] http://www.nationalatlas.gov/articles/mapping/a_projections.html
[18] http://es.wikipedia.org/wiki/Sistema_de_Informacion_Geografica
[19] http://www.openstreetmap.es/
[20] https://developers.google.com/maps/faq?hl=es-ES
[21] http://www.microsoft.com/maps/product/licensing_for_mobile.aspx
[22] http://cloudmade.com/about
[23] http://www.nutiteq.com/map-api
[24] http://gallir.wordpress.com/2011/12/07/android-ios-tiempos-de-respuestas-y-por-que
[25] http://www.sozpic.com/desarrollo-ios-vs-android-por-donde-empiezo/
[26] https://support.google.com/googleplay/android-developer/bin/answer.
py?hl=es&answer=113469
[27] https://developer.apple.com/programs/mac/distribution.html
7.4. Implementaci
on
[28] http://www.sgoliver.net/blog/?p=1313
[29] http://developer.android.com/index.html
[30] https://developer.apple.com
96