6-2-2012

|

PROJECTE DSA LOGISTIC EXPRESS

Víctor Alcázar Júlia Garrigós Albert Enrich Gerard Solé Rubén Vilches

1

Índex

1. Introducció ................................................................................................................................................. 2

2. Presentació de l’aplicació .......................................................................................................................... 2

2.1. Funcionalitats..................................................................................................................................... 2

2.2. Part del mercat que pot estar interessat per l’aplicació ................................................................. 2

3. Tecnologies i eines emprades ...................................................................................................................3

3.1. KML (XML) .........................................................................................................................................3

3.2. Jquery ................................................................................................................................................ 4

3.3. Google API ........................................................................................................................................ 4

3.4. CSS ..................................................................................................................................................... 4

4. Disseny i organització ............................................................................................................................... 6

4.1. General .............................................................................................................................................. 6

4.2. Aplicació Java (Gestor de l’administrador) ...................................................................................... 7

4.2.1. Localització del repartidor ....................................................................................................... 8

4.3. Aplicació Android (Repartidor) ........................................................................................................ 8

4.4. Web (Client) ...................................................................................................................................... 9

5. Els reptes més difícils .............................................................................................................................. 10

5.1. Interacció de l’usuari amb la web: javascript i css ......................................................................... 10

5.2. Localització del repartidor: GPS, API de Google Maps ................................................................. 12

5.3. Llista personalitzada: android listactivity ....................................................................................... 13

6. Planificació del projecte .......................................................................................................................... 14

6.1. Repartiment de tasques .................................................................................................................. 14

6.2. Diagrama de tasques ....................................................................................................................... 15

7. Conclusions .............................................................................................................................................. 15

2

1. Introducció

Logistic Express és un producte destinat a la venta y repartiment d’aliments a una cartera de clients. La seva funció és permetre que els clients puguin realitzar comandes, i que aquestes siguin gestionades per tal d’aconseguir que els productes arribin al client el més ràpid possible.

Un aspecte innovador que aporta Logistic Express és que a mentre s’estan realitzant les entregues, l’administrador de l’empresa pot saber en temps real la localització dels repartidors. De manera que, es pot comprovar si segueixen la seva ruta i per tant, detectar si algun repartidor està cometent alguna irregularitat.

El projecte guia de l’assignatura Disseny de serveis i aplicacions és la millor referencia que podíem tenir per dur a terme aquest projecte ja que consta dels mateixos components: una pagina web, una aplicació Java i una aplicació Android.

2. Presentació de l’aplicació

2.1. Funcionalitats

L’aplicació necessita d’una base de dades MySQL on s’emmagatzema tota la informació relativa als productes en venta, als treballadors, als clients i a les comandes. L’administrador podrà gestionar els productes, els treballadors i l’assignació de comandes a través de l’aplicació Java, la qual consta d’una interfície gràfica ordenada i amigable.

Un cop l’administrador assigna una comanda a un repartidor, aquest pot trobar tota la informació de la comanda i del client que l’ha realitzat, al seu telèfon mòbil (que incorpora Android). Al arribar al destí el repartidor marcarà la comanda com ha realitzada i automàticament s’actualitzarà la base de dades, de tal manera que l’administrador podrà veure la comanda com entregada a l’aplicació d’administració. A més, durant el trajecte, el treballador haurà de tenir el GPS activat per saber constantment la seva situació. En intervals de cinc minuts l’administrador rebrà aquestes dades per corroborar que el repartidor segueix la ruta establerta.

Els clients faran totes les seves gestions gràcies a la pagina web de l’empresa des d’on poden fer les comandes i consultar totes les que hagin fet.

2.2. Part del mercat que pot estar interessat per l’aplicació

L’aplicació pot interessar a qualsevol empresa que vulgui disposar d’una bona gestió dels productes i dels treballadors. Una empresa que permeti als clients fer les seves gestions des de qualsevol punt a qualsevol hora emprant la web. A més, si l’empresa disposa d’una flota d’automòbils per fer arribar els productes al client podrà saber en temps real la ubicació d’aquests.

En aquest cas, Logistic Express està enfocada al sector alimentari però aquesta filosofia de treball es pot extrapolar a altres camps.

3

3. Tecnologies i eines emprades

