ListView, équivalent IPhone

[Pierre87]

Salut !

Je bosse en ce moment sur un projet Android assez important...

Ayant vu ce que peut faire l'IPhone au niveau des "list view", je me suis demandé si il était possible de faire la même chose sur Android.

(je connais déjà assez bien les ListView, Adapter sur Android)

On m'a parlé de 3 choses sur IPhone : TableViewController, Section, Row

C'est surtout le principe de "section" qui m'intéresse.

Sur IPhone, on peut découper une "liste" en plusieurs "sections" qui contiennent elles même des "rows"

Peut on faire la même chose sur une ListView Android ?

J'ai vu dans Adapter un lien avec ViewGroup, ça pourrait être ce que je cherche ?

Merci !

[Fluckysan]

Je ne sais pas si j'ai bien compris ce que tu cherchais :o

Mais il va falloir que tu fasses ton propre adapter et que tu surcharges son getView pour afficher ce que tu veux (utilisé par exemple pour intercaler des lignes :))

[eden91940]

un screen shot ?

[Pierre87]

en fait tu peux avoir dans une liste :

- section

- row

- row

- row

- row

- section

- row

- row

- row

- section (vide)

- section

- row

- row

Modifié 16 avril 2010 par Pierre87

[eden91940]

ça me parle pas, mais je pense que c'est bien possible, regarde dans les samples du sdk ApiDemos

sinon y'a des listviews avec des trees mais je pense pas que c'est cela dont tu parles

[Pierre87]

ça peut m'intéresser les listview avec tree !

sauf que moi je ne veux pas replier le tree :P

[Pierre87]

et comment ça marche les listview "tree" ?

[thomas.l]

Tu veux faire comme la liste des RDV de l'application calendrier j'imagine ?

[Pierre87]

exactement !

[neoakira]

http://android.cyrilmottier.com/?p=232

[Pierre87]

ouais je vois le principe

mais c'est un peu "crade" de mélanger 2 types d'éléments dans CE cas

je voulais savoir s'il n'y avait pas un truc spécialement prévu pour ça, comme on me l'a dit pour l'iphone

[neoakira]

No comment

[Pierre87]

j'ai déjà lu ça et je l'ai déjà mis en pratique

mais je veux obtenir un truc du genre : http://www.absolutelyandroid.com/wp-content/uploads/2010/01/autostarts.png

alors ton "no comment" ...

[neoakira]

ExpandableListActivity et ExpandableListView ...

http://developer.android.com/intl/fr/reference/android/app/ExpandableListActivity.html

http://developer.android.com/intl/fr/reference/android/widget/ExpandableListView.html

[Pierre87]

je pense que c'est exactement ce que je cherche !

merci bien !

