Application pour iOS et OS X

JE729

Bonjour, 

 

Je commence un projet qui va être à  la fois porter sur iOS (iPad) et OS X. J'essaie de suivre les règles du MVC.

Pour ce qui est du modèle, mes fichiers sont compatibles avec les deux à  l'aide de define. Voici un exemple :

#if TARGET_OS_IPHONE || TARGET_IOS_SIMULATOR



#define CPColor UIColor



#else



#define CPColor NSColor



#endif

Au niveau des controllers, rien de particulier non plus.

Mais je cherche à  organiser les fichiers du coté View. D'apparence elles sont pratiquement pareil mais les fonctionnement ne sont pas vraiment similaires en interne. Par exemple la gestion des événements et du drag and drop de vue en vue sont vraiment different selon l'OS et cela me fait ajouter des #if TARGET_OS_IPHONE || TARGET_IOS_SIMULATOR un peu partout, chose qui a tendance à  rendre le code un peu fouillis.


Je me demandais donc comment il faut organiser les choses ? séparer complètement les classes, créer des categories ou je ne sais pas quel artefact ?

Si vous avez d'autres conseils, je suis preneur

AliGator

S'il y a trop de différences, faire des classes séparées et inclure la bonne classe dans chacun des target.

JE729

Ok je vais faire comme ca merci

yoann

Le bouquin Design Pattern serait d'une grande aide ici.

JE729

Tu penses à  quel bouquin en particulier ?

yoann

LE livre Design Pattern :-)


http://www.amazon.fr/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612

samir

Bonsoir,

 

Moi (avis sans expérience sur le sujet), j'aurais crée deux projets complètement différent sans utilisation des targets, puisque à  mon avis toute les if target X  va compliquer encore plus le code. 

 

Le mieux serait de respecter au mieux les conventions objets et d'utiliser les patterns adéquats et de réutiliser le maximum en tre les deux projets :

 

1. MVC : Bien séparer les trois composants. Tu dois pouvoir réutiliser ton modèle dans les deux plateformes.

 

2. Bien définir les responsabilités de tes classes. Chaque classe doit avoir une seule responsabilité et non pas un nombre illimité.

 

3. Avec le respect du point 2, tu dois avoir des classes qui ne sont pas dépendantes donc réutilisables. ( Comme la classe qui gérer les communications réseaux,....). 

....

 

JE729

Je viens de télécharger le livre yoann plus qu'à  le lire maintenant

 

Je viens de commencer à  lire /B-Meyer-Conception-et-programmation-orientees-objet qui est apparemment de ce qu'on m'a dit LE livre sur la programmation objet.

Mala

Le problème de ces bouquins c'est qu'ils sont très génériques et qu'ils ne peuvent donc tenir compte des subtilités d'un language. 

 

Par exemple en Cocoa on a le "Toll-Free Bridging" qui peut sérieusement compliquer la vie au niveau héritage et qui oblige bien souvent à  encapsuler plutôt qu'à  hériter. Dans le cas qui te concerne, ce serait d'ailleurs l'approche qui me semble la plus seine. Ainsi tu enrichies tes accesseurs à  mesure de tes besoins et tu es sûr de ne jamais appeler une méthode sous iOS qui ne serait pas implémentée sous OS X et vice et versa.

Booleanne

Moi (avis sans expérience sur le sujet), j'aurais crée deux projets complètement différent sans utilisation des targets, puisque à  mon avis toute les if target X  va compliquer encore plus le code.

 

Avis sans expérience non plus, mais je travaille depuis maintenant 2 ans sur un projet mixte iPhone/iPad avec interfaces totalement différentes et pas mal de spécificités au niveau du code. J'apprécie vraiment d'avoir un projet unique quand je fais des mises à  jour. Je n'imagine même pas si je devais faire le boulot 2 fois. Même si je dois tester sur les différents device, il y a quand-même une grosse partie de méthodes uniques, et je trouve que ça fiabilise le code. Ca me paraà®t plus léger, quand-même.


 

et tu es sûr de ne jamais appeler une méthode sous iOS qui ne serait pas implémentée sous OS X et vice et versa.

Par contre, cela demande probablement une grande rigueur.

yoann

Le problème de ces bouquins c'est qu'ils sont très génériques et qu'ils ne peuvent donc tenir compte des subtilités d'un language. 

 

Il ne faut pas oublier que le livre Design Pattern du GoF est grandement à  la base de ce qu'est Objective-C / Cocoa. En le lisant tu retrouve bon nombre de paradigme utilisé chez nous (ce n'est pas pour rien que les documentations Apple portant sur l'objet cite ce livre).

 

Entre autre, tu trouvera des architecture d'exemple sur comment faire un seul code portable tournant sur deux système d'affichage différent.

Céroce

Il ne faut pas oublier que le livre Design Pattern du GoF est grandement à  la base de ce qu'est Objective-C / Cocoa.

Certes, mais je ne suis pas sûr qu'il soit très utile, parce qu'Apple a justement déjà  intégré la plupart des patterns dans Cocoa.

yoann

Certes, mais je ne suis pas sûr qu'il soit très utile, parce qu'Apple a justement déjà  intégré la plupart des patterns dans Cocoa.

 

C'est utile pour comprendre comment cocoa est pensé et comment l'étendre correctement.

 

Comme je disais plus haut, pour la problématique des multiples système d'affichage, la meilleur explication que j'ai vu est dans ce livre.

colas_

Par exemple en Cocoa on a le "Toll-Free Bridging" qui peut sérieusement compliquer la vie au niveau héritage et qui oblige bien souvent à  encapsuler plutôt qu'à  hériter. 

 

Pourquoi le Toll-Free Bridging est-il problématique ?

 

(D'ailleurs, personnellement, je ne l'ai jamais utilisé)

Mala

Pourquoi le Toll-Free Bridging est-il problématique ?

 

(D'ailleurs, personnellement, je ne l'ai jamais utilisé)

On ne peut pas hériter de ces classes.