Per desenvolupar aquesta aplicació s’ha fet servir Eclipse Helios, aquest entorn ha permès programar en java, javascript, html, etc. Pel que fa a la base de dades, s’ha fet servir mysql, més endavant es detallarà el disseny de la mateixa. Per realitzar certes funcions a la web s’ha fet servir Javascript.

Pel que fa a l’intercanvi d’informació s’ha fet servir la llibreria httpclient que permet emprar els mètodes get i post d’HTTP per comunicar els servlets del servidor amb les aplicacions. Per al parsejat d’objectes (convertir-los a text pla de tal manera que es puguin enviar i després ser recuperats) s’ha fet servir JSON, concretament la llibreria de Google GSON.

A continuació es detallen alguns dels aspectes més importants de les tecnologies que s’han emprat en el projecte que no han estat explicades a classe.

3.1. KML (XML)

El llenguatge KML (Keyhole Markup Language) és un llenguatge basat en XML utilitzat per a fer representacions de dades geogràfiques sobre mapes. Permet representacions d’objectes i formes tan en 2D com en 3D. A continuació es mostra el format de KML utilitzat en aquest projecte juntament amb l’explicació dels paràmetres més importants.

<?xml version="1.0" encoding="UTF-8"?> <kml xmlns="http://earth.google.com/kml/2.1"> <Document> <Placemark> Bloc a representar <LineString> Les coordenades s’uniran per formar línies <coordinates> Dins del camp coordinates s’introdueixen totes les coordenades que es desitgin unir -3.75926664,40.32965991,0.000000 -3.75927499,40.32967242,0.000000 -3.76280636,40.32936246,0.000000 -3.76282401,40.32937803,0.000000 </coordinates> </LineString> </Placemark> <Placemark> Un altre bloc a representar <name>Josep Carnet</name> Títol que es mostrarà en clicar sobre el punt <description>Última posició a les 19:45:20</description> La descripció mostrada pel punt <Point> Cada coordenada representa un punt <coordinates> Per a cada punt s’ha de passar una coordenada -3.77623888,40.33736203,0.000000 </coordinates> </Point> </Placemark> </Document> </kml>

4

3.2. Jquery

JQuery són unes llibreries per a Javascript que milloren i faciliten molt l’ús d’aquest llenguatge. En aquest projecte bàsicament s’han utilitzat per a una funcionalitat molt concreta: poder realitzar peticions GET sense refrescar tota la pàgina web.

Com es veurà més endavant, a l’aplicació de Java, el mapa (veure Fig. 1) es va refrescant cada 5 minuts. Tanmateix, no es baixa tota la web de nou sinó que només s’actualitza la llista de repartidors i les dades del mapa corresponents als repartidors seleccionats.

Fig. 1 Captura de pantalla de la web amb el mapa i el recorregut d’un repartidor (en aquest cas el Sergi Castellví).

JQuery permet obtenir dades noves en temps real sense la interacció per part del usuari (automatitzant-ho tot). S’hauria pogut adaptar una altre solució, com ara refrescar tota la web, però això comportaria un problema, la pèrdua de les dades del mapa (seria necessari seleccionar de nou el repartidor).

3.3. Google API

Per altre banda, ha estat necessària la utilització de les Google Maps APIs, tan per la representació de posicions en el mapa com per obtenir i mostrar la ruta. Aquest servei de Google també proporciona la incorporació de dades geogràfiques (fitxer KML) al mapa.

El funcionament es basa en els principis d’una API, solituds client-servidor basades en JSON i intercanvi de valors. Per a realitzar la majoria de sol·licituds cal obtenir i utilitzar una clau proporcionada per Google, que els permet controlar l’ús del seu servei.

3.4. CSS

El CSS o també conegut com a Cascading Style Sheet permet donar format i estil a documents HTML. Es tracta de fulles on es recullen les propietats de cada objecte utilitzat en una web. Ajuda a donar molta qualitat visual a una pàgina web i alhora facilita el posicionament dels marcs en una web. Bàsicament es

5

tracta de donar propietats i característiques als Tags com ara <body>, <H1>, <div>, ... o bé a classes d’objecte. A continuació es pot observar la pàgina web de la empresa sense CSS (Fig. 2) i amb CSS (Fig. 3).

Fig. 2 Pàgina web sense emprar CSS.

Fig. 3 Pàgina web emprant CSS.

6

4. Disseny i organització

4.1. General

