›

UIKit for Mac Development

muqaddarmuqaddar Administrateur
05:30 modifié dans Actualités #1
Un projet brillant ?
http://chameleonproject.org/  :o

Pour ceux qui ne veulent pas pas porter leur soft sur Mac, ça peut être une solution idéale.
A tester. J'ai juste fait un run d'un projet démo.

Réponses

  • SystemSystem
    05:30 modifié #2
    Un projet de merde ouaip... on va encore se ramasser les soft merdique qui existent sur iOS vers le Mac... super.
    Et puis avec Lion qui arrive.. Je dis rien, mais y'a pas mal de changements surtout au niveau des TableView..
  • muqaddarmuqaddar Administrateur
    05:30 modifié #3
    dans 1300817941:

    Un projet de merde ouaip... on va encore se ramasser les soft merdique qui existent sur iOS vers le Mac... super.
    Et puis avec Lion qui arrive.. Je dis rien, mais y'a pas mal de changements surtout au niveau des TableView..


    J'étais sûr que t'allais décoller au quart de tour.
    Moi je dis, en attendant de développer une version spécifique Mac, ça peut toujours être utile.
  • SystemSystem
    05:30 modifié #4
    Y'a plein de choses à  prend en compte... Pour un jeu je dis pas.. Mais pour une application c'est l'erreur totale que d'imaginer qu'il suffira simplement de ça pour réaliser une version Mac. Et c'est pourtant comme ça qu'ils présentent la chose.
  • AliGatorAliGator Membre, Modérateur
    05:30 modifié #5
    +1 pareil que Louka.
    Les projets comme ça ça montre typiquement que y'en a certains qui pensent encore qu'une application sur ordi de bureau et une appli sur iPhone ou sur iPad ont la même ergonomie et le même design...
    Déjà  que c'est pas toujours évident de faire comprendre à  certains qu'une appli iPhone et une appli Android n'ont déjà  pas du tout la même ergonomie...
  • muqaddarmuqaddar Administrateur
    05:30 modifié #6
    Ne pensez pas qu'en termes de projets pour des clients... mais aussi de projets personnels.
    En attendant un développement spécial Mac, ça peut être une bonne solution, y compris pour des entreprises. Quand t'as par exemple une appli iPad et une appli PC, si tu veux une appli Mac... mais que t'as pas les ressources pour le faire. C'est un exemple.
  • muqaddarmuqaddar Administrateur
    05:30 modifié #7
    Et je rajoute qu'il est évident qu'une appli spécialement développée pour le Mac, avec les vraies API Mac, sera forcément meilleure.
  • SystemSystem
    05:30 modifié #8
    Même en projet perso j'exige le meilleur, personnellement  ???
  • muqaddarmuqaddar Administrateur
    05:30 modifié #9
    dans 1300827756:

    Même en projet perso j'exige le meilleur, personnellement  ???


    Et moi j'exige le moins bien, le vite fait, et le mal fait.  :P
  • AliGatorAliGator Membre, Modérateur
    05:30 modifié #10
    Moi aussi je suis un perfectionniste, comme Louka je supporterai pas d'avoir un truc foireux porté par un truc générique
  • CéroceCéroce Membre, Modérateur
    05:30 modifié #11
    dans 1300823687:

    En attendant un développement spécial Mac, ça peut être une bonne solution, y compris pour des entreprises.


    Ton argument me paraà®t très pertinent.
    Du point de vue de l'utilisateur, il vaut mieux un produit moyen maintenant qu'un produit parfait dans deux ans.
    Les logiciels servent à  répondre à  des besoins après tout !

    ça ne m'empêche pas de penser que les IHM portées telles quelles d'iOS à  Mac OS sont une abomination. Utiliser un tel outil de conversion dans un univers très concurrentiel (par exemple, un client Twitter) me semble un calcul risqué.
  • FKDEVFKDEV Membre
    mars 2011 modifié #12
    Moi je trouve que c'est une bonne idée.
    Y'a des tas de choses qui devraient être communes entre UIKit et AppKit.

    Je ne connais pas encore bien le SDK Mac mais j'ai l'impression que le SDK iOS est plus abouti dans la simplicité et le pragmatisme.

    J'aimerais bien qu'Apple fasse le back to Mac pour l'API.

    Il n'y a pas que UIKit, il y a des framework qui n'existent carrément pas sous Mac (comme le MapKit par exemple, c'est certainement pas l'API la plus utile pour des applis desktop mais moi j'aimerais bien l'avoir).
  • AliGatorAliGator Membre, Modérateur
    05:30 modifié #13
    C'est vrai que les touchBegan, les UIGestureRecognizers, et tout ce qui est dans UIKit (pour rappel le framework UIKit c'est celui qui gère toute l'interface... des appareils tactiles (iPhone, iPod, iPad) et les événements qui s'y rapportent) ça manque sur Mac... mais en même temps vous avez des écrans tactiles vous sur vos Macs ?
  • CéroceCéroce Membre, Modérateur
    05:30 modifié #14
    dans 1300892575:

    Je ne connais pas encore bien le SDK Mac mais j'ai l'impression que le SDK iOS est plus abouti dans la simplicité et le pragmatisme.

    C'est souvent vrai. D'ailleurs, ils pourraient commencer par déclarer les propriétés.

    Apple a évité de refaire les mêmes bêtises sur Cocoa Touch que sur Cocoa Mac. Le meilleur exemple est le système de coordonnées qui a son origine dans le coin supérieur gauche sur UIKit, alors qu'elle était dans le coin inférieur gauche sur AppKit. ça n'a l'air de rien, mais ce truc nous pourrit la vie depuis dix ans.
  • DrakenDraken Membre
    05:30 modifié #15
    Beurk.. C'est rectifié sur le SDK MacAppstore ?

  • AliGatorAliGator Membre, Modérateur
    05:30 modifié #16
    Oui par contre je suis d'accord le SDK OSX on sent qu'il date des débuts de Cocoa et Objective-C 1.0, du temps où les @property n'existaient pas et où les @protocol n'avaient pas la possibilité d'avoir des méthodes optionnelles, et ça se ressent un peu partout dans la conception malheureusement.

    Du coup il y a plein de classes qui définissent leur delegate sous la forme de protocoles informels (catégories de NSObject) ce qui est plutôt crade (c'est un peu un hack pour contourner le pb qu'il y avait de ne pas avoir de @protocol avec @optional), plein de classes où on aimerait bien utiliser les @property et la syntaxe pointée pour accéder à  des propriétés des instances au lieu de devoir utiliser les getters... et ça ça me manque quand je retourne sous OSX !
    Au moins qd ils ont commencé iOS, on était déjà  à  ObjC 2.0 et plus 1.0 donc les @protocol @optional et les @property existaient déjà  et ils sont directement partis sur les bonnes bases, il faudrait qu'ils refassent une passe un peu partout sous OSX pour remonter ces bienfaits dans le SDK OSX.
    Ils le font déjà  un peu pour le delegate de certaines classes qui étaient sous forme de protocoles informels et sont passés depuis en protocoles formels, ce qui est bien plus propre et permet au compilo de signaler s'il y a des incohérences, mais c'est pas encore partout
  • DrakenDraken Membre
    05:30 modifié #17
    ça ne donne pas envie.  >:(

  • AliGatorAliGator Membre, Modérateur
    05:30 modifié #18
    La syntaxe pointée, on aime ou on aime pas, mais par contre les formal protocols quelle horreur ! Ca devrait avoir disparu de OSX depuis longtemps !!
    C'est source de plantage en plus car aucune vérification effectuée par le compilateur (il peut pas de toute façon pour ces cas-là ) !
  • muqaddarmuqaddar Administrateur
    05:30 modifié #19
    Si Apple se bougeait les fesses pour implémenter ça sous Lion, ça veut dire aucune possibilité de faire marcher un tel code sous 10.6 ?
  • AliGatorAliGator Membre, Modérateur
    05:30 modifié #20
    Bah bien sûr que non, 10.6 et même avant Objective-C 2.0 existait déjà , ça fait quelques temps qu'il existe et que la version 2 du langage propose les @property et les @protocol @optional. C'est juste que les API n'ont pas été mises à  jour.
    Mais le code que tu crées toi pour OSX tu peux déjà  utiliser les @protocol @optional et les @property.
    Et depuis plusieurs versions de OSX Apple fait progressivement passer des protocoles informels (implémentés sous la forme de catégories de NSObject donc) en protocoles formels de façon tout à  fait transparente. Sauf qu'ils prennent leur temps...

    Par exemple NSApplicationDelegate est un protocole formel depuis 10.6 alors qu'il était informel avant.
    De même pour NSTableViewDelegate, NSXMLParserDelegate et d'autres encore.
  • ezmacezmac Membre
    05:30 modifié #21
    J'ai atterri il y a 10 mois dans le dev. pour iOS.... mais je développe depuis 1988 avec MPW et 4D.
    et je suis du même avis ... vouloir tout mettre dans le même sac c'est se suicider à  feu lent...  car le résultat, est que l'on n'a que le pire de chaque monde ...

    de même ce qui pensent qu'une simple récompilation pour un hypothétique mac avec ARM fera l'affaire !!
  • CéroceCéroce Membre, Modérateur
    05:30 modifié #22
    dans 1306553990:

    de même ce qui pensent qu'une simple récompilation pour un hypothétique mac avec ARM fera l'affaire !!

    Et pourquoi pas ? Après tout, on compile déjà  les applis pour x86 et PowerPC, qu'est-ce qui empêche de le faire pour ARM ?
  • FKDEVFKDEV Membre
    05:30 modifié #23
    J'ai lu quelque part qu'il y avait de plus en plus d'API commune entre iOS et OSX.
    Est-ce qu'il s'agit simplement de nouveau portage vers iOS (type CoreImage) ou bien y'a t-il eu des portages dans l'autre sens dans Lion ?
    (je n'ai pas la licence dev Mac  ::))
Connectez-vous ou Inscrivez-vous pour répondre.