Discussion :

[declencher]

Bonjour,

J'ai une question classique en programmation, et à laquelle je cherche une réponse optimisée pour Android.

Pour illustrer ce que je veux faire, je vais prendre l'exemple d'une base de donnée avec des biens immobiliers.

Je souhaite donc créer un formulaire pour enregistrer les biens immobiliers dans ma base et ça de la meilleure façon possible car il ne me semble pas intéressant de créer un formulaire générique.

Si le type de bien immobilier est "parking", alors je ne dois proposer de saisir que la surface.
Si c'est un garage, alors j'ai en plus des boolean comme "eau" et "électricité".
Si c'est un appartement, alors je peux avoir un garage ou un parking avec chacun leur caractéristique, et en plus j'ai les caractéristiques d'un logement, et des caractéristiques spécifique à l'immeuble (ascenseur...).
Si c'est une maison, j'ai un parking ou un garage avec leurs caractéristiques, les carastéristiques d'un logement, et les caractéristiques spécifique à une maison (jardin...).

Comme vous pouvez le voir avec cet exemple, j'ai des caractéristiques qui sont parfois communes sous condition, d'autres qui sont spécifiques, le tout étant piloté par le type de la construction.

Sur un formulaire Web, il aurait suffit de désactiver de nombreuses zones de saisie en fonction du type, mais ce comportement ne me semble pas acceptable pour une appli mobile.

J'ai regardé de nombreuses appli en exemple, et je n'ai rien trouvé de similaire. Il y a toujours une activité simple, peu de dynamisme dans les zones de saisies, et des choix par liste déroulante (ou une activité affichant une liste à cocher) uniquement...

Vous en pensez quoi ? Vous auriez un avis et des conseils à me donner ?

[grunk]

Sur un formulaire Web, il aurait suffit de désactiver de nombreuses zones de saisie en fonction du type, mais ce comportement ne me semble pas acceptable pour une appli mobile.

et pourquoi donc ?

Un formulaire complet dont tu conditionne l'affichage me semble être une bonne solution.
Une autre possibilité pourrait être un viewpager , avec chaque page qui correspond à un type de bien et donc le formulaire associé au type de bien dans le fragment.

[declencher]

et pourquoi donc ?

Je n'ai jamais vu d'appli avec un formulaire aussi dynamique que ce qu'il me faudrait, et surtout ça obligerai à afficher de nombreux composants visuels qui ne servirait pas. Je me demande si ça n'apporterait pas plus de confusion.

Pas mal ton idée du viewpager.

Je viens de me demander si ce ne serait pas sympa d'avoir une liste déroulante pour le choix du "type", et des fragments qui sont chargés dynamiquement en fonction du "type" choisi. ça en revient au même que le viewpager.

En fait j'ai un appriori sur le viewpager. Je n'ai jamais vu une appli pour qui son utilisation était "évidente" (ergonomique). Qu'en penses tu ? Tu aurais un exemple d'appli ?

[grunk]

Je viens de me demander si ce ne serait pas sympa d'avoir une liste déroulante pour le choix du "type", et des fragments qui sont chargés dynamiquement en fonction du "type" choisi. ça en revient au même que le viewpager.

C'est une possibilité oui

Je n'ai jamais vu une appli pour qui son utilisation était "évidente" (ergonomique). Qu'en penses tu ? Tu aurais un exemple d'appli ?

L'application horloge , le play store , toute les appli qui on une navigation horizontale utilisent généralement un view pager. L'ergonomie du view pager vient en grande partie des onglets ou de l'indicateur de pagination que tu vas lui associer. Il arrive effectivement que ce soit pas toujours très clair.

[declencher]

Salut,

J'ai un gros doute sur la pertinence d'utiliser un viewpager. Dans mon cas il faudrait un formulaire de saisie par type de bien immobilier

J'ai tenté la solution du formulaire classique tel que sur le web où je joue avec la propriété enable en fonction d'un choix fait dans une liste déroulante. Le résultat n'est pas convainquant : Sur 10 données, il faut parfoit que j'active la première et la dernière, et dans d'autre cas il faut que j'active la première, la deuxième et la cinquième... Bref c'est pas pratique. Et en plus visuellement on ne voit pas toujours bien si le composant est editable ou non...

Les pistes qu'il me reste :
- construire le formulaire par code (dynamiquement)
- tester le viewpager
- une autre idée ?

[nicroman]

Voilà comment j'approcherai le problème.

Question "structure de données", même si certaines notions ne sont pas pertinentes en fonction du "type" de bien, il y a de fortes chances pour que le stockage (BdD, ...) lui s'en fiche et stocke tout bêtement. Ne serait-ce que par simplification des requêtes agrégées par la suite.

Par conséquent, un formulaire *complet* permettant de remplir cette structure de données est à prévoir. Le fait qu'une donnée soit pertinente pour un type ou non n'a de sens qu'au niveau de l'utilisateur (et donc de l'UI).

Par conséquent un simple "mapping" des "données pertinentes" par type devrait suffire pour "customiser" le formulaire (par simple "hide" de l'élément dans l'interface en fonction du type).



Après le fait qu'une garage / parking / cave soit associé à un bien c'est une notion différente... un "lien" de parentée entre les objets eux-même.
De deux manières: une table de liaison indépendante (Le bien X est lié au bien Y), ou simplement la notion à l'intérieur de l'objet lui même: chaque bien a potentiellement un autre bien en parent.
Dans les deux cas, cela veut dire que le formulaire contient une "liste" (ListView) de bien liés..

[declencher]

Salut !

Le voilà l'élément qui me manquait ! setVisibility

Pour les newbies comme moi, cette méthode peut prendre ça comme paramètre :

View.GONE - This view is invisible, and it doesn't take any space for layout purposes.
View.INVISIBLE This view is invisible, but it still takes up space for layout purposes.

Je vais tester ça.

Pour le reste je suis complètement d'accord sur le principe. Et là nous avons peut être identifié la meilleur solution technique.

Merci nicroman !