A la Fig. 4 es pot observar l’esquema general del projecte, en ell es poden veure els diferents elements que el formen: l’aplicació java, l’aplicació Android, el servidor i la web a la qual s’accedirà a través d’un navegador.

En lila es poden veure les servlets, en vermell les classes més rellevants i en verd la base de dades. Com es pot veure, per accedir a la base de dades, tots els servlets fan servir les funcions del DatabaseConnector. Aquesta classe conté les funcions que realitzen consultes a la base de dades.

Cada aplicació té el seu propi ServletAccess, aquesta classe conté totes les funcions necessàries per fer peticions i rebre respostes dels servlets. El navegador, com que no pot contenir cap classe, el que fa és accedir a la classe ClientServletAccess que es troba al servidor i aquesta accedeix al ClientServlet que fa les peticions a la base de dades amb les funcions del DatabaseConnector.

Més endavant s’explicarà el funcionament del LocationServlet, per ara es mostra la seva connexió amb la base de dades emprant el DatabaseConnector.

Fig. 4 Esquema general del projecte amb els elements que el formen (cada un en un rectangle blau). En lila els servlets, en vermell les classes i en verd la base de dades.

Per a l’intercanvi d’informació es fa servi, tal com ja s’ha comentat, httpclient i JSON. S’ha establert un paràmetre action, aqueste s’incorpora a totes les peticions i la seva funció és definir al servlet quin recurs es sol·licita i quina informació s’aporta (Per exemple, es sol·licita la informació d’un client concret i s’aporta el seu CIF). El servlet té un Switch que diferencia entre tots els action possibles i realitza per a cada un les accions pertinents.

7

El servlet sempre contesta amb un paràmetre result que indica si la petició s’ha pogut resoldre correctament o si hi ha hagut un error. I també pot incorporar un paràmetre replay que es posa al cos d’HTTP. Si la resposta conté Replay aquest porta en format text (JSON) la informació requerida (En l’exemple anterior un objecte del tipus Client).

4.2. Aplicació Java (Gestor de l’administrador)

L’aplicació Java està programada emprant SWT que permet fer una interfície gràfica com la que es veu a la Fig. 5. L’aplicació de l’administració consta d’una finestra principal en la qual es demana el login i d’una secundària que té 5 pestanyes que permeten moure’s per les diferents funcionalitats. Les quatre primeres pestanyes mostren la informació de la base de dades i permeten fer certes modificacions mentre que l’última pestanya permet veure la localització dels repartidors actius, es detallarà el funcionament d’aquesta pestanya a l’apartat Localització del repartidor.

Fig. 5 Captura de l’aplicació java a la pestanya Gestió de comandes, es pot observar que hi ha una comanda seleccionada de la qual es mostren els productes.

La programació de la interfície gràfica s’ha fet emprant gridlayouts el qual implica que cada finestra està dividida en cel·les i s’ha de definir quantes cel·les omple cada element i com l’omple (centrat, aprofitant tot el lloc, etc.). Els composites formen cada finestra i a més contenen altres composites, per exemple, a la Fig. 5 es mostra el commandListComposite que a dintre conté el ChangeDealerComposite que és el Grup que es veu a baix a l’esquerra que permet canviar el repartidor de les comandes.

Un dels problemes principals d’aquest tipus de programació és passar la informació d’uns composites a uns altres, per exemple, és necessari que el ChangeDealerComposite sàpiga quina fila de la taula de comandes està seleccionada per canviar el repartidor de la comanda correcta. Per aconseguir-ho s’ha passat als composites “interns” (com el ChangeDealerComposite) el composite “extern” de tal manera que puguin accedir funcions tals com “actualitzar la taula de comandes” (perquè s’ha canviat el repartidor, per exemple).

8

4.2.1. Localització del repartidor

En aquest apartat es detallen les comunicacions que es produeixen per aconseguir que l’aplicació java mostri el mapa amb el recorregut del repartidor (veure Fig. 6).

1. L’aplicació java fa una petició al LocationServletAcces del recurs map/index.jsp 2. El LocationServlet envia el jsp requerit a l’aplicació java, en aquest jsp hi ha el llistat de

repartidors actius i un espai per un mapa. L’aplicació java, al detectar que hi ha un espai per un mapa, farà la petició del mateix (aquesta comunicació no apareix a la Fig. 6) (Nota: aquest mapa està buit, mostra Barcelona però encara no conté cap coordenada dibuixada).

