Xcode 4.2
muqaddar
Administrateur
Salut,
Je suis content des petites améliorations présentes ici ou là dans Xcode 4.2 (je n'avais néanmoins pas eu accès à la 4.1).
Xcode 4.x commence à se bonifier avec le temps.
Par exemple, le target visible des actions et des outlets dans le .h est sympa (devant le numéro de la ligne de code).
La partie IB semble progresser un peu également.
Comment trouvez-vous Xcode 4.2 ?
Je suis content des petites améliorations présentes ici ou là dans Xcode 4.2 (je n'avais néanmoins pas eu accès à la 4.1).
Xcode 4.x commence à se bonifier avec le temps.
Par exemple, le target visible des actions et des outlets dans le .h est sympa (devant le numéro de la ligne de code).
La partie IB semble progresser un peu également.
Comment trouvez-vous Xcode 4.2 ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
8--)
j'ai installé la dernière version de xcode (4.2) et j'ai remarqué qu'il était nettement moins bavard que la version 4.0.
En effet, un exemple tout bête.
Sur la version 4.0 si vous essayez de faire [[uneliste objectAtIndex:1] objectForKey:@unecle] et que l'objet dans la liste ne reçoit pas ce message, on avait un plantage avec la stack qui s'affichait dans la log en gras ainsi qu'une explication de l'erreur genre "don't respond to objectForKey".
Par contre sur la version 4.2, il ne me mets plus ça. Ca plante direct et je me retrouve directement sur le main.m ...
Pouvez-vous me dire comment le rendre plus bavard ?
Merci d'avance
PS: je teste sous le simulateur !!
Le sujet a été fusionné à celui-ci.
Je le cherchais partout mon post
Je ne vois pas trop l'intérêt. En tous il faudrait au moins le mettre au niveau "verbose" par défaut.
ah ok.
En fait, je pense qu'il montre le code "utilisateur" le plus profond dans la stack au moment du plantage.
Je pense que c'est pour éviter de perturber les développeurs débutants ou pour qu'ils évitent de dire que "ça plante dans le code d'Apple".
Enfin, ce n'est pas une bonne idée dans les deux cas.
Moi j'ai bien un log dans la console si j'envoie un message qui n'existe pas :
'Unrecognized selector sent to instance 0x8e55750'
Effectivement, je n'ai plus la stack dumpée dans la console, mais ce n'est pas plus mal.
- Genre quand tu oublies de connecter une view dans un XIB, avant il disait un truc du genre : "Main view is not set to controller in XIB file"
- Idem pour les méthodes non présentes, j'ai plus de "Unrecognize selector"
A la place, il plante (normal) et m'affiche mon main()... du coup, je dois pister le bug avec des pointeurs, je perds un temps fou.
Faut les rajouter pour déclarer les outlets, je rate un truc ?
En plus, tu as beau de pas sélectionner ARC, tu te retrouves avec des @autoreleasePool et des (strong, nonatomic) ...
Dans mon scheme, j'ai opté mon LLDB et pas GDB.
Pourquoi faut-il faire cela si on a mis tout le projet en LLVM 3.0 ?
Y-a-t-il un avantage à utiliser un debugger plutôt qu'un autre ?
Moi j'en ai quasiment plus jamais besoin... vu que je ne mets que très très rarement des variables d'instance dans mes classes.
Tout est maintenant migré en @property (et de toute façon les IBOutlets faut les mettre en @property sinon on constate un leak, j'en ai déjà parlé sur les forums), et avec le ModernRuntime (qui existe depuis le début de iOS, d'ailleurs) plus besoin de créer des ivars à associer aux @property, les @property suffisent (y'a que pour MacOSX 32 bits que c'est encore nécessaire vu qu'il utilise le LegacyRuntime). On en a également parlé plusieurs fois dans le forum aussi.
(Les IBOutlets j'ai toujours préféré mettre le mot clé sur la @property même du temps où je déclarais aussi la ivar associée, car la ivar peut avoir un nom "interne" alors que la @property a un nom plus "lisible" visible en tant qu'API publique de la classe, donc autant que l'IBOutlet utilise ce nom plutôt que le nom de l'ivar... et de toute façon vu qu'en fait il n'y a pas besoin de mettre une ivar pour les IBOutlets avec le Modern Runtime...)
Au final dans 90% des cas je n'ai plus besoin de mettre de variables d'instance dans mon .h et donc plus besoin des accolades que j'enlève la plupart du temps.
(Après si ça te gènes tu peux toujours modifier le template des nouveaux fichiers et nouveaux projets mais bon)
Le problème c'est de débuguer.
Je ne mets plus les ivars associées aussi.
Alors j'utilises "po objet_property_name" dans la console, mais c'est limité, surtout si l'objet a des propriétés, impossible de faire "po objet.property" alors que si on déclare l'ivar dans la classe de l'objet, on l'aura. T'as une astuce ?
Donc oui : [tt]po [objet property][/tt] tout simplement.
Après c'est vrai que ça serait un plus que les valeurs des @property s'affichent à côté des variables dans le débogueur (même si je comprend pourquoi ça n'est pas le cas pour les @property qui sont + que juste des conteneurs de variables)
C'est vrai ?
Il s'installe directement depuis les préférences de Xcode (comme pour la doc.).
Encore merci
Par exemple en ce moment je travaille sur du PDF et pour faire un retain sur le document PDF il faut faire :
Comment gérer ça avec des properties ?
CGxxx (CoreGraphics) et CFxxx (CoreFoundation) = C
PS : Qu'est ce que ta question fait dans ce sujet, quel rapport avec Xcode 4.2 ?!
Mais c'est vrai qu'on n'est plus dans l'objet, c'est dommage d'ailleurs qu'Apple oblige encore a faire du C, c'est pas fini leur truc.
L'objective-C n'est qu'une surcouche du C rajoutant les concepts objets.
C'est bien, c'est pratique, c'est plus propre au niveau des concepts etc. Mais ça nécessite le mécanisme d'envoi de message, donc de résolution des selectors et de dispatch de ces messages via [tt]objc_msgSend[/tt]. Pour des choses qui nécessitent des optimisations très fines en particulier pour l'affichage écran, au moment de la phase de composition et de drawing, le C est bien plus efficace.
Donc c'est un choix justifié et tout à fait cohérent.
Après tu peux toujours espérer avoir des wrappers pour certains trucs, en particulier pour faire de la composition offline hors de la boucle de drawing ça peut se défendre. Mais pour le drawing et donc CoreGraphics ça parait plutôt logique d'avoir une API C.
PDFKit ?
Tu dois pouvoir gérer tout ce qui concerne ton objet document avec un PDFDocument que tu "castes" en CGPDFDocument si tu as besoin de méthodes fonctions qui ne sont pas dans le PDFKit. (je dis "tu dois pouvoir" parce que je n'ai pas essayé trouvant mon bonheur avec ce qui est dans le PDFKit)
Ce n'est peut-être pas le bon thread mais c'est très bizarre ce que tu dis car Android a choisi Java, langage objet y compris pour l'API OpenGL semble-t-il. J'en conclu que Objective-C est un mauvais choix puisqu'on ne peut pas l'utiliser de bout en bout. Ce sera peut-être une discussion pour le CocoaHeads de jeudi si je peux venir.
@laudema
je n'ai pas compris ce qu'était PDFKit. C'est dans le SDK ? Moi j'utilise les fonctions C CGPDF du SDK.
En fait j'ai l'impression que PDFKit n'existe que sur Mac, je suis sur iphone.
Et Android a du ajouter le NDK pour une question de vitesse...
Tout comme tu peux faire de la composition avec le PDFKit
C'est juste si tu veux des perfs efficaces qu'il est plus judicieux de passer à du C
Si tu n'es pas capable de faire la bascule il y a toujours des wrappers
Sur Android c'est pareil. Tu as le JDK pour la plupart des trucs, mais si tu as besoin de performances, tu as le NDK. Sauf que ça nécessite de faire une gymnastique avec JNI pour passer du code Java au C et vice-versa (avec la galère de gestion de contexte qui m'avait un peu dégoûté qd j'avais eu à m'y mettre, on a le pire des deux mondes avec JNI dans ce cas là malheureusement en plus d'avoir le meilleur).
Bah sous iOS/OSX c'est pareil, tu as Objective-C, mais si tu as besoin de perfs tu as le C. Sauf que là tu n'as pas besoin de passerelle comme JNI (fait mumuse avec Android et le NDK tu verras tu vas apprécier le mélange ObjC/C après ^^)