Organisation des UIView, UIViewControlleur et NSObject dans une application iOS

Bonjour,

Je débute en objective-C, j'ai lu le livre "Big Neerd Ranch" et j'ai suivi les cours en ligne de Standford sur iTunes.
J'ai réalisé de petites applications avec succès mais je bloque sur la réalisation d'une plus complexe.

Ma question finale sera : quelle architecture/organisation des UIView, UIViewControlleur et NSObject dans une application iOS ?

Mon application simple : afficher un histogramme (juste des baton de taille différentes pour le moment) sur une partie de l'écran
- Je ne fais rien dans le storyboard
- Je crée 3 classes :
*** une NSObject "Baton" avec la valeur du baton
*** une NSObject "ListeBaton" avec un tableau de "Baton" dans les valeurs sont générée aléatoirement
*** une UIView "BatonHistogramme" avec des @property : hauteur, largeur, position x et y
- Dans le contrôleur de vues j'initialise un "listeBaton" et j'ajoute des "BatonHistogrammes" à ma vue.

Cela me donne le résultat attendu : des batons de tailles différentes alignés dans une zone plus petite que l'écran (car je l'ai défini comme cela)

Mon application complexe : afficher un graphique avec plusieurs séries d'histogrammes, une légende, une échelle... et plusieurs graphiques de ce même style à l'écran. Non superposés bien entendus :-)
- Comment gérer tout cela :
*** utiliser un MVC pour chaque partie ? par exemple un MVC pour l'histogramme, un pour l'échelle... ?
*** faire des vues et sous-vues ? par exemple une vue graphique qui appelle un vue légende et plusieurs vues histogrammes qui appellent elles-même plusieurs vues batonHistogramme...?

Vous l'aurez compris : je me perds dans la logique de ces différents "objets" et les interactions entre eux.
Ce que j'attends donc comme réponse est plutôt le mode de pensée que de résoudre mon problème d'histogramme de façon pratique (c'est juste pour donner un exemple pour être plus parlant)

Merci de votre aide :-)

Greg

Effectivement tu n'as pas [totalement] compris le MVC :mrgreen:

Donc ton but c'est de faire un seul écran avec des histogrammes.

Mais un écran c'est un MVC (peut-être pas la façon la plus élégante de le dire :wow:): tu vas avoir d'1 côté ton contrôleur, de l'autre tes vues (avec les différentes versions iPhone/ IPad et les localisations) et éventuellement tes données.

Un vue c'est un fichier xib (peut-être pas, également, la façon la plus élégante de le dire :wow:)
Dans ton xib, tu vas mettre tous tes éléments.
Lorsque je parle d'éléments ce sont des UIVIew ou des classes filles (comme UIImageView).
Par exemple, pour la légende tu peux prendre un label
Si tu veux une vue personnalisée donc c'est simple: 1) tu codes une classe en la dérivant au moins de UIVIew qui sera la logique, l'affichage et les interactions avec le contrôleur 2) dans ton xib tu mets une UIVIew 3) Tu changes la classe de cette UIVIew (2ième onglet dans les propriétés Interface Builder de mémoire)

Ton contrôleur lui est au milieu: il va gérer les interactions (comme le redimensionnement, le passage avec la vue suivante et précédente, etc...) et la gestion de la mémoire (notamment il va contenir tous tes éléments et gérer les alertes mémoire).
Par exemple si tu appuies sur un bouton, il va appeler le contrôleur (avec une fameuse méthode IBAction)
Le contrôleur peut avoir d'autres rôles: à voir, et à définir.

Pour tes données: là cela dépend :mrgreen:
Moi pour les petits projets, j'avais un singleton "all datas", initialisé et détruit par le AppDelegate (notamment le gestion background/ foreground était pratique :mrgreen:)
Et je faisais bien attention qu'il n'y avait qu'une seule classe qui écrivait une donnée, même si plusieurs la lisait.

Après tout n'est pas "gravé dans le marbre", mais c'est l'approche classique :mrgreen:

Citation:

---

Envoyé par gregfreemind

Je ne fais rien dans le storyboard

---

Je ne suis pas passé aux storyboards, mais c'est le même principe mais tu traites plusieurs écrans en même temps :mrgreen:

Citation:

---

Envoyé par gregfreemind

- Je crée 3 classes :
*** une NSObject "Baton" avec la valeur du baton
*** une NSObject "ListeBaton" avec un tableau de "Baton" dans les valeurs sont générée aléatoirement
*** une UIView "BatonHistogramme" avec des @property : hauteur, largeur, position x et y
- Dans le contrôleur de vues j'initialise un "listeBaton" et j'ajoute des "BatonHistogrammes" à ma vue.

---

Ne te sens pas obliger de coder comme en Java :mouarf: :mouarf:

Les cas où j'ai utilisais les NSObject c'est pour les collections (NSArray, NSMutableArray, et autres petits frères) qui travaillent qu'avec ces objets ou dérivés (ils font des retain et des release en théorie)


Mais cela me semble un peu tordu: :aie:
Pour ta vue BatonHistogramme, c'est ce que je ferais.

Il faut un tableau d'entiers ou de flottants. Pourquoi faire une classe Baton pour encapsuler une valeur? :koi: :koi:
Le mettre dans le contrôleur ou ailleurs (comme dans un singleton)

Mais tu as besoin de rien d'autre. Dans ta vue BatonHistogramme, dans la méthode - (void)drawRect:(CGRect)rect tu demandes ton tableau et tu l'affiches avec une boucle for.

Après, pour un exemple aussi trivial, tu peux mettre ton tableau dans ta vue.

Merci beaucoup par réponse et d'avoir pris le temps de préciser aussi clairement les choses.
c'est beaucoup plus clair comme ça :D
Thanks
Greg