3. Un cop es selecciona un dels repartidors l’aplicació java fa una petició a Google mitjançant una URL que conté, entre d’altres paràmetres, l’adreça del servidor (que és qui té els KMLs amb la les coordenades) i el NIF del repartidor del qual es vol visualitzar el recorregut.

4. Google farà la petició del KML del repartidor requerit al servidor. 5. El servidor enviarà el KML on li indiqui Google. 6. Google agafa les dades del KML i les incorpora a un objecte que un cop s’ajunti amb el mapa del

navegador mostrarà les coordenades dibuixades tal com es veu a la Fig. 1.

Fig. 6 Esquema amb les comunicacions que es produeixen per mostrar el mapa amb el recorregut del repartidor.

4.3. Aplicació Android (Repartidor)

L’aplicació Android consta de tres activity’s principals (en blau a la Fig. 7). Un cop es fa el Login del repartidor s’inicia el Service del GPS. Aquest Service el que fa és recopilar la informació de localització i enviar-la periòdicament al servidor (a l’apartat Localització del repartidor: GPS, API de Google Maps es donaran més detalls sobre recopilació d’informació amb el GPS).

9

Al fer el Login apareix el llistat de comandes del repartidor (ComandesActivity), és a dir, les entregues que ha realitzat i les que ha de realitzar (periòdicament s’eliminaran les entregues realitzades per tal d’enviar el mínim d’informació possible). En aquesta llista es poden fer diverses coses, actualitzar-la (per si l’administrador acaba d’assignar una comanda al repartidor en qüestió) i veure les dades de la comanda. Al clicar a sobre d’una comanda s’obre l’activity DetailInfoActivity que mostra una llista amb tres elements expansibles que mostren la informació de la comanda. La informació es divideix en tres seccions: encàrrec, client i productes. A encàrrec es mostren les dades generals de la comanda, a client les dades de localització del client i a productes el llistat de productes que ha comprat, juntament amb la quantitat .

En aquesta activity es poden realitzar dues accions: trucar al client, i veure la ruta que s’ha de seguir per arribar al destí (es mostra un mapa i la ruta des del punt en el que es troba el repartidor en aquell moment fins al destí). Per aconseguir mostrar aquest mapa cal accedir a l’API de Google MAPs; es fa una petició amb una URL en la qual s’estableix l’adreça del client i la posició actual perquè així Google pugui retornar la ruta més ràpida.

Fig. 7 Esquema de l’aplicació android i la seva interacció amb el servidor i Google. En blau les activities en vermell les classes, en lila el servlet i en verd la base de dades.

4.4. Web (Client)

L’estructura de la web es pot separar en: accés, control i emmagatzematge.

• La part d’accés formada està formada pels JSPs, que són els responsables de mostrar i recollir la informació de l’usuari.

10

• La part de control està formada pels servlets, que són els que gestionen la informació: formen el cervell del servidor.

• L’emmagatzematge està format per l’accés a base de dades i la base de dades, permet a la part de control un lloc on guardar la informació.

La part d’accés està formada per un conjunt de JSPs que controlen el que es mostrar en cada cas. S’ha de ressaltar que a l’aplicació no hi ha cap HTML, ja que a totes les pagines es fa un control de sessió per comprovar si l’usuari està connectat o no, i per fer-ho fa falta un JSP. Si el client està loguejat (ha iniciat sessió correctament) el menú mostrarà les funcions exclusives per usuaris registrats. Els JSPs poden ser només informatius, com per exemple oldorders.jsp encarregat de proporcionar informació sobre les comandes realitzades; o de gestió de dades com el neworder.jsp, encarregat de permetre a l’usuari realitza una nova comanda. La diferencia entre ells és la seva estructura: en el cas dels informatius, en general es requereix d’informació de la base de dades, a l’inici del JSP es crida a una funció del ClientServletAccess, el qual s’encarregarà de fer un post contra el ClientServlet per a rebre aquesta informació. Un cop disposa de la informació construeix la pagina i la mostra al usuari.

D’altre banda, els JSPs que han de gestionar informació no necessiten fer aquesta comunicació inicial amb el servidor, sinó que mostren una pagina estàndard on l’usuari introduirà informació. Un cop l’usuari realitza una acció que implica introduir dades al sistema, una funció javascript s’encarregarà de verificar el seu format. Si el format és correcte donarà el vist i plau i es realitzarà un post contra el mateix JSP. Al JSP s’activarà una funció que cridarà al ClientServletAccess per a fer el post contra el ClientServlet amb la informació.