(bizarre que ça m'ait échappé ces classes...)

Modifié 17 avril 2010 par Pierre87

[Cyril Mottier]

En fait il n'y a pas vraiment ce qu'on trouve sur iPhone tout simplement parce que sur iPhone cette notion de section est directment intégrée au framework. Une cellule n'est pas seulement déterminée par une position mais par un objet "NSIndexPath" qui est un couple de 2 valeurs : section et row.

L'ExpandableList est ce qui se rapproche le plus de la notion mais son comportement est un peu différent. Si tu souhaite vraiment avoir le même comportement, il faut faire comme dans mon post (cf réponse de neoakira).

[thomas.l]

Dans le code de Cyril Mottier, ces lignes font toute la différence avec une liste basique :

               @Override
       public int getItemViewType(int position) {
           return (OBJECTS[position] instanceof String) ? ITEM_VIEW_TYPE_SEPARATOR
                   : ITEM_VIEW_TYPE_VIDEO;
       }

       @Override
       public boolean isEnabled(int position) {
           // A separator cannot be clicked !
           return getItemViewType(position) != ITEM_VIEW_TYPE_SEPARATOR;
       }

voir http://developer.android.com/reference/android/widget/BaseAdapter.html#getItemViewType%28int%29

[Pierre87]

@thomas.l

oui oui je connais cette "astuce"

mais ça me fait vraiment bizarre d'employer ça pour des "en têtes", car le type de données n'est absolument pas le même

Je trouve cette technique plus adaptée dans le cas où les données sont "différentes mais pas trop"

Par exemple, dans une de mes application, j'avais une liste de connexions (wifi et bluetooth).

Donc pour stocker mes données, j'avais une bête liste qui contenait des connexions.

Par contre, pour afficher des en têtes, getItemViewType me fait un peu peur :/

[Cyril Mottier]

@Pierre87

Il existe d'autre façon de créer des titres de sections mais il faut vraiment comprendre que ça n'est pas une fonctionnalité que le framework prévoit comme cela peut être le cas sur iPhone. Néanmoins, comme le framework permet de faire à peu prés tout ce qu'on veut, il est bien sûr possible de "simuler" ces en-têtes.

Une autre solution qui est parfois employée c'est de n'avoir qu'un seul et unique type de cellule puis de cacher ou afficher la partie "header" de cette cellule en fonction de sa place de la section (affichée si première, cachée sinon). Cette technique permet d'éviter les "bidouilles" sur les types de vues mais à d'autres inconvénients comme par exemple un "list selector" qui est partiellement caché pour les cellules au header affiché. ... Ok, je pense que j'ai laché tout le monde là :( Bah sachez que c'est possible et ça peut donner de très bon résultat !

[thomas.l]

Une autre solution qui est parfois employée c'est de n'avoir qu'un seul et unique type de cellule puis de cacher ou afficher la partie "header" de cette cellule en fonction de sa place de la section (affichée si première, cachée sinon). Cette technique permet d'éviter les "bidouilles" sur les types de vues mais à d'autres inconvénients comme par exemple un "list selector" qui est partiellement caché pour les cellules au header affiché. ... Ok, je pense que j'ai laché tout le monde là :( Bah sachez que c'est possible et ça peut donner de très bon résultat !

N'y-a-t-il pas des blagues du genre : l'en-tête reste clickable vu qu'elle "fait partie de la ligne du dessous" avec cette technique ?

Qui plus est, les composants masqués restent en mémoire et ça c'est moins bon (à la limite voir la technique de lazy init dans le xml ui mais sur une longue liste tous les composants en cache auront eu la chance d'afficher une fois un "premier de catégorie" et auront donc chargé le composant header).

[Cyril Mottier]

Une autre solution qui est parfois employée c'est de n'avoir qu'un seul et unique type de cellule puis de cacher ou afficher la partie "header" de cette cellule en fonction de sa place de la section (affichée si première' date=' cachée sinon). Cette technique permet d'éviter les "bidouilles" sur les types de vues mais à d'autres inconvénients comme par exemple un "list selector" qui est partiellement caché pour les cellules au header affiché. ... Ok, je pense que j'ai laché tout le monde là :( Bah sachez que c'est possible et ça peut donner de très bon résultat ![/quote']

N'y-a-t-il pas des blagues du genre : l'en-tête reste clickable vu qu'elle "fait partie de la ligne du dessous" avec cette technique ?

Qui plus est, les composants masqués restent en mémoire et ça c'est moins bon (à la limite voir la technique de lazy init dans le xml ui mais sur une longue liste tous les composants en cache auront eu la chance d'afficher une fois un "premier de catégorie" et auront donc chargé le composant header).

En effet, l'entête reste cliquable et c'est un bon point je trouve car ça évite les "rattages" de clics :)

Concernant l'empreinte mémoire c'est vraiment minime puisque qu'une ListView réutilise les vues et qu'au point de vue "measure" et "draw", les vues en visibilité "View.GONE" ne sont pas prise en compte.

[Pierre87]

Finalement, j'ai choisi une solution un poil différente de celle proposée par Cyril.

J'ai une (ou plusieurs) ArrayList pour mes éléments "similaires".

Et j'inflate mes Views "uniques" à la création de mon Activity.

C'est mon Adapter qui se charge de calculer le "décalage"

En gros, dans ma ListView j'ai :

- une ligne de titre

- une ligne d'onglets

- un nombre de ligne variable en fonction de l'onglet choisi précédemment

C'est assez rapide, mais l'adapter a vraiment une sale gu***** :D