ListView : gestion de la sélection d'un item

Dans cette troisième partie sur les ListView, nous allons nous intéresser à la gestion du "click" sur un élément de la liste. 


Classiquement, la réponse à un évènement est gérée par un EventHandler. Ici, pour le click sur un élément d'une ListView, c'est l'évènement ListView.ItemClick qui est mis à contribution.
Une recherche rapide dans Google nous donne un exemple de code qui ressemble à ça :


protected override void OnCreate (Bundle bundle)
{

     // ...

     maListView = FindViewById<ListView>(Resource.Id.maListView);
     maListView.ItemClick+=new EventHandler<ItemEventArgs>(maListViewItemClick);
     //...
}



void maListViewItemClick(object sender, ItemEventArgs e)
{
      maListView = FindViewById<ListView>(Resource.Id.maListView);
      var selectedItem = maListView .Adapter.GetItem(e.Position);
}


Explication :
L'évenement levé indique, dans le paramètre ItemEventArgs, la position dans la liste de l'élément clické. En se référant à l'adapter de la listView, on peut ainsi récupérer l'objet affiché par l'item de la ListView, en utilisant la méthode Adapter.GetItem(int position)


Ouais, bof, ce n'est pas franchement propre comme façon de faire. Il suffit que, pour une raison ou pour une autre les données de l'adapter ne soient plus dans le même ordre que les données affichées à l'écran pour que la méthode nous produise un joli bug bien sympathique. Et même, si aujourd'hui, l'ordre est censé être le même pour l'adapter et la listview, personne ne peut dire qu'une prochaine version de ListView ne sera pas capable de faire des tris sans modifier les données de l'adapter... 


Ce qu'il faudrait, c'est pouvoir retrouver l'objet affiché dans l'item de la listview directement à partir de l'item lui-même. 
La documentation fait mention, au niveau de ListView, d'une propriété ListView.SelectedItem. Bien ! Ca semble être ce que l'on cherche. On récupère directement l'objet, et c'est bon. En pratique, ça ne fonctionne pas, le SelectedItem restant toujours null à l'exécution (j'ai posté un message dans le forum monodroid, sans obtenir de réponse satisfaisante à ce sujet...).


Il faut donc trouver une autre solution, et c'est l'item de la ListView qui va nous la donner :
Chaque élément d'une ListView est lui-même de type Android.Views.View. Et cette classe propose une propriété spécialement faite pour résoudre notre problème : View.Tag


View.Tag, de type Java.Lang.Object, permet, selon la doc Monodroid, de stocker tout objet : "Tags can also be used to store data within a view without resorting to another data structure.", ref ici
C'est pile poil ce que l'on veut faire !!!


La seule restriction est que l'objet que l'on va mettre dans ce Tag soit un Java.Lang.Object. Ce qui n'est pas bien compliqué : dans la plupart des cas, il suffit de faire hériter notre objet directement de Java.Lang.Object, 


Notre méthode de gestion du click devient donc la suivante : 



void maListViewItemClick(object sender, ItemEventArgs e)
{
     // On peut remplacer le type de selectedItem par un type perso,
     var selectedItem = e.View.Tag;
}





La dernière chose à ne pas oublier, est la valorisation du Tag, dans la méthode GetView de notre Adapter, en castant notre objet en Java.Lang.Object.




Si je reprends le code de l'article précédent sur les ListView, le GetView devient donc : 




public override View GetView (int position, View convertView, ViewGroup parent) 
{
     View v = convertView;
     if(position>=this.Count)
          return v;


     T o = this.items[position];
     if (o != null) 
     {                    
          if (v == null) 
          {
               LayoutInflater vi =   (LayoutInflater)Context.GetSystemService(Context.LayoutInflaterService);
               v = vi.Inflate(o.ResourceId, null);
          }
          o.FillView(v);
          // On valorise notre propriété Tag, ici : 
          v.Tag = (Java.Lang.Object)o;
     }
     return v;
}




Les autres modifications dans l'article précédent concerne la classe "Moto" : 
 public class Moto : Java.Lang.Object , iViewItem


et bien sur, l'ajout de la gestion de l'évènement ItemClick :


protected override void OnCreate (Bundle bundle)
{
[...]
 // Settings ListView
 ListView listOfMotorCycle = FindViewById<ListView>(Resource.Id.listMotorCycle);
  // On s'abonne à l'évement ItemClick 
listOfMotorCycle.ItemClick += new EventHandler<ItemEventArgs>(listOfMotorCycleItemClick);
[...]
}


La gestion de l'évènement en elle même 



void listOfMotorCycleItemClick(object sender, ItemEventArgs e)
{
     Moto selectedMoto = (Moto)e.View.Tag;
     // Et maintenant, je fais ce que je veux avec la moto sélectionnée...
     selectedMoto.DoWhatYouWant();
}



Si vous souhaitez l'intégralité du code, un petit message dans les commentaires...

Que la presse se ...presse !!!