5. Els reptes més difícils

5.1. Interacció de l’usuari amb la web: javascript i css

Un dels objectius que va quedar clar des del inici va ser que la web havia de ser amigable i interactiva; les eines que han permès aconseguir-ho han estat css i javascript.

Al Cascading Style Sheets (css) és on es declaren les classes d’estil, amb paràmetres com amplada, marge, mida i color de lletra, etc. D’aquesta manera es simplifica i organitza millor el codi d’HTML, ja que enlloc de definir tot l’estil només s’ha de fer una referència a la funció que el caracteritza.

Per altre banda, javascript permet crear funcions que s’executaran localment al terminal de l’usuari. Amb aquestes funcions es poden fer efectes visuals, comprovació de camps, etc. S’ha de recordar sempre que la velocitat d’aquestes funcions es relativa a la maquina des d’on s’executi. Han de permetre fluïdesa a l’hora de navegar i fer les seves tasques de manera transparent a l’usuari.

Els reptes plantejats han estat aprendre a utilitzar aquestes eines pel nostre compte.

Es pot veure que tota la web fa referència a diversos *.css on s’especifica l’estil. Algunes de les funcionalitats que aporta javascript són:

• Comprovar que s’han omplert els camps correctament a l’hora de registrar, actualitzar dades o fer una comanda.

• El dinamisme de les taules:

11

o Llistat de productes: permet anar passant pàgines i la reordenació dels camps en ordre ascendent o descendent.

o Comandes realitzades: al pitjar a sobre d’una comanda es desplega la llista de productes comprats i també la reordenació dels camps en ordre ascendent o descendent.

o Fer una comanda: permet afegir columnes o treure-les, fixar el producte un cop elegit, bloquejar la seva reelecció i tornar-lo a habilitar si és eliminat de la llista.

• Adapta la informació: canvia valors de paràmetres per així poder realitzar el post al servidor amb èxit.

• Creació del calendari flotant per elegir la data d’entrega.

A continuació s’explicarà un dels molts reptes que van sorgir mentre es dissenyava la web: el disseny de la taula en la que es mostren les comandes realitzades. En primer lloc, es va buscar per Internet alguna taula que fes alguna cosa similar al que interessava. Un cop trobat un codi adequat es va adaptar a les necessitats concretes.

L’efecte de la taula de comandes es basa en amagar una fila en funció de si és fa un clic a una altre (en general la de a sobre). A més, aquesta taula també te l’opció de reordenar (funció sort) les columnes en ordre ascendent o descendent, la complicació d’aquest reordenament és que s’ha de mantenir la relació de la fila oculta amb la visible; ja que la única que s’hauria de reordenar és la visible i la de sota sempre hauria de seguir oculta.

La informació que s’havia d’ocultar era el llistat de productes que s’havien comprat en aquella comanda. Per a mostrar aquesta informació es va optar per fer una taula, que es va posar a dintre de la cel·la de la fila que s’amagaria de la taula principal. Un cop fet tot el disseny per tal de que quedes tal com es desitjava va sorgir un problema nou: la funció sort no funcionava.

Desprès d’investigar la raó, va resultar que aquella funció deixava de reordenar just quan se li afegia una altra taula a dintre. Per tant, s’havia de mostrar la informació d’una taula però sense taula, buscant informació es va trobar una opció que consisteix en imitar una taula mitjançant divisions (div).Amb l’objectiu de que quedes idèntica a la taula que anteriorment s’havia fet es va omplir la cel·la amb divisions vinculades a funcions de CSS fins que amb unes quantes hores de feina va quedar igual. A continuació es pot veure el resultat (Fig. 8), la taula que està feta a partir de divisions és la interna.

Fig. 8 Taula de comandes realitzades de la web.

12

5.2. Localització del repartidor: GPS, API de Google Maps

Quan es va començar a dissenyar el mòdul de localització d’empleats es van presentar tota una sèrie de reptes que va caldre resoldre. Al principi, el desenvolupament es va fer completament separat a la línia general del projecte. Això va permetre fer les proves pertinents per assegurar que funcionava abans d’integrar-lo al projecte.

