Cheers!

Some months ago I started one of those projects you start, you hold, you retake, you forgot’em, you go back to… those projects that when you retake them you meet your past self, that self you are ashamed of because you see a technology newbie. You still appreciate him, but you’d have a chat about… “fancy a fifa party?”.

This outstanding project with a thousand breaks has been named NFCar, and it started as a test to begin in the NFC for Android world. The idea was to create a mechanism which would mod the phone to a specially designed desk for the car, from which to have better access to those apps you might use while driving, besides than showing your car’s logo. This is one of those projects you do it for yourself, and gets published at Market just because, without aiming it to get really used. If you got curious: http://kcy.me/90yj

With this post I’m looking to share with you all I’ve learnt about NFC besides of reminding it to the future Roc, just in case something following is forgotten:

• In Android 4.0 NCF chips cannot be formatted in NDEF, which is a quite cool standard to write in NFC. This has some important meanings: if you haven’t bought the NDEF pre-formatted tags, forgot about it. And if you hand write a single byte in a NDEF formatted tag, avoiding the standard, you’ll have broke the NDEF format permanently. #congratsson

• Android apps cannot be proactive and ask if there is a NFC near. Tag connection is acquired via Intent, and you are responsible of saving the provided instance in order to use it further. That is to say, if the phone has sent you a signal telling you’ve got an NFC nearly, and you missed it, is lost. The NFC tag keeps near, and you know it, but you cannot access it. #congratsson

• If you want to keep a connection with an NFC tag (because you know it will be nearly for a while), you cannot. I mean, you can’t set a listener “enDesconexióDeNfc” “onNfcDisconnected”. You can create yourself a method if needed to keep calling nfc.isConnected() periodically. This will work perfectly at home, with the phone USB connected to the computer… also when you test it with the phone disconnected… But, when the battery is low, quite far from your test results, it is possible to lose the connection with the NFC even with the device touching the phone. So, with the battery lower than 100%, your onNfcDisconnected listener will work for a while… 5 seconds… 30 seconds… even a minute. But there will come a time it will return false, and you won’t understand the reason. It’s simply because your battery isn’t fully charged. And this is not documented anywhere. And I am testing it with the galaxy Nexus, the Google’s beauty. #congratsson

• The Android Developers Manual explains how to start the Activity through the Intent thrown when you bring the phone closer to a NFC tag. This is rather good, and when your app grows you will see that your main Activity is absolutely docked with the business is run over the NFC. This means that my main Activity where I like to have only view and user interaction, I have a lot of docked code managing the NFC control. Alright Google, the way of implementing NFC detection is sending me an Intent which launches one of my activities… but don’t try to convince me that this is good. Now that the project is finished I see it wouldn’t have been a bad idea to manage all the NFC connections through a see-through Activity which would forward an Intent to my man Activity depending on the case. So, summarizing: Google proposes a… doubtful arquitectre. #congratsson

• Every NFC chip is written its own way. I don’t mind to write the bytes in 64bit packs to improve efficiency when able, or maybe to write using lines when the tag requires it… but I don’t relish to be obliged to learn how to work with every single new chip appearing. A “writeString” and a “readString”. That’s it. I’m not asking that much, am I? If the String is too long for that NFC tag, a TooLongMEssageException could be thrown. And that’s all. #congratsson

• The mobile phone makes a sound every time an NFC is reached. The mobile phone turns off the NFC scan when the screen is switched off. The mobile phone triggers the NFC scan when the screen is switched on. These 3 elements which alone are not a mistake, altogether they are a patience attack when we work with my idea: phone near the NFC all the car trip along. Nothing happens when the screen turns off. But when you switch it on again… the sound again. The phone considers the NFC is new, just appeared there. And there is no way from your app to decide if it is new or not. The phone sounds definitively, and you cannot disable this audible notification anyway. Actually, not even user can. #congratsson

 

Despite these points: good enough. Actually, Android 4.0 has brought a very sexy detail: writing an NFC with an own Android Standard, so you can write there your app’s package. When the phone comes near this NFC no Intent is sent to any application, but the application is launched if installed. Otherwise it goes alone to the Market for it to be downloaded. Pretty good! This functionality brings a bunch of possibilities. Fetch your phone near the Bicing station and download the official app. Or don’t.

When I’ll have a while I’ll upload the code to Google Code for you to see what I’ve written. I hope it to be very useful, and specially to avoid you from failing as I’ve failed. Stay tuned to this post! :·)

Special thanks to Saúl Prior for translating this article to english! :·)

Bones!

Fa uns mesos vaig començar un d’aquells projectes que els comences, els talles, els segueixes, els oblides, hi tornes a treballar… d’aquells projectes que qual els reprens, coneixes al teu jo del passat. Aquell jo del que te n’arrepenteixes, que es nota que estava descobrint una nova tecnologia. Que te l’estimes, però li dires un parell de paraules ben dites. O tres… “fem un fifa?”.

Aquest flamant projecte mil vegades interrumput s’ha anomenat NFCar, i va començar com una prova per a conéixer el món de l’NFC sobre Android. L’idea era la de tenir un mecanisme on, a l’apropar el telèfon al cotxe, s’actives un escriptori especialment dissenyat per al cotxe, des d’on tenir un millor accès a les aplicacions que s’utilitzen mentre condueixes, i a més, afegint al layout el logotip del teu cotxe. És un d’aquells projectes que els fas per tu mateix, i que es publiquen al Market perquè si, sense moltes ganes de que es converteixi en una aplicació gaire utilitzada. Si us fa curiositat: http://kcy.me/90yj

Amb aquest post el que busco és compartir amb vosaltres tot el que he après d’NFC, i a més, recordar-li-ho a en Roc del futur, per si alguna vegada no se’n recorda d’algun d’aquests punts:

• En Android 4.0 els tags NFC no es poden formatejar en NDEF, que és un standard molt chulo per a escriure en NFC. Això té algunes implicacions molt importants: Si no has comprat els tags pre-formatejats en NDEF, oblida’t d’escriure en format NDEF. I si en un tag formatat en NDEF hi escrius algun byte a ma, sense utilitzar l’standard, et carregaras el format NDEF i mai més el recuperaras. #etfelicitofill

• Les aplicacions no poden ser proactives i preguntar si hi ha un NFC aprop. La connexió amb el tag es reb via Intent, i tu mateix has de guardar l’instància que se’t proporciona per a poder utilitzar-la en un futur. És a dir, si el mobil t’ha enviat una senyal de que tens un NFC aprop, i no te l’has guardat, ja ho has perdut. El tag NFC segueix aprop, i ho saps. Però no hi pots accedir. #etfelicitofill

• Si vols mantenir una connexió amb un tag NFC (perquè saps que el tindras molt aprop durant molt de temps), no ho pots fer. És a dir, no pots posar un listener “onNfcDisconnected”. Si vols, pots crear-te tu mateix un mètode que vagi cridant a nfc.isConnected() periòdicament. És un mètode que funciona molt bé a casa, amb el mobil connectat via USB amb el teu ordenador… també quan fas proves amb el mobil desconnectat… Però quan la bateria baixa, molt i molt lluny del teu banc de proves, pot ser que la connexió amb l’NFC es perdi, tot i tenir el NFC enganxat al mobil. És a dir, si la bateria no està al 100%, el listener onNfcDisconnected que tu mateix t’has programat funcionarà una estona… 5 segons… 30 segons… potser un minut. Però arribarà un moment en que tornarà false, i no entendras per què. Doncs és perquè no tens la bateria al màxim. I això no està documentat enlloc. I ho estic provant amb el Galaxy Nexus, el nen bonic de Google. #etfelicitofill

• El manual d’Android Developers t’explica com iniciar l’Activity a traves de l’Intent que es llença quan apropes el teu mobil a un tag NFC. Això està molt bé, i quan la teva aplicació creix, veus que la teva Activity principal està totalment acoplada amb el negoci que es fa sobre l’NFC. És a dir, que en la meva Activity principal, on m’agrada que tan sols es parli de Vista i interacció amb l’usuari, hi tinc un munt de codi acoplat que gestiona el control sobre l’NFC. Entesos, Google, la manera d’implementar la detecció d’un NFC és enviant-me un Intent que obre una de les meves Activities… però no m’animis a fer-me veure que això és bo. Ara que ja tinc el projecte acabat, veig que no hauria estat pas malament que tota la gestió de l’NFC fos en una Activity d’aquelles que no ensenyen res de res, i que depenguent del cas, em llences un Intent cap a la meva Activitat principal. Doncs bé, resumint: Google ens planteja una arquitectura… dubtosa. #etfelicitofill

• Cada model de tag NFC s’escriu d’una manera. No em sembla malament poder escrirue els bytes en blocs de 64 bits per a millorar l’eficiència quan es pot, o poser-ho fer per linies quan aquell tag NFC en concret ho requereix… però no m’agrada estar obligat a empapar-me com s’escriure en cada un dels xips que van apareixent. Vull un “writeString” i un “readString”. I ja està. No demano tant. Si l’String és massa llarg per aquell tag NFC, que em llençi una TooLongMessageException. I ja està. #etfelicitofill

• El mobil fa un soroll cada vegada que troba un NFC. El mobil desactiva l’scan d’NFC quan s’apaga la pantalla. El mobil torna a activar l’scan d’NFC quan s’encèn la pantalla. Aquests 3 elements que per separat no són pas dolents, junts són un atac a la paciència quan treballem amb la meva idea: mobil aprop de l’NFC durant tot el teu trajecte en cotxe. Quan s’apaga la pantalla, no passa res. Quan tornes a encendre la pantalla… s’emet de nou un soroll. Es considera que aquell NFC és nou, que te l’acaben de posar allà. I no forma part de la teva aplicació decidir si és nou o no. El mobil sona, si o si, i no pots apagar aquesta notificació sonora de cap manera. De fet, ni tan sols l’usuari pot. #etfelicitofill

 

A part d’això: molt bé. De fet, Android 4.0 s’ha inventat una cosa molt sexy: Escriure un NFC amb un standard propi d’Android, de manera que s’hi escriu el package de la teva aplicació. Aleshores, quan s’apropa el mobil a aquest NFC no es llença un Intent cap a cap aplicació, sino que o et llança l’aplicació definida pel package si la tens instal·lada, o et porta cap al Market per a que te la descarreguis. Molt bé! Amb aquesta funcionalitat s’obre un món de possibilitats. Apropa el teu mobil a aquesta estació de Bicing i baixa’t l’aplicació oficial. O no.

Quan tingui un moment, pujaré el codi de l’app a Google Code per a que podeu veure el que he escrit. Espero que us sigui molt últil, i sobretot, que no patiu els fracassos que jo he patit. Stay tuned to this post! :·)

Gràcies a les trobades que anem fent els típics de CatDroid, la comunicació amb altres desenvolupadors Android és constant. I això ens aporta estar sempre a l’aguait de detalls que fan que les nostres apps siguin de més qualitat. I la eficiència està dintre de la ISO 9126, així que la eficiència ha de ser un objectiu del dia a dia.

Aquest article parlarà del ViewHolder, un patró extremadament senzill que és d’aplicació obligatòria a qualsevol ListView. I ListView, quasi que és vista obligatòria de qualsevol aplicació, així que… quan la dominis, pensaras “i què he fet jo tot aquest temps”? I començaràs a buscar aplicacions al teu mobil que no utilitzin ViewHolder… si, són aquelles que no van tant fluïdes com les que tu has fet.

Què és un ViewHolder?

ViewHolder no és una classe del sistema ni és una nova feature ni res similar: ViewHolder és un patró (pattern), una idea que un geni va tenir i que s’ha convertit en una best practice que Google encara no ha documentat enlloc (gràcies!).

Si no sabeu la màgia de la reutilització de les files que fa ListView internament, us recomano aquesta lectura: http://android.amberfog.com/?p=296. Si no us fa goig o no enteneu anglès, us ho resumeixo: Android reutilitza les files de la ListView que no estas veient. És a dir: quan es crea la ListView, no s’agafen les dades dels 1.000 elements que hi ha a la teva array, creant 1.000 rows que després es mostren quan fas scroll. Tan sols es processen els 15 primers elements, i es creen 15 rows. I què en fa dels altres 985 elements?

Ni els mira. Oi que quan tu vulguis veure el 16è element deixaras de veure el 1r, per culpa de l’scroll? Doncs bé, Android aconsegueix la instància del 1r element, que ja no es veu, li posa les dades del 16è element, i te la mostra a la 16à posició. I això t’ho fa oferint-te el paràmetre View convertView al mètode getView() del ArrayAdapter que ja tens. Poso una imatge genial que ha dissenyat l’autor de la web anterior: http://android.amberfog.com

---

Espero haver-me explicat bé. Si és així, i hem entès el concepte, passem al següent pas:

La manera típica de crear una row per a una ListView és anar carregant tots els elements gràfics que hi ha en una row, i posant-hi les dades una a una. És a dir, partint del disseny d’una row, que al cap i a la fi és tan sols un .xml del nostre directori de resources, anar carregant cada element d’aquesta row i editant el contingut: Faig findViewById() del TextView del nom, i hi poso el nom… faig findViewById() del TextView del cognom, i hi poso el cognom… faig findViewById() de tal ImageView, i hi poso el Drawable que vull… Doncs bé, findViewById() és molt costos. Android Developers tampoc ens ho comenta (gràcies!) però s’ha d’evitar sempre que es pugui.

Com fer-ho en una ListView? Molt senzill: Tot el que fem que té a veure amb findViewById(), fer-ho tan sols quan no hi ha més remei (és a dir, la primera vegada que s’utilitza una row, quan es crea). Quan Android reutilitzi aquesta row de la ListView, no hem de fer findViewById(), sino recuperar-ho d’una catxé. I qui es pot encarregar d’enmagatzemar aquesta catxé? setTag() i getTag(), uns mètodes molt pràctics que ens ofereix la classe de la row, View, i on hi podem guardar de tot. Així que al tag de la row, hi tindrem els Views que formen la row, i mai més caldrà recuperar-los amb findViewById().

Si no s’entèn… tocarà creure-s’ho. Al mirar el codi que us passo direu “Ah! Vale!”. Així que cap problema.

La part pràctica

Aquest petit how-to l’escriuré de la manera més fàcil possible:

• Fent una aplicació amb una ListView, tal com ens recomanen a Android Developers: HelloListView
• Modificant l’app, per a que funcioni amb un ArrayAdapter propi poc eficient.
• Complicar les rows que es mostren (per a exagerar el baix rendiment).
• Aplicar ViewHolder a l’ArrayAdapter.
• Cachejar elements lents (Drawables).
• Convertir tota la feina a 3 Activities accessibles mitjançant el launcher (per a que la comparació entre una i altra sigui senzilla).
• Afegir logging per a comparar rendiment

Doncs allà anem… a escriure el projecte de les 3 Activities!

Thread.sleep(1000*60*60*1); //typing this foo project…

Comparació “without ViewHolder” i “with ViewHolder”

Ara que ja he escrit l’exemple, us penjo aquí una imatge on hi ha un diff entre el getView() de la versió sense ViewHolder, i el de la versió amb ViewHolder. Examinant amb calma aquesta diferència s’hauria d’entendre quina és la tasca del ViewHolder. Atenció: La única diferència és el mètode getView(). No hi ha més magia.

Screenshots de les 3 Activities

Doncs aquí les tenim. La primera Activity, va lenta. La segona, va extremadament més rapida. I la tercera, és imperceptiblement més rapida encara. En screenshots és difícil d’expressar, però bé… un .gif quedaria una mica old-fashioned.

Resultat en números de fer scroll a les 3 Activities

Un detall: Aclarir que els test els he fet en un HTC Hero a.k.a. “Roc, canvia’t el mobil”, que corre Android 2.3.7. En un mobil d’última generació, els resultats són diferents.

Sense ViewHolder:

• Crear una row costa uns 10ms
• El Garbage Collector ha de passar 11 vegades
• log
  

Amb ViewHolder:

• Crear una row costa de 2 a 4 ms
• El Garbage Collector ha de passar 1 vegada
• log

Amb ViewHolder i cache de Drawables:

• Crear una row a vegades costa 0 ms …
• El Garbage Collector no ha de passar mai.
• log

Per si ho voleu tocar vosaltres mateixos, aquí us deixo un .zip amb tot el codi que he escrit, un repositori públic a Google Code, i un link al Android Market amb el compilat. Veureu que hi ha 3 Activities: Cada una d’elles és la que he executat per a obtenir els resultats que acabo d’escriure. Si executeu el programa al vostre Android, al launcher us apareixeran les 3, així que la comparació és molt senzilla. I si mireu el logger, podeu filtrar per “RBLS”, i us acabareu de convèncer de l’importància de l’eficiència.

Ah! La icona que he posat a l’app és un plàtan genial Creative Commons (CC-BY-SA) que m’he baixat de Wikia.com:
http://ztreasureisle.wikia.com/wiki/Emerald_Island

Bé, i els plàtans que he posat al market, són de la wikipedia:
http://upload.wikimedia.org/wikipedia/commons/8/89/Green_yellow_bananas_dsc07775.jpg

Espero que aquest post us sigui d’utilitat, jo m’ho he passat bé escrivint-ho, així que… bé, al primer, ja li ha servit :·)

Llicència

Que me n’oblidava, tot això està alliberat sota GPLv3, així que feel free d’utilitzar-ho allà on volgueu: classes magistrals, xerrades amb els amics, powerpoints per al cole, projectes finals de carrera, doctorats… Per termes legals us haig de posar un link a la llicència, així que aquí teniu un link a la llicència: GPLv3

Enjoy coding!

Fa uns mesos, l’equip de Ciutadania 4.0 es va posar en contacte amb mi per a presentar-me l’event que volien tirar endavant: Conèixer 100 iniciatives ciutadanes relacionades amb les TIC, escollir-ne les 20 més interessants, recolzar-les en 20 experts en l’àmbit del negoci i la innovació, i presentar tot el mix a un públic a l’altura. M’havien conegut a través de l’aplicació Barcelona Bicing, i volien que presentes el meu projecte a aquest gran públic. No tenia molt clar què volien de mi, però com sempre, vaig dir que sí. Així que ja tenia una cita pel dia 6 de juliol.

Després d’una fase selectiva, l’organització em va posar en contacte amb el meu orientador, en Joan Carles Jerez, responsable de R+D del RACC. Ell em va donar unes valuoses pautes sobre com encarar el projecte al negoci, quines són les claus d’èxit d’un projecte amb visió internacional, i la força que ha de tenir un speaking de tan sols 7 minuts. Per exemple, a la presentació hi havia una agressiva comparació entre l’aplicació oficial del Bicing, i la meva aplicació no oficial. Un detall que va agradar molt (i que va fer saltar algunes piulades a twitter), que a mi potser m’hauria fet respecte tirar endavant.

La conclusió, l’esperada: Reunir a tantes persones i presentar una idea a la sala de presentacions de la Torre Telefònica, amb aquest públic, ha estat una experiència increïble que tan de bo es repeteixi moltíssimes vegades. A més, conèixer a tanta gent, tant persones del públic, com totes les persones que, com jo, tenen ganes de tirar un projecte endavant, és una experiència per a la que no hi ha qualificatius.

Si després de llegir tant de positivisme us queden uns minuts i prou curiositat, aquí podeu veure el video de la meva presentació, i aquí les diapositives que vaig utilitzar.

Doncs ja tenim un codesprint a la motxilla!

Aquest dissabte va començar sense esmorzar i amb una petita presentació sobre Google Maps: quin és el servei que ens dóna Google, com n’és de fiable, què ens permet fer la seva llicència, que no, i quin és el procediment per a integrar un mapa de Google a la nostra aplicació Android.

