Projet mixte iOS et OS X

Bonjour,


 


Je tente de convertir mon programme iPocket Draw (iOS) pour le faire tourner directement sur OS X.


Même en dehors de l'UI, il y a des différences notables.


Par exemple UIFont, UIImage dont les pendants OS X ne fonctionnent pas toujours identiquement.


 


Y-a-t-il une manière élégante (et simple) pour pouvoir conserver un code commun ?


Avec des balises "#if TARGET_OS_IPHONE" et autres ?


Avec Chameleon ?


2 projets différents ?


1 projet avec 2 targets ?


 


Avez-vous déjà  expérimenté cela ?


Quels ont été vos choix ?


 


Réponses

  • muqaddarmuqaddar Administrateur

    Moi, je ferai 2 projets différents plutôt que 2 targets, je pense que c'est sujet à  moins de problème.


    Tu y mets les classes communes (shared) et spécialisées.


    Tu te fais des dossiers sur le HD pour les classes (iOS, Mac, Shared/common) comme ça, ça reste propre.


     


    Après, tu peux te faire des macros persos pour les classes communes qui ont des parties différentes (TARGET_IOS, TARGET_OSX).


  • AliGatorAliGator Membre, Modérateur
    1 projet, 2 targets. Pourquoi s'embêter.

    #define pour les TARGET_IPHONEOS / TARGET_MACOSX
    Ou alors fichiers & classes différentes (voire wrappers avec API commune mais implémentation différente) pour les cas où il y a trop de différences, et tu inclus l'implémentation OSX uniquement dans le target OSX, et l'implémentation iOS uniquement dans le target iOS.
  • J'ai quelques applications qui font iOS / OS X. Pour ma part, les essais de un projet deux target ont toujours fait de la merde. Xcode finissant par ne voir que l'une ou l'autre des cibles de compilation (va builder une app Mac pour la tester sur le simulateur iOS...).


     


    Sinon, globalement, la seule chose réellement réutilisable c'est naturellement ton modèle. La partie vue n'est pas réutilisable même si UIImage ressemble à  NSImage, il y a trop de différence entre le fonctionnement d'UIKit et de AppKit. Et l'ergonomie des applications est totalement différentes, donc dans tous les cas ce serait une mauvaise idée.


     


    Le seul cas où une bonne partie de la vue est réutilisable, c'est si tu travail avec un viewport OpenGL.


  • Joanna CarterJoanna Carter Membre, Modérateur

    Moi, je ferais un workspace, et trois projets.


     


    Un projet pour un framework avec tout ce qui est en commun


    Un projet pour le UI iOS


    Un projet pour le UI OS X


     


    Comme Yoann, je crois qu'en gérant la compilation conditionnelle, tu y trouveras des soucis et des frustrations


  • CéroceCéroce Membre, Modérateur

    Avec Chameleon ?

    J'ai déjà  donné, ça nous avait bien dépanné, mais Chameleon n'évolue plus depuis au moins deux ans (les créateurs sont passés à  autre chose), et il y a de grosses limitations comme l'impossibilité d'ouvrir un xib.
    Pour moi, c'est vraiment une solution de secours, mais beaucoup de problèmes à  moyen terme.

    2 projets différents ?
    1 projet avec 2 targets ?

    Je suis de l'avis de Yoann. J'ai eu également trop de problèmes avec Xcode qui confond souvent les targets.


  • J'ai eu également trop de problèmes avec Xcode qui confond souvent les targets.




     


    Tous mes projets ont plusieurs Targets et aucun souci à  ce niveau, mais jamais travaillé sur des targets OS X et iOS dans le même projet :).

  • Merci à  tous pour vos avis !


     


    Je constate qu'ils sont bien partagés...


     


    Concernant l'UI, j'avais l'intention de bien les distinguer.


    Ma question portait plus sur le code de ma partie dessin et calcul, par exemple dans un objet de dessin "Texte", j'ai plein d'appels à  UIFont que je dois modifier par des appels à  NSFont pour OS X.


    Donc si j'ai bien compris, pour avoir un code commun aux deux OS, je vais devoir utiliser les "#if TARGET_OS_IPHONE" et autres.


    Comme je ne connais pas encore l'utilisation des workspaces, je vais probablement m'orienter vers 2 projets différents avec un dossier de code commun.


     


    Merci encore.



  • Tous mes projets ont plusieurs Targets et aucun souci à  ce niveau, mais jamais travaillé sur des targets OS X et iOS dans le même projet :).




     


    Bien entendu, Céroce et moi parlons de problème avec Xcode lorsqu'on mixe les type de target. Plusieurs target d'un même type ne pose aucun problème.


     


    Et pour info, j'ai eu le problème que ce soit avec plusieurs target dans un projet ou plusieurs projet dans un même workspace.

  • AliGatorAliGator Membre, Modérateur


    Bien entendu, Céroce et moi parlons de problème avec Xcode lorsqu'on mixe les type de target. Plusieurs target d'un même type ne pose aucun problème.


     


    Et pour info, j'ai eu le problème que ce soit avec plusieurs target dans un projet ou plusieurs projet dans un même workspace.




     


    En effet je n'ai pas d'expérience pour ma part entre un projet avec plusieurs targets de cibles / plateformes différentes iOS+OSX, du coup je n'ai jamais eu l'occasion d'avoir ces soucis. Donc je t'invite à  oublier ma recommandation de "1 projet 2 target" qui était sur la base de mon expérience mono-plateforme et suivre celle de yoann et de Céroce.

  • CéroceCéroce Membre, Modérateur
    En fait, rien ne dit que ces problèmes n'ont pas été corrigés dans Xcode 6 ! Mais j'en doute quand même.
  • muqaddarmuqaddar Administrateur


    Je suis de l'avis de Yoann. J'ai eu également trop de problèmes avec Xcode qui confond souvent les targets.




     


    Idem, d'où ma première réponse.

  • Joanna CarterJoanna Carter Membre, Modérateur

    N'oublies pas que c'est possible d'ajouter le même fichier à  multiples projets


  • AliGatorAliGator Membre, Modérateur

    Sinon fais des pods aussi, c'est l'idéal pour ce genre de cas.


     


    Par exemple si tu as tout un composant / bout de ton application qui regroupe tes classes métier, tes algos, etc... bref tout ton moteur générique (une sorte de "PocketDrawKit"), tu peux faire un genre de framework, le plus simple étant d'utiliser CocoaPods (en attendant que iOS8 soit utilisé assez largement avec le support des frameworks dynamiques)


     


    Tu fais tes classes, tu fais un PocketDrawKit.podspec qui va lister tous les fichiers sources à  mettre dans ton PocketDrawKit, et tu mets ensuite à  la fois dans ton Podfile du projet OSX et ton Podfile du projet iOS que tu veux utiliser le pod "PocketDrawKit".


     


    (Note que tu n'es pas obligé de publier ce pod PocketDrawKit sur CocoaPods en public, tu peux tout à  fait le garder en local et le référencer dans tes Podfiles par un chemin local)


     


     


    Avantages principaux : Intégration automatique, mais surtout Gestion de version sur ton "composant interne" PocketDrawKit (si tu le fais évoluer, et que tu bosses sur ton app OSX en priorité mais n'a pas le temps de migrer l'app iOS tout de suite vers la nouvelle version de ton kit, c'est pas un problème), contrairement à  si tu copies directement à  la main ton fichier dans les 2 projets (où tu ne pourras pas avoir 2 versions à  vivre en même temps et que si tu changes des choses dans tes classes de ton PocketDrawKit il faudra tout de suite dans la foulée à  la fois changer le code de ton projet OSX et de ton projet iOS pour qu'ils continuent à  compiler, contrainte que tu n'auras pas avec de la gestion de version)


  • Encore merci à  tous !


     


    Je vais étudier tout ça.

  • Il ya une session de wwdc sur le sujet (en 2013, en 2014 je ne sais pas), mais elle ne contient pas de remède miracle.

    Pour certaines classes, le simple fait de remplacer UI par NS peut être suffisant, dans ce cas tu peux faire un #define sur le nom de la classe en fonction du type de target.
Connectez-vous ou Inscrivez-vous pour répondre.