Així doncs, calia crear un “segon projecte” fàcilment integrable al principal. Un cop esquematitzat tot el flux de dades, i comprovades les funcionalitats bàsiques de captura de posició o representació d’un punt sobre un mapa, es va procedir a analitzar la necessitat i a aportar solucions.

El major repte va ser dissenyar l’algoritme per capturar punts tenint en compte que l’aplicació podria ser utilitzada per un repartidor a peu o muntat sobre un vehicle. A més, s’ha de considerar que un vehicle pot circular a diferents velocitats segons la via en la que circula.

La solució va arribar amb un simple càlcul matemàtic: 𝑥 = 𝑣 · 𝑡 . Tenint en compte que un vianant pot caminar a uns 4Km/h i que un vehicle de repartiment pot anar a 110Km/h es va considerar que prendre una mostra cada 15 segons donava distàncies acceptables per als dos casos. Si es circula a poca velocitat implica que el repartidor es troba a una ciutat i, en aquest cas, el que interessa és tenir mostres cada poca distancia. En canvi, si el vehicle circula a molta velocitat significa que circula per una autovia/autopista i per tant, no interessa tant la distància entre els diferents punts. Així doncs, a uns 4Km/h s’obtenen punts aproximadament cada 16 metres, mentre que per una carretera a 50Km/h els punts tindran una distància d’aproximadament 208 metres; en autopista els punts es trobarien a uns 416 metres.

Tot seguit calia desenvolupar un algoritme per a obtenir uns millors resultats. Per exemple, és necessari desestimar punts (a partir d’ara fix) obtinguts amb el GPS que no siguin suficientment precisos. Si la precisió del fix és superior a 35 metres es descarta el punt si no és que la distància des de l’últim fix precís és molt gran, en tal cas el punt amb poca precisió s’accepta. S’ha de tenir en compte que no interessa tenir buits temporals de punts molt grans.

Mentre es realitzaven aquestes proves en un escenari real (circulant per ciutat) es va trobar un altre defecte relacionat també amb la posició. És necessari saber quan un repartidor està parat entregant una comanda, parat en un embús o en un semàfor. Tenir aquesta informació evita agafar punts repetits en el mateix lloc (al fer això el mapa queda molt brut). Llavors fent diferents proves es va considerar que si la distància entre el penúltim punt i l’actual és menor a la precisió establerta, no cal guardar el fix (pot interpretar-se com que el repartidor està parat).

Un cop funcionant el sistema a android va caldre solucionar dos problemes més, aquest cop en la part del servidor. Per fer les proves de representació dels punts és necessari emprar una IP pública. El servei de Google ha de comunicar-se amb el servidor (a través d’una IP pública), i si aquest es troba darrere d’un NAT (que no estigui configurat correctament) és impossible veure’n la representació gràfica. Per resoldre aquesta problemàtica es va configurar un ordinador junt amb el seu corresponent router per a poder atendre peticions de la xarxa externa (internet) i respondre-les correctament. La solució trobada va ser la utilització de dyndns, un servei que permet mantenir una IP dinàmica lligada a un domini.

Un cop solucionat aquest inconvenient en va aparèixer un altre, Google fa una cache del KML (fitxer de tipus XML on s’emmagatzemen les coordenades) a representar. Cada 5 minuts s’enviava el fitxer KML

13

amb modificacions (amb punts nous) però Google representava el fitxer que tenia en cache , és a dir, representava dades antigues. Un cop definit el problema es va trobar una solució senzilla, donar aleatorietat a la adreça on google tenia que fer la petició per a obtenir el KML. Cal recordar que el servidor fa una petició a Google en la qual dóna la seva adreça perquè aquest li faci la petició del KML i li enviï el mapa. La petició es fa a través d’una URL com la següent:

http://shiva.upc.es:50500/com.dealer.webserver/LocationServlet?action=1&nif='+r.value+'&rand=”+(new Date()).valueOf())

Com que la petició es realitzava des d’una funció amb Javascript es podia aleatoritzar la URL mitjançant un nou paràmetre anomenat rand. Al servidor no li afectarà aquest canvi però per a google implicarà obtenir un fitxer nou i el representarà sense consultar la cache. La part en vermell de la URL representa aquesta funció aleatòria, s’obté un objecte “Date” de Javascript i se’n pren el seu valor numèric.

5.3. Llista personalitzada: android listactivity

