›

Organisation du code d'un projet

AstramAstram Membre
dans Apple Developer Programs #1
Bonjour à  tous,



jusque là  je n'ai programmer que pour moi-même, donc juste fait des petits programmes "tests" sur iOS.



Je voudrai maintenant passer à  la programmation d'une application iPhone permettant la gestion d'un compte utilisateur, avec accès à  l'application seulement après avoir passé un formulaire de login.



Je voulais savoir comment organiser un projet comme celui là .



Dois-je organisation sous forme de librairie statique (une classe utilisateur par exemple avec les méthodes et attributs relatifs à  un utilisateur et appelé depuis les viewcontrollers?



Ou alors utiliser directement les .m .h .xib directement représentant chacun un écran avec les données qui s'y rapportent?



Je ne sais pas si j'ai été très clair...en gros, y a-t-il des principes recommandé d'organisation du code ?



J'espère que vous pourrez m'éclairer.



Merci
Mots clés:

Réponses

  • StephSteph Membre
    #2
    Si c'est juste un fenêtre de login, tu peux gérer ça directement dans un viewController je pense.



    En revanche, si il y a plusieurs interaction utilsateur, dans différentes vues, à  ce moment là , mieux vaut une class dont tu appelleras les méthodes depuis tes contrôleurs, ça évite de répéter du code.



    Prends le cas d'un dialogue avec un webservice par exemple, tu risques de faire plusieurs fois les mêmes choses (ouverture de session, récupération d'informations, post, etc) là , clairement, fais toi une class.
  • AstramAstram Membre
    #3
    Merci de ta réponse,



    c'est justement ce que j'ai besoin de faire, j'aurai 4 onglet dans un tabbar. Dans chaque onglet, j'aurai besoin de récupérer des infos via webservice. Existe-t-il des exemples de class comme celle que tu m'a proposé de faire?
  • StephSteph Membre
    #4
    Euh, des exemples, tu as toutes les lib dispo sur le net.



    En gros tu fais une class, tu l'a fais hériter de NSObject.



    Tu places tes méthodes accessible avec un +(void) ou +(ce que tu veux) et les méthodes internes classiquement avec un - et roule.
  • CeetixCeetix Membre
    #5
    'Steph' a écrit:


    Tu places tes méthodes accessible avec un +(void) ou +(ce que tu veux) et les méthodes internes classiquement avec un - et roule.




    O_O
  • AliGatorAliGator Membre, Modérateur
    #6
    Gné?
  • AstramAstram Membre
    #7
    hin? image/wink.png' class='bbc_emoticon' alt=';)' />
  • zoczoc Membre
    #8
    'Axton56' a écrit:


    Dois-je organisation sous forme de librairie statique


    Une librairie statique ?



    Le seul intérêt d'une librairie statique (ou dynamique si on ne se limite pas à  iOS), c'est de faciliter la réutilisation du même code au sein de plusieurs applications sans avoir à  recompiler tout à  chaque fois.



    Ou alors pour les très grosses applications, regrouper effectivement le code par fonctionnalité. J'aurais tendance, en ce qui me concerne, à  faire une librairie par "package" UML (quoi, vous ne faites pas de modélisation UML pour vos applications ? image/xd-laugh.gif' class='bbc_emoticon' alt='xd' /> ).



    Sinon, clairement, pour une application avec 4 pauvres controlleurs qui se battent en duel, une librairie n'a aucun intérêt (à  part, encore une fois, si tu comptes réutiliser les controlleurs dans plusieurs applications, et encore...).
  • CeetixCeetix Membre
    #9
    Moi je ferai un singleton pour ton cas.
  • CéroceCéroce Membre, Modérateur
    #10
    Purée, arrêtez avec les singletons à  toutes les sauces.
  • CeetixCeetix Membre
    #11
    Bah là  ça n'est pas justifié pour toi ?

    Tu instancierais une classe dans chacun de ses controlleurs ?
  • StephSteph Membre
    #12
    Bon ok, je suis pas en état de bien expliquer ma pensée là  ... MDR !



    Je vous laisse le faire les gars !
  • zoczoc Membre
    #13
    Le pattern singleton, c'est le pire truc qui ait été inventé... Autant coder directement en C, ça revient au même et au moins il n'y a plus tout l'overhead du runtime.
  • CéroceCéroce Membre, Modérateur
    #14
    Le Singleton a été fait pour représenter un objet qui a forcément une instance unique dans une application, pas comme un moyen "objet" d'implémenter des variables globales.

    Par exemple, sur Cocoa Touch, UIDevice est un singleton, et c'est logique, on ne tourne que sur un seul terminal.



    Pour une base de données par exemple, ce n'est pas malin: on peut tout à  fait imaginer ouvrir plusieurs bases au sein d'une même appli. N'est-il pas plus intelligent d'instancier l'objet BdD dans l'App Delegate, et le passer aux contrôleurs qui en ont besoin ?
  • CeetixCeetix Membre
    avril 2012 modifié #15
    Ah mais il parle de BDD là  ? Moi je pensais à  un objet qui permet de checker si genre la session était tjs bonne (online donc). C'est pas bon non plus ?



    Après pour passer un objet d'un controlleur à  l'autre oui mais tu ne crées par une forte dépendance ?
  • CéroceCéroce Membre, Modérateur
    avril 2012 modifié #16
    'Ceetix' a écrit:


    Ah mais il parle de BDD là  ? Moi je pensais à  un objet qui permet de checker si genre la session était tjs bonne (online donc). C'est pas bon non plus ?


    C'était un exemple. Mais là , on pourrait passer un objet Session.


    'Ceetix' a écrit:


    Après pour passer un objet d'un controlleur à  l'autre oui mais tu ne crées par une forte dépendance ?


    Au contraire, les dépendances sont clairement identifiées et n'apparaissent que là  ou c'est nécessaire. Par exemple, si la session n'est nécessaire que dans l'onglet Option, alors OptionViewController aura une propriété Session, et l'AppDelegate lui passera. Après, OptionViewController en fait ce qu'il veut. Peut-être qu'il ne l'utilise pas directement, et que c'est un sous-contrôleur qui l'utilise. L'avantage est évident: l'AppDelegate n'a pas à  connaitre la structure sous-jacente de OptionViewController. Celle-ci peut changer, tant que l'interface publique d'OptionViewController ne change pas, l'AppDelegate y fait toujours appel de la même façon. Les dépendances sont donc faibles.



    L'inconvénient de cette méthode, c'est qu'on doit souvent surcharger les setters pour passer un objet d'un contrôleur à  un autre!
  • CeetixCeetix Membre
    #17
    Ok c'est vrai tu as raison.

    Par contre pourquoi surcharger le setter ?
  • CéroceCéroce Membre, Modérateur
    avril 2012 modifié #18
    Parce que si OptionViewController utilise un sous-contrôleur et qu'en fait c'est lui qui a besoin de l'objet Session, tu auras quelque chose comme ça dans OptionViewController:


    <br />
- (void) setSession:(Session *)session<br />
{<br />
childController.session = session;<br />
}<br />
- (Session *)session<br />
{<br />
return childController.session;<br />
}<br />
  • BaardeBaarde Membre
    #19
    Ou alors on peut considérer que la session ne changera pas, mettre la property en readonly et implémenter initWithSession:
Connectez-vous ou Inscrivez-vous pour répondre.