Gestion Zoo

Jean-MichelJean-Michel Membre
août 2010 modifié dans Vos applications #1
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

Réponses

  • GreensourceGreensource Membre
    03:42 modifié #2
    Tu peux pas, il faut attendre un modo. Ou alors tu tapes Google dans Google mais là  tu fou en l'air l'internet tout entier c'est un peu radical.
  • Jean-MichelJean-Michel Membre
    août 2010 modifié #3
    Finalement, faut pas supprimer ça ira :)
  • Jean-MichelJean-Michel Membre
    03:42 modifié #4
    J'ai essayé de créer un vue uniquement par code, c'est faisable, ça fonctionne, c'est même pas forcément complexe (pour un helloWorld bien sur :p), en revanche, faire toute l'appli en code, ça me semble un peu aubsé !

    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...)

  • GreensourceGreensource Membre
    03:42 modifié #5
    Si c'est pas trop méchant tu fait un méga XIB avec tout, et tu cache ce dont tu n'as pas besoin. Je pense que c'est ce qui prend le moins de code et le moins la tête.
  • Jean-MichelJean-Michel Membre
    03:42 modifié #6
    Bah, ça dépend de ce que tu appelles "pas trop méchant" :)

    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
  • GreensourceGreensource Membre
    03:42 modifié #7
    J'ai pas saisi exactement ce que tu dis dans ton dernier message mais j'ai l'impression que tu es sur la bonne voie. En tout cas moi j'essaierais de factoriser ce qui peut l'être et ce qui est vraiment spécifique le faire par le code.

    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...
  • Jean-MichelJean-Michel Membre
    03:42 modifié #8
    Bonjour,

    Je vais détailler un peu plus mon idée à  la pause déjeuner ;)

    Merci
    Jean-Michel
  • Jean-MichelJean-Michel Membre
    août 2010 modifié #9
    Alors, voici un peu plus de détails sur ma façon de voir et sur laquelle j'aimerais des avis donc :


    - 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
  • GreensourceGreensource Membre
    03:42 modifié #10
    Bas ouais du coup ça me semble pas mal si j'ai bien compris. Peut-être je factoriserai la vue besoin naturel dans un seul XIB à  part vue que tu le retrouves partout?
  • Jean-MichelJean-Michel Membre
    03:42 modifié #11
    Oui en effet, si ensuite je peux appeler plusieurs XIB en même temps, alors pourquoi pas :)

    Merci des infos en tout cas !

    Jean-Michel
  • DrakenDraken Membre
    03:42 modifié #12
    Tu penses trop à  la technique. On ne crée pas un programme en pensant à  sa structure interne, mais plutôt à  la manière dont il vas interagir avec l'utilisateur. Prend un crayon et un papier et dessine tes interfaces, pense à  ce que l'utilisateur doit voir sur l'écran. Aux fonctions dont il a naturellement besoin et la manière de les utiliser. Des boutons à  cliquer, des gestures ?

    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.


  • Jean-MichelJean-Michel Membre
    03:42 modifié #13
    dans 1281019940:

    Tu penses trop à  la technique. On ne crée pas un programme en pensant à  sa structure interne, mais plutôt à  la manière dont il vas interagir avec l'utilisateur. Prend un crayon et un papier et dessine tes interfaces, pense à  ce que l'utilisateur doit voir sur l'écran. Aux fonctions dont il a naturellement besoin et la manière de les utiliser. Des boutons à  cliquer, des gestures ?

    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
  • AliGatorAliGator Membre, Modérateur
    03:42 modifié #14
    Dans l'exemple que tu cites, tout est générique-personnalisé, c'est à  dire que comme tu le dis, tu as le choix d'un enclos, puis d'un animal, puis des actions. Après, certes la liste des actions possibles dépend de l'animal choisi. Un Koala ne pourra pas plonger. Mais ça c'est ton modèle qui fournira la liste des actions possibles. Cette liste d'actions, tu peux la présenter dans une UITableView aux cellules personnalisées (ou pas), chaque cellule (UITableViewCell) pouvant par exemple soit juste contenir le texte de l'action (et quand l'utilisateur clique sur la cellule, ça exécute l'action), soit un UIButton avec le nom de l'action comme "title"... Ou sinon, tu peux utiliser une UIActionSheet, etc... mais tout ça reste générique. Seule la liste des actions possibles change.

    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.
  • GreensourceGreensource Membre
    03:42 modifié #15
    dans 1281019940:

    comme exemple Green peut pousser un beep d'énervement en recevant une entrecôte au lieu d'une pile de 9 volts.


    Tiiiteee Beeeep Wahouuuuuuuuuuu
  • DrakenDraken Membre
    03:42 modifié #16
    :D
Connectez-vous ou Inscrivez-vous pour répondre.