Gestion Zoo
Jean-Michel
Membre
Bonjour,
Je dois réaliser une application qui doit permettre de gérer un parc animalier
La gestion de ce parc est virtuelle, mais j'aimerais pouvoir avoir une application qui tourne bien.
Avant de me lancer dans tout et n'importe quoi, j'aurais préféré connaitre vos avis sur la conception de la chose, donc je vais vous donner quelques infos pour vous permettres de m'orienter !
Scénario de l'application :
Ecran 1 : Affichage du choix de l'utilisateur (un XML de config m'informe si je dois charger les logins ou non et un autre me donne la liste)
Ecran 2 : Affichage du plan avec choix de la zone (chargement d'un png de la zone + un XML qui défini de CGRect cliquable pour les enclos)
Ecran 3 : Liste des différents animaux de l'enclos sélectionné
Ecran 4 : Liste des différentes actions pour l'animal sélectionné
donc, l'architecture de navigation c'est :
--> login (une liste)
--> plan des enclos (un png)
--> liste des animaux (4 icones sur x icones 57x57px)
--> actions sur les animaux (Manger, boire, courir, rentrer, etc...)
Je vois mal comment organiser mes XIB, etc...
Je me demande si :
- Je crée un XIB par race d'animal ou 1 XIB "Animaux" que je rempli et vide par code
- Je crée un XIB vide pour le plan, que je charge un PNG à la volée et une liste de coordonnées via XML pour la position et taille des enclos ou si je crée le plan dans IB
La liste des animaux par enclos (et genre d'animaux), sont gérer par XML
Je me met au XCode, je réussi les tutos, mais ensuite faut quand même une logique de prog avant de se lancer pour ne pas devoir recommencer !
Merci d'avance pour vos avis et conseils
Jean-Michel
Je dois réaliser une application qui doit permettre de gérer un parc animalier
La gestion de ce parc est virtuelle, mais j'aimerais pouvoir avoir une application qui tourne bien.
Avant de me lancer dans tout et n'importe quoi, j'aurais préféré connaitre vos avis sur la conception de la chose, donc je vais vous donner quelques infos pour vous permettres de m'orienter !
Scénario de l'application :
Ecran 1 : Affichage du choix de l'utilisateur (un XML de config m'informe si je dois charger les logins ou non et un autre me donne la liste)
Ecran 2 : Affichage du plan avec choix de la zone (chargement d'un png de la zone + un XML qui défini de CGRect cliquable pour les enclos)
Ecran 3 : Liste des différents animaux de l'enclos sélectionné
Ecran 4 : Liste des différentes actions pour l'animal sélectionné
donc, l'architecture de navigation c'est :
--> login (une liste)
--> plan des enclos (un png)
--> liste des animaux (4 icones sur x icones 57x57px)
--> actions sur les animaux (Manger, boire, courir, rentrer, etc...)
Je vois mal comment organiser mes XIB, etc...
Je me demande si :
- Je crée un XIB par race d'animal ou 1 XIB "Animaux" que je rempli et vide par code
- Je crée un XIB vide pour le plan, que je charge un PNG à la volée et une liste de coordonnées via XML pour la position et taille des enclos ou si je crée le plan dans IB
La liste des animaux par enclos (et genre d'animaux), sont gérer par XML
Je me met au XCode, je réussi les tutos, mais ensuite faut quand même une logique de prog avant de se lancer pour ne pas devoir recommencer !
Merci d'avance pour vos avis et conseils
Jean-Michel
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
D'un autre côté, comme je risque d'avoir plusieurs type d'animaux, est-ce qu'un XIB par animal (et donc se retrouver avec une 100ène de XIB) est une bonne idée ?
Surtout que la plupart pourraient avoir de nombreuses similitude (boire, manger, dormir), et d'autres pourraient (sauter, se rebeller, imiter, etc...)
Mettre 50 vues sur un seul XIB c'est ptet un peu lourd si je dois modifier une vue non ?
Je lance le .XIB et j'ai mes 50 vues qui s'affichent ? si c'est ça, c'est pas gérable lol
Par contre, peut-etre que je peux créer des groupes de commandes (des vues?) et en afficher un, ou deux, ou trois ...
genre :
- XIB 1 besoin naturel : manger, boire, dormir
- XIB 2 divertissement : courir, sauter, plonger, etc...
et dans chaque XIB plusieurs vue (ex XIB 2) :
- Vue 1 : Courir, Sauter, Tomber
- Vue 2 : Courir, Voler
- Vue 3 : Ramper
et là se serai une vue ou une autre (voir 2 en même temps pourquoi pas)
ça vous semble logique ?
Jean-Michel
Par oui c'est pas logique d'avoir un XIB avec 50 éléments et seulement 10% qui servent à chaque fois que tu l'ouvres. De la même façon c'est illogique d'avoir 50 XIB avec des choses identique qui se trouvent dans 90% des XIB.
Donc il faut trouver le bon compromis.
Au cas ou j'aurais bien compris ton exemple, moi j'aurais même splitter un peu plus:
1 XIB pour la vue: Courir, Sauter, Tomber
1 XIB pour la vue: Courir, Voler
1 XIB pour la vue: Ramper
Mais c'est peut-être trop pour le coup...
Je vais détailler un peu plus mon idée à la pause déjeuner
Merci
Jean-Michel
- Login.XIB (la liste des logins, chargé via XML sur le réseau)
- Plan.XIB (c'est le plan, chargement de l'image via le réseau et des coordonnées via XML)
Plusieurs vues possible si le plan à besoin d'etre découpés en catégorie (poisson view, mammifère view, etc view...)
- Aminaux.XIB (la liste des animaux dispo pour chaque "enclos")
Presque au format des pages d'accueil de l'iphone, à savoir 4 icones horizontales sur X icones vertical (pas le même sens de slide que iOS donc)
- ControlTerre.XIB avec plusieurs vues dont :
* besoin naturels view : les boutons "Manger", "Boire", "Dormir", "Copuler"
* sport view 1 : "courir"
* sport view 2 : "sauter"
* complicite view 1 : "donner la patte", "se rouler par terre", "tendre le bras", "regarder fixement"
- ControlMer avec plusieurs vues dont :
* besoin naturels view : les boutons "Manger", "Boire", "Dormir", "Copuler"
* attitude view 1 : "plonger", "rester dans l'eau"
* attitude view 2 : "sauter hors de l'eau", "rester à la surface"
* attitude view 3 : montrer les dents
- ControlAir
* besoin naturels view : les boutons "Manger", "Boire", "Dormir", "Copuler"
* attitude view 1 : "reperage de proie"
* attitude view 2 : "voler", "planer", "s'accrocher sur une branche"
par exemple un chien pourrait avoir sur le "XIB Terre" les vues simultanées :
* besoin naturels
* sports view 1
* sports view 2
* complicite view
par exemple un hamster pourrait avoir sur le "XIB Terre" les vues simultanées :
* besoin naturels
* sports view 1
par exemple un poisson rouge pourrait avoir sur le "XIB Mer" les vues simultanées :
* besoin naturels
* attitude view 1
par exemple un requin pourrait avoir sur le "XIB Mer" les vues simultanées :
* besoin naturels
* attitude view 1
* attitude view 2
* attitude view 3
Voila un peu comment le vois le truc, avec une tabBar présente en permanence qui me permet de revenir rapidement à certains endroit de l'interfaces (plan, user, liste...)
Est-ce plus claire sur ma façon de voir, et est-ce que c'est une méthode viable ?
Jean-Michel
Merci des infos en tout cas !
Jean-Michel
Prenons par exemple l'action de nourrir un animal.
Dans un système informatique classique, c'est un bouton "Nourrir" à cliquer. On peut personnaliser le texte en fonction du type d'animal.
- "Donner de la viande" (lions, tigres, loups, Ali, etc.)
- "Donner des poissons" (Phoques, Otaries, etc)
- "Donner du fourrage" (herbivores)
- "Donner des bananes" (singes)
- "Donner du bambous" (panda)
- "Piles électrique" (greenSource)
Et même ajouter de petites images d'aliments à coté des textes.
Dans un système tactile comme l'iPhone, l'action la plus naturelle est de poser le doigt sur un aliment et le déplacer sur l'animal affamé. Tu peux afficher directement l'aliment adapté ou un tas de tous les aliments possibles (viandes, poissons, fourrages, bananes, etc). L'utilisateur devant faire le bon choix. Un animal recevant un mauvais aliment pourra protester, comme exemple Green peut pousser un beep d'énervement en recevant une entrecôte au lieu d'une pile de 9 volts.
Bref, les choix d'interfaces sont nombreux, des utilisateurs ciblés (enfants en jeunes âge) ou professionnels de la gestion d'un parc, du temps de développement, de ton budget, de ta capacité à faire réaliser des ressources graphiques ou sonores (ça coute cher les zolies images et les bruitages).
C'est seulement alors que tu pourras penser à l'architecture interne de ton application. L'interface et "l'expérience utilisateur" ne doivent pas être dépendants de raisons techniques.
Alors, je suis d'accord avec toi, la technique ne doit pas à elle seule être un frein à l'ergonomie de l'interface. Cependant, avoir sur un même écran tous les animaux et toutes les fonctions risquent de rendre le tout un peu fouilli.
C'est pour ça, entre autre, que j'avais vu d'abord le choix de l'animal (on n'a rarement un seul animal dans un enclos !), puis des actions possible sur celui ci.
Donner du poisson à un chat, le chat rale, effectivement ça va pas lui plaire, mais dans mon cas, je ne veux pas que cela arrive, je ne veux pas donner à l'utilisateur la possibilité de se tromper (ça doit être simple, je ne fais pas un jeu éducatif où les plus petits apprennent à savoir quoi donner à qui).
Donc,
- je choisi mon enclos sur ma carte
- je choisi le koala (celui avec la petite tache blanche sur l'oreille)
- je lui donne à "manger", ou je le fait "grimper", etc. mais je ne veux pas pouvoir lui donner l'occasion de plonger dans l'eau, il ne doit avoir que des choses possibles. Donc en faut de sa fiche perso à lui, il aura son age, son poid, etc... et en dessous des infos, les actions possibles (mais peu d'actions).
Je n'ai pas de contrainte de budget (c'est fait en interne), contrainte de temps un peu mais sans plus (le plus vite possible en fait lol), et graphiquement j'ai déjà tout ce qu'il faut !
Merci en tout cas pour les bons conseils
Par exemple tu peux créer une classe "Animal", avec une méthode [tt]-(NSArray*)possibleActions;[/tt], et des sous-classes "Koala", "Cochon", "Poisson", "Lion", ... dérivant donc de "Animal" et implémentant cette méthode chacun à leur manière, renvoyant chacune le bon tableau / la bonne liste d'actions possibles pour chaque classe / type d'animal.
Et après utiliser ce NSArray / liste d'actions pour remplir ton interface avec des boutons, le plus simple étant via une UITableView donc mais rien ne t'empêche de les présenter autrement, avec une interface générique pouvant présenter de 1 à N actions pour l'animal choisi. Cette interface sera donc générée par code, mais si c'est une UITableView, ça se fait en quelques lignes dans le [tt]tableView:cellForRowAtIndexPath:[/tt] qui retourne l'"objetAtIndex:x" de ton NSArray... et si ce sont des UIButtons que tu positionnes manuellement dans une UIView, ça se fait dans une boucle "for" de toute façon... alors bon c'est pas violent, et ne mérite surtout pas d'avoir un XIB par animal pour ce genre de cas, un seul XIB commun pour présenter les actions possibles (voire aucun XIB, tout via un UITableViewController) ça suffit amplement.
Tiiiteee Beeeep Wahouuuuuuuuuuu