La ratp a récemment annoncé sa volonté de généraliser l'accès 3g dans le métro parisien. Le dernier sanctuaire du "non connecté" va tomber, comme sont tombés tous les autres lieux de non connexions (bars, restaurants, voitures, supermarchés...). Pour plusieurs centaines de milliers de parisiens, c'est un ouf de soulagement. Ils vont enfin pouvoir utiliser leurs smartphones dans les transports en commun, gagner 20 minutes (la durée n'est pas choisie au hasard...) d'utilisation en plus.


Pour la presse, cette annonce est une vrai révolution, pour ne pas dire une catastrophe. Car, pour avoir pris le métro (et le RER, également) - trop - longtemps, j'ai noté que le dernier endroit ou l'on pouvait encore voir des gens lire la presse quotidienne, c'était bien dans les transports en commun. 20minutes, d'ailleurs, n'est pratiquement distribué que dans les transports en commun. 


Avec cette concurrence du smartphone connecté, la lutte pour la survie deviendra encore plus difficile. Non seulement les quotidiens vont devoir continuer à se battre contre leurs ennemis historiques -  la télé, les gratuits, les titres spécialisés, et plus généralement le manque d'intérêt, mais, en plus, ils devront affronter les emails, youtube et Facebook. Surtout Facebook, d'ailleurs, la 3g ne permettant pas un visionnage YouTube de qualité (et pour le son, la musique reste en bonne place, pas besoin du son pourri d'une vidéo saccadée).  


Pour ne pas sombrer dans les oubliettes, ou pire, devenir un média entièrement subventionné, cette presse devra s'adapter, très rapidement, et utiliser les mêmes armes que son nouveau concurrent direct. Facebook a en effet de nombreux atouts pour capter ces quelques minutes de cerveau plus ou moins disponible. 
- Une lecture simple, aisée. Il est plus facile de tenir un smartphone debout, d'une main, en le pilotant du pouce, que de tenir un quotidien, même s'il est passé sous petit format.
- Un cerveau pas nécessairement réveillé.  On ne peut pas le nier, lire un mur facebook demande beaucoup moins d'attention et de concentration que lire les pages intérieures du Monde.
- Un rôle d'acteur. Enervé un matin ? Marre des grèves ? du boulot ? des élections ? Facebook permet de se défouler, de partager avec ses contacts son humeur du matin, au contraire d'un quotidien qui n'a que la page Sudoku pour aider à passer ses nerfs. Et on a vu mieux qu'un sudoku, pour exprimer quelque chose...
- Du contenu, toujours du contenu. Pour peu que l'on ait quelques dizaines de contacts sur facebook, on est à peu près certain de toujours avoir du nouveau sur son mur. Et au pire, on peut naviguer à l'infini sur l'ensemble des comptes facebook, ce qui donne une source de contenu inépuisable.


La presse, si elle veut survivre, devra appliquer les mêmes recettes. En se dotant, si ce n'est déjà plus ou moins fait, d'une application smartphone utilisable facilement, qui se contente de peu de ressources, et qui sait se manifester auprès de l'utilisateur quand il le faut.
Ce n'est certainement pas le plus difficile. L'engagement financier pour disposer d'une application iPhone/Android n'est rien en comparaison de ce qui a été demandé pour disposer d'un site web. Et les coûts sont mutualisables.

La réelle difficulté vient du contenu. Passer de la production de contenu pour un quotidien papier à la production de contenu pour un site web n'était déjà pas simple, et a plutôt été bien réalisé par les principaux groupes de presse. Mais pour s'adapter au format smartphone, il faudra encore innover, prendre en compte les supports multiples, les situations de lecture, l'ergonomie particulière (comment intégrer la publicité sur un écran de 4 pouces de diagonal ?), prendre en compte un temps de lecture très court (combien de temps un utilisateur de smartphone passe sur chaque mur facebook ?). Oui, parce qu'en plus, la presse va véritablement rencontrer le démon qui a fait trembler la télévision, le zapping !


Et surtout, encore plus que pour un site web, il faudra s'adapter à la temporalité qu'imposent
les réseaux sociaux. On ne parle plus de quotidien, ni même d'une édition par demi-journée. Il faut, sur un smartphone, qu'à chaque utilisation, le contenu soit nouveau. Parce qu'il est hautement périssable. 


Je passe beaucoup de temps à utiliser mon smartphone, pour lire la presse, le matin, le midi, le soir, dès que je dois attendre quelque part, au travers des multiples applications que j'utilise (des quotidiens type Le Monde, jusqu'aux pure players Slate, rue89, en passant par les hebdos). En gros, l'ensemble tient sur presque 2 écrans de mon android (soit une grosse vingtaine d'applis "presse"). Aucune ne réalise un sans faute selon mes critères, et la plupart sont tellement indigentes (plantage récurrents, contenu illisible, inaccessible, pas de possibilité de "read it later", etc...), que je préfère passer par une application de syndication de contenu - News republic.


Je ne connais pas les termes des contrats, s'ils existent, passés entre cette appli et les sources de contenu, mais il est certain que ce n'est pas de cette façon que la presse trouvera un second souffle, et retrouvera des moyens financiers dignes de son ambition...