El desenvolupament d’aquesta part de l’aplicació ha sigut un repte ja que tota la informació s’ha assolit de forma autònoma (degut a que la major part dels elements que s’incorporen no s’han estudiat a classe). El principal problema, relacionat amb les sessions, va ser el de tenir una sola instància de l’objecte que inicia la sessió, és a dir, un cop el repartidor accedeix a l’aplicació i crea un objecte que inicia la sessió només pot haver-hi una única instància d’aquest objecte. Si es feia servir una instància diferent el servidor considerava que la sessió no era la mateixa i per tant, no permetia accedir a la informació. Aquest problema es resol mitjançant l’ús del singleton.

Oferir un llistat personalitzat amb les comandes que un repartidor ha de fer també va enrederir el progrés.Un cop definida l’estructura del llistat es va haver de crear un event onClick que s’activés quan es cliqués sobre cada element de la llista, per poder mostrar la informació de cada comanda (es va comprovar que l’event onClick d’una llista amb l’estructura predefinida no funcionava).

Un cop solucionat aquest gran problema, es va donar pas al llistat d’especificacions, que en un principi constava només d’un conjunt de Textviews on s’afegia el text amb les dades de cada comanda. Però evidentment això era massa pobre i es va decidir organitzar la informació detallada d’una altra manera: llistes expansibles (veure Fig. 9). També va sorgir la idea d’utilitzar llistes amb capçaleres però la opció més còmode era la primera. Va ser costós adaptar l’antiga estructura a la nova, doncs no s’ha utilitzat objectes tipus Hashmap en cap assignatura de programació.

14

Fig. 9 Captura del resultat de la llista expansible que s’ha emprat per mostrar la informació de les comandes.

6. Planificació del projecte

6.1. Repartiment de tasques

A continuació es mostra quin ha estat el repartiment de les tasques d’aquest projecte. S’han fet assignacions de tasques de la manera més ajustada possible però cal remarcar que en molts casos també s’ha participat (tot i que en menys mesura) en activitats que no apareixen a la llista següent.

Es parlarà de pàgina web v1 referint-se a la que no incorporava CSS i, es parlarà de v2 fent referència a la que incorpora CSS a més de javascript molt més complex que la v1.

• Rubén o Pàgina web v1 o Pàgina web v2 o Suport documentació

• Gerard: o Suport CSS (web v2) o Projecte localització repartidors i integració d’aquest projecte al global o Suport documentació

• Julia: o Servlets, o Disseny de base de dades o Aplicació java (Administrador) o Suport Integració del projecte de localització (part del servidor) o Suport documentació

15

• Victor: o Aplicació Android o Integració del projecte de localització (part del client Android) o Suport documentació

• Albert: o Suport servlets, o Suport aplicació Android o Documentació

6.2. Diagrama de tasques

Tot seguit es mostra el diagrama de tasques que pot ser consultat al document PDF adjunt “Diagrama de Gannt.pdf”.

Fig. 10 Diagrama de Gantt en el qual es mostra la realització de les tasques del projecte distribuïdes temporalment.

7. Conclusions

Ja des del principi es va presentar un gran problema, quin projecte escollir i de quines parts havia de constar. Al llarg de la realització també va anar passant, calia definir com havien de ser algunes parts com per exemple el sistema de venda de la web o bé la interfície del mapa i sempre hi havien coses a millorar. En molts casos la funcionalitat era provada per algun altre membre de l’equip de desenvolupament i, per exemple, li resultava complicat l’ús.

A banda d’aquests problemes relacionats amb el disseny del servei o les funcionalitats d’aquest van aparèixer problemes més tècnics, a continuació s’expliquen algunes de les solucions. Es van buscar tecnologies com ara JQuery per a permetre realitzar peticions HTML sense recarregar pàgines, utilització de classes d’una única instància (Singleton) per solucionar problemes en android. Compartir objectes entre moltes classes fàcilment (Singleton). També es va aprofundir en el desenvolupament d’Android de forma significativa.

16

Per altre banda, s’ha vist la importància de disposar d’una IP Pública, estàtica i fàcilment utilitzable, es fa molt més fàcil realitzar les proves, sobretot si un requeriment de les proves és estar en circulació (que és el que s’ha hagut de fer per comprovar que la localització i emmagatzematge de punts funciona correctament). També és important saber on s’executarà finalment l’aplicació desenvolupada, per a minimitzar problemes en la posada en marxa i alhora per treballar amb un entorn de desenvolupament el més semblant possible al de producció.