Mentre els més experimentats esmorzaven, a l’aula vàrem fer una petita pràctica per a que tothom dissenyés una aplicació bàsica utilitzant la Google API. Va ser el primer contacte amb una MapActivity!

Després d’això, vàrem proposar 4 projectes:

• Un client del Bicing: una aplicació senzilla que carregues informació oberta d’internet i la mostrés en un mapa amb punts de diferents colors. Aquesta aplicació, a part de la utilitat funcional, serà l’exemple perfecte per a futures sessions de formació.
• Guia turístic: Una aplicació que, al passar aprop d’un PDI, ens proporcionés informació de valor sobre aquest punt. En un futur es podria variar l’objectiu per, a més, tractar-ho com un joc. “Has descobert 192 punts dels 2819 que hi ha a Barcelona!”
• On és el trencadís?: Recordes el “¿dónde está Carmen Sandiego?” Gràcies a les pistes, has de trobar on està el Trencadís!
• CityWalk: Una aplicació per a planificar rutes turístiques: on vull anar, quin transport públic puc utilitzar, quan puc trigar…

Diferents projectes, diferents dificultats i motivacions: els assistents van escollir un projecte i el van moure endavant. Els equips integraven professionals de diferents perfils i edats. Valors diferents movien discussions sobre un mateix anàlisi o funció. Diferents àrees d’experiència, feien que uns mòduls s’escriguessin ràpid, i d’altres donessin més voltes. Però en tot cas, l’objectiu comú de fer equip per moure una idea endavant va fer que la jornada, a part de didàctica, fos molt divertida.

Si vols veure els projectes que es van moure, aquí tens uns links cap als repositoris Googlecode de Catdroid:

• Bicing: http://code.google.com/p/catdroid-bicing/
• Guia turístic: http://code.google.com/p/catdroid-guiaturistic/
• On és el trencadís?: http://code.google.com/p/catdroid-oneseltrencadis/

I per aquí un altre link, amb unes fotografies capturades per en Josep Rosich en el transcurs de l’esdeveniment: http://www.flickr.com/photos/59166157@N04/

I has vist el video que encapçala aquest post? És obra d’en Palisandro Gamez i la seva fantàstica GoPro HD! I bé… ni més ni menys que 12 hores de renderitzat!!

Per últim, també volem agrair el suport de Citilab, qui ens va facil·litar dues sales amb projectors i internet per a donar cabuda als equips.

En fi, gràcies a tots els que van participar! Quan repetim?

Crear una base de dades:

CREATE database prova;

 

Crear i assignar un usuari local (localhost) amb tots els permisos:

GRANT ALL ON prova.* TO ‘roc’@’localhost’ IDENTIFIED BY ‘password';

 

Crear i assignar un usuari local i remot (%) amb permisos select i insert:

GRANT SELECT, INSERT ON prova.* TO ‘roc’@’%’ IDENTIFIED BY ‘password';

 

Fer un backup de la BBDD i restaurar-la:

mysqldump -u root -p prova > dumpfilename.sql
mysql -u root -p prova < dumpfilename.sql

Ara que ja hem vist la part teòrica de com fer aplicacions per android durant les píndoles, anem a posar mans a l’obra i fer una app (dissenyar, programar i testejar) senzilleta però funcional.

Per aprofitar que molts han practicat una mica a casa i que no comencem des de zero (comencem des de l’1), anem a donar-li una mica més d’interès a la app introduint l’ús de mapes amb Google Maps i OpenStreetMap.

Al matí el nostre company Roc Boronat introduïrà el tema de com utilitzar els mapes, i amb l’ajuda de tots intentarem posar-nos a picar codi i obtenir una app que funcioni.

La idea és que tothom (o gairebé tothom) porti el seu portàtil amb eclipse instal.lat. Segons la quantitat de gent, farem una sola app entre tots o bé farem diversos grups i que cada grup faci la seva app (totes fent ús dels mapes).

Hem d’agrair al Citilab que ens cedeixi un espai per posar-nos a jugar amb el nostre androide. De fet, si ens portem bé, hi ha la possibilitat de continuar la sessió de mapes després de dinar, entrant amb el tema de OpenStreetMap. Entre tots ens podem posar al dia de com funciona i de les diferències entre OpenStreetMap i Google Maps.

No oblideu portar el vostre portàtil configurat per poder programar! Us recordem que en Roc va preparar un paquet d’instal·lació d’eclipse preparat per treballar amb android i personalitzat per a CatDroid. El podeu trobar a http://catdroid.org/?p=210, a http://rocboronat.net o directament a http://kcy.me/1ohy.

Si teniu una proposta concreta d’app per desenvolupar entre tots, o voleu donar la vostra opinió, feu servir el fil del fòrum de CatDroid a http://groups.google.com/group/CatDroid/browse_thread/thread/ca55f96082e1b861.

Donem una volta a les pílores!

Les xerrades que hem fet a Barcelona i Girona han estat experiències genials: hem ensenyat moltes coses i n’hem après moltes altres. Fins ara organitzàvem xerrades 1.0, però hem pensat que el pròxim event fos més participatiu. Què pot passar si aprenem tots plegats?

De cara al dia 5 de febrer estem organitzant un codesprint al Citilab de Cornellà on puguem moure projectes que ens despertin la curiositat. Per ara, només ha sortit la idea de fer un sample utilitzant OpenStreetMap per a Android. És un projecte que desconec, i m’agradaria aprendre’n.

I a tu, què t’agradaria fer? Si tens curiositat per alguna tecnologia o simplement vols començar un projecte en grup, digues la teva en aquest post. Totes les idees són benvingudes, ja ho saps! http://bit.ly/gB3MLu

• Tecnologies: J2EE
• Motivació: OpenData
• Any: 2010
• Llicència: http://www.gnu.org/licenses/gpl-3.0.html
• Site: http://rocboronat.net/barcelonabicing/
• TRAC: http://rocboronat.net/tracBicingJ2EE
• Codi font: http://kcy.me/1tsh
• Subversion: svn://rocboronat.net:3694
• Col·laboradors:
  • Manel Simon (@manelizzard): Mòdul d’scrapping del servei de Sant Vicent del Raspeig, Alacant
  • Alfonso Ruzafa (@superruzafa): Hardcode de la posició de l’estació 274. La pàgina web del Bicing mostra informació desactualitzada. Versió 4
  • Javier González (@JavierGonzalez): Hardcode de la posició de l’estació 143. La pàgina web del Bicing mostra informació desactualitzada. Versió 37

---

Aquesta aplicació té l’objectiu d’extreure informació d’una pàgina web que no ofereixi facilitats per reutilitzar-la, i oferir-la en format de fàcil lectura per a tothom. Per exemple, llegir l’estat de les estacions de Bicing del Google Maps de la web del Bicing, i oferir-la en format XML, JSON, Java Serialitzat… El projecte va néixer amb l’objectiu d’extreure informació en temps real de l’estat de les estacions de Bicing, però ha anat creixent per a donar lloc a d’altres ciutats.

La aplicació està formada per un motor que gestiona Threads, els quals s’encarreguen de fer scrapping de les webs dels serveis dels quals necessitem obtenir dades. El projecte s’ha modularitzat de manera que, si un desenvolupador vol afegir codi que llegeix d’un altre sistema de bicicletes (o d’un sistema similar), pot fer-ho sense una alta complexitat.

A partir de finals de 2011, les dades de Barcelona les proporciona Citybik.es, el projecte obert on s’hi troben els serveis de bicicletes de tot el món. El meu projecte es manté, per un costat, per a adaptar el format de les dades de Citybik.es, i per altra, per a definir exactament els noms dels carrers i els números de les direccions postals. Això marca una diferència amb les dades oficials que proporciona Bicing, on les denominacions no estan gens clares.

Paths d’interès:

Resum: http://rocboronat.net/barcelonabicing/string

http://rocboronat.net/barcelonabicing/bcnG
http://rocboronat.net/barcelonabicing/bcnG?all=1
http://rocboronat.net/barcelonabicing/bcnJ
http://rocboronat.net/barcelonabicing/bcnJ?all=1