Cette version de Talaria présente quelques petites améliorations:
Le site de la RATP indique dans ses mentions légales, rubrique « propriété intellectuelle »:
L’ensemble des textes, graphismes, icônes, photographies, plans, logos, vidéos, sons, marques [...] et ne peuvent, conformément à l’article L122-4 du code de la propriété intellectuelle, faire l’objet d’une quelconque représentation ou reproduction
Je suis un peu surpris qu’une régie publique n’ait pas déversé dans le domaine public les symboles représentants les lignes. Justement, je voulais utiliser l’icônographie des lignes RATP, dans mon application mobile
Je me demande si l’article L513-6 du code la propriété intellectuelle permet d’utiliser ces pictogrammes.
Les droits conférés par l’enregistrement d’un dessin ou modèle ne s’exercent pas à l’égard [...] d’actes de reproduction à des fins d’illustration ou d’enseignement, si ces actes mentionnent l’enregistrement et le nom du titulaire des droits, sont conformes à des pratiques commerciales loyales et ne portent pas préjudice à l’exploitation normale du dessin ou modèle.
Est-ce que l’utilisation des pictogrammes pour indiquer le nom des lignes est un acte d’illustration?1
Dans le doute, j’ai demandé directement le consentement de la RATP. Voici leur réponse:
C’est extrêmement décevant. La RATP ne cherche visiblement pas à construire une image cohérente autour de la signalétique. Et d’ailleurs, ils s’emmèlent parfois les pinceaux eux-mêmes.
Le paradoxe, c’est que la police de caractères Parisine, utilisée par la RATP, est libre de droits utilisable par tous (mais payante). Et qu’on ne peut pas protéger des couleurs… Je vais donc bêtement utiliser autre chose qu’un cercle, pour « élaborer de nouveaux pictogrammes » différents mais qui ressemblent quand même.
J’espère que la réponse de la SNCF sera plus intelligente positive.
Un bref message pour dire ce qu’il y a de nouveau dans cette version 1.0
Sur le détail d’un incident, le bouton menu permet de poster un tweet por commenter cet incident.
Le client twitter du téléphone est détecté automatiquement (j’ai vraiment eu du mal à mettre en œuvre cette fonctionnalité, si votre client n’est pas détecté, dites-le moi)
Et comme le tweet contient le lien vers la age web idoine, il apparaîtra dans les commentaires de la page, tout comme le twwet d’Olivier apparaît sur l’incident 258.
J’avais un fichier de ressource qui traînait. Il est parti 
Ooops, une fenêtre d’erreur qui était créée dans le mauvais thread.
Le filtre « en cours uniquement » est appliqué plus régulièrement (sur le retour
des écrans « ajout » et « détail » notamment).
Rendu possible grâce à une amélioration du service web. Merci Olivier.
Un switch/case dans lequel il manquait un break. Ça aurait pu faire des ravages.
Enjoy!
J’ai finalement donné le nom Talaria à mon application pour accéder à http://incidents-transports.com/ (qui a changé de nom mais pas fermé, malgré les menaces).
Les talaria sont les sandales ailées que porte Hermès, qui, dans la mythologie grecque, est le dieu des voyages, des routes, du commerce et des voleurs.
Aujourd’hui, j’ai fignolé l’interface, en joutant des icônes dans le menu. J’ai aussi intégré une nouvelle fonctionnalité de l’API, qui évite d’avoir à recharger tous les incidents, quand on vient d’en poster un.
En tout cas, l’application est maintenant disponible sur l’Android market.
Scannez ce QR code sur votre mobile pour télécharger l'application
J’ai apporté quelques petites modifications à IncidentsTransports pour Android.
D’expérience, je sais que les utilisateurs sont sans pitié quand une application crashe. Et les bêta-testeurs m’ont justement remonté que ça arrivait sur mon appli, avec le message d’erreur « Exception: Application has leaked window here ».
Je n’ai pas mis longtemps à comprendre d’où vient le problème. Lorsque je raffraîchis la liste des incidents, je crée une fenêtre ProgressDialog que je ferme quand le serveur a répondu. C’est d’ailleurs ce que recommande de faire le guide de développement sur Using AsyncTask:
To update your UI, you should implement onPostExecute(), which delivers the result from doInBackground() and runs in the UI thread, so you can safely update your UI.
Mais ces conseils ne sont pas si bons 
Comme toute boîte de dialogue, celle-ci est rattachée à une vue, celle de l’activité. La boîte de dialogue est créée dans onPreExecute() (« This step is normally used to setup the task, for instance by showing a progress bar in the user interface.) et fermée dans le onPostExecute(). Problème: si l’utilisateur modifie l’orientation de son écran, ou tout autre type de changement de configuration, l’activité est détruite (« This is done because any application resource, including layout files, can change based on any configuration value« ). Du coup, la fermeture du ProgressDialog se fait dans un contexte qui n’existe plus.
Le message de l’exception ainsi levée laisse sous-entendre qu’il y a un me memory leak. J’ai commencé à regarder le code source de la méthode dismiss() des Dialog dans d’Android (j’aime les projets open-source), mais je ne suis pas sûr de cette implication.
Pour le moment, j’ai changé la configuration de l’activité pour qu’elle ne soit pas détruite sur un changement de configuration de l’appareil, mais il est sans doute possible de faire mieux.
Quand le serveur ne répond pas HTTP OK, je me contentais d’afficher le code de statut, par exemple BAD REQUEST. Mais souvent, le serveur donne une explication plus détaillée dans le contenu de la réponse. Celle-ci est maintenant affichée.
Quand l’utilisateur crée un incident, j’avais affecté la ligne mais oublié l’identifiant de ligne, nécessaire pour l’affichage du pictogramme.
J’ai aussi découver #7 Impossible de confirmer/infirmer/indiquer terminé l’incident que l’on vient de créer.
Contournement: rafraîchir la liste des incidents, avant de tenter l’